Well - I'va waited patiently for someone to answer Mr. Kent on his technical presentation of the DNS. No one seems to have rebutted this within the last 24 hours - so I shall proceed to do so. Kent has done this group a disservice. The presentation and technical description he gave here are confused. He's mixed apples and oranges together and called the resulting fruit a bannana. So with that said I shall proceed to respond to the technical issues presented here. On Thu, 17 Aug 2000, Kent Crispin wrote: > 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. Nothing at all complex in that. Caching is a standard part of most protocols. Again - there is nothing complex or myterious with respect to the protocol. > 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. Again up to this point his technical description is accurate on the workings of the dns resolver. Unfortunately at this point Kent decide to visit Wonderland with Alice. Let's take that trip with him. > > 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). No - this is not correct. Trying to associate what Eugene did by comparing it to email is incorrect. Let us deal with the technical aspects and not confuse the user with examples that are inappropriate. First Kashpureff's action have nothing to do with alternative root server operations and everything to do with hacking. Eugene took advantage of a security hole in BIND (the dns daemon). This security hole has existed since BIND was forst introduced to the internet. For details on all the security issues in BIND see: http://bind1999.pccf.net/cgi-bin/bindhelp?=bind-table Eugene specifically attacked the internic.net servers at NSI. And he never attacked the root server records - so this never was a root server issue. What he did was redirect the old internic.net web site to his site using existing vulnerabilities in the DNS Daemon BIND. > 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. No - this is not what happened. At no time was his server authoritative for the internic.net domain. What he did was alter the records on the internic.net nameservers so the rs.internic.net and www.internic.net sites would point to his site. If I remember correctly - he achived this by using the maxdname vulnerability in bind and spoofing a record update. http://bind1999.pccf.net/cgi-bin/bindhelp?bind-table=maxdname Again - non of this has anything to do with alternate root servers. The only association is tha Eugene ran his own root servers. But at no time were those root servers in control of the internic.net domain. Let me provide everyone here with an example. What Eugene did to the internic.net nameservers was nothing short of irrelevant in my opinion. Hackers do it every day to systems throughout the internet by taking advantage of existing DNS vulnerabilities and spoofing record updates. This is a serious problem on the internet and is ususally the reason hackers break into web sites and alter them. Once hackers take control of the dns they can trick the system into thinking your a trusted user. And we can go further in this assement. At this time the internet has an estimated 600,000 to 800,000 nameservers. That's my educated estimate based on this years bind2000 survey and last years bind1999 stats - which see: http://bind1999.pccf.net/stats.html And in almost all cases these servers are vulnerable to various internet attacks. Not to mention a good portion are just improperly configured. And for some strange reason non of it seems to bother surfers. Which brings me to my last point, the DNS is a very robuts protocol which can deal misconfigured settings - but not hackers. > 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. No - now your visiting wonderland again. Machines do not have to be brought down and in the case of the Eugene attack all that happened is that the servers refreshed their case once the TTL (time to live value) expired. This had absolutly nothing to do with the root servers and everything to do with hacking. This is a clear situation where Kent has mixed apples (hacking) and oranges (a person associated with alternate roots) together and called the resulting fruit a bannana (i.e. this diatribe). > 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". This is a completely bogus statement. Never has happened. And Kent has been asked by many to provide concrete examples - and he's never come through on it. Alternate root have been in operation for some time - no problems. > 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. might or might not? Not a good example here and I still don't see any technical support for your argument. > > 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. NO - the point is it will always be able to resolve abc.com and also xyz.foo. I still see no dns instability in your proof - just alot of hot air. > 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. The only affect it would have is deminishing ICANN's control - nothing more. > 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. Ah yes - ye old "everything is more complex" argument. Just in case - right Kent. > > 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". Well - it's a fact misconfiguration are the rule of the day and for some reason it all runs well. I still see no supporting technical evidence in which you have made your point. > > 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... Not at all - why do you think it will be harder to deploy? It won't. Once again - please try not to make DNS into some cult of the long dead god. It isn't. > > 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? No - Kaspureff was arrested for hacking - not running a root server. Again apples plus oranges do not equal bannanas. > The alternate root guys will have all kinds of bad stuff to say about > this, of course -- and about me :-) Not at all Kent. The alternate root guys depend on people like you lying to people in conferences like this - it wins them over. People don't like being made to look like fools by ICANN fluffers. Now Kent - back to business - if you feel I'm mistaken in my rebuttal to your technical diatribe then be my guest and point it out. regards Joe Baptista http://www.dot.god/ dot.GOD Hostmaster +1 (805) 753-8697
