APNIC Labs: DNS clients refuse to take NXDOMAIN for an answer, sending 4.4 queries per name

When a device asks the Domain Name System (DNS) for a name that does not exist, the authoritative server sends back a negative answer called NXDOMAIN (DNS response code 3), which means "no such domain." In theory, one clear "no" should be enough. But new measurements from APNIC Labs suggest that millions of clients and resolvers simply refuse to accept that answer the first time, sending repeat queries and multiplying the load on name servers. This behavior matters because it makes the DNS more fragile and helps explain why a particular denial-of-service attack, known as a random name attack, is so effective.

A random name attack aims to flood a domain's authoritative nameservers with queries for random nonexistent names in that zone. Because each random query is unique, caching resolvers cannot serve answers from memory, so every query reaches the authoritative server. If the attack used a constant existing name, the resolver cache would protect the authority; even a constant nonexistent name would be cached after the first response. But randomness defeats caching entirely. If enough queries arrive, the server becomes too busy to answer legitimate requests and the targeted domain can go dark. Unlike more sophisticated attacks, a random name attack does not require crafted packets or privileged control of bots; a simple script on many compromised machines can generate endless random labels under the target domain.

To understand why this works, APNIC Labs ran an experiment embedded in online advertisements. The ad script generated a DNS query for a random nonexistent name whose only authoritative servers belonged to the lab. The team then observed how many queries actually arrived at those servers. In October 2019, 60,210,983 measurements produced 142,631,272 DNS queries, an average of 2.37 queries per unique name. Four experimental servers were located in Singapore, Frankfurt, Dallas, and São Paulo, and most round-trip times were well below half a second, so network delay alone could not explain the high repetition rate. At that time, 24 percent of sampled clients had IPv6 capability and HTTPS queries were not in use, so ideal behavior would have produced roughly 75 million queries, less than half the observed total.

Fast forward to August 2026. From 5 to 11 August, the same experiment used a pool of 115,750,503 endpoints gathered through a Google Ads campaign, collected from all parts of the Internet that Google Ads reaches, with Russia being the major exception. All DNS names were randomly constructed to prevent cache hits, and the authoritative servers returned NXDOMAIN. The zone was not signed with Domain Name System Security Extensions (DNSSEC), so responses did not include NSEC or NSEC3 proof records. Servers supported UDP and TCP but no encrypted DNS transports such as DNS over TLS or DNS over HTTPS. In that week, APNIC Labs saw 509,410,787 queries, or an average of 4.40 queries per unique domain name. That is nearly double the 2019 average.

The increase has several components. 48 percent of endpoints queried for both A and AAAA records, up from 23 percent in 2019, while 51 percent asked only for A records, down from 74 percent, and 1 percent asked only for AAAA. In addition, 39 percent of endpoints generated an HTTPS record query. If every query type were sent exactly once, the total would have been 218 million queries. The remaining 291 million queries, or 57 percent of all observed lookups, came from some form of repetition. On average, each repeated name was queried an additional 2.5 times. But averages hide the detail: 67,316,541 endpoints completed resolution with no more than one query per type, while 48,433,962 endpoints were responsible for 291,919,927 repeated queries, an average repetition rate of 6.03 among those repeaters.

Why do clients and resolvers repeat a query after receiving a clear negative answer? Part of the explanation lies in the way client stub resolvers are built. A stub resolver is the small DNS library inside a device that sends queries to a recursive resolver. Because DNS normally runs over the User Datagram Protocol (UDP), there is no guarantee of delivery. If a timer expires before a response arrives, the stub resolver sends the query again, often to a different configured resolver. Microsoft's client resolver library, for example, uses a one-second timer for the first repeat, then two seconds, then four seconds, and gives up after five queries and ten seconds. Recursive resolvers have their own similar timeout logic and can also re-query authoritative servers. The general rule is that unresponsive servers will elicit further queries, but these re-queries should not multiply to the extent that they impose a significant additional load on the server. If they do, a single user query can turn into a storm, and a transient load event can become an unintentional denial of service.

The original promise of NXDOMAIN is that it is a terminating, cacheable response. A recursive resolver can cache the negative answer for the duration of its time to live (TTL) and answer repeated queries for the same name locally. But with random names, each query is new, so caching cannot help. The 2026 data shows that after a negative response, many systems still ask again, as if they do not believe the server. This raises the question of whether NXDOMAIN is the most efficient way to say no in the DNS. APNIC Labs notes that other negative responses exist, such as NOERROR with no answer data, but the comparison will be part of a separate study.

The source also touches on the problems of asking whether a name exists in the DNS. Every DNS query asks for a specific record type, such as A for IPv4 or AAAA for IPv6. The ANY query type was historically treated by some servers as a request for all records, but that creates reflection and amplification risks, especially with DNSSEC-signed zones. RFC 8482, Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY, recommends that servers answer ANY queries with a compact synthetic record such as HINFO, or with NS records, instead of dumping the full zone. This helps limit abuse and keeps the DNS more robust.

The findings are a reminder that the DNS is built on a chain of trust and retries that can be exploited when an attacker generates random nonexistent names. For ordinary internet users and website owners, the takeaway is not to assume the DNS will always behave efficiently. Using a privacy-first encrypted resolver such as AEU DNS can protect your own lookups from local spoofing and surveillance, and its caching and filtering help reduce unnecessary upstream queries. For people who run domains, choosing a DNS provider with rate limiting, anycast distribution, and DDoS protection is essential to survive a random name flood.