Slashdot Mirror
ICANN, National Registrars Still Feuding
Damalloch writes: "The BBC website has this story about the EU's concern over ICANN's refusal to make guarantees about root server stability. Domain name registrars such as Nominet are threatening to withhold payment of ICAAN's fees unless something is done to reassure them. So far ICAAN has remained stubborn because of the huge lawsuit potential if a root server were to go down but with the possibility of having their income reduced, they might just be convinced to do something."
They'd need ISPs who run DNS servers for their clients to point to their root servers. This is somewhat nontrivial.
It would (go to another root) - but if these systems are already running close to capacity, then that may be enough to cause the next server to choke, crash, and the next server will fall even faster.
It's a scenario much like the AT&T switch fiasco, where a seldom exercised chunk of code took out one server. Once one server was down, the others took more load, which, coupled with the fact part of the problem was a live switch receiving a "I'm back!" message while under heavy load, caused more switches to go. Cascade failure all the way.
After reading the article, I'm actually rather surprised myself. These systems must chew a ton of bandwidth, but it seems ICANN doesn't pay for it? Not to mention that all but three are in the US - isn't that going to oversaturate the cross-oceanic links?
I think I'm definately with the registrar organizations - ICANN should be having contracts in place to require certain things, rather than a wink and a nod and a handshake.
A faulty version of software was released. And yes the fault was buried waaay down in a giant case or if/elseif statement. Normally no big deal, right? Just roll back. But they had things set up so that any machine connected to another would poll it for the version of software it had. If what it connected to had a newer version, it would download that and then hand it off to all its fellows. So by the time the bad code triggered and they realized they had a problem it had already spread virus-like across the whole network. Going back to the older version one one machine was futile because as soon as it booted up it would connect to other machines and download the flawed software.
They had to eventually take their old version, give it a new, higher number, and then compile and release that. So that that 'feature' once again became a feature and not a bug. Many lessons to be learned.
http://www.cisco.com/public/sw-center/sw_download_ guide/dnsfaq.html gives a list of root servers and their IP Addresses, as well as some good information about the basics of DNS.
http://www.isi.edu/in-notes/rfc2870.txt talks about the requirements for a root server. From this:
1.1 The Internet Corporation for Assigned Names and Numbers (ICANN)has become responsible for the operation of the root servers. The ICANN has appointed a Root Server System Advisory Committee (RSSAC) to give technical and operational advice to the ICANN board. The ICANN and the RSSAC look to the IETF to provide engineering standards.
As such, it looks like ICANN is the only organization that can take responsibility of the system.
section 2.3 estimates that 2/3rds of the servers could be taken out and functionality would be maintained.
The Internet Software Consortium runs F on BIND 8.2.3 (Hrmmn... their latest release is 8.3.0 and they've noted that 8.2.5 has a security bug, and the 9 series *is* out and at the 9.2 series, does anyone else find it disconcerting that they run 8.2.3?) Does anyone know of a list of who takes care of these root servers?
First? It is already several years too late for China to somehow be first. Alternate roots have been around for a long time. I use one, you can too.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
This is totally inaccurate. If you are searching for www.bbc.co.uk, your computer asks the local DNS cache (listed in /etc/resolv.conf, unless you have some retard OS). That cache then asks a root server for www.bbc.co.uk (if that information has not already been cached). This produces a referral to the .uk nameservers. The process continues for co.uk and bbc.co.uk as necessary. Note that it does not ask the closest root server, because the cache has no way to know what this is. BIND uses the "fastest" server (until it overloads from all the other BIND servers using this strategy); djbdns's dnscache picks one at random.
One way to avoid delays at the root servers is to run your own local root server, and periodically download the root zone. This shows you how to do it using the ORSC root zone, but you can do it with the standard root as well. You can AXFR it from one of the root servers. Then you tell your local cache to use your local root as the root server.
This message has been scanned for memes and dangerous content by MindScanner, and is believed to be unclean.
The reason why there are only 12 or 13 root servers is based on several factors.
.biz servers are, I believe, handled this way.
The most basic factor is that the DNS specification imposes an obsolete 512 byte limit on the size of UDP DNS packets. (DNS can run on TCP but the overhead is much higher than with UDP.
Since reply packets often contain many resource records, and DNS names can be up to 255 bytes each, you can see that one can brew up server names that would strongly press that 512 byte limit even with two servers. Fortunately, server names are usually not all that long.
DNS name compression comes into play to help, and that situation has improved since most root servers now support root-servers.net as the right hand part of their names.
Internationalization of domain names under the ACE rules coming out of the IETF will work the other way - internationalized server names will tend to be longer than than the a.root-servers.net form that we see today.
Now, just because we see one NS record in a list of servers doesn't mean that there is only one computer there - or even that it is in one place. Many servers are actually clusters that are hiding behind load balancers.
And with IP "anycast" technology (essentially a way of establishing multiple instances of the same address block by using localized more specific route announcements) we can have as many servers as we want at the same apparent address but located in widely scattered locations around the world. The
Oh, by-the-way, don't fall into the belief that the names/addresses listed in the "hints" file are the root - those addresses merely serve as a way to find a single root server. That server, in turn, will provide the actual set of root servers. That's why the hints file is called "hints" - it's just there to get the ball rolling.
Just got ahold of my copy of the book.
I was half mistaken.
RT is not the record of interest for ports, SRV is.
This is from chapter 15.7.6
Quoting the book (and all credits due)
~~~~~
The experimental SRV record, introduced in RFC 2052, is a general mechanism for locating services. SRV also provides powerful features that allow domain administrators to distribute load and provide backup services, similar to the MX record.
A unique aspect of the SRV record is the format of the domain name it's attached to. Like service-specific aliases, the domain name to which an SRV record is attached gives the name of the service sought, as well as the protocol it runs over, concatenated with a domain name. So, for example:
ftp.tcp.movie.edu
would represent the SRV records someone ftping to movie.edu should retrieve in order to find the movie.edu FTP servers, while:
http.tcp.www.movie.edu
represents the SRV records someone accessing the URL http://www.movie.edu/ should look up in order to find the www.movie.edu web servers.
~~~~~~~~~~~
Hope this helps
. .
If I read this correctly, the reason why the EU local registries don't have their own root servers, and hence control over service levels is a historical issue.
Excerpting from the Internet Software Consortium's page, linked above - and please allow me to state that such a reference is anecdotal rather than given fact,
The "one in Europe" btw was NOT Nominet or another registrar, it was a guy working for LINX, the London INternet eXchange.
There's good reason for this, as late as the early 1990s, Europe was still thinking that X.500 was the way forward, and a large amount of resources from universities, telcos and local standards agencies was devoted to "interoperability" testing of X.500 directory services. What really happened was the standards lagged the implementations so badly that vendors and implementors went ahead and did their own thing, creating, as anyone who has dealt with X.500, a nightmare for inter -vendor interoperability. That created the space in which the InterNet and DNS / BIND could flourish. FWIW, LDAP is a (nor precisely, so please don't flame me, too large a subject for absolute accuracy here) derivative of X.400, itself a cut down form of X.500. Novell's eDirectory, which runs some of the largest sites (CNN.com, AOL messenger services) is itself a souped up LDAP implementation.
You can find a brief overview of X.500 and what the "authorities" in Europe were up to as late as 1990 and beyond in this history of X.500
I'm British born myself, but this all seems to me to be Euro - Whining. Particularly the UK's Nominet making an issue of this is absolutely BS. Nominet has, IMO, very sharp practises. If you "buy" a domain in the UK (domain.co.uk) via an ISP, Nominet maintains a "tag" linking your domain to the "provding" ISP, until another ISP takes it over. Domains _never_ go back into circulation when they expire. Nominet refuses, on the whole, unless you threaten or cajoule them with considerable effort, to "release" your domain because it states it will not get involved in contractual disputes between you and your ISP. Most UK ISPs make contracts which lock you in to your services and charge a considerable and hefty severance fee, usually buried in the small print. You _can_ get a "Neutral Tag" applied to a UK domain, if you pay GBP £80 for two years, which fee goes back to the ISPs who are members of Nominet, which is a for profit company, limited by guarantee, a rare form of UK company which offers very lax statutory reporting. Even though you _can_ do all this, I've had several clients now who've complained to Nominet, e.g. when their ISP is TU and no longer provides service, and Nominet tells them anyway that they can only deal with an ISP who is a member of Nominet. Obviously that's BS. But you can't register a domain in the UK for
Sorry for that rant against Nominet, but it's Crocodile Tears time again and minus several million points for the Brits, as per usual.
Please follow the links above, investigate yourself . . .
The problem is that 13 is a magic number in DNS. The maximum size of a DNS message when carried over UDP is 512 bytes. And guess how many NS records and associated A records you can fit in 512 bytes, assuming domain name compression is working as efficiently as possible? Thirteen.
If you add more root name servers, when name servers look up the list of root name servers (via something called a system query) you truncate the DNS message, and then those name servers retry over TCP and all hell breaks loose.
That said, two of the existing roots (j and l) are temporarily housed at ISI and VeriSign, which already have roots. Those two really need to be deployed to parts of the Internet that need them.
There's no reason we have to use whichever ACE becomes the standard in the domain names of root name servers. We sacrificed the old domain names of the root name servers (e.g., ns.nasa.gov) to the greater good of better domain name compression years ago.
The countervailing force is EDNS0, which will allow 4096 byte UDP-based DNS messages. And BIND 8.3.0, recently released, supports EDNS0. f's already running it. Once 8.3.0 is fully deployed on the roots, I think additional root name servers are just a quick hack away:
- System query without EDNS0: You get 13 root name servers
- System query with EDNS0: You get more