Measuring the use of DNS over IPv6

In theory, the design of IPv6 was such that the upper-level end-to-end transport protocols, namely TCP and UDP, need not be aware of the IP layer protocol being used. We should be able to use IPv4 and IPv6 interchangeably in the DNS, right?

This topic was the subject of an Internet Best Common Practice published in 2004, RFC 3091, ‘DNS IPv6 Transport Operational Guidelines’. This document had two major recommendations:

• Every recursive nameserver should be either IPv4-only or dual-stack.
• Every DNS zone should be served by at least one reachable nameserver using IPv4.

It’s really saying: ‘Don’t stop using IPv4 yet’! At the time, this was pragmatic advice.

A proposed revision, RFC 3901BIS, nearing publication in early 2026, includes a somewhat different set of recommendations. This document proposes that at least two nameservers for a zone are dual-stacked nameservers, which implies that every nameserver would be reachable using IPv6.

As an operational guideline for IPv6 support in the DNS, this document is saying, ‘It’s time to take IPv6 seriously’! The assumption behind RFC 3901BIS is that IPv6 is now a mature and well-understood technology, and using IPv6 as a transport for the DNS is as efficient and fast as using IPv4. But is this reasonable advice?

The main operational problem for the DNS in terms of service resilience has been in adapting large payloads to travel through size-constrained networks. IPv6 removed the ability for routers to perform ‘fragmentation on the fly’, and this has impacted the DNS when using an IPv6 UDP transport with large payloads.

What if we restrict our view to the common DNS use case, where queries and responses can sit comfortably within the 1,280-byte maximum unfragmented IPv6 packet size limit? How much of the Internet user base can reliably access a DNS server where the only form of access is via IPv6?

To answer such a question, we would need to undertake a broad measurement of Internet users and test their ability to resolve a DNS name where the only means of access is by using IPv6. The extent of end-user readiness to use IPv6 to access all forms of Internet services is a topic that has had considerable interest over many years, within the larger scheme of transitioning the entire Internet to IPv6.

The question I would like to examine is the extent of user support for DNS over IPv6. In other words, if you placed an authoritative server or two on an IPv6-only transport service, how many of the Internet users would be able to reach you?

Measuring the DNS

First, a few words of caution. In measuring the DNS, nothing is as straightforward as it sounds. When we talk about the DNS in this context, we are actually talking about the function of name resolution, and central to that is the concept of a ‘DNS resolver’.

Resolvers

So, let’s ask the question: ‘What is a DNS resolver?’

Oddly enough, there isn’t a straightforward answer. We really don’t understand what a DNS resolver is. It could be:

• A single platform running an instance of DNS resolver code.
• A collection of back-end DNS systems with some kind of front-end load distributor.
• A hybrid collection of servers with a set of semi-synchronized caches so they emulate a common cache and use that common cache in the operation of each server engine.

We’ve crudely classified DNS resolvers into:

• Stub resolvers that exist close to the end user in the end user’s device.
• Recursive resolvers that are meant to navigate through the DNS’s distributed database to resolve queried names.
• Forwarding resolvers that pass on their queries to other resolvers rather than answering them themselves.

There are more complex forms of hybrid behaviour that may be distributed across many resolution systems. All of these are called resolvers.

Not all resolvers are equal, nor are they as significant as others. A resolver might have just one client, like the DNS resolver on my local network. It might have millions, if not hundreds of millions, of clients, like some of the larger open DNS resolvers, or it could be anything in between. So when we talk about DNS resolvers, it’s quite challenging to know exactly what we’re referring to.

Deriving a measurement statistic of the form of some percentage of DNS resolvers that support queries over IPv6 is a meaningless measurement when assessing the utility of IPv6 in the DNS. The metric we’ll be using to measure the level of support for IPv6 in DNS resolution is not a count of DNS resolvers, but a count of users, as a proportion of the total estimated user population.

Queries

If you thought that was a tough DNS question, there’s another one too: ‘What is a query?’

