cTLD and DNS upgrade

Peter Dambier peter at peter-dambier.de
Tue Jul 5 15:34:42 UTC 2005


Brad Knowles wrote:
> At 12:15 PM +0200 2005-07-05, Peter Dambier wrote:
> 
> 
>> Seeing in practice how cache-poisoning even root-poisoning accidently
>> works I am glad I can prevent this with mirroring all important zones
>> on my resolver. I have seen banks and agencies do the same and exchange
>> zone files among them happyly.
> 
> 
> 	In other words, you haven't done any tests.  You found something 
> that may or may not have worked in one specific instance, and you are 
> blindly applying it to everything.

I could reproduce it easyly:

001   For every domain (X) in the root zone
002
003      "dig (X) +nssearch"
004
005   Done

After that you could be sure I had the "wrong" root-servers in my
cache. That was the time when '.KE' did not resolve in the ICANN
root but on the Public-Root it did.

; <<>> DiG 9.1.3 <<>> @204.61.216.7 ke axfr
;; global options:  printcmd

ke.                             SOA     mzizi.kenic.or.ke. hostmaster.kenic.or.ke. 2004053023 ...

ke.                             NS      NS.ANYCAST.kenic.or.ke.
ke.                             NS      NS1.COZA.NET.ZA.
ke.                             NS      mzizi.kenic.or.ke.
#.ke.                           NS      NS1.SWIFTKENYA.COM.
#.ke.                           NS      NS2.SWIFTKENYA.COM.

#NS1.SWIFTKENYA.COM.ke.         A       80.240.192.7
#NS2.SWIFTKENYA.COM.ke.         A       64.49.144.5
NS.ANYCAST.KENIC.OR.KE.ke.      A       204.61.216.7
MZIZI.KENIC.OR.KE.ke.           A       198.32.67.9

ke.                             SOA     mzizi.kenic.or.ke. hostmaster.kenic.or.ke. 2004053023 ...

;; Query time: 199 msec
;; SERVER: 204.61.216.7#53(204.61.216.7)
;; WHEN: Tue Jul  5 16:11:40 2005
;; XFR size: 12 records


It probably happened like that:

fafnir at lumbamba:~/iason> dig  -t any @80.240.192.7  #.ke

; <<>> DiG 9.1.3 <<>> -t any @80.240.192.7
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36617
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 9

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       430239  IN      NS      m.root-servers.net.
.                       430239  IN      NS      a.root-servers.net.
.                       430239  IN      NS      b.root-servers.net.
.                       430239  IN      NS      c.root-servers.net.
.                       430239  IN      NS      d.root-servers.net.
.                       430239  IN      NS      e.root-servers.net.
.                       430239  IN      NS      f.root-servers.net.
.                       430239  IN      NS      g.root-servers.net.
.                       430239  IN      NS      h.root-servers.net.
.                       430239  IN      NS      i.root-servers.net.
.                       430239  IN      NS      j.root-servers.net.
.                       430239  IN      NS      k.root-servers.net.
.                       430239  IN      NS      l.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.     1740    IN      A       198.41.0.4
c.root-servers.net.     52458   IN      A       192.33.4.12
d.root-servers.net.     52459   IN      A       128.8.10.90
f.root-servers.net.     52460   IN      A       192.5.5.241
i.root-servers.net.     52455   IN      A       192.36.148.17
j.root-servers.net.     417297  IN      A       192.58.128.30
k.root-servers.net.     52456   IN      A       193.0.14.129
l.root-servers.net.     52457   IN      A       198.32.64.12
m.root-servers.net.     52458   IN      A       202.12.27.33

;; Query time: 723 msec
;; SERVER: 80.240.192.7#53(80.240.192.7)
;; WHEN: Tue Jul  5 16:24:58 2005
;; MSG SIZE  rcvd: 372

This one is not much better. At least it does not overwrite my root-servers
but it might leave a negative answer in my cache:

fafnir at lumbamba:~/iason> dig  -t any @80.240.192.7  \#.ke

; <<>> DiG 9.1.3 <<>> -t any @80.240.192.7 #.ke
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 13482
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;#.ke.                          IN      ANY

;; Query time: 1367 msec
;; SERVER: 80.240.192.7#53(80.240.192.7)
;; WHEN: Tue Jul  5 16:26:46 2005
;; MSG SIZE  rcvd: 22


I dont think '#' is one of the allowed charaters in the first place and
I dont know how the convinced Bind to accept it. Maybe they used one
of the patched Bind9 servers from

http://www.i-DNS.net/support_download/downloads/downloads.html


This little change in my /etc/named.conf did it:


# zone "." in {
#   type hint;
#   file "/etc/root.hint";
# };

zone "." in {
   type slave;
   file "/Bunker/a.public-root.net.axfr";
   masters { 205.189.71.2; };
};


My root-servers were never overwritten again nor did I need them
except for copying. :)

The reason why '.ke' was invisible was there where different
nameservers in the root-file an in the '.ke' zone file. And
existing servers had diffrent ip addresses. It took me
half a day to put things together.

