AAAAs in the Root and /48 Filtering

All,

As you may be aware, the DNS root zone will be updated on Monday,
February 4, with AAAA resource records for six of the root servers.
(Please see http://iana.org/reports/root-aaaa-announcement.html for
IANA's official announcement.) In preparation for this change, we have
noticed that some sites seem to be having reachability problems to the
new root server IPv6 addresses that are located in critical
infrastructure Micro-allocations (/47s or /48s), but not to the root
servers located in /32s. Further testing has shown that we can ping
these sites experiencing reachability problems when sourcing the
provider allocated (PA) space on our links that aggregates up to a /32,
but not when sourcing from the provider independent (PI) /48s of our
root servers.

With the AAAA RRs going into the root zone on Monday, now is a good time
to check your IPv6 route filters. To prevent reachability problems,
network operators should update IPv6 route filters to permit up to at
least /48s from the appropriate RIR Micro-allocation blocks.

I tried to gather as many of these blocks as I could find from the RIRs.
Notably, I wasn't able to identify anything from AfriNIC -- hopefully
someone on the list will be able to fill in that gap. This list is not
meant to be complete nor authoritative, but it does cover all of the
root server IPv6 addresses that are going live on Monday (that we are
aware of) and that are in blocks allocated as /47s or 48s.

That being said, please accept at least /48s from these blocks ASAP, or
your network may experience reachability problems to the IPv6 root
servers.

  ARIN (http://www.arin.net/reference/micro_allocations.html,
        http://www.arin.net/policy/nrpm.html#six10)
  2001:0500::/30

  RIPE
  (https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html)
  2001:7F8::/29

  APNIC (http://www.apnic.net/db/min-alloc.html)
  2001:0C00:/23
  2001:07FA:/32

  LACNIC (http://lacnic.net/en/registro/index.html)
  2001:12f8:0000::/35
  2001:12f8:4000::/35

If you are having IPv6 reachability problems to the V6 IP addresses for
a.root-servers.net and j.root-servers.net (2001:503:BA3e::2:30 and
2001:503:C27::2:30) please feel free to contact us. We may be able to
assist in getting filters updated or working around any connectivity
issues.

Thank you,

Frank Scalzo
VeriSign

I tried to gather as many of these blocks as I could find from the RIRs.
Notably, I wasn't able to identify anything from AfriNIC -- hopefully
someone on the list will be able to fill in that gap.

Hope springs eternal...

According to:

http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2007/msg00542.html

Well, that part works ok. But I'm seeing significant slowdowns when depending on an IPv6-only nameserver, and it could be that this is the culprit:

# dig B.GTLD-SERVERS.net. aaaa

; <<>> DiG 9.4.1-P1 <<>> B.GTLD-SERVERS.net. aaaa
;; global options: printcmd
;; connection timed out; no servers could be reached

Now the A and B GTLD servers do have AAAA glue in the root responses:

# dig @h.root-servers.net GTLD-SERVERS.net. ns

; <<>> DiG 9.4.1-P1 <<>> @h.root-servers.net GTLD-SERVERS.net. ns
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25901
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 15
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;GTLD-SERVERS.net. IN NS

;; AUTHORITY SECTION:
net. 172800 IN NS a.GTLD-SERVERS.net.
net. 172800 IN NS b.GTLD-SERVERS.net.
net. 172800 IN NS c.GTLD-SERVERS.net.
net. 172800 IN NS d.GTLD-SERVERS.net.
net. 172800 IN NS e.GTLD-SERVERS.net.
net. 172800 IN NS f.GTLD-SERVERS.net.
net. 172800 IN NS g.GTLD-SERVERS.net.
net. 172800 IN NS h.GTLD-SERVERS.net.
net. 172800 IN NS i.GTLD-SERVERS.net.
net. 172800 IN NS j.GTLD-SERVERS.net.
net. 172800 IN NS k.GTLD-SERVERS.net.
net. 172800 IN NS l.GTLD-SERVERS.net.
net. 172800 IN NS m.GTLD-SERVERS.net.

;; ADDITIONAL SECTION:
a.GTLD-SERVERS.net. 172800 IN A 192.5.6.30
b.GTLD-SERVERS.net. 172800 IN A 192.33.14.30
c.GTLD-SERVERS.net. 172800 IN A 192.26.92.30
d.GTLD-SERVERS.net. 172800 IN A 192.31.80.30
e.GTLD-SERVERS.net. 172800 IN A 192.12.94.30
f.GTLD-SERVERS.net. 172800 IN A 192.35.51.30
g.GTLD-SERVERS.net. 172800 IN A 192.42.93.30
h.GTLD-SERVERS.net. 172800 IN A 192.54.112.30
i.GTLD-SERVERS.net. 172800 IN A 192.43.172.30
j.GTLD-SERVERS.net. 172800 IN A 192.48.79.30
k.GTLD-SERVERS.net. 172800 IN A 192.52.178.30
l.GTLD-SERVERS.net. 172800 IN A 192.41.162.30
m.GTLD-SERVERS.net. 172800 IN A 192.55.83.30
a.GTLD-SERVERS.net. 172800 IN AAAA 2001:503:a83e::2:30
b.GTLD-SERVERS.net. 172800 IN AAAA 2001:503:231d::2:30

;; Query time: 324 msec
;; SERVER: 2001:500:1::803f:235#53(2001:500:1::803f:235)
;; WHEN: Tue Feb 5 10:47:51 2008
;; MSG SIZE rcvd: 506

However, I'm thinking this is the reason why BIND isn't using that glue:

# dig @2001:503:a83e::2:30 GTLD-SERVERS.net. ns

; <<>> DiG 9.4.1-P1 <<>> @2001:503:a83e::2:30 GTLD-SERVERS.net. ns
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48256
;; flags: qr rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 8
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;GTLD-SERVERS.net. IN NS

;; ANSWER SECTION:
GTLD-SERVERS.net. 172800 IN NS a2.nstld.com.
GTLD-SERVERS.net. 172800 IN NS c2.nstld.com.
GTLD-SERVERS.net. 172800 IN NS d2.nstld.com.
GTLD-SERVERS.net. 172800 IN NS e2.nstld.com.
GTLD-SERVERS.net. 172800 IN NS f2.nstld.com.
GTLD-SERVERS.net. 172800 IN NS g2.nstld.com.
GTLD-SERVERS.net. 172800 IN NS h2.nstld.com.
GTLD-SERVERS.net. 172800 IN NS l2.nstld.com.

;; ADDITIONAL SECTION:
a2.nstld.com. 172800 IN A 192.5.6.31
c2.nstld.com. 172800 IN A 192.26.92.31
d2.nstld.com. 172800 IN A 192.31.80.31
e2.nstld.com. 172800 IN A 192.12.94.31
f2.nstld.com. 172800 IN A 192.35.51.31
g2.nstld.com. 172800 IN A 192.42.93.31
h2.nstld.com. 172800 IN A 192.54.112.31
l2.nstld.com. 172800 IN A 192.41.162.31

;; Query time: 204 msec
;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30)
;; WHEN: Tue Feb 5 10:49:39 2008
;; MSG SIZE rcvd: 307

I.e., the roots and the GTLD servers disagree on who is authorative for gtld-servers.net. It would be good if this can be fixed.

# dig @h.root-servers.net GTLD-SERVERS.net. ns
[The expected response to this query--a normal referral to .net name
servers--omitted for brevity]

However, I'm thinking this is the reason why BIND isn't using that glue:

# dig @2001:503:a83e::2:30 GTLD-SERVERS.net. ns
[The expected response to this query--a normal referral to
gtld-servers.net name servers--omitted for brevity]

To recap, you queried a root server for gtld-servers.net/NS and got a
referral to the .net zone's name servers, which is to be expected.
Then you followed up and sent the same query to a .net name server
(via its IPv6 address, but that's irrelevant) and got a referral to
the gtld-servers.net name servers, also the expected response.
Everything is fine here.

I believe you might be confused by one or the other of the responses
because you might have been expecting something else. But only if the
two responses agreed would something have been wrong.

I.e., the roots and the GTLD servers disagree on who is authorative
for gtld-servers.net.

No, they do not.

Matt