Wait until you try to load a DNSSEC signed zone of.com size - you'll recollect with fondness those days when the unsigned zone used to load in mere hours.
The mongo servers of the mongo zones (.com/.net/.org/.de) are moving towards being based on databases and do not need to go through a full reload when the zone contents are changed.
The root zone, however, is so small that it reloads in the blink of an eye.
Let's see if I can deal with at least some of 'em.
First, regarding use of data on a CD/DVD to recover locally - this is for use when a community is cut off, as happened here in Santa Cruz in 1989 when we have a medium sized earthquke. There were enough folks here with enough gear that we could rebuild a local, usable net to assist with recovery even though the links over the mountain to the rest of the world took a while to be restorred. In that situation the folks who risked any bad information that might be introduced were those who knowingly changed the hints addresses, and if they knew enough to do that they also probably knew enough to clear things out (i.e. reboot named) when they changed the hints file back to the global values.
I've actually experienced the introduction of bad DNS data. Before ICANN permitted its version of.biz there was already an operational.biz. I had some machines that were using the ICANN version and some using the pre-existing version. And yes, there were some confusions. The point to draw is not that the idea is thereby necessarily bad, but rather that consistency is important. But DNS never operates with perfect consistency - for example for years Taiwan (.tw) was operating with its own roots that were hacked into the system in a really strange way. I was the only one who noticed. (The situation was corrected last year after we [ICANN] pointed it out to them - it turned out that it was an experiment that they forgot to turn off.)
As for the location of the big TLD servers (such as those for.com). Well, the folks at Verisign, much as we like to dislike 'em, are smart and have more than a lot of "clue". Yes, for a while two root servers sat in the same room, but things like that are past history. No, I do not know the actual locations (I intentionally chose not to use my position at ICANN to try to learn that information), but I can assure you that the concept of physical separation has become an article of faith. And with the increasing use of anycast, replica servers are getting easier to deploy.
As for the reputation value of an attack - yup, some perverse folks would feel their reputations enhanced if they brought down DNS. And for that reason I feel that all the armor plating is good. But we need to recognize the gaps in that armor, which are things like routing or mindless belief that there must be one catholic system of DNS root servers. And we have to remember that a lot of bad things are caused by mother nature and Murphy's law rather than folks who have abandoned reasoned discourse and moved to techno-mayhem.
Microsoft - or SCO (if it had the cash) - could go out and try to buy all the root servers. There is nothing to stop the root operators from selling out.
Nor is there anything that prevents root server operators from giving preference to queries coming from paying IP addresses.
All of that is hypothetical, but without legally enforceable obligations, we're just hoping that nothing changes for the worse.
And things *do* change - for example, back in the 1980's SCO was a fun company here in Santa Cruz.
Many of the root server operators have deployed mirrors of their machines using "anycast".
Anycast is a way of using routing information so that a single IP address appears at many locations on the net. Packets flowing to an anycast IP address tend to go to the nearest instance of such an address.
Physical security isn't the risk that the roots face - the issue is damaged connectivity to those 13 addresses on which those root machines are to be found.
As I mentioned in my note on Circle-ID, the biggest risk isn't to root servers but rather to the set of servers that deliver.com,.net,.org, and.in-addr.arpa. The roots are heavily cached and easily replicated. It isn't quite so easy to handle a loss of connectivity to the big top level domain servers.
I've suggested a "DNS on a CDROM" (which I guess should be updated to "DNS on a DVD") in which all the stuff needed to get a local but limited DNS running in cases when a community has been cut off from the main body of DNS services.
I've been publishing SPF records for the cavebear.com domain for about two months now.
I've only done the publishing side, I have not yet enabled my mail servers to use them.
Even though SPF may not be a complete or perfect solution, I see no harm in announcing to the world that if it purports to come from my domain than it also comes from my designated mail servers.
Netbios did not come from Microsoft, it came from Sytek. They built a broadband LAN system way back in the early 1980's. The chief designers of Netbios were folks like Greg Ennis and Mark Gang. A lot of the semantics of netbios were dictated by the particular characteristics of Sytek's broadband system and by the need to squish the entire system into just a couple K bytes of ROM.
RFC1001/1002 (Netbios over TCP) came out in early 1987 (mea culpa). I do not believe that anyone from Microsoft participated in that RFC work.
I'd suggest John Romkey (author of PC/IP and one of the two original Internet toasters), Phil Karn (KA9Q), Louis Pouzin (I probably misspelled that), Don Davies. Mike St. Johns, Jake Feinler, Bob Braden, Milo, Jun Murai, Marshall Rose, Dave Mills, Dave Farber, Dave Clark, Jerry Saltzer, Noel Chiappa, Steve Casner, Dan Lynch, Radia Pearlman... and many many others. One more than a few occassions siblings were involved - Judy and Deborah Estrin, and the Lyons brothers come to mind.
Carl Malamud's 1992 book, "Exploring the Internet" has a lot of anecdotes and a few photos.
If ICANN has been centric around any principles it is these:
- Protection of trademarks beyond that enacted by any legislature anywhere in the world.
- Protection of trademarks beyond that enacted by any legislature anywhere in the world.
(Yes, I wrote that twice, on purpose)
- Exclusion of any but those who make money from the internet from its policy making forums (users, since they merely pay money, are relegated to the peanut gallery.)
- Generate lots and lots of fees for the law firm that created it.
ICANN's US/EU centricity is merely an ancillary kind of centricitiy.
The ITU does have many of the same closed door problems as does ICANN. But the ITU's people seem to have some conception that the door is closed and that it was wrong to do it. ICANN, on the other hand, is very proud of its door slamming abilities.
The ITU and ICANN are both captured by those entities that they purport to regulate, and both ICANN and the ITU have procedures that are full of twisty turny passages that all look the same. ICANN, according to its reconsideration committee is as infallible as the Pope.
The ITU pushed OSI and failed - ICANN pushed the UDRP and succeeded. OSI, overly complicated as it was, did at least contain many good technical ideas yet to be mined in more purified and streamlined form. The UDRP on the other hand is unmittigated dross.
So, it's a close toss up. It's often said that the devil we know is better than the devil we don't. Well, we know the ITU devil and the ICANN devil both pretty well.
My personal choice would be for ICANN - but only, and this is a big only, if they allow for 51% or more of the seats on its Board of Directors to be directly elected by the public and retract the UDRP as being an improper usurpation of the role of national legislatures.
Verisign is playing a cat and mouse game with the US Dept of Commerce (NTIA) and ICANN.
As I see it, Verisign is building a portfolio of legal positions that it will be using in what I belive is almost certain litigation between Verisign and ICANN and possibly involving the US Department of Commerce?
- Verisign is trying to engender a sufficient number of statements by technical experts that it can convince a judge that there is really a technical debate and that thus the judge ought to stay out of the matter.
- It is trying to come up with enough anecdotal evidence that the internet isn't broken by sitefinder. Of course, those anecdotes are from a point of view, such as that of the typical mom and pop user, that is unlikely to perceive the real damage that has been caused. But we have to remember that most people who use the net, including most judges and lawyers, see the net in that same, technially naive, way.
- It is trying to expose the fact that the US Department of Commerce never articulated, and may not have, any authority to have done what it has done in these areas and that thus it has no authority over Verisign.
- It is trying to use the previous item to undermine ICANN's authority. And ICANN's authority is far from clear: a) the contracts ICANN uses are very, very complicated (and like many complicated things, may be full of holes) b) ICANN's claims of "consensus" are far from broadly established, particularly given ICANN's explusion of the broad community of internet users from its decision making forums.
- It is trying to establish that if there is any harm to the net, it is not of such an immediate and overwhelming nature that it has to be restrained during any legal proceedings. (Verisign would, of course, reap the financial proceeds of sitefinder during those proceedings - thus giving it a cash flow to finance the litigation. ICANN's pockets are not so deep and it is not in a position to outspend Verisign.)
So, the DNS wildcarding part of sitefinder may be turned off for the moment, but I think that is merely a tactical move on Verisign's part.
Yes! My IBM Thinkpads run much warmer, in fact they get positively hot, when setiathome is running - to the point where the fan is on almost constantly. I no longer run setiathome on laptops.
Also, I have several dual-Xeon boxes. These become noticably warmer when running setiathome than when running relatively idle.
Verisign gets $6 each year for each and every registration in.com and.net no matter who you "buy" the name from.
This $6 amount was fixed into the contract under which ICANN (with the help of the US Dept of Commerce) gifted.com unto Verisign effectively in perpetuity (infinite renewals unless Versign does something very, very bad). There are no provisions in the contract to drive that amount to a lower amount. I voted against that contract.
I've been using a 3Ware 7504 with in a 4 drive RAID 5 for about a year.
The card was solid until about a week ago - then it blew chunks, claiming that it suddenly didn't like the motherboard's bios. It took several days to jump through 3Ware's web-page-based RMA mish-mosh.
It's clear to me that 3Ware doesn't really understand the "I need it NOW!" aspect of running 24x7 servers. So I'd suggest considering buying a spare card or having a second running card that can be cannibalized.
I'm running the Linux drivers (Red Hat 9) for the card and they seem solid enough.
The BIOS level support on the 7504 is more than a bit weak - it is positively limp. There's no ability at the 7504 BIOS level to do the things you want to do when things are broken, like rebuilding the array.
Also - 3Ware controllers don't take kindly to simply powering off the machine - graceful shutdown is necessary to avoid a long array verification (and fsck) when coming back up.
The server is still there, it never died, nor did the link ever get beyond about 20% until the last half hour (and it's some other traffic flow that's burning the bits.) And the log files are full of 200 - good transfer - indicators
So if you saw an outage, it was probably on the path, not the server. (Which, by the way is an older 800mhz Athlon box running Red Hat 9 with most of the updates.)
The unit of blocking may very well fall along the basic proposed unit of IPv6 allocation - the/48 prefix.
Sure, that potentially leaves 2**80 such blocks - a number that I've heard is akin to the number of electrons in the universe.
But we'll probably find that the IPv6 space is, like the IPv4 space, carved up, significantly reducing the number of really usable address blocks.
You are right in that the result will still be a huge number - and it seems that it is big enough to accomodate some lossage - but then again, we once thought that the oceans were too big to be polluted.
The machine is old - but the system isn't that out of date. It's Red Hat 9 with most of the patches applied. I'm running kernel 2.6-test4 on some of my other machines.
My access link is running at nearly 100% right now.
The posting of the text at the start of this thread cut off a couple of lines at the end.
There are certain aspects of DNSSEC that are infrequently discussed.
First is that DNSSEC adds a degree of rigidity and inter-dependency to the net that makes it more brittle in the face of a natural or intentional disaster. When things have fallen apart, the time to recover is greatly increased if the rebuilders have to rebuild the security hierarchy before names can start resolving.
Another aspect is that DNSSEC tends to wire-in a single DNS root and wire-out competing roots.
Now, a lot of people think that competing roots are a horrible thing. And a lot of other people think they are a great thing. (I've been using competing roots for years with zero problems, so you can guess which camp I'm in.) And some communities (AOL) and countries, are not necessarily making noises that they really like the idea of one god-like root for DNS. (They want consistency, their concern is about there being a single authority.) Competing roots are also advocated as a way to escape captured regulatory bodies, such as ICANN.
For some of the big zones -.com - I have heard that DNSSEC can make it take a very long time to come up after a change in zone contents. That's sort of having to wait for fsck to complete on a 500gigabyte disk every time you want to change a file in the filesystem.
In response to the statement: "Even if electronic voting machines can be made to work (this requires open-source software,..."
We ought to remember Ken Thompson's famous ACM lecture about how he might have hidden a trojan horse in the Unix login program by buggering a version of the C compiler so that it could not have been found by inspection of the source code.
The US military wants to make sure that US servicemen/women overseas can vote. That's not a bad thing and there is a US law that requires this.
But there is a bad thing - the system they are promoting runs on MS Windows - including Win 95/98 - using Internet Explorer (5.5 and up) and Netscape.
Somehow they have in their minds that if they run HTTPS and require anti-virus software that the machines will be secure enough so that votes made through those machines won't be buggered.
Oh, and did I mention that the voter registration occurs through the same machines and same web-browser/https mechanisms?
Seems to me that this is a recipie for disaster - I don't consider any operating system safe from tampering, particularly none of the MS products. And these machines will likely be shared by many people, configured by DHCP (itself a security risk), perhaps with programs being loaded over insecure nets from insecure file servers, and crossing the internet via web proxies, "transparent" web caches, WCCP, and who knows what else.
Don't feel sorry for PeopleSoft or its CEO. In my opinion there is little within the bounds of legality that Ellison or Oracle could do to him or to PeopleSoft (whose board chose to hire him) that would be so bad that it would be beyond a kind of karmic what-goes-around-comes-around kind of payback.
It's become pretty clear that the US Dep't of Commerce likes ICANN the way it is. The Dept of Commerce can pretend it has authority over the Internet via ICANN (despite having absolutely no statutory authority granting the DoC the ability to do what it is doing), and because ICANN is nominally "private", the DoC can do a shell game of exercising authority when it wants authority and evading responsibility when it does not want responsibility.
The real shame of ICANN is not ICANN - although there is more than enough in that swamp alone - but, rather, in the way that the US government, in the form of the US Dept of Commerce, has abandoned principles of Constitutional and administrative law. Congress is only slightly less to blame for letting the executive branch (which is where one finds the Dep't of Commerce) get away with it.
It costs a signifcant amount of money to run around the world to rebut ICANN's paid mouthpieces. ICANN's president, who was in Geneva on Wednesday, had been in Taiwan only a couple of days before - all on ICANN's (and thus indirectly, your) tab. ICANN's travel budget is utterly amazing. But that travel fund is available only to those who kow tow to ICANN's management.
I was amused at ICANN director Hans Kr...'s comment that my submission was merely my personal opinion. ICANN's board has never voted on the policy put into place by ICANN's "staff" in which ICANN holds ccTLDs out to dry unless they sign contracts with ICANN. Al Capone in Chicago also probably never formally announced his "protection" racket, but it didn't take much insight to recognize that it was, in fact, there.
Slashdot Mirror
Wait until you try to load a DNSSEC signed zone of .com size - you'll recollect with fondness those days when the unsigned zone used to load in mere hours.
The mongo servers of the mongo zones (.com/.net/.org/.de) are moving towards being based on databases and do not need to go through a full reload when the zone contents are changed.
The root zone, however, is so small that it reloads in the blink of an eye.
You raise a number of really good points.
.biz there was already an operational .biz. I had some machines that were using the ICANN version and some using the pre-existing version. And yes, there were some confusions. The point to draw is not that the idea is thereby necessarily bad, but rather that consistency is important. But DNS never operates with perfect consistency - for example for years Taiwan (.tw) was operating with its own roots that were hacked into the system in a really strange way. I was the only one who noticed. (The situation was corrected last year after we [ICANN] pointed it out to them - it turned out that it was an experiment that they forgot to turn off.)
.com). Well, the folks at Verisign, much as we like to dislike 'em, are smart and have more than a lot of "clue". Yes, for a while two root servers sat in the same room, but things like that are past history. No, I do not know the actual locations (I intentionally chose not to use my position at ICANN to try to learn that information), but I can assure you that the concept of physical separation has become an article of faith. And with the increasing use of anycast, replica servers are getting easier to deploy.
Let's see if I can deal with at least some of 'em.
First, regarding use of data on a CD/DVD to recover locally - this is for use when a community is cut off, as happened here in Santa Cruz in 1989 when we have a medium sized earthquke. There were enough folks here with enough gear that we could rebuild a local, usable net to assist with recovery even though the links over the mountain to the rest of the world took a while to be restorred. In that situation the folks who risked any bad information that might be introduced were those who knowingly changed the hints addresses, and if they knew enough to do that they also probably knew enough to clear things out (i.e. reboot named) when they changed the hints file back to the global values.
I've actually experienced the introduction of bad DNS data. Before ICANN permitted its version of
As for the location of the big TLD servers (such as those for
As for the reputation value of an attack - yup, some perverse folks would feel their reputations enhanced if they brought down DNS. And for that reason I feel that all the armor plating is good. But we need to recognize the gaps in that armor, which are things like routing or mindless belief that there must be one catholic system of DNS root servers. And we have to remember that a lot of bad things are caused by mother nature and Murphy's law rather than folks who have abandoned reasoned discourse and moved to techno-mayhem.
Microsoft - or SCO (if it had the cash) - could go out and try to buy all the root servers. There is nothing to stop the root operators from selling out.
Nor is there anything that prevents root server operators from giving preference to queries coming from paying IP addresses.
All of that is hypothetical, but without legally enforceable obligations, we're just hoping that nothing changes for the worse.
And things *do* change - for example, back in the 1980's SCO was a fun company here in Santa Cruz.
Many of the root server operators have deployed mirrors of their machines using "anycast".
.com, .net, .org, and .in-addr.arpa. The roots are heavily cached and easily replicated. It isn't quite so easy to handle a loss of connectivity to the big top level domain servers.
Anycast is a way of using routing information so that a single IP address appears at many locations on the net. Packets flowing to an anycast IP address tend to go to the nearest instance of such an address.
Physical security isn't the risk that the roots face - the issue is damaged connectivity to those 13 addresses on which those root machines are to be found.
As I mentioned in my note on Circle-ID, the biggest risk isn't to root servers but rather to the set of servers that deliver
I've suggested a "DNS on a CDROM" (which I guess should be updated to "DNS on a DVD") in which all the stuff needed to get a local but limited DNS running in cases when a community has been cut off from the main body of DNS services.
I've been publishing SPF records for the cavebear.com domain for about two months now.
I've only done the publishing side, I have not yet enabled my mail servers to use them.
Even though SPF may not be a complete or perfect solution, I see no harm in announcing to the world that if it purports to come from my domain than it also comes from my designated mail servers.
Netbios did not come from Microsoft, it came from Sytek. They built a broadband LAN system way back in the early 1980's. The chief designers of Netbios were folks like Greg Ennis and Mark Gang. A lot of the semantics of netbios were dictated by the particular characteristics of Sytek's broadband system and by the need to squish the entire system into just a couple K bytes of ROM.
RFC1001/1002 (Netbios over TCP) came out in early 1987 (mea culpa). I do not believe that anyone from Microsoft participated in that RFC work.
Some names (and photos) seem to be missing.
... and many many others. One more than a few occassions siblings were involved - Judy and Deborah Estrin, and the Lyons brothers come to mind.
I'd suggest John Romkey (author of PC/IP and one of the two original Internet toasters), Phil Karn (KA9Q), Louis Pouzin (I probably misspelled that), Don Davies. Mike St. Johns, Jake Feinler, Bob Braden, Milo, Jun Murai, Marshall Rose, Dave Mills, Dave Farber, Dave Clark, Jerry Saltzer, Noel Chiappa, Steve Casner, Dan Lynch, Radia Pearlman
Carl Malamud's 1992 book, "Exploring the Internet" has a lot of anecdotes and a few photos.
If ICANN has been centric around any principles it is these:
- Protection of trademarks beyond that enacted by any legislature anywhere in the world.
- Protection of trademarks beyond that enacted by any legislature anywhere in the world.
(Yes, I wrote that twice, on purpose)
- Exclusion of any but those who make money from the internet from its policy making forums (users, since they merely pay money, are relegated to the peanut gallery.)
- Generate lots and lots of fees for the law firm that created it.
ICANN's US/EU centricity is merely an ancillary kind of centricitiy.
The ITU does have many of the same closed door problems as does ICANN. But the ITU's people seem to have some conception that the door is closed and that it was wrong to do it. ICANN, on the other hand, is very proud of its door slamming abilities.
The ITU and ICANN are both captured by those entities that they purport to regulate, and both ICANN and the ITU have procedures that are full of twisty turny passages that all look the same. ICANN, according to its reconsideration committee is as infallible as the Pope.
The ITU pushed OSI and failed - ICANN pushed the UDRP and succeeded. OSI, overly complicated as it was, did at least contain many good technical ideas yet to be mined in more purified and streamlined form. The UDRP on the other hand is unmittigated dross.
So, it's a close toss up. It's often said that the devil we know is better than the devil we don't. Well, we know the ITU devil and the ICANN devil both pretty well.
My personal choice would be for ICANN - but only, and this is a big only, if they allow for 51% or more of the seats on its Board of Directors to be directly elected by the public and retract the UDRP as being an improper usurpation of the role of national legislatures.
Verisign is playing a cat and mouse game with the US Dept of Commerce (NTIA) and ICANN.
As I see it, Verisign is building a portfolio of legal positions that it will be using in what I belive is almost certain litigation between Verisign and ICANN and possibly involving the US Department of Commerce?
- Verisign is trying to engender a sufficient number of statements by technical experts that it can convince a judge that there is really a technical debate and that thus the judge ought to stay out of the matter.
- It is trying to come up with enough anecdotal evidence that the internet isn't broken by sitefinder. Of course, those anecdotes are from a point of view, such as that of the typical mom and pop user, that is unlikely to perceive the real damage that has been caused. But we have to remember that most people who use the net, including most judges and lawyers, see the net in that same, technially naive, way.
- It is trying to expose the fact that the US Department of Commerce never articulated, and may not have, any authority to have done what it has done in these areas and that thus it has no authority over Verisign.
- It is trying to use the previous item to undermine ICANN's authority. And ICANN's authority is far from clear: a) the contracts ICANN uses are very, very complicated (and like many complicated things, may be full of holes) b) ICANN's claims of "consensus" are far from broadly established, particularly given ICANN's explusion of the broad community of internet users from its decision making forums.
- It is trying to establish that if there is any harm to the net, it is not of such an immediate and overwhelming nature that it has to be restrained during any legal proceedings. (Verisign would, of course, reap the financial proceeds of sitefinder during those proceedings - thus giving it a cash flow to finance the litigation. ICANN's pockets are not so deep and it is not in a position to outspend Verisign.)
So, the DNS wildcarding part of sitefinder may be turned off for the moment, but I think that is merely a tactical move on Verisign's part.
Yes! My IBM Thinkpads run much warmer, in fact they get positively hot, when setiathome is running - to the point where the fan is on almost constantly. I no longer run setiathome on laptops.
Also, I have several dual-Xeon boxes. These become noticably warmer when running setiathome than when running relatively idle.
Verisign gets $6 each year for each and every registration in .com and .net no matter who you "buy" the name from.
.com unto Verisign effectively in perpetuity (infinite renewals unless Versign does something very, very bad). There are no provisions in the contract to drive that amount to a lower amount. I voted against that contract.
This $6 amount was fixed into the contract under which ICANN (with the help of the US Dept of Commerce) gifted
You've got your history wrong. Modems existed long before ISDN.
Not all ISDN is a price rip off, there are apparently some tarifs for it in the US that undercut regular POTS prices.
ISDN was simply too complicated, too late, and too slow.
The server that died was not my own - it was Circle ID's. My own machines have been happily running throughout.
If you want to know more about who I am check out my web pages at http://www.cavebear.com/" You can find the original version of my note in my blog.
I've been using a 3Ware 7504 with in a 4 drive RAID 5 for about a year.
The card was solid until about a week ago - then it blew chunks, claiming that it suddenly didn't like the motherboard's bios. It took several days to jump through 3Ware's web-page-based RMA mish-mosh.
It's clear to me that 3Ware doesn't really understand the "I need it NOW!" aspect of running 24x7 servers. So I'd suggest considering buying a spare card or having a second running card that can be cannibalized.
I'm running the Linux drivers (Red Hat 9) for the card and they seem solid enough.
The BIOS level support on the 7504 is more than a bit weak - it is positively limp. There's no ability at the 7504 BIOS level to do the things you want to do when things are broken, like rebuilding the array.
Also - 3Ware controllers don't take kindly to simply powering off the machine - graceful shutdown is necessary to avoid a long array verification (and fsck) when coming back up.
In case anyone wants to read the original paper on this it's at:
l o-TheBlockerTag.pdf
http://theory.lcs.mit.edu/~rivest/JuelsRivestSzyd
Ah I see the problem - the /. article points to a copy of my original article on another site's server. That server apparently got squished.
m l
The original URL, on my own server, is:
http://www.cavebear.com/cbblog-archives/000051.ht
The server is still there, it never died, nor did the link ever get beyond about 20% until the last half hour (and it's some other traffic flow that's burning the bits.) And the log files are full of 200 - good transfer - indicators
So if you saw an outage, it was probably on the path, not the server. (Which, by the way is an older 800mhz Athlon box running Red Hat 9 with most of the updates.)
The unit of blocking may very well fall along the basic proposed unit of IPv6 allocation - the /48 prefix.
Sure, that potentially leaves 2**80 such blocks - a number that I've heard is akin to the number of electrons in the universe.
But we'll probably find that the IPv6 space is, like the IPv4 space, carved up, significantly reducing the number of really usable address blocks.
You are right in that the result will still be a huge number - and it seems that it is big enough to accomodate some lossage - but then again, we once thought that the oceans were too big to be polluted.
The machine is old - but the system isn't that out of date. It's Red Hat 9 with most of the patches applied. I'm running kernel 2.6-test4 on some of my other machines.
My access link is running at nearly 100% right now.
The posting of the text at the start of this thread cut off a couple of lines at the end.
There are certain aspects of DNSSEC that are infrequently discussed.
.com - I have heard that DNSSEC can make it take a very long time to come up after a change in zone contents. That's sort of having to wait for fsck to complete on a 500gigabyte disk every time you want to change a file in the filesystem.
First is that DNSSEC adds a degree of rigidity and inter-dependency to the net that makes it more brittle in the face of a natural or intentional disaster. When things have fallen apart, the time to recover is greatly increased if the rebuilders have to rebuild the security hierarchy before names can start resolving.
Another aspect is that DNSSEC tends to wire-in a single DNS root and wire-out competing roots.
Now, a lot of people think that competing roots are a horrible thing. And a lot of other people think they are a great thing. (I've been using competing roots for years with zero problems, so you can guess which camp I'm in.) And some communities (AOL) and countries, are not necessarily making noises that they really like the idea of one god-like root for DNS. (They want consistency, their concern is about there being a single authority.) Competing roots are also advocated as a way to escape captured regulatory bodies, such as ICANN.
For some of the big zones -
In response to the statement: "Even if electronic voting machines can be made to work (this requires open-source software, ..."
We ought to remember Ken Thompson's famous ACM lecture about how he might have hidden a trojan horse in the Unix login program by buggering a version of the C compiler so that it could not have been found by inspection of the source code.
See: http://www.acm.org/classics/sep95/
The US military wants to make sure that US servicemen/women overseas can vote. That's not a bad thing and there is a US law that requires this.
But there is a bad thing - the system they are promoting runs on MS Windows - including Win 95/98 - using Internet Explorer (5.5 and up) and Netscape.
Somehow they have in their minds that if they run HTTPS and require anti-virus software that the machines will be secure enough so that votes made through those machines won't be buggered.
Oh, and did I mention that the voter registration occurs through the same machines and same web-browser/https mechanisms?
Seems to me that this is a recipie for disaster - I don't consider any operating system safe from tampering, particularly none of the MS products. And these machines will likely be shared by many people, configured by DHCP (itself a security risk), perhaps with programs being loaded over insecure nets from insecure file servers, and crossing the internet via web proxies, "transparent" web caches, WCCP, and who knows what else.
This could make Florida 2000 look like a picnic.
Don't feel sorry for PeopleSoft or its CEO. In my opinion there is little within the bounds of legality that Ellison or Oracle could do to him or to PeopleSoft (whose board chose to hire him) that would be so bad that it would be beyond a kind of karmic what-goes-around-comes-around kind of payback.
It's become pretty clear that the US Dep't of Commerce likes ICANN the way it is. The Dept of Commerce can pretend it has authority over the Internet via ICANN (despite having absolutely no statutory authority granting the DoC the ability to do what it is doing), and because ICANN is nominally "private", the DoC can do a shell game of exercising authority when it wants authority and evading responsibility when it does not want responsibility.
The real shame of ICANN is not ICANN - although there is more than enough in that swamp alone - but, rather, in the way that the US government, in the form of the US Dept of Commerce, has abandoned principles of Constitutional and administrative law. Congress is only slightly less to blame for letting the executive branch (which is where one finds the Dep't of Commerce) get away with it.
I have suggested reforming ICANN - not the pseudo reform that ICANN has gone through. See my notes at http://www.cavebear.com/rw/apfi.htm
It costs a signifcant amount of money to run around the world to rebut ICANN's paid mouthpieces. ICANN's president, who was in Geneva on Wednesday, had been in Taiwan only a couple of days before - all on ICANN's (and thus indirectly, your) tab. ICANN's travel budget is utterly amazing. But that travel fund is available only to those who kow tow to ICANN's management.
I was amused at ICANN director Hans Kr...'s comment that my submission was merely my personal opinion. ICANN's board has never voted on the policy put into place by ICANN's "staff" in which ICANN holds ccTLDs out to dry unless they sign contracts with ICANN. Al Capone in Chicago also probably never formally announced his "protection" racket, but it didn't take much insight to recognize that it was, in fact, there.