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
On 1 feb 2008, at 20:22, Scalzo, Frank wrote:
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....
We have consequently as of today started making /48 PI assignments from the following block:
2001:43f8::/29
On 1 feb 2008, at 20:22, Scalzo, Frank wrote:
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.
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.
On Tue, 05 Feb 2008, Iljitsch van Beijnum wrote:
# 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
participants (3)
-
Iljitsch van Beijnum -
Larson, Matt -
Scalzo, Frank