Summary

  • Adding a second authoritative server name and one IPv4 and one IPv6 address coincided with average observed queries per test falling from 3.43 to 2.57; the share of tests producing a single query rose from 58% to 71%.
  • APNIC Labs did not establish a cause. The result is evidence against treating one public resolver address as one stable resolver process, client or retry state.
  • A defensible incident record links the client request, dispatcher, backend engine, cache decision, authoritative destination, response and retry into one resolution chain.
Observation One authoritative server Two authoritative servers
Tests 254,894,985 150,221,951
Total queries 875,316,423 385,725,364
Queries per test 3.43 2.57
Tests with one query 58% 71%
Average repeats in repeating tests 3.80 2.56

A small configuration change moved a large behavioural number

The result begins with a clean intervention. In the control described in APNIC Labs’ experiment, the experimental zone had one dual-stack authoritative server. The later configuration added another authoritative server name, with an IPv4 and an IPv6 address of its own. The response remained positive. This was not an outage test and not a comparison between NXDOMAIN and SERVFAIL.

Yet the authoritative logs changed sharply. Across nearly 255 million control tests, the single-server setup received 875 million queries, an average of 3.43 per test. With two servers, 150 million tests generated 386 million queries, or 2.57 per test. Single-query tests went from 58% to 71%. Among tests that repeated, the mean repeat count fell from 3.80 to 2.56.

Those figures are not a universal performance verdict. The two samples cover different volumes, and the experiment cannot expose every state between a user’s stub and the authoritative edge. Its value lies in the discontinuity. A change at the destination side altered what looked, from the authoritative side, like the behaviour of recursive resolvers.

The timings do not fit one simple timeout story

Most repeats arrived quickly. In the one-server condition, about 85% of duplicates arrived within the first second; in the two-server condition, about 75% did. Roughly 90% had arrived within five seconds in both cases. The one-server distribution had visible peaks near 100, 310 and 800 milliseconds. The two-server distribution introduced additional peaks near 50, 370 and 750 milliseconds while retaining others.

The largest difference lay between 10 and 70 milliseconds, particularly from 10 to 40 milliseconds. That interval is too short to explain comfortably as a conventional per-query UDP timeout. “Rapid fire” repetitions inside 10 milliseconds also fell, from about 17% of repeats to 12%. The timing evidence therefore points to more than a single endpoint waiting, expiring and trying again.

The adjacent APNIC negative-response study provides a useful boundary. There, response class visibly changed amplification: positive responses averaged 3.43 queries per test, while SERVFAIL averaged 51.73 and no response 83.46. That work concerns failure handling and caching. The second-nameserver observation concerns positive answers under a changed authoritative topology. Conflating the two would make the present result easier to explain than it is.

One address can conceal a scheduling system

APNIC offers a plausible, expressly unproven possibility: some public recursive services place a dispatcher in front of a farm of recursive engines. The client sends to one public IP address. The front end chooses a backend. More than one backend may lack the relevant cache entry, or may pursue the same logical request without sharing complete state. At the authoritative service, their packets can still appear under the same public source address.

This is an ordinary topology, not an exotic one. The official dnsdist manual describes a DNS-aware load balancer that receives queries, sends them to downstream servers and relays responses. Its selection policies include least-outstanding, hashing and weighted choices. Its tuning guidance discusses multiple listener and response threads and even registering the same downstream more than once. These facts establish possibility, not attribution. Nothing in the APNIC traces proves that any measured resolver ran dnsdist, or that backend dispatch caused the fall.

That distinction matters. A public address is excellent for routing. It is a poor default key for joining every observation into a single actor. Network address translation, anycast, load balancing, thread pools, backend retries and state replication can all make several execution contexts look like one endpoint—or one logical resolution look like several packets.

The query tuple is necessary and still insufficient

The experiment counts another observation of the same query name and query type as a repeat. Protocol work supplies further discriminators. RFC 9520 separates server, address and transport, and describes a query tuple of QNAME, QTYPE and QCLASS. RFC 1035 adds the 16-bit message ID used by a requester to match a response with an outstanding query.

Even those fields do not reconstruct the whole act. Message IDs may be rewritten at a dispatcher. Separate backends can choose the same value. The authoritative observer cannot see a cache hit that caused no upstream packet, the original client transaction, the backend chosen, the local timer that expired, or the decision that declared the resolution complete. An authoritative packet record is real evidence, but it belongs to one reality layer: arrival at that authoritative interface.

The stronger model is a chain of receipts. A client-facing receipt identifies the request and its deadline. A dispatcher receipt names the chosen backend. The recursive engine records cache state, delegation state and its QNAME/QTYPE/QCLASS work item. Each outbound attempt records server name, address, transport and send time. Each inbound response records class and validation outcome. A retry receipt records the timer or error that authorized another attempt. A completion receipt closes the logical resolution and connects the answer returned to the initiating request.

No single organization necessarily owns this whole chain. That is precisely why operators should not let the easiest shared field—the public resolver address—pretend to be the missing join key.

Redundancy and observability answer different questions

RFC 2182 explains why zones need multiple authoritative servers and why topological and geographic separation matters. It also warns that more servers carry operational cost. APNIC’s result does not replace that engineering logic with “two is faster.” It asks a different question: why did the resolver population send fewer observable copies after the authoritative choice set expanded?

The answer could involve selection diversity, address-family behaviour, dispatcher scheduling, shared cache state, racing or another mechanism not visible in the study. A careful operator preserves these alternatives. The empirical claim is strong and narrow: the distribution changed. The causal claim remains open.

Sources