Repotting report
# dig @f.root-servers.net ns . +bufsize=1280 ; <<>> DiG 9.3.1 <<>> @f.root-servers.net ns . +bufsize=1280 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17525 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30 K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:7fd::1 L.ROOT-SERVERS.NET. 3600000 IN A 199.7.83.42 M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33 M.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:dc3::35 ;; Query time: 6 msec ;; SERVER: 192.5.5.241#53(192.5.5.241) ;; WHEN: Mon Feb 4 18:28:37 2008 ;; MSG SIZE rcvd: 615 So far so good. But with a default buffer size: # dig @f.root-servers.net ns . ; <<>> DiG 9.3.1 <<>> @f.root-servers.net ns . ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45287 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30 ;; Query time: 6 msec ;; SERVER: 192.5.5.241#53(192.5.5.241) ;; WHEN: Mon Feb 4 18:29:20 2008 ;; MSG SIZE rcvd: 500 At the time of this writing A just went live, after F and M and some others, but B, C, D and G seem to need a bit more time to get used to the new situation.
I have been using queries like these to test: dig any . @f.root-servers.net | egrep "(DiG 9|AAAA)" dig +bufsize=1400 any . @f.root-servers.net | egrep "(DiG 9|AAAA)" The first offers up a standard DNS query, the second an EDNS0 query of 1400 bytes. In a standard query you're only going to get 3 AAAA records, EDNS0 should allow for all of them. There are currently 6 servers with AAAA records: % dig any . @f.root-servers.net | egrep "(DiG 9|AAAA)" ; <<>> DiG 9.5.0b2 <<>> any . @f.root-servers.net A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 % dig +bufsize=1400 any . @f.root-servers.net | egrep "(DiG 9|AAAA)" ; <<>> DiG 9.5.0b2 <<>> +bufsize=1400 any . @f.root-servers.net A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30 K.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:7fd::1 M.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:dc3::35 It is also the case that various servers are still getting up to date; virtually all the root servers are more than one machine either load balanced or anycasted. As a result YMMV until everything is in sync again. Rest assured, those who run root servers are paying very close attention today. I've already helped people fix two problems, both a result of ISP's filtering the RIR's micro-allocation blocks in ways they should not be doing. Please, if you have IPv6 filters make sure you've updated them to allow down to a /48 in the various RIR's micro allocation blocks (recently posted to nanog by someone else). -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 4 feb 2008, at 19:36, Leo Bicknell wrote:
In a standard query you're only going to get 3 AAAA records, EDNS0 should allow for all of them.
Actually I get (almost?) always 10 As and 4 AAAAs from A and J running "VGRS4", C, D, E and F running BIND 9.3.2-P1 - 9.4.2 and G and I running unknown software. H, K and L run different versions of NSD and give me the 13 As and two AAAAs, as do B running BIND 8.4.1-REL and M running BIND 9.4.2 (?). With EDNS0 the packet size increases to 615 bytes and they all serve up all glue records since about 30 minutes ago.
Rest assured, those who run root servers are paying very close attention today.
I've already helped people fix two problems, both a result of ISP's filtering the RIR's micro-allocation blocks in ways they should not be doing.
:-) I was expecting trouble because of truncated responses that need a retry over TCP, but that doesn't happen, at least not with the dig tool. So apparently firewalls aren't going to cause trouble after all. And the new named.root has arrived: ftp://rs.internic.net/domain/named.root
In a message written on Mon, Feb 04, 2008 at 10:05:40PM +0100, Iljitsch van Beijnum wrote:
Actually I get (almost?) always 10 As and 4 AAAAs from A and J running "VGRS4", C, D, E and F running BIND 9.3.2-P1 - 9.4.2 and G and I running unknown software. H, K and L run different versions of NSD and give me the 13 As and two AAAAs, as do B running BIND 8.4.1-REL and M running BIND 9.4.2 (?).
I'll go back to the part where I'm not a DNS expert. :) I get 8 A's + 3 AAAA's in my attempts at a regular query. Seems to be the same across all servers that return AAAA's. I'm using dig 9.5.0b2 for what it's worth.
With EDNS0 the packet size increases to 615 bytes and they all serve up all glue records since about 30 minutes ago.
Actually, just to be sure I set my EDNS0 packet size to 1400. However, I agree with your assessment, using EDNS0 I get 100% of the answers from all 13 servers over IPv4, and from all 6 IPv6 capable servers over IPv6. There are still a number of servers returning zero AAAA's when queried with a regular query over both IPv4 and IPv6. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On 4-Feb-2008, at 16:05, Iljitsch van Beijnum wrote:
And the new named.root has arrived:
ftp://rs.internic.net/domain/named.root
I seem to think it has become fairly widespread practice for people to refresh their named.root files (or whatever they decide to call it) using something like this: $ dig . NS >named.root This worked before today. From today, it still works (in the sense that it will still result in a named.root file which is sufficiently complete in most situations for a nameserver to be able to send a priming query) but it won't contain a complete set of glue. So, if you're in the habit of doing dig . NS >named.root you would ideally change that habit to something like curl -O ftp://rs.internic.net/domain/named.root instead. (Incidentally, for me, rs.internic.net is giving "530 Login incorrect" after PASS when logging in using "ftp" or "anonymous"). Joe
In a message written on Mon, Feb 04, 2008 at 05:20:20PM -0500, Joe Abley wrote:
This worked before today. From today, it still works (in the sense that it will still result in a named.root file which is sufficiently complete in most situations for a nameserver to be able to send a priming query) but it won't contain a complete set of glue.
So, if you're in the habit of doing
dig . NS >named.root
you would ideally change that habit to something like
curl -O ftp://rs.internic.net/domain/named.root
If you're willing to use an EDNS0 query, this works: dig +bufsize=1400 . NS > named.root I'm not sure if that's better or worse. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Feb 4, 2008, at 2:20 PM, Joe Abley wrote:
instead. (Incidentally, for me, rs.internic.net is giving "530 Login incorrect" after PASS when logging in using "ftp" or "anonymous").
Apparently, the limit on simultaneous connections was reached. I'm told they're upping the limit temporarily. Regards, -drc
In article <D2EFA74C-EE9C-4189-BF18-43E73B7C7892@ca.afilias.info> you write:
On 4-Feb-2008, at 16:05, Iljitsch van Beijnum wrote:
And the new named.root has arrived:
ftp://rs.internic.net/domain/named.root
I seem to think it has become fairly widespread practice for people to refresh their named.root files (or whatever they decide to call it) using something like this:
$ dig . NS >named.root
This worked before today. From today, it still works (in the sense that it will still result in a named.root file which is sufficiently complete in most situations for a nameserver to be able to send a priming query) but it won't contain a complete set of glue.
So, if you're in the habit of doing
dig . NS >named.root
you would ideally change that habit to something like
curl -O ftp://rs.internic.net/domain/named.root
Why? dig is quite capable of coping. Depending apon dig's age and firewall configuration one or more of these will work. dig +edns=0 . NS @a.root-servers.net > named.root dig +bufsize=1200 . NS @a.root-servers.net > named.root dig +vc . NS @a.root-servers.net > named.root As none of these sets DO, they should suffice for the foreseeable future. When DNSSEC is deployed for the root and root-servers.net you will want to do crypto checks. Even then the above queries won't break. Mark
instead. (Incidentally, for me, rs.internic.net is giving "530 Login incorrect" after PASS when logging in using "ftp"
Joe
Leo Bicknell wrote:
I have been using queries like these to test:
dig any . @f.root-servers.net | egrep "(DiG 9|AAAA)" dig +bufsize=1400 any . @f.root-servers.net | egrep "(DiG 9|AAAA)"
The first offers up a standard DNS query, the second an EDNS0 query of 1400 bytes.
In a standard query you're only going to get 3 AAAA records, EDNS0 should allow for all of them. There are currently 6 servers with AAAA records:
% dig any . @f.root-servers.net | egrep "(DiG 9|AAAA)" ; <<>> DiG 9.5.0b2 <<>> any . @f.root-servers.net A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235
There is an interesting variation in what records are returned for a standard 512 byte request (dig ns . @[x].root-servers.net): A,C,D,E,F,G,I,J: return the same 10 A records and 4 AAAA records in the same order every time. They never return A records for K,L,M and never get AAAA records for K,M. B: returns all 13 A records in random order and then two AAAA records in random order. This allows all records to be returned with equal weight within each record type. H,K,L,M: return all 13 A records in static order and then A and F AAAA records so H,J,K,M AAAA records are never returned. Tested with dig 9.4.1-p1 on a v6 enabled system. - Kevin
In a message written on Mon, Feb 04, 2008 at 07:50:50PM -0500, Kevin Loch wrote:
There is an interesting variation in what records are returned for a standard 512 byte request (dig ns . @[x].root-servers.net):
A,C,D,E,F,G,I,J: return the same 10 A records and 4 AAAA records in the same order every time. They never return A records for K,L,M and never get AAAA records for K,M.
B: returns all 13 A records in random order and then two AAAA records in random order. This allows all records to be returned with equal weight within each record type.
H,K,L,M: return all 13 A records in static order and then A and F AAAA records so H,J,K,M AAAA records are never returned.
Tested with dig 9.4.1-p1 on a v6 enabled system.
I concur. An interesting thing I noticed that doesn't really cause an operational problem but may confuse some people is their behavior is also quite different when queried for "any". If your a lazy admin like me who is used to typing "dig any foo" for testing you may try "dig any . @[a-m].root-servers.net." When I do that, I get the following response: a, c, d e, f, g, i and j return 1 SOA, 8 A, and 3 AAAA's (the first 3). b, h, l, k, and m return 1 SOA, 13 A, no AAAA records. If you make this mistake you might think b, h, l, k and m have no IPv6 data, which is wrong. Querying with NS (as nameserver would do) clearly shows that. While a cosmetic problem, I fear it may confuse a number of admins as the troubleshoot problems in the near future. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Mon, 4 Feb 2008, Leo Bicknell wrote:
may try "dig any . @[a-m].root-servers.net."
When I do that, I get the following response:
a, c, d e, f, g, i and j return 1 SOA, 8 A, and 3 AAAA's (the first 3). b, h, l, k, and m return 1 SOA, 13 A, no AAAA records.
If you make this mistake you might think b, h, l, k and m have no IPv6 data, which is wrong. Querying with NS (as nameserver would do) clearly shows that.
While a cosmetic problem, I fear it may confuse a number of admins as the troubleshoot problems in the near future.
It certainly will. Section 1.4 of RFC 4472 may be helpful here, though it mainly talks about this from the viewpoint of caching, not root servers. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Feb 5, 2008 2:10 AM, Pekka Savola <pekkas@netcore.fi> wrote:
On Mon, 4 Feb 2008, Leo Bicknell wrote:
may try "dig any . @[a-m].root-servers.net."
When I do that, I get the following response:
a, c, d e, f, g, i and j return 1 SOA, 8 A, and 3 AAAA's (the first 3). b, h, l, k, and m return 1 SOA, 13 A, no AAAA records.
If you make this mistake you might think b, h, l, k and m have no IPv6 data, which is wrong. Querying with NS (as nameserver would do) clearly shows that.
While a cosmetic problem, I fear it may confuse a number of admins as the troubleshoot problems in the near future.
It certainly will. Section 1.4 of RFC 4472 may be helpful here, though it mainly talks about this from the viewpoint of caching, not root servers.
So, how will this sort of thing affect traffic levels to the servers in question? Will this affect stability on a v6only or v4-limited site/network? (13 v4 servers, 4 v6 servers...) How does a cache-resolver know that it's time to issue a query with edns0? Having inconsistent information seems like it might cause more than just troubleshooting headaches... -Chris
In article <75cb24520802051931y398474aja16999bdf86b995b@mail.gmail.com> you write:
On Feb 5, 2008 2:10 AM, Pekka Savola <pekkas@netcore.fi> wrote:
On Mon, 4 Feb 2008, Leo Bicknell wrote:
may try "dig any . @[a-m].root-servers.net."
When I do that, I get the following response:
a, c, d e, f, g, i and j return 1 SOA, 8 A, and 3 AAAA's (the first 3). b, h, l, k, and m return 1 SOA, 13 A, no AAAA records.
If you make this mistake you might think b, h, l, k and m have no IPv6 data, which is wrong. Querying with NS (as nameserver would do) clearly shows that.
While a cosmetic problem, I fear it may confuse a number of admins as the troubleshoot problems in the near future.
It certainly will. Section 1.4 of RFC 4472 may be helpful here, though it mainly talks about this from the viewpoint of caching, not root servers.
So, how will this sort of thing affect traffic levels to the servers in question? Will this affect stability on a v6only or v4-limited site/network? (13 v4 servers, 4 v6 servers...)
How does a cache-resolver know that it's time to issue a query with edns0?
cache-resolver that support EDNS0 will make EDNS0 queries by default. They will fallback to plain DNS if the query fails or they get a response that indicated the authoritative server doesn't support EDNS. BIND's been making EDNS0 queries for ~8 years now. If your cache-resolver doesn't support EDNS it is long past time to upgrade. Mark
Having inconsistent information seems like it might cause more than just troubleshooting headaches...
-Chris
On Feb 6, 2008 12:11 AM, Mark Andrews <Mark_Andrews@isc.org> wrote:
(from me) How does a cache-resolver know that it's time to issue a query with edns0?
cache-resolver that support EDNS0 will make EDNS0 queries by default. They will fallback to plain DNS if the query fails or they get a response that indicated the authoritative server doesn't support EDNS.
BIND's been making EDNS0 queries for ~8 years now. If your cache-resolver doesn't support EDNS it is long past time to upgrade.
excellent, thanks! (as always). Any thoughts on the possible lack of resilence from losing 9 server names/ips in the v4 to v6 move? (and I realize that later most/all root boxes will have both addresses)
On Feb 6, 2008 12:11 AM, Mark Andrews <Mark_Andrews@isc.org> wrote:
(from me) How does a cache-resolver know that it's time to issue a query with edns0?
cache-resolver that support EDNS0 will make EDNS0 queries by default. They will fallback to plain DNS if the query fails or they get a response that indicated the authoritative server doesn't support EDNS.
BIND's been making EDNS0 queries for ~8 years now. If your cache-resolver doesn't support EDNS it is long past time to upgrade.
excellent, thanks! (as always). Any thoughts on the possible lack of resilence from losing 9 server names/ips in the v4 to v6 move? (and I realize that later most/all root boxes will have both addresses)
It won't be a issue. IPv6 capable nameservers are supposed to use EDNS (see IPv6 node requirements). The roots can be tuned to preference A vs AAAA records. Most/all currently maintained caching servers support EDNS now or the next release will support EDNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
On Feb 6, 2008, at 12:48 AM, Mark Andrews wrote:
IPv6 capable nameservers are supposed to use EDNS (see IPv6 node requirements). The roots can be tuned to preference A vs AAAA records. Most/all currently maintained caching servers support EDNS now or the next release will support EDNS.
So would there be benefit in the roots being tuned to only return AAAA if the request is EDNS? Just out of curiousity that is.
--Apple-Mail-32-671463028 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On Feb 6, 2008, at 12:48 AM, Mark Andrews wrote:
IPv6 capable nameservers are supposed to use EDNS (see IPv6 node requirements). The roots can be tuned to preference A vs AAAA records. Most/all currently maintained caching servers support EDNS now or the next release will support EDNS.
So would there be benefit in the roots being tuned to only return AAAA if the request is EDNS?
No.
Just out of curiousity that is. --Apple-Mail-32-671463028 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "> <br><div><div>On Feb 6, 2008, at 12:48 AM, Mark Andrews wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><p = style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font face=3D"Helvetica" = size=3D"3" style=3D"font: 12.0px Helvetica"><span class=3D"Apple-tab-span"= style=3D"white-space:pre"> </span>IPv6 capable nameservers are = supposed to use EDNS (see IPv6</font></p> <p style=3D"margin: 0.0px = 0.0px 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: = 12.0px Helvetica"><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>node requirements).<span = class=3D"Apple-converted-space">=A0 </span>The roots can be tuned to = preference</font></p> <p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font = face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica"><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>A vs AAAA = records.<span class=3D"Apple-converted-space">=A0 </span>Most/all = currently maintained caching</font></p> <p style=3D"margin: 0.0px 0.0px = 0.0px 0.0px"><font face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px = Helvetica"><span class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>servers support EDNS now or the next release will = support</font></p> <p style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><font = face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica"><span = class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>EDNS.</font></p> </blockquote></div><br><div>So would there be = benefit in the roots being tuned to only return AAAA if the request is = EDNS?</div><div><br class=3D"webkit-block-placeholder"></div><div>Just = out of curiousity that is.</div></body></html>=
--Apple-Mail-32-671463028-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
; <<>> DiG 9.3.2 <<>> . NS @2001:503:c27::2:30 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37303 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 L.ROOT-SERVERS.NET. 3600000 IN A 199.7.83.42 M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33 ;; Query time: 75 msec ;; SERVER: 2001:503:c27::2:30#53(2001:503:c27::2:30) ;; WHEN: Mon Feb 4 13:41:08 2008 ;; MSG SIZE rcvd: 436 hey j-root, UPDATE! :) On Feb 4, 2008 12:33 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
# dig @f.root-servers.net ns . +bufsize=1280
; <<>> DiG 9.3.1 <<>> @f.root-servers.net ns . +bufsize=1280 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17525 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN NS
;; ANSWER SECTION: . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30 K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:7fd::1 L.ROOT-SERVERS.NET. 3600000 IN A 199.7.83.42 M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33 M.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:dc3::35
;; Query time: 6 msec ;; SERVER: 192.5.5.241#53(192.5.5.241) ;; WHEN: Mon Feb 4 18:28:37 2008 ;; MSG SIZE rcvd: 615
So far so good. But with a default buffer size:
# dig @f.root-servers.net ns .
; <<>> DiG 9.3.1 <<>> @f.root-servers.net ns . ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45287 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION: ;. IN NS
;; ANSWER SECTION: . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:2f::f G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:500:1::803f:235 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 J.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:c27::2:30
;; Query time: 6 msec ;; SERVER: 192.5.5.241#53(192.5.5.241) ;; WHEN: Mon Feb 4 18:29:20 2008 ;; MSG SIZE rcvd: 500
At the time of this writing A just went live, after F and M and some others, but B, C, D and G seem to need a bit more time to get used to the new situation.
participants (9)
-
Christopher Morrow -
David Conrad -
Iljitsch van Beijnum -
Joe Abley -
John Payne -
Kevin Loch -
Leo Bicknell -
Mark Andrews -
Pekka Savola