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