Keeping Private Namespace Queries Private

Quad9 is a protective DNS resolver. Protecting the privacy of our users has always been our highest priority, and we are continuously looking for ways to improve both privacy and security across our service. Some of these improvements are visible features. Others, like the one described in this post, work quietly in the background. However, “protection” is not only in the form of blocking malware, phishing, and other cyber threats but also to limit leaking of unnecessary information about our users and their networks.

Every network that uses private IP addresses produces reverse DNS queries for those addresses, such as a lookup for 1.1.168.192.in-addr.arpa when a host wants a name for 192.168.1.1. These addresses are only meaningful in scope of a local network, where they are used, so no server on the public internet can ever give a useful answer. The correct behavior, long established in IETF standards, is for the local network or the recursive resolver to answer these queries itself and never send them upstream.

Quad9 has historically done this for the RFC 1918 private address ranges. We have recently extended the scope to cover all private and special-use address space and namespaces. This now includes the reverse zones for RFC 1918 addresses, the IPv4 and IPv6 special-purpose registries defined in RFC 6890 (part of BCP 153, which also covers the RFC 6598 shared address space used by carrier-grade NAT), IPv6 unique local and link-local addresses, home.arpa (RFC 8375), service.arpa (RFC 9665, Section 9), and .local (RFC 6762) along with the private-use names listed in its Appendix G, such as .internal, .intranet, .private, .corp, .home, .onion, and .lan. Queries for any of these are answered directly on our resolvers and never leave our network.

We have also started attaching Extended DNS Error (RFC 8914) code 29, registered as “Synthesized” in the IANA registry, to these responses. It tells the client that the answer was generated by the resolver itself, and no resolution was performed on its behalf. This is in line with our ongoing efforts toward transparency with our users. You can see it in action today:

The Case for Answering Locally

What we do in our treatment of these names is by no means a new idea. RFC 6303 (BCP 163), “Locally Served DNS Zones”, says in Section 1 that “there are a number of DNS zones that all iterative resolvers and recursive nameservers SHOULD automatically serve, unless intentionally configured otherwise.” Part of the reasoning is operational, because reverse queries for private addresses that leak to the public internet put a constant and unnecessary load on the root servers, and the client ends up waiting on a round trip for an answer that does not exist. Answering such queries locally is simply faster.

But the more important reason is the privacy risk. A leaked reverse query often carries more information about the end user and their network. Host names and device names show up in this traffic, and so do hints about how an internal network is laid out. Whoever receives it can quietly build a picture of what equipment people run at home or at work and when it is active. None of that information was ever meant to cross the boundary of a private network. Since Quad9 exists to protect its users, we would rather answer these queries ourselves than let them travel any further.

A Detour Through AS112

Queries that leak past the resolver have to land somewhere. For most of the internet, that somewhere is AS112, a network of anycast nameservers run by volunteers and described in RFC 7534. AS112 absorbs this traffic to keep it off the .arpa nameservers and answers everything with NXDOMAIN. The project has been doing quiet, useful work for the hygiene of the internet since 2002, running on infrastructure that operators around the world donate and operate. Anyone can become an operator by announcing the AS112 prefixes and answering queries. In fact there are many serious and hobby network operators that host an AS112 node to help make the internet a better and safer place.

But it is also where the trouble starts, because nobody verifies who is announcing those prefixes or what they do with the queries they receive. Researchers at the University of Glasgow recently measured the deployment and found 469 AS112 sites run by 97 operators, only 57 of which appear on the project’s self-reported operator list (Boswell et al., PAM 2026). In a companion study presented at DNS-OARC 46, the same group analyzed about 2.8 billion queries captured at three AS112 sites over three days in April 2025. The traffic contained much more than reverse lookups. Around 5.8% of requests were DNS dynamic updates, which can expose local network configuration. Another 18% were DNS service discovery queries, some of them looking for authentication, tunneling, and other infrastructure protocols. The risk in these queries is that whoever receives them can answer them differently than a local network would. A hostile operator could direct devices or users to connect to unexpected and potentially malicious services, and spoofed answers for the right protocols could serve as the first step in a multi-stage takeover of a network.

The authors of RFC 7534 saw this coming. Its Security Considerations (Section 8) warn that “Hosts that send queries to AS112 servers may well leak information relating to private infrastructure to the public network, and this could present a security risk. Additionally, AS112 operators may log this information, making it further subject to whatever security and privacy risks that might entail.” The same section points out that the loose coordination of the project makes a compromised or malicious node harder to detect than in a centrally managed anycast service.

None of this is a complaint about AS112 or the people who run it. The project does what it was designed to do, and the internet is better off for it. We both support the idea and the great work operators are doing to run this network and encourage more people to join the project. However its design relies on the assumption that the queries that escape to AS112 are harmless, and as we know, the measurements above suggest otherwise. Our answer is to stop these queries even earlier.

The View from Our Resolvers

Since we extended the scope of this blocking, the number of queries we answer locally has grown significantly. Much of the growth comes from networks behind carrier-grade NAT, where reverse lookups for the RFC 6598 shared address space (100.64.0.0/10) leak upstream in enormous numbers.

Quad9 now answers billions of these queries every day and, with the rise of CGNAT and constant growth of the internet, that number is increasing. We ensure none of those queries leave our network, as we blogged last month when updating our privacy policy. Each one is an answer the client gets sooner and a query that nobody else ever sees. The .arpa infrastructure and the AS112 operators carry that much less junk as a result. Most users will never notice any of this, which is rather the point.