> 
> 	There have been places in the code where data could be returned 
> as part of a cached answer, and then turn around and hand that same 
> bogus data back out as part of an authoritative response.  This is 
> why you want to make sure that your caching-only servers are not 
> authoritative for anything, beyond the standard 
> "0.0.127.in-addr.arpa." and "localhost." zones.
> 
> 
>>> 	Vixie's company?  You mean Nominum?  He may have helped to found
>>> the company, but everything I've heard from various people who've
>>> worked there indicate that he hasn't had any material involvement in
>>> it for a very long time.
>>
>> For my small memory Bind is Vixie, not the money but the brain.
> 
> 
> 	Paul Mockapetris created the DNS.  He drafted Paul Vixie into 
> working on BIND.  Paul Vixie brought in a team of people to work with 
> him on the code, and one of the things he insisted on was that BIND-9 
> be a complete ground-up re-write without a single line of code from 
> him.  Nominum was contracted to handle that work.
> 
> 	Among other things, Paul Vixie helped found the company Nominum, 
> but many other principals are also involved, with Paul Mockapetris at 
> the top of the list.  If you're going to be in this business, it 
> would be a good idea to check out the list of people at 
> <http://www.nominum.com/company.php?subid=1>.
> 
> 

Thankyou for updating my view of history a bit. It is good to
remember the internet was not a one man show, nor was DNS.

>> They did a good job with Bind9. They solved a lot of problems a had
>> with earlier versions. That is why I think of them as Vixies
>> company. Bind9 is his child.
> 
> 
> 	Nominum is one of the companies that Paul Vixie helped found, 
> that's true.  And Paul has been the principal steward for BIND for 
> many years.  But he has taken a completely hands-off attitude towards 
> BIND-9.  He maintains his relationship with the Internet Systems 
> Consortium (ISC), which is the home of BIND, INN, NTP, and a number 
> of other good works.  You might want to take a look at 
> <http://www.isc.org/sw/bind/bind-history.php> and 
> <http://www.isc.org/about/history/>.
> 
> 
>> I guess it is worth the money - if it was not running on windows.
> 
> 
> 	The recommended hardware configurations for Nominum's ANS and CNS 
> products do not include Windows.  See 
> <http://www.nominum.com/products.php?id=2&faq=1#faq_33> and 
> <http://www.nominum.com/products.php?id=1&faq=1#faq_20>.
> 
> 

Yes, I have mixed it up.

>> Probably that is the reason why they had to split resolver and
>> authoritative nameserver. Windows is famous for caching used
>> horseshoes thrown at it besides NetBIOS and other non-DNS packets.
> 
> 
> 	Windows has nothing to do with it.  Nominum's products run only 
> on Linux (Red Hat and SuSE), FreeBSD, and Solaris.  That's it.  No 
> Windows.  At least, that's the story according to the datasheets at 
> <http://www.nominum.com/content/documents/nominum_ds_cns.pdf> and 
> <http://www.nominum.com/content/documents/ans_datasheet.pdf>.
> 
> 	Perhaps you were thinking of the stuff from Men&Mice, and their 
> Active Directory-enhanced products?  While their stuff will run on 
> Windows (and the AD stuff obviously requires Windows networks), 
> that's not the only platform they support.  Moreover, they can fully 
> integrate their unique front-end management tools with a standard 
> BIND-9 back end.  Of course, this is a totally different company, one 
> that Cricket Liu had some involvement with a little while back.  He's 
> now at InfoBlox, a company that sells high-performance Linux-based 
> DNS/DHCP appliances.
> 
> 
> 	My understanding is that the caching/recursive versus 
> authoritative split for Nominum ANS/CNS was done for both performance 
> and security reasons, but to get the official word you'd have to talk 
> to people who work there (or who have worked there), and who are more 
> knowledgeable on that subject.
> 
> 
>> Did you ever read the '.' zone file and make it an /etc/hosts?
> 
> 
> 	I was using HOSTS.TXT back in 1990, and I got fed up with trying 
> to keep that file up-to-date.  I set up the first caching/recursive 
> nameserver within what was then the Defense Communications Agency. 
> Yes, DCA owned Milnet, and the one-and-only NIC at the time (SRI-NIC, 
> later nic.ddn.mil) was run under the auspices of DCA, but those were 
> all outward facing services -- mine was the first on the internal 
> network serving internal clients.
> 
> 	I know how /etc/hosts works, and I'm not particularly interested 
> in ever going back that way.
> 
> 
>> I used check_soa from the O'Reilly book 'DNS and Bind' and was
>> shocked how many errors I got on so many toplevel domains.
> 
> 
> 	I am the maintainer for "doc" (which I inherited from Paul 
> Mockapetris), and a contributor to "dnswalk".
> 
> 	I did some more extensive testing a while back on the root zone 
> and all the TLDs.  See 
> <http://www.shub-internet.org/brad/papers/dnscomparison/>.  I am in 
> the process of updating this testing, and the results so far do not 
> look good.
> 

Thankyou for that paper. It helped me a lot. Last time I looked on the
page I could not find the proper spelling for bunzip2 for the PDFs.


Kind Regards,
Peter and Karin

-- 
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
+1-360-226-6583-9563 (INAIC)
mail: peter at peter-dambier.de
http://iason.site.voila.fr
http://www.kokoom.com/iason



More information about the bind-users mailing list