-----BEGIN PGP SIGNED MESSAGE----- - From our vantage point, it looks like most of the root nameservers have bad delegation data. Most of them return no delegation info for what should be working domains: roy@ns% foreach ns ( a b c d e f g h i j k l m ) do echo $ns.root-servers.net host -t ns digital.com $ns.root-servers.net host -t ns webcrawler.com $ns.root-servers.net echo done a.root-servers.net digital.com NS CRL.DEC.COM digital.com NS NS11.digital.com digital.com NS NS.DEC.COM webcrawler.com NS NS00.EXCITE.COM webcrawler.com NS NS01.EXCITE.COM webcrawler.com NS NSE00.EXCITE.COM webcrawler.com NS NSE01.EXCITE.COM b.root-servers.net digital.com does not exist at b.root-servers.net (Authoritative answer) webcrawler.com does not exist at b.root-servers.net (Authoritative answer) c.root-servers.net digital.com does not exist at c.root-servers.net (Authoritative answer) webcrawler.com does not exist at c.root-servers.net (Authoritative answer) d.root-servers.net digital.com does not exist at d.root-servers.net (Authoritative answer) webcrawler.com does not exist at d.root-servers.net (Authoritative answer) e.root-servers.net digital.com does not exist at e.root-servers.net (Authoritative answer) webcrawler.com does not exist at e.root-servers.net (Authoritative answer) f.root-servers.net digital.com does not exist at f.root-servers.net (Authoritative answer) webcrawler.com does not exist at f.root-servers.net (Authoritative answer) g.root-servers.net digital.com does not exist at g.root-servers.net (Authoritative answer) webcrawler.com does not exist at g.root-servers.net (Authoritative answer) h.root-servers.net digital.com NS NS.DEC.COM digital.com NS CRL.DEC.COM digital.com NS NS11.digital.com webcrawler.com NS NS00.EXCITE.COM webcrawler.com NS NS01.EXCITE.COM webcrawler.com NS NSE00.EXCITE.COM webcrawler.com NS NSE01.EXCITE.COM i.root-servers.net digital.com NS CRL.DEC.COM digital.com NS NS11.digital.com digital.com NS NS.DEC.COM webcrawler.com NS NS01.EXCITE.COM webcrawler.com NS NSE00.EXCITE.COM webcrawler.com NS NSE01.EXCITE.COM webcrawler.com NS NS00.EXCITE.COM j.root-servers.net digital.com NS record currently not present at j.root-servers.net webcrawler.com NS record currently not present at j.root-servers.net k.root-servers.net digital.com NS record currently not present at k.root-servers.net webcrawler.com NS record currently not present at k.root-servers.net l.root-servers.net digital.com NS record currently not present at l.root-servers.net webcrawler.com NS record currently not present at l.root-servers.net m.root-servers.net digital.com NS record currently not present at m.root-servers.net webcrawler.com NS record currently not present at m.root-servers.net To enable our resolvers to work properly, we've had to tell them to ignore the root nameservers which appear to have bad data. On a Bind 4.X system, one can do this with the 'bogusns' configuration directive: bogusns 128.9.0.107&255.255.255.255 192.33.4.12&255.255.255.255 128.8.10.90&255.255.255.255 192.203.230.10&255.255.255.255 192.5.5.241&255.255.255.255 192.112.36.4&255.255.255.255 198.41.0.10&255.255.255.255 193.0.14.129&255.255.255.255 198.32.64.12&255.255.255.255 198.32.65.12&255.255.255.255 For Bind 8.X servers, something like server 128.9.0.107 { bogus yes; } server 192.33.4.12 { bogus yes; } [etc...] should work, I think. - roy - -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBM84G8mx7n9NanyP9AQENvwP/dEYxFjxDh83OL9xvVImGrjO2202h4jts kK57u41y+DnnMehZitF9mtAhRPT0z469mmBrmWJC1EhgKlDjrm0YZwv7ZmHTgPQU 0GYcRMUPR8g7zYlnNwZxoEgUwpMzOj/SFbokL38Kojuy58CZDJZ7BrN5WFsV9/a9 Zc0s4eg+z8M= =fzlJ -----END PGP SIGNATURE-----
Roy, methinks you are a bit hasty here. j-m have never had tlds present. And the other servers are being corrected as we "speak". But then, perhaps you don't have a problem reloading your servers every couple hours or so... --bill
-----BEGIN PGP SIGNED MESSAGE----- Yes - too hasty - I wasn't thinking right :-) j-m shouldn't have been on the list. We don't like reloading our nameservers prematurely, but when things like this happen, our NOC gets deluged with customer complaints very quickly :-( If we hadn't taken action, most of our customers using MCI nameservers for resolution purposes would still be unable to reach large portions of the internet. We really can't wait while these nameservers get fixed. Anyway, I'm glad there are already people working toward resolution of this problem. Thanks for the info ! - roy -
Roy, methinks you are a bit hasty here. j-m have never had tlds present. And the other servers are being corrected as we "speak". But then, perhaps you don't have a problem reloading your servers every couple hours or so...
--bill
COM. and NET. zone files were corrupted.
a-g were affected by this corruption, h-i did not take the corrupted update (perhaps they're otherwise broken), and j-m do not serve the affected zones.
a was finally corrected at 6:55am, and admins of b-g were asked to reload their zones. It appears that none of said admins have done so to date.
J.ROOT-SERVERS.NET. 146428 A 198.41.0.10 K.ROOT-SERVERS.NET. 146428 A 193.0.14.129 L.ROOT-SERVERS.NET. 146428 A 198.32.64.12 M.ROOT-SERVERS.NET. 146428 A 198.32.65.12
should all be fine, so please remove them from your list.
--jhawk
-----BEGIN PGP SIGNATURE----- Version: 2.6.2
iQCVAwUBM84PaGx7n9NanyP9AQG+zwP/R8mo7C7vWlphf+gONOvgy8tWIJ40laps bupWG5KryzsC1z27KXAy1oSnSbgWt8WzzYre0w8qnCyw2ehpwNN/zQR99dLZSbYo xN/2724wRCZkTXDFeo3dMCFq+IwxpsVsOxwONLcPppcZXxh/uiRrryC7CjFGBn0b dyOtf/C/8rg= =h633 -----END PGP SIGNATURE-----
Can I assume that the fact that www.microsoft.com no longer exists in the DNS is a result of the (ongoing) root nameserver problems? Things have been really flaky since the INTERNIC/ALTERNIC flap the other day. Thanks, Dan Ehrlich daneel:8> dig www.microsoft.com @e.root-server.net ; <<>> DiG 2.2 <<>> www.microsoft.com @e.root-server.net ; Bad server: e.root-server.net -- using default server and timer opts ; (3 servers found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; www.microsoft.com, type = A, class = IN ;; AUTHORITY RECORDS: com. 577 SOA A.ROOT-SERVERS.NET. hostmaster.INTERNIC.NET. ( 1997071700 ; serial 10800 ; refresh (3 hours) 900 ; retry (15 mins) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ;; Total query time: 3 msec ;; FROM: daneel to SERVER: default -- 130.203.1.10 ;; WHEN: Thu Jul 17 09:53:23 1997 ;; MSG SIZE sent: 35 rcvd: 112
It seems that b,e,f, and g are still affected for com, and that net is ok at the moment. Michael On Thu, 17 Jul 1997, Daniel R Ehrlich wrote:
Can I assume that the fact that www.microsoft.com no longer exists in the DNS is a result of the (ongoing) root nameserver problems? Things have been really flaky since the INTERNIC/ALTERNIC flap the other day.
Thanks, Dan Ehrlich
daneel:8> dig www.microsoft.com @e.root-server.net
; <<>> DiG 2.2 <<>> www.microsoft.com @e.root-server.net ; Bad server: e.root-server.net -- using default server and timer opts ; (3 servers found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr aa rd ra; Ques: 1, Ans: 0, Auth: 1, Addit: 0 ;; QUESTIONS: ;; www.microsoft.com, type = A, class = IN
;; AUTHORITY RECORDS: com. 577 SOA A.ROOT-SERVERS.NET. hostmaster.INTERNIC.NET. ( 1997071700 ; serial 10800 ; refresh (3 hours) 900 ; retry (15 mins) 604800 ; expire (7 days) 86400 ) ; minimum (1 day)
;; Total query time: 3 msec ;; FROM: daneel to SERVER: default -- 130.203.1.10 ;; WHEN: Thu Jul 17 09:53:23 1997 ;; MSG SIZE sent: 35 rcvd: 112
Can I assume that the fact that www.microsoft.com no longer exists in the DNS is a result of the (ongoing) root nameserver problems?
No.
Things have been really flaky since the INTERNIC/ALTERNIC flap the other day.
Indeed, but not the way you think.
daneel:8> dig www.microsoft.com @e.root-server.net
you are asking a nonrecursive server for data it doesn't have.
; <<>> DiG 2.2 <<>> www.microsoft.com @e.root-server.net ; Bad server: e.root-server.net -- using default server and timer opts
in fact you are asking a nonexistent server, so it used your default one. [gw.home:i386] dig @a.root-servers.net microsoft.com ns | grep IN ;; microsoft.com, type = NS, class = IN microsoft.com. 2D IN NS DNS1.microsoft.com. microsoft.com. 2D IN NS DNS3.NWNET.NET. microsoft.com. 2D IN NS DNS4.NWNET.NET. microsoft.com. 2D IN NS ATBD.microsoft.com. DNS1.microsoft.com. 2D IN A 131.107.1.240 DNS3.NWNET.NET. 2D IN A 192.220.250.7 DNS4.NWNET.NET. 2D IN A 192.220.251.7 ATBD.microsoft.com. 2D IN A 131.107.1.7
On Thu, Jul 17, 1997 at 05:13:09AM -0700, bmanning@ISI.EDU wrote:
Roy, methinks you are a bit hasty here. j-m have never had tlds present. And the other servers are being corrected as we "speak". But then, perhaps you don't have a problem reloading your servers every couple hours or so...
Maybe I'm just too much of a babe in the woods, but I don't think he's being a _bit_ hasty. AFAIC, root nameservers are the quintessence of "mission critical", and the Internet simply is _not_ a geek toy anymore; it actually _matters_. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
With the root servers blowing up, someone down here told me that our BIND 8.1 server was looking up less names than other servers. Of course I denied it, but he coaxed me into running a few tests. I tested 3 servers, a BIND 8.1 server, a BIND 4.9.5 p1 server, a BIND 4.9.5 server, and a BIND 4.9.3 server. I tested a total of 100 uncached domains. 16% of the domains couldn't be looked up by the BIND 4.9.3 server 16% of the domains couldn't be looked up by the BIND 4.9.5p1 server 17% of the domains couldn't be looked up by the BIND 4.9.5 server 26% of the domains couldn't be looked up by the BIND 8.1 server All queries were sent to all the nameservers at the same time. I'm not sure if this is by chance, but it seems that BIND 8.1 isn't doing as good a job as the older 4.9.x servers. Can anyone confirm this? Jordan -- Jordan Mendelson : www.wserv.com/~jordy/ Web Services, Inc. : www.wserv.com Quote Of The Day : The world is only round if you perceive it to be so.
16% of the domains couldn't be looked up by the BIND 4.9.3 server 16% of the domains couldn't be looked up by the BIND 4.9.5p1 server 17% of the domains couldn't be looked up by the BIND 4.9.5 server 26% of the domains couldn't be looked up by the BIND 8.1 server
BTW, what was the quality of the results? randy
Hello. Welcome to BIND-NANOG, the mailing list where North American BIND problems (rather than BIND problems in general) are discussed among network operators. If you would prefer to just discuss general network operations issues, sorry, there is no such mailing list. If you would prefer to just discuss BIND problems, see usenet:comp.protocols.dns.bind. Now for our topic:
With the root servers blowing up, someone down here told me that our BIND 8.1 server was looking up less names than other servers. Of course I denied it, but he coaxed me into running a few tests.
I tested 3 servers, a BIND 8.1 server, a BIND 4.9.5 p1 server, a BIND 4.9.5 server, and a BIND 4.9.3 server.
I tested a total of 100 uncached domains.
16% of the domains couldn't be looked up by the BIND 4.9.3 server 16% of the domains couldn't be looked up by the BIND 4.9.5p1 server 17% of the domains couldn't be looked up by the BIND 4.9.5 server 26% of the domains couldn't be looked up by the BIND 8.1 server
All queries were sent to all the nameservers at the same time. I'm not sure if this is by chance, but it seems that BIND 8.1 isn't doing as good a job as the older 4.9.x servers.
Can anyone confirm this?
Without knowing exactly what test you ran, I suspect that noone will be able to confirm it. However, I can say that BIND-8.1.1 is less promiscuous than its predecessors, and so it is likely to actually reflect underlying origin server problems more directly than its predecessors. (This is part of the cost of preventing AlterNIC, et al, from polluting your cache.) If you would also run your test (whatever it is) against BIND-4.9.6 I suspect that the results will be similar to BIND-8.1.1 (which it's not clear that you used; BIND-8.1 has already been deprecated by its first patch release.) We now return you to NANOG-FIBRE, wherein the world wide fibre situation and its possible effects on North American network operations are discussed hourly.
The shutdown of the root name servers is the shutdown of the internet! Take out 12 servers and you disable a multi-billion dollar industry (are you listening cisco, microsoft, intel, ....??) The only reliable protection of the internet from this weakness is to allow the free and open duplication by anybody of the full information in the root servers and in the whois database. Otherwise just wait and some fool will test the weakness. ...What if the internic does not have a full backup ??? Has this weakness been tested before, and what is your confidence factor in a business that is streached to the max? On Thu, 17 Jul 1997, Jay R. Ashworth wrote:
On Thu, Jul 17, 1997 at 05:13:09AM -0700, bmanning@ISI.EDU wrote:
Roy, methinks you are a bit hasty here. j-m have never had tlds present. And the other servers are being corrected as we "speak". But then, perhaps you don't have a problem reloading your servers every couple hours or so...
Maybe I'm just too much of a babe in the woods, but I don't think he's being a _bit_ hasty. AFAIC, root nameservers are the quintessence of "mission critical", and the Internet simply is _not_ a geek toy anymore; it actually _matters_.
Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592
Art Houle e-mail: houle@zeppo.acns.fsu.edu. Academic Computing & Network Services Voice: 644-2592 Florida State University FAX: 644-8722
Hot Diggety! Art Houle was rumored to have said...
The shutdown of the root name servers is the shutdown of the internet! Take out 12 servers and you disable a multi-billion dollar industry (are you listening cisco, microsoft, intel, ....??) The only reliable protection of the internet from this weakness is to allow the free and open duplication by anybody of the full information in the root servers and in the whois database.
Sorry, no dice. To stay somewhat within the charter, let me clarify what NSI just announced, for the really clueless (operational issue): Why? This specific situation was due to *corrupted* information being propagated to the other root nameservers, not from any network failure or physical (machine) shutdown, according to a recent NSI announcement on this topic. So by pushing for wider dissemination, just doesn't really help if it's corrupted information, and actually has potential to make things worse. Besides, duplication by unauthorized parties may lead to data integrity problems or loss of control over system, which could be a fatal blow for the Internet as we know it today. I would imagine you'd have to petition the IANA for this kind of thing - and look how far the other alternative TLDs/registries has gotten in terms of being IANA-sanctioned. Now... I would imagine that root server issues would be of the highest operational priority, for obvious reasons. So if there are known failures in the system, they're promptly taken care of. (AFAIK) Maybe not always *promptly* (as that recent snafu illustrated) but usually taken care of as soon as a problem is brought to light. I cannot speculate on how well prepared NSI is for a serious failure in their database system that they would be unable to fix, because I just don't really know anything about NSI's internal workings. Perhaps someone from NSI will comment on this, but that's extremely unlikely. Let's save the rest of this for com-priv or something? (We wouldn't want to deprive the regulars there of meaty posts, now, would we? ;-) ) -Dan Foster Internet: dsf@frontiernet.net P.S. I *really* liked that MAE-Mir idea. I'm sure the Russians would really appreciate a cash infusion that MFS/Worldcom would bring by buying co-lo space on Mir for this. ;-)
Earlier, Dan Foster said:
P.S. I *really* liked that MAE-Mir idea. I'm sure the Russians would really appreciate a cash infusion that MFS/Worldcom would bring by buying co-lo space on Mir for this. ;-)
Yeah, but that unsightly fibre run to the station would only get in the way...(not to mention make it real easy to get cut by a back-hoe...) =) -- -Myk Myk O'Leary (System Administrator) --> moleary@ironlight.com Ironlight Digital (Marketing/Design/Network) --> http://www.ironlight.com 222 Sutter Street 6th floor * San Francisco, CA 94108 * 415.646.7000 ------ FOR NETWORK PROBLEMS, WRITE TO tech-support@ironlight.com ------
- From our vantage point, it looks like most of the root nameservers have bad delegation data. Most of them return no delegation info for what should be working domains:
COM. and NET. zone files were corrupted. a-g were affected by this corruption, h-i did not take the corrupted update (perhaps they're otherwise broken), and j-m do not serve the affected zones. a was finally corrected at 6:55am, and admins of b-g were asked to reload their zones. It appears that none of said admins have done so to date.
To enable our resolvers to work properly, we've had to tell them to ignore the root nameservers which appear to have bad data. On a Bind 4.X system, one can do this with the 'bogusns' configuration directive:
bogusns 128.9.0.107&255.255.255.255 192.33.4.12&255.255.255.255 128.8.10.90&255.255.255.255 192.203.230.10&255.255.255.255 192.5.5.241&255.255.255.255 192.112.36.4&255.255.255.255 198.41.0.10&255.255.255.255 193.0.14.129&255.255.255.255 198.32.64.12&255.255.255.255 198.32.65.12&255.255.255.255
J.ROOT-SERVERS.NET. 146428 A 198.41.0.10 K.ROOT-SERVERS.NET. 146428 A 193.0.14.129 L.ROOT-SERVERS.NET. 146428 A 198.32.64.12 M.ROOT-SERVERS.NET. 146428 A 198.32.65.12 should all be fine, so please remove them from your list. --jhawk
participants (13)
-
Art Houle -
bmanning＠ISI.EDU -
Dan Foster -
Daniel R Ehrlich -
Jay R. Ashworth -
John Hawkinson -
Jordan Mendelson -
MCI Hostmaster -
MFS -
moleary＠ironlight.com -
Paul A Vixie -
randy＠psg.com -
roy alcala