The major TLDs (.com,.net, etc) are relatively safe, since any changes would likely be difficult to get through - with any changes quickly noticed... as in within minutes, or even seconds; likely wouldn't even be that effective, since the most popular TLDs zone dns entries are heavily cached.
However, ccTLDs are a different story completely, since ccTLD zone name server changes are more common and thus such change requests would be far less scrutinized.
I've never heard of any TLD being hijacked, but could likely be easily done, since the social engineering involved would be very similar.
Changes to TLD nameservers need to pass human inspection at the IANA, human inspection at the US Department of Commerce, and human inspection at Verisign (who provide maintenance for the root zone). This is in stark contrast to the largely mechanical process by which domains in gTLD and ccTLD registries are modified.
Requests to change entire NS sets (as opposed to simply dropping a couple and adding a couple of other nameservers) are typically stalled early in the process while the IANA requests justification for why the entire set is being changed at once.
Hijacking a TLD would require a lot more social engineering than your note suggests.
This has nothing to do with the root servers. The slashdot article is inaccurate.
Verisign are publishing delegations in the DNS from their registry for the COM and NET domains much more frequently than they were before. The TTL on records in the COM and NET zones is not changed.
The affected nameservers are a.gtld-servers.net through m.gtld-servers.net. These are not root servers. They are authority servers for the COM and NET zones.
Verisign also runs two root servers (a.root-servers.net and j.root-servers.net). There has been no announced change in the way A and J are being run.
Not a standard. RFC 1644 is classed experimental; it's not a standards-track protocol. See
The Internet Standards Process (RFC 2026). The claim in the story leader that Microsoft were somehow ignoring RFCs looks, uh, foolish though, which is the point you were making.
If you're using a single TCP session to transfer the data, and your transmit and receive windows are not set appropriately large, or if the hardware you are using is under-spec, then sure.
On the other hand if you transferred the data in some other way (in parallel over multiple TCP sessions, or over UDP), you could exceed 400Mbit/s trivially. I saw nothing in the release which suggested a single TCP session was used.
The Internet2 people are just trying to promote their network as somehow record-breaking, when in fact many commercial "Internet1" networks are years ahead of them.
It also seems odd to brag so loudly about a sustained transfer of 400Mbit/s between North America and Europe. That's really not particularly fast.
There are plenty of ISPs with multiple 10Gbit/s circuits across the Atlantic, and within Europe and North America, and they all sell colo on dedicated gigabit ethernet. Speed record my ass.
actually mr. slashbot that's wrong. you see, out here in the real world, we're able to run a 5,000 machine windows network with practically NO infections due to a simple email filtering software package. guess you're the moron now.
You run 5000 windows machines, and you're calling me a moron?
Of course, now it's 2002, and the dream of universal display / printing remains only partly realized; PDFs really have helped to narrow the gap between dream and reality, though.
NeXTStep realised that dream, as does Mac OS X. Apple is now the largest Unix OS vendor on the planet, so it's fair to say that the majority of Unix systems now realise this dream.
If we discount Windows users, on the basis that they are not qualified to make informed decisions about anything (or else they wouldn't be using Windows) it looks like that dream has been mainly realised, in fact.
Slashdot Mirror
For the record:
There's really no reason to drag Cowboy into your rhetoric; your own writing is surely sufficient.
The major TLDs (.com, .net, etc) are relatively safe, since any changes would likely be difficult to get through - with any changes quickly noticed ... as in within minutes, or even seconds; likely wouldn't even be that effective, since the most popular TLDs zone dns entries are heavily cached.
However, ccTLDs are a different story completely, since ccTLD zone name server changes are more common and thus such change requests would be far less scrutinized.
I've never heard of any TLD being hijacked, but could likely be easily done, since the social engineering involved would be very similar.
Changes to TLD nameservers need to pass human inspection at the IANA, human inspection at the US Department of Commerce, and human inspection at Verisign (who provide maintenance for the root zone). This is in stark contrast to the largely mechanical process by which domains in gTLD and ccTLD registries are modified.
Requests to change entire NS sets (as opposed to simply dropping a couple and adding a couple of other nameservers) are typically stalled early in the process while the IANA requests justification for why the entire set is being changed at once.
Hijacking a TLD would require a lot more social engineering than your note suggests.
This has nothing to do with the root servers. The slashdot article is inaccurate.
Verisign are publishing delegations in the DNS from their registry for the COM and NET domains much more frequently than they were before. The TTL on records in the COM and NET zones is not changed.
The affected nameservers are a.gtld-servers.net through m.gtld-servers.net. These are not root servers. They are authority servers for the COM and NET zones.
Verisign also runs two root servers (a.root-servers.net and j.root-servers.net). There has been no announced change in the way A and J are being run.
Yes, you're confused. T/TCP is an extension to TCP, over which HTTP runs.
Not a standard. RFC 1644 is classed experimental; it's not a standards-track protocol. See The Internet Standards Process (RFC 2026). The claim in the story leader that Microsoft were somehow ignoring RFCs looks, uh, foolish though, which is the point you were making.
If you're using a single TCP session to transfer the data, and your transmit and receive windows are not set appropriately large, or if the hardware you are using is under-spec, then sure.
On the other hand if you transferred the data in some other way (in parallel over multiple TCP sessions, or over UDP), you could exceed 400Mbit/s trivially. I saw nothing in the release which suggested a single TCP session was used.
The Internet2 people are just trying to promote their network as somehow record-breaking, when in fact many commercial "Internet1" networks are years ahead of them.
It also seems odd to brag so loudly about a sustained transfer of 400Mbit/s between North America and Europe. That's really not particularly fast.
There are plenty of ISPs with multiple 10Gbit/s circuits across the Atlantic, and within Europe and North America, and they all sell colo on dedicated gigabit ethernet. Speed record my ass.
You run 5000 windows machines, and you're calling me a moron?
The kind whose users are stupid enough to use mail clients or operating systems that are vulnerable.
NeXTStep realised that dream, as does Mac OS X. Apple is now the largest Unix OS vendor on the planet, so it's fair to say that the majority of Unix systems now realise this dream.
If we discount Windows users, on the basis that they are not qualified to make informed decisions about anything (or else they wouldn't be using Windows) it looks like that dream has been mainly realised, in fact.
Hooray!