Repotting report

Iljitsch_van_Beijnum · February 4, 2008, 5:33pm

# 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.

Leo_Bicknell1 · February 4, 2008, 6:36pm

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).

Christopher_Morrow · February 4, 2008, 6:42pm

; <<>> 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!

Iljitsch_van_Beijnum · February 4, 2008, 9:05pm

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

Leo_Bicknell1 · February 4, 2008, 9:11pm

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.

Joe_Abley1 · February 4, 2008, 10:20pm

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

Leo_Bicknell1 · February 4, 2008, 10:23pm

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.

David_Conrad3 · February 4, 2008, 11:38pm

Apparently, the limit on simultaneous connections was reached. I'm told they're upping the limit temporarily.

Regards,
-drc

Kevin_Loch2 · February 5, 2008, 12:50am

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 . @.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

Leo_Bicknell1 · February 5, 2008, 1:21am

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 . @.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.

Mark_Andrews1 · February 5, 2008, 1:36am

In article <D2EFA74C-EE9C-4189-BF18-43E73B7C7892@ca.afilias.info> you write:

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

Pekka_Savola · February 5, 2008, 7:10am

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.

Christopher_Morrow · February 6, 2008, 3:31am

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

Mark_Andrews1 · February 6, 2008, 5:11am

In article <75cb24520802051931y398474aja16999bdf86b995b@mail.gmail.com> you write:

> 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

Christopher_Morrow · February 6, 2008, 5:31am

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)