This is a quick update on the recent article on the surprisingly large number of repeat queries in the Domain Name System (DNS). This article, “What part of ‘No!’ is so hard for the DNS to understand?” described a scenario where we tasked many millions of users to resolve a unique DNS name (unique because we wanted to avoid conventional DNS caching).
We ran this measurement from 5 to 11 August 2026, and recorded the following results:
| Response type | Tests | Single query tests | Queries | Average queries per test | Repeats | Average repeats |
| Control | 254,894,985 | 147,233,117 | 875,316,423 | 3.43 | 408,891,797 | 3.80 |
| NXDOMAIN | 115,750,503 | 67,316,541 | 509,410,787 | 4.40 | 291,919,927 | 6.03 |
| NODATA | 115,571,398 | 64,033,517 | 454,213,932 | 3.93 | 235,724,371 | 4.57 |
| SERVFAIL | 138,643,924 | 3,702,576 | 7,171,673,166 | 51.73 | 6,920,490,780 | 51.29 |
| REFUSED | 115,415,259 | 47,625,165 | 1,324,355,211 | 11.47 | 1,106,379,779 | 16.32 |
| NO RESP | 116,050,253 | 2,519,191 | 9,685,775,212 | 83.46 | 9,466,474,491 | 83.38 |
Where there is a definitive negative response, namely NXDOMAIN and NOERROR/NODATA or a positive response, there is a common query repetition profile. On average, we see four queries per test. Some 55% to 60% of tests complete with a single query, and where repetition occurs, the average number of query repeats is between four and six.
Where there is no definitive response, the DNS slips into a behaviour mode that repeats queries. The REFUSED response is accepted with a single response 40% of the time, but in other cases of the REFUSED response, there is an average of a further 11 repeat queries. SERVFAIL and NO RESPONSE responses show a more extreme pattern of repeat queries.
It was noted in the report that these measurements were conducted using a single nameserver that is authoritative for the zone. Our measurement setup divides the Internet into six ‘zones’, and each zone uses its own namespace. These zones are North America, South America, Europe and Africa, India, Asia, and China.
Within each zone, we are using a single authoritative nameserver, so each recursive resolver is presented with a single nameserver name. This single authoritative nameserver is configured as a dual-stack server with both an IPv4 and an IPv6 address.
An obvious question is whether we would see more or fewer queries if the zone was served by more than one dual-stack nameserver. We’ve repeated just the control measurement with two authoritative dual-stack nameservers. The results are shown in Table 2.
| Number of nameservers | Tests | Single query tests | Queries | Average queries per Test | Repeats | Average repeats |
| 1 | 254,894,985 | 147,233,117 | 875,316,423 | 3.43 | 408,891,797 | 3.80 |
| 2 | 150,221,951 | 106,376,529 | 385,725,364 | 2.57 | 112,191,597 | 2.56 |
With one nameserver, 58% of the test cases completed the experiment using a single DNS query for each query type. With two nameservers, the single query rate has risen to 71%. The average number of queries per test has fallen from 3.43 to 2.57 queries, and where a query is repeated, the average number of repeat queries has fallen from 3.8 queries to 2.6 queries.
This is a completely unexpected result. The addition of this second nameserver name (and two nameserver IP addresses, in IPv4 and IPv6) appears to significantly reduce the number of repeat queries. (A ‘repeat’ is defined as a query with the same query name and query type).
We would expect an increase in the repeat query count when the number of authoritative servers increases, as an obsessive recursive resolver would query all authoritative nameservers with the same query to satisfy itself that all the nameservers are responding in a manner that is mutually consistent. In any case, this is not what was observed in this experiment.
A cumulative distribution of repeat queries over time is shown in Figure 1.
The major difference in behaviour of query duplication occurs in the first second of DNS name resolution, where slightly more than 85% of duplicate queries are received in the case of a single nameserver, while the number drops to 75% in the case of two nameservers. In the case of two nameservers there is also some form of exponential backoff behaviour, where there is a slight peak in repeat queries at 0.75 seconds, 1.5 seconds and 3 seconds. Within five seconds we have observed 90% of all repeated queries for each experiment.
A detailed view of the time distribution of repeat queries is shown in Figure 2.
In the case of a single nameserver, 17% of all repeated queries are observed within 10ms of the initial query, in a form of ‘rapid-fire’ query duplication. This rapid-fire duplication drops to 12% of all repeated queries in the case of two nameservers. A single nameserver sees local peaks of duplicate queries at 100ms, 310ms and 800ms, whereas in the two nameservers case there are peaks at 50ms, 100ms, 310ms 370ms, 750ms and 800ms.
Is this caused by resolver ‘farms’, where a query is passed across multiple back-end resolver engines over time, or by a change in the behaviour of individual resolvers? Figure 3 shows the query repetition behaviour of individual resolver addresses.
I’ve normalized the numbers from the two datasets to allow direct comparison. The difference lies in the period of between 10ms to 70ms after the initial query, where the single server case shows a significantly higher repeat volume, particularly in the period between 10ms to 40ms. This is a time interval that is normally well below most individual resolver’s individual User Datagram Protocol (UDP) timeout values. Why would an individual resolver perform query repetition in such a short time interval?
One explanation may lie in the configuration of resolver ‘farms’.
When the volume of DNS query traffic is greater than individual platforms can handle, which is often the case for large consumer Internet Service Providers (ISPs), a common approach is to use a ‘resolver farm’ where a single front end query dispatcher is placed in front of a set of individual recursive resolvers.
An example of this setup can be seen with PowerDNS’s DNSdist. It appears that a very common configuration is to incorporate a DNS relay-like function, where the front-end dispatcher paces the public Internet with a public IP address, but uses private IP addresses to communicate with individual recursive resolvers. That way, the resolver farm sits behind a single public IP address. In this case the query repetition behaviour we are seeing here could be attributed to the behaviour of these front-end systems, rather than the errant behaviour of recursive resolver implementations.
It’s unexpected to observe the query repetition volume drop when an additional authoritative nameserver is added to a domain, but as the DNS handles individual queries relatively opaquely, we cannot offer a definitive explanation of the behaviour. It could be based in a desire of a DNS front end to improve DNS resolution speed and service resilience by duplicating incoming queries across multiple resolver instances in a resolver farm when there is just a single authoritative nameserver.
However, this observed behaviour points to some practical value in the DNS operational advice of using a minimum of two nameservers to serve a zone in today’s DNS. It seems to keep recursive resolvers happy!
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.