g.root-servers.net returns NXDOMAIN for com.
g.root-servers.net is returning NXDOMAIN for all .com domains, and in fact the com zone itself. This causes all access to all of .com to fail, mail to bounce, and much woe overall. Is there a more appropriate channel for reporting problems of this sort? If so, perhaps that information could be posted at http://www.root-servers.net or in another intuitive place. .net domains seems to be ok. ~$ host -t ns msrl.com 192.112.36.4 msrl.com does not exist at G.ROOT-SERVERS.NET (Authoritative answer) ~$ host -t ns google.com 192.112.36.4 google.com does not exist at G.ROOT-SERVERS.NET (Authoritative answer) ~$ host -t ns yahoo.com 192.112.36.4 yahoo.com does not exist at G.ROOT-SERVERS.NET (Authoritative answer) ~$ host -t ns root-servers.net 192.112.36.4 root-servers.net NS ns.ripe.net root-servers.net NS ns-ext.vix.com !!! root-servers.net NS host ns-ext.vix.com does not exist root-servers.net NS rs0.internic.net ~$ host -t ns com. 192.112.36.4 com does not exist at G.ROOT-SERVERS.NET (Authoritative answer) -- Shields.
check carefully. most root servers are no longer authoritative for gTLDs. The gTLDS are being moved to their own machines.
g.root-servers.net is returning NXDOMAIN for all .com domains, and in fact the com zone itself. This causes all access to all of .com to fail, mail to bounce, and much woe overall.
... and it's about damned time too! How long did it take, four years? ... or is it five?
check carefully. most root servers are no longer authoritative for gTLDs. The gTLDS are being moved to their own machines.
g.root-servers.net is returning NXDOMAIN for all .com domains, and in fact the com zone itself. This causes all access to all of .com to fail, mail to bounce, and much woe overall.
Its not complete. It started two years ago with a few machines, the main thrust was pushed in 1h2000 and a couple remain.
... and it's about damned time too! How long did it take, four years? ... or is it five?
check carefully. most root servers are no longer authoritative for gTLDs. The gTLDS are being moved to their own machines.
g.root-servers.net is returning NXDOMAIN for all .com domains, and in fact the com zone itself. This causes all access to all of .com to fail, mail to bounce, and much woe overall.
And again: jmalcolm@nodens [~] [main] 2-860> dig ns @g.ROOT-SERVERS.NET com ; <<>> DiG 8.2 <<>> ns @g.ROOT-SERVERS.NET com ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; com, type = NS, class = IN ;; AUTHORITY SECTION: . 1D IN SOA A.ROOT-SERVERS.NET. hostmaster.nsiregistry.NET. ( 2000080301 ; serial 30M ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum ;; Total query time: 257 msec ;; FROM: nodens.uraeus.com to SERVER: g.ROOT-SERVERS.NET 192.112.36.4 ;; WHEN: Fri Aug 4 09:12:55 2000 ;; MSG SIZE sent: 21 rcvd: 97
Once upon a time, jmalcolm@uraeus.com <jmalcolm@uraeus.com> said:
And again:
jmalcolm@nodens [~] [main] 2-860> dig ns @g.ROOT-SERVERS.NET com
And again: $ dig @a.root-servers.net com ns ; <<>> DiG 8.2 <<>> @a.root-servers.net com ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 12 ;; QUERY SECTION: ;; com, type = NS, class = IN ;; ANSWER SECTION: com. 6D IN NS A.ROOT-SERVERS.NET. com. 6D IN NS E.GTLD-SERVERS.NET. com. 6D IN NS F.GTLD-SERVERS.NET. com. 6D IN NS F.ROOT-SERVERS.NET. com. 6D IN NS J.GTLD-SERVERS.NET. com. 6D IN NS K.GTLD-SERVERS.NET. com. 6D IN NS A.GTLD-SERVERS.NET. com. 6D IN NS M.GTLD-SERVERS.NET. com. 6D IN NS G.GTLD-SERVERS.NET. com. 6D IN NS C.GTLD-SERVERS.NET. com. 6D IN NS I.GTLD-SERVERS.NET. com. 6D IN NS B.GTLD-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 6D IN A 198.41.0.4 E.GTLD-SERVERS.NET. 6D IN A 207.200.81.69 F.GTLD-SERVERS.NET. 6D IN A 198.17.208.67 F.ROOT-SERVERS.NET. 6D IN A 192.5.5.241 J.GTLD-SERVERS.NET. 6D IN A 198.41.0.21 K.GTLD-SERVERS.NET. 6D IN A 195.8.99.11 A.GTLD-SERVERS.NET. 6D IN A 198.41.3.38 M.GTLD-SERVERS.NET. 6D IN A 210.176.152.18 G.GTLD-SERVERS.NET. 6D IN A 198.41.3.101 C.GTLD-SERVERS.NET. 6D IN A 205.188.185.18 I.GTLD-SERVERS.NET. 6D IN A 192.36.144.133 B.GTLD-SERVERS.NET. 6D IN A 203.181.106.5 ;; Total query time: 28 msec ;; FROM: fly.HiWAAY.net to SERVER: a.root-servers.net 198.41.0.4 ;; WHEN: Fri Aug 4 09:03:25 2000 ;; MSG SIZE sent: 21 rcvd: 434 $ Do you see g.root-servers.net listed? Then why are you asking it about com? -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Information Services I don't speak for anybody but myself - that's enough trouble.
Chris Adams writes:
Do you see g.root-servers.net listed? Then why are you asking it about com?
Because it is a root server. Note its appearance in the set of NS records below for ',', for example. If you ask g about 'com', and instead of giving an answer like the one a.ROOT-SERVERS.NET gave you, it says it *does not exist*, you will, correctly, assume that means it doesn't exist and neither do any subdomains. Hence, if you randomly query the one server that is returning NXDOMAIN for com, all com lookups will fail. Servers must be able to follow the delegation chain, which starts at the root. The fact that a.ROOT-SERVERS.NET thinks g.root-servers.net is not authoritative doesn't matter much if you ask g and it does think it is authoritative. jmalcolm@nodens [~] [main] 2-875> dig ns @a.ROOT-SERVERS.NET . ; <<>> DiG 8.2 <<>> ns @a.ROOT-SERVERS.NET . ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUERY SECTION: ;; ., type = NS, class = IN ;; ANSWER SECTION: . 6D IN NS A.ROOT-SERVERS.NET. . 6D IN NS H.ROOT-SERVERS.NET. . 6D IN NS C.ROOT-SERVERS.NET. . 6D IN NS G.ROOT-SERVERS.NET. . 6D IN NS F.ROOT-SERVERS.NET. . 6D IN NS B.ROOT-SERVERS.NET. . 6D IN NS J.ROOT-SERVERS.NET. . 6D IN NS K.ROOT-SERVERS.NET. . 6D IN NS L.ROOT-SERVERS.NET. . 6D IN NS M.ROOT-SERVERS.NET. . 6D IN NS I.ROOT-SERVERS.NET. . 6D IN NS E.ROOT-SERVERS.NET. . 6D IN NS D.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 6D IN A 198.41.0.4 H.ROOT-SERVERS.NET. 6D IN A 128.63.2.53 C.ROOT-SERVERS.NET. 6D IN A 192.33.4.12 G.ROOT-SERVERS.NET. 6D IN A 192.112.36.4 F.ROOT-SERVERS.NET. 6D IN A 192.5.5.241 B.ROOT-SERVERS.NET. 6D IN A 128.9.0.107 J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10 K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129 L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12 M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33 I.ROOT-SERVERS.NET. 6D IN A 192.36.148.17 E.ROOT-SERVERS.NET. 6D IN A 192.203.230.10 D.ROOT-SERVERS.NET. 6D IN A 128.8.10.90 ;; Total query time: 313 msec ;; FROM: nodens.uraeus.com to SERVER: a.ROOT-SERVERS.NET 198.41.0.4 ;; WHEN: Fri Aug 4 10:06:31 2000 ;; MSG SIZE sent: 17 rcvd: 436
jmalcolm@uraeus.com writes:
If you ask g about 'com', and instead of giving an answer like the one a.ROOT-SERVERS.NET gave you, it says it *does not exist*, you will, correctly, assume that means it doesn't exist and neither do any subdomains.
Currently G isn't answering queries, so it's not causing a problem. A.ROOT-SERVERS.NET and H.ROOT-SERVERS.NET don't agree as to the minimum TTL (518400 vs 172800), but that's not going to wreck anything.
Hence, if you randomly query the one server that is returning NXDOMAIN for com, all com lookups will fail.
This is why BIND 8 has the bogus characteristic, or why one may need to edit their root hint file. Too bad both require a reload/restart.
On Fri, Aug 04, 2000 at 09:03:59AM -0500, Chris Adams wrote:
Do you see g.root-servers.net listed? Then why are you asking it about com?
Because g.root-servers.net should still return a list of authoritative name servers for .com *even if* g.root-servers.net is no longer authoritative for .com. When g.root-servers.net returns an *AUTHORITATIVE NXDOMAIN* for .com things start breaking. Jeff
[ On Friday, August 4, 2000 at 09:23:48 (-0500), Jeffrey C. Ollie wrote: ]
Subject: Re: g.root-servers.net returns NXDOMAIN for com.
Because g.root-servers.net should still return a list of authoritative name servers for .com *even if* g.root-servers.net is no longer authoritative for .com.
When g.root-servers.net returns an *AUTHORITATIVE NXDOMAIN* for .com things start breaking.
I was going to write: Anyone asking g.root-servers.net for anything in .com is who's broken. Any delegation pointing .com to g.root-servers.net should have long long ago timed out from any properly running nameserver out there. but then I see this little surprise from a "host -C com.": com NS G.ROOT-SERVERS.NET com SOA record currently not present at G.ROOT-SERVERS.NET com has lame delegation to G.ROOT-SERVERS.NET When I look at the delegations directly in the two copies of the root zone now in active use (2000080400 and 2000080301) I do not find where my local copy of the above NS record originated! When I do a dumpdb I find that it has the following origination: com 81712 IN NS G.ROOT-SERVERS.NET. ;Cr=addtnl [192.203.230.10] Oddly it's not there now: # host -r -t ns com. 192.203.230.10 com NS I.GTLD-SERVERS.NET com NS B.GTLD-SERVERS.NET com NS A.ROOT-SERVERS.NET com NS E.GTLD-SERVERS.NET com NS F.GTLD-SERVERS.NET com NS F.ROOT-SERVERS.NET com NS J.GTLD-SERVERS.NET com NS K.GTLD-SERVERS.NET com NS A.GTLD-SERVERS.NET com NS M.GTLD-SERVERS.NET com NS G.GTLD-SERVERS.NET com NS C.GTLD-SERVERS.NET G.root-servers.net is also found in my cache as an NS for .ORG and .NET, neither of which should be there according to the current root zone at a.root-servers.net, nor even the older 2000080301 '.' zone still at some other root servers! org 116876 IN NS G.ROOT-SERVERS.NET. ;Cr=addtnl [192.33.4.12] NET 115866 IN NS G.ROOT-SERVERS.NET. ;Cr=addtnl [198.41.0.10] So I can see clearly where the bogus NS records came from, and I can see approximately when too (the above dump records were generated at 12:29 EDT). Does this mean someone foolishly made some radically BAD changes within the 144-hour window where no changes should have been made!?!?!?!?!? Can 'g.root-servers.net' QUICKLY be brought back online for com/org/net until the 144-hour window necessary for a root zone change properly expires? -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
participants (8)
-
bmanning＠vacation.karoshi.com -
Chris Adams -
Jeffrey C. Ollie -
jmalcolm＠uraeus.com -
Mark Milhollan -
Michael Shields -
Roeland M.J. Meyer -
woods＠weird.com