It sounds like a silly question, but there is a point here. The resolution process used by the DNS to navigate through the DNS data structures causes a fan-out of queries. A single initial query to a recursive resolver causes that resolver to launch a sequence of discovery queries, as the resolver tries to understand where that requested information might lie within the framework of the distributed database that is the DNS.

The related issue is that, by default, the DNS uses UDP as its transport. UDP does not provide any end-to-end assurance, so the sender must wait for some period of time for a response, and if none is forthcoming in that time, it has no choice but to retry the query.

Resolvers do not behave uniformly, and implementations use their own timer selections to figure out when to re-query. The timer choice is a compromise between attempting to respond as rapidly as possible to the original DNS query and avoiding flooding the DNS with extra queries.

DNS queries have no hop count, so if a query is forwarded from one resolver to another, there’s no attached history of where the query comes from. There’s no forwarding metadata as to why the query has been forwarded, and no time-to-live to detect and remove ‘aged’ queries. The result is that the DNS resolution tends to err on the side of over-querying. Our measurements, taken at the authoritative server for a DNS name, show that 25% to 30% of individual queries get repeated within the DNS (Figure 1).

I suspect that part of the reason for this query repetition within the DNS lies with the choice to use UDP as the default transport protocol. A resolver does not know when a query has been dropped, and the best strategy for a resolver is to fan out the query to other authoritative servers, and in the case of a stub resolver, to other recursive resolvers, to compensate for unpredictable response times over a UDP transport.

APNIC’s measurement

Finally, let’s have a look at APNIC’s own measurement setup that is used to perform these kinds of measurements.

We use Google’s advertising network to seed DNS queries inside online advertising campaigns, and use parameters in the ad campaigns to get as broad a distribution of the advertisement as we can. Each advertisement contains a list of URLs, and a control script that tasks the browser to fetch each URL and then report back on the success (or failure) of each attempted fetch.

The DNS names embedded in each URL contain a component that is unique to each individual user who receives an advertisement. In that way, the DNS recursive resolvers have no cached data and are forced to query upstream towards the authoritative nameserver to resolve the presented name. We observe these recursive-to-authoritative queries by instrumenting our authoritative nameserver, and match those queries with the experiment platform’s ad placement records.

Measuring DNS over IPv6 using web fetch

To perform this measurement, we scripted an advertisement that includes a URL that uses a unique DNS name, and configured the authoritative server for that DNS name to be reachable only using IPv6.

The user can only resolve the DNS name and thereby fetch the web object if their name resolver setup supports DNS queries over IPv6. While the resolution of the DNS name relies on IPv6, the name itself is resolvable to both IPv4 (A) and IPv6 (AAAA) records.

The measurement is therefore quite straightforward. We measure the advertisement placement records and the proportion of those records where the user performs a fetch of the IPv6-over-DNS web object. The proportion of successful fetches is therefore the measurement of the Internet-wide capability of users to perform a DNS resolution using IPv6. This data is shown in Figure 2.

This appears to be a reasonable measurement. The result shows that 50% to 65% of users demonstrate their capability to resolve a DNS name that requires the use of DNS over IPv6.

We’re done, right? Well, maybe not.

You see, there’s couple of actions going on inside the user’s browser that we need to be aware of. The browser received a task to fetch a web object, given a DNS name that it must resolve first. But what if the execution of the advertisement script is terminated before the script completes? The DNS task, which may have already been passed to a resolver, will continue until completion, but when the result is passed back to the browser, there will be no subsequent web fetch. Perhaps this result is undercounting.

Is there another way to perform this measurement of IPv6 capability in the DNS using only the DNS? If this were feasible, then as soon as the task was passed into the DNS, the effort to resolve the name would continue until completion, and would not be terminated early if the ad’s control script was terminated.

Measuring DNS over IPv6 using the DNS

It is possible to perform this form of measurement completely within the DNS using a technique called ‘glueless delegation’.

When a recursive resolver asks an authoritative server for a name that does not exist within the served zone, but is contained in a delegated zone, the nameserver will return a referral response.

Delegation in the DNS lists the name of the delegated zone and the names of the nameservers that are authoritative for that zone. When an authoritative nameserver is queried for a name that is in a delegated zone, the nameserver will generate a referral response that contains the nameserver records in the Authority Section of the response. It will also contain the IP addresses of these nameservers in the Additional Section of the response (‘glue records’). If these nameserver names are contained within the delegated zone, then these glue records are essential, as there is no other way for the recursive resolver to resolve these names to their IP addresses.

However, when the names are defined in a different zone that is unrelated to the queried zone, then these glue records are not essential to the resolution. If the glue records are not present in a referral response, then the recursive resolver will need to suspend the primary task of resolving the original name and work on a sub-task of resolving the nameserver name. Once the nameserver name is resolved, it can use these IP addresses to resume the resolution of the original name.

This then provides the basis for an IPv6 capability test within the DNS, as shown in this example of a ‘glueless delegation’:

Zone: example.com
…
a	IN	NS	ns1.some.other.zone.
…
 
Zone: some.other.zone
.	IN	NS	ns0.some.other.zone.
ns0	IN	AAAA	2001:db8::1
…
ns1	IN	AAAA	2001:db8::2
…

Zone: a.example.com
.	IN	NS	ns1.some.other.zone.
.	IN	A	192.0.2.3
	IN	AAAA	2001:db8::3

In this case, a recursive resolver attempting to resolve the name a.example.com would receive a referral response with the nameserver name of ns1.some.other.zone, with no glue records. It would then need to suspend the task of resolving a.example.com, and start the resolution of the nameserver name ns1.some.other.zone. Once this resolution is completed (with the IPv6 address 2001:db8::2), it can then resume its original task and query this IPv6 address for the IP addresses of a.example.com. However, as the nameserver for some.other.zone is an IPv6-only nameserver, then the recursive nameserver can only pose this query if it supports DNS queries over IPv6 and can receive the IPv6-only DNS response.

We can test the user’s DNS environment using both methods by performing both DNS-over-IPv6 measurements within the same ad script. We expect the measurements to be reasonably well correlated, with the DNS measurement giving a slightly higher result. This is what we have observed (Figure 3). We can attribute the approximate 10% lower web-based measurement to ‘lossy’ transition from DNS resolution to a completed web fetch.

Are we justified in making this assumption?

Measurement anomalies

There are several economies in Africa that report consistent, but anomalous behaviour in this measurement, where the web-based measurement is consistently higher than the DNS-based measurement. A good example is Algeria (Figure 4), although a similar behaviour is apparent in Libya, Egypt, Mauritania, Liberia and several other mostly African economies (see APNIC Labs).

There are also economies, like Ethiopia (Figure 5), that have the opposite anomalous measurement result, where the DNS measurement is much more than 10% higher than the web measurement.

Another result also worth mentioning can be seen in the measurements for Germany, where the daily web-based and DNS-based measurements correlate very well. The level of ‘web-loss’, where the DNS result is not converted into a visible web fetch, is extremely low across the entire sampled population in that economy (Figure 6).

These results are challenging to explain within the framework of a conventional model of the DNS infrastructure, since they are attempting to measure precisely the same behaviour, among the same users, testing the same DNS resolvers.

One way to compare these two methodologies is to look at each network and compare the DNS and web measurements. This comparison is shown in Figure 7.

For less than 8% of measured endpoints, the DNS measurement was more than 10% smaller than the web measurement, while the opposite was the case for 30% of the measured endpoints. For the remaining 62% of measurement samples, the two measurements were within 10% of each other.

Figure 8 shows a breakdown of the web and DNS results daily. In 4% of cases, the web is giving a positive result showing support for DNS over IPv6, while the DNS does not provide a positive result. In 26% of cases, the DNS measurement provides a positive result, while the web result does not. In 45% of cases, both the web and the DNS provide positive measurements.

The results are certainly interesting. The DNS-only measurement is more robust, in that we see the DNS operate through glueless delegation more reliably, and while there are networks where a lack of glue records appears to block the resolution of domain names, this appears to affect 3% of the total user count.

The overall result is that we see an overall capability of 75% of users who can use DNS over IPv6.

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.