From: Kent Crispin To: , Cc: Bcc: Subject: Re: ICANN's 15 August Criteria for new TLD applications On Fri, Aug 18, 2000 at 09:06:52PM -0400, !Dr. Joe Baptista wrote: [...] > > 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. I'm not "comparing it with email". Sending email is just an example of one of several possible ways to get someone to use your nameserver, a standard hacker trick. You provide another nice example below of how a hacker would get someone to use their nameserver. > First Kashpureff's action have nothing to do with alternative root > server operations and everything to do with hacking. You completely misunderstand my intent. The aim is to provide a concept-level explanation of cache pollution in DNS, and Eugene's hack is an interesting example. The tie to alternate roots is a separate part of the discussion. > Eugene specifically attacked the internic.net servers at NSI. Eugene's hack used standard features of DNS, and indeed was not dependent on the fact that he was running a root server. While information is actually sketchy, it is also the case that he did not "hack NSI's servers" -- at least NSI vehemently denied that their servers had been hacked. Instead, he hacked his OWN servers, and let the bad data flow out. > And he never attacked the root server records Never said said he did. > What he did was redirect the old internic.net web site to his > site using existing vulnerabilities in the DNS Daemon BIND. He didn't do anything at all with web site redirects; he didn't hack their dns servers. He used the normal DNS protocol; he just altered some of the data that was returned. In any case, bad data must spread to end resolvers before it has any effect whatsoever. If my resolvers have good data in their cache, they will go to the right address, regardless of what NSI's nameservers have in them at the moment, and if they have bad data in their cache, they will go to the wrong place, regardless of what the authoritative nameservers say. The bad data can be transmitted through corruption of *any* nameserver. [...] > 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 Here's an example of what I was referring to above: You just supplied a url with the pccf.net domain in it. To visit that site my browser would have to look up the IP address of bind1999.pccf.net -- that is, it would have to visit YOUR nameservers to get the information. If you were playing Eugene's trick, you would have modified YOUR nameserver to return bogus information as the "extra information", which would then be dutifully cached by my nameserver (if it wasn't patched). Different versions of bind deal differently with the extra info; later versions of bind handle it better. But no version of bind without dnssec can handle it perfectly, because, fundamentally, the problem is intrinsic to the dns protocol itself. You can weed out SOME of the bogus data because it has characteristics that you can identify as bogus. But ultimately there is no magic way to tell, because ultimately, dns servers trust each other. > Again - non of this has anything to do with alternate root servers. We are discussing how cache pollution works. The issue with alternate root servers will come up in due course. The goal here is a conceptual understanding of the mechanism. The details of Eugene's stunt are not important, as long as the basic idea of how cache pollution works is communicated. [ ... ] > > 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 Here -- let me quote from "DNS and Bind, 3rd edition", by Albitz and Liu, p336: "You need to rid both name servers of the old record simultaneously. Our solution to this problem is to bring both name servers down at the same time, clean out any backup files, and then start them both up again. That way, the caches can't re-infect each other." Here's another quote about a related problem that gives a good illustration of the difficulties involved (p333): "The only ways to track down the source of these bogus roots are to turn name server debugging way up (to level four or above) and watch for the receipt of these records, or to patch your name server so that it reports receiving bad root information. With BIND 4.9 and BIND 8, you can see the source of the bad data in a database dump. Even when you think you've found the culprit, though, you may have only discovered another name server that was corrupted before yours, not the original source of the corruption. To uncover the original sinner, you'd have to work backwards, together with other administrators, to discover who made the first gaffe. If you don't have the tenacity to suffer through that process, it's probably easier to upgrade to a BIND 4.9 or BIND 8 server." Now, this particular example refers to a problem with an older version of bind (but one still in use in many places). It does illustrate what must be done when pernicious cache pollution happens, though. And, to be fair, I must point out that the "bogus roots" they refer to aren't YOUR bogus roots. [...] > 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. This is really funny :-). You ask me to provide concrete examples of your alternate root servers screwing up, knowing full well that I wouldn't touch them with a 100 foot pole. :-) [...] > > 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 contents of any cache are non-deterministic. Depends completely on past queries. Hence: "might or might not". No mystery. You should know this. > > 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. You have to think about it just a bit deeper. The cache could (for example) contain a NS record that says effectively abc.com IN NS xyz.foo but the A record that contains the address of xyz.foo (which would look like xyz.foo IN A 1.2.3.4 ) may have been flushed from the cache (or never been delivered). In that case the resolver has to go to the .foo server to find the address of xyz.foo. To do that it needs to find the address of the .foo server. But it doesn't HAVE a record for the .foo server, so it can't find the address of xyz.foo, so it can't resolve abc.com. On the other hand, completely dependent on the past history of queries, and their timing, and the version of bind, and a whole bunch of things, it MIGHT have an "A" record for xyz.foo, or even the .foo server, that somehow got in the cache, and in that case it WOULD resolve the name. Sometimes it would, sometimes it wouldn't, just depending on the past history of queries. The key point is that all the servers involved are CORRECTLY CONFIGURED, and nobody is being malicious -- they are all serving up what they believe to be the correct view of things. But if you look at the information in DNS from a global point of view, it is actually inconsistent -- some zones have multiple parent zones. This problem is fundamental. In an alternate root situation some zones have multiple parent zones, and there is no way to tag information in DNS to tell which parent was used. The information flows freely through the caches, and you can get different results depending on which parent information you have in your cache at the moment. This is the essence of instability, and it is a fundamental design charateristic of the DNS protocol. It was not designed to support multiple root zones. > I still see no dns instability in your proof - just alot of hot > air. 1) I'm not surprised you don't see it -- I believe you *wouldn't* see it, even if you could. 2) You have it exactly backward -- the burden of proof isn't on me -- I'm not advocating any changes. The alternate root advocates are the ones who proposing radical change, and it is the alternate root advocates that will have to PROVE that what they do will work, including the necessary changes to the protocols. But strangely enough, none of the alternate root advocates are participating in the IETF WGs where this kind of thing is discussed. -- Kent Crispin "Do good, and you'll be kent@songbird.com lonesome." -- Mark Twain