IPv6 Service at k.root-servers.net and IPv6 Glue for Root Name Servers

19 February 2008

Introduction

On 4 February 2008 the IANA added IPv6 glue to the DNS root zone.

This is a first quick look at measurement data for K-root, k.root-servers.net. It is based on data taken with the DNS Statistics Collector (DSC) tool, which we highly recommend.

K-root Service Provision

K-root serves on IPv6 from two of its global instances:

• AMS-IX (Amsterdam)
• NAP of the Americas (Miami)

IPv6 Carried Queries

The bulk of the IPv6 queries are served by the AMS-IX instance. We expect though, that as the number of IPv6 peerings at the NAP of the Americas grows, that ratio will change.

The publication of the IPv6 glue in the root zone is reflected by the steep increase in the number of queries. Queries received before that time most likely resulted from monitoring efforts such as DNSMON, since they exhibit no diurnal pattern. Please note that this graphs starts at 1 February because prior to that our DSC set-up was not collecting this data.

Service Quality

This DNS Monitoring (DNSMON) graph shows round-trip times from some 30 probes to the IPv6 service address of K:

The increase in load over IPv6 has caused no change in service quality.

When you interpret the IPv6 DNSMON data, please note that DNSMON does not measure the servers themselves, but the quality of the IPv6 service at the probe locations. This includes the networks between our probes and the target servers.Please also note that there are currently fewer IPv6 probes than IPv4 probes.

Other Consequences of the Introduction of IPv6 Glue

Potential Additional Queries for Missing Glue

Clients that are not speaking EDNS will not receive a full set of glue resource records (RRs) in response to the DNS priming query. This may cause them to query for the missing glue, and there were concerns that deficient DNS implementations would cause excessive load on root servers. For more details, see: http://www.icann.org/committees/security/sac018.pdf

k.root-servers.net is configured to include all A (IPv4) glue RRs and two AAAA (IPv6) glue RRs in responses to non-EDNS speakers at this time. So one would expect an increase of queries for AAAA glue. However, the number of AAAA queries to k.root-servers.net shows no significant change after 4 February, meaning that this potential problem has not materialised:

Changes in Load Distribution Among Service Addresses due to Omitted Glue

Some root name servers are now configured in a way that does not include glue for k.root-servers.net in responses to non-EDNS speakers. Some DNS implementations might not use root name servers for which they have not received glue in the original response to the priming query. When looking at the total number of queries received at K-root we can see a slight drop in both peak and average load after 4 February:

Absolute number of queries to all instances of K-root per query type

The change is certainly not big enough to have any operational impact. Indeed, it is not clear whether it is a significant change at all, in the sense that other factors may contribute to it. The only certain way to find out would be to change the configuration of those servers omitting glue for K-root and observe the subsequent load on K-root.

Changes in the Number of Queries Using TCP

A few experts were also concerned that the omission of some glue from responses to priming queries would cause defective DNS software to retry the query using TCP. The following graph shows clearly that this has not been the case, and that the number of TCP connections to all instances of k.root-servers.net did not increase.

Absolute number of TCP connections to all instances of K

Please note that this graphs starts at 1 February because prior to that our DSC set-up was not collecting this data.

Summary

k.root-servers.net receives significantly more queries over IPv6 now that its IPv6 address has been published in the DNS root zone. Currently about 0.8% of all queries arrive over IPv6. The inclusion of IPv6 addresses for six root name servers into the DNS root zone went smoothly and as expected, and there are no operational problems or concerns.