Date: Thu, 17 Aug 2000 02:29:50 -0700 From: Kent Crispin To: Subject: Re: ICANN's 15 August Criteria for new TLD applications On Thu, Aug 17, 2000 at 07:51:32PM +1200, Al Koning wrote: > > DNS as implemented is a much more subtle protocol than it appears, and > > DNSSEC will make it even more complicated. The alternate root guys sit > > in their little pool and play with toy boats, and pretend that they are > > commanding aircraft carriers. But there really is a bit more to it. > > I hate to break it to you Kent, but if you want to rely on some "genuine > technical and policy issues that [we] don't understand" to support your > claims - you will have to tell us what these issues are. > > This is not a list dedicated to discussion of technical issues and naturally > some do not fully appriciate all the issues involved (I know i do not). But > this is why this list exists - to help people to understand these issues adn > DISCUSS them (not DISMISS them). Simply saying that you know more than > somebody else does not give your point of view much credit. > > Would you care to tell what are these "genuine technical and policy issues" > that none on this list but you can understand ? OK DNS as implemented is indeed far more complex than it appears. Two factors are major contributors to this complexity: caching, and "extra information" that is returned in answers to queries. Caching: All domain name resolvers keep a cache of recently answered queries, so that it isn't necessary to make another trip out to the network to answer the same question again. This caching is part of the dns protocol; every record contains information such how long it should be cached before it is considered stale; the caching behavior is absolutely critical to the performance of dns. The "extra information": When a resolver sends a query to a server asking for information, the server sends back gratuitous extra information with the answer; information that the server thinks will optimize future queries. For example, in the process of sending this email, the songbird resolver will send a query to the .org server, asking for information about the isoc.org email domain. The .org server will send information about where to get information about the isoc domain. The songbird resolver will then contact the isoc nameserver, asking about mx records for isoc. The isoc nameserver will send back information about what host serves mail for isoc. The nameserver will send back additional information, including potentially the names of other nameservers, and their IP addresses, as extra information included in the response to the other queries. What extra information is returned is not determined in the protocol -- it's server implementation dependent. All this extra information gets cached. Eugene Kashpureff's famous hack against the InterNic made use of this feature -- he would contact a host through some protocol that would require that host to do a lookup of the name of Eugene's host. (For example, he could send an email, requesting that you look at a web site). Eugene altered the dns server so that it would send back bogus "extra information" in the reply -- in particular, he sent back information that said that his server was authoritative for the domain "internic.net". This information was dutifully cached at every receiving site affected site, and when the site later tried to access the internic.net domain, it was sent to Eugene's machine, instead. This was deliberate action on Eugene's part, but on rare occasions (usually on intranets) similar things happen through misconfiguration. These give raise to similar cache pollution; the resulting problems can be devilishly hard to fix, because the various servers keep returning the same erroneous information in the "extra information", and keep regenerating the problem. In the worst case you have to find all the affected machines, bring down all of their dns servers, clear their caches, and start up again. Alternate root servers are essentially institutionalized sources of potential cache pollution. Briefly: if an alternate root server has a TLD .foo, and simultaneously serves .com, and there are individual hosts out there that had both .foo and .com identities (which would be very common -- for example, essentially all the hosts in the current alternate root experiments have "real" identies as well as their alter egos), then the information about the alternate TLDs can flow into the caches of name servers of hosts that don't recognize the alternate TLDs. That is, a server that only knows the ICANN root servers can still pick up information about alternate TLDs without ever explicitly requesting it, or wanting it, because of information that builds up in its cache through the flow "extra information". Concretely, xyz.foo might be the same machine as xyz.com. My nameserver might at one time learn that xyz.com was the nameserver that dealt with abc.com, and at another time learn that xyz.foo was the nameserver that dealt with abc.com, all through the "extra information", without making an explicit query. It might or might not have picked up that there was a .foo TLD somewhere along the way as well. The point is that sometimes it would be able to resolve abc.com, and sometimes it wouldn't. This is the essence of dns instability. The information about xyz.foo would essentially be cache poison; the alternate root serving up .foo is essentially an institutional source of that poison. This problem exists with the current alternate root experiments, but they are such a miniscule fraction of the total that it really doesn't matter. Widespread deployment of alternate TLDs would have a much larger effect. This discussion is somewhat schematic -- the situation is much more complex, because the behavior of resolvers and nameservers is quite variable. However, this kind of cache pollution does happen -- I have in fact seen it. The alternate root guys will say that all this doesn't matter, because any guy with a misconfigured linux box could cause similar problems. To paraphrase: "we should get a license to screw things up, because a kid with a linux box could screw things up anyway". There are a number of ways that the net is vulnerable to kids with linux boxes; a lot of effort is going into fixing the problems with dns by including digital signatures for the information -- so when you get the address of a machine, the nameserver will be able to verify its identity to you. Of course, it will be a little harder to deploy alternate roots when there is a chain of signature authority going down from the root... In any case, that's a technical issue. I'll leave policy issues as an exercise for the reader. Consider, though, that Kashpureff was arrested for his antics. What do you suppose the legal liability would be for an alternate root operator who was persistantly causing legitimate lookups to fail? The alternate root guys will have all kinds of bad stuff to say about this, of course -- and about me :-) -- Kent Crispin "Do good, and you'll be kent@songbird.com lonesome." -- Mark Twain