Quad9 Release Notes

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:

[Terminal output showing a kd ig command querying reverse DNS for 192.168.1.1 via 9.9.9.9 with status NXDOMAIN and EDNS pseudo section details.]

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.

Quad9 is enabling DNSSEC validation on its remaining non-validating resolver address. Starting June 15, 2026, DNSSEC strict validation will be active across every Quad9 service endpoint.

Background: Quad9’s Service Endpoints

Quad9 offers several resolver addresses that differ along two main dimensions: whether Threat Protection is active, and whether EDNS Client Subnet (ECS) is enabled. Users who want Threat Protection can use 9.9.9.9; users who need ECS for CDN routing accuracy can use the ECS-enabled endpoint; users who want neither can continue using 9.9.9.10. Historically, the resolver at 9.9.9.10 (149.112.112.10 / 2620:fe::10) has operated without Threat Protection, without ECS, and without DNSSEC validation, and resolver at 9.9.9.12 only provided ECS, without Threat Protection. From June 15 2026,all of these options will have DNSSEC validation enabled.

With this change, Quad9’s service matrix remains the same in every respect except one. Users who want Threat Protection can use 9.9.9.9; users who need ECS for CDN routing accuracy can use the ECS-enabled endpoint; users who want neither Threat Protection nor ECS can continue using 9.9.9.10, and 9.9.9.12 will be available for users who only want to have ECS, without Threat Protection. What changes is that all of these options now have DNSSEC validation enabled by default.

DNSSEC as a Baseline

DNSSEC validation applies only to zones signed by their operators. For those zones, DNSSEC allows a validating resolver to authenticate the origin and integrity of the DNS data it receives, as defined in RFC 4033. Without it, a resolver has no mechanism to detect manipulation in transit and must simply trust that what it receives is correct - an assumption which may be false when adversaries are attempting to spoof DNS data for criminal or other purposes.

Quad9 has long held that DNSSEC validation is not something a security-focused resolver should make optional. Our post on

Negative Trust Anchors

covers that thinking in depth, including how we handle cases where DNSSEC validation causes problems in practice. Leaving resolver addresses without strict DNSSEC validation sends an implicit message that DNS integrity checking is optional depending on which endpoint a user picks. In the last several years, the decreasing number of reported DNSSEC problems have led us to feel comfortable adding DNSSEC to 9.9.9.10 and 9.9.9.12. These service addresses have been exempted from DNSSEC validation (and blocklist application) as a method to provide a workaround for domains or users who were running into persistent DNSSEC problems. Nearly ten years has passed since we originally made those decisions, and the improvements in DNSSEC stability and requirements for DNS integrity has led us to finally remove this insecure exemption from our service set. Now we will provide that service address only with an exemption from malicious site blocking - essentially equivalent to an “off-the-shelf” DNS resolver with no special filters. This matches the behavior seen in several open-source DNS recursive resolver software platforms which now come with DNSSEC strict validation enabled by default, and we hope that trend expands further.

What Changes for Users

For most users, this change will be invisible. Queries to 9.9.9.10 and 9.9.9.12 will continue to resolve correctly for well-configured domains, and the behavior around our service addresses which provide threat protection and ECS remains unchanged. The one change: 9.9.9.10 and 9.9.9.12 will now return SERVFAIL for DNSSEC failures, whether caused by misconfiguration or a tampered response. This brings these service addresses in line with all other Quad9 addresses.

Users who specifically chose 9.9.9.10 as a non-validating reference for testing or diagnostics and 9.9.9.12 for its ECS feature without Threat Blocking, should keep this in mind after June 15, 2026. If you need a non-validating resolver for comparison purposes, you will need to use one outside of Quad9’s network. We believe that for everyday use DNSSEC validation working quietly in the background is exactly what you want, and this conversion is one more thing that ensures the security and trustworthiness of responses you receive from Quad9.

The QUIC Protocol

Quad9 has enabled DNS over HTTP/3 (DoH3) and DNS over QUIC (DoQ) across its global resolver network. DNS transport protocols have continued to evolve since Quad9 first launched and following that evolution is part of how Quad9 serves users who care about the privacy and security of their queries.

Both protocols are built on QUIC as the underlying transport protocol, and that is where most of their improvements over existing encrypted DNS transports come from.

QUIC was designed as a general-purpose transport protocol with encryption as a core requirement, not an afterthought. Every QUIC connection is encrypted, and there is no such thing as cleartext mode. QUIC also requires TLS 1.3 specifically, which is faster and more cryptographically secure than earlier versions. Quad9 already requires a minimum of TLS 1.2 on its DoH service, so QUIC-based transports take that further. This is the architectural difference from TCP, where TLS is a separate layer negotiated after the connection is established. Similarly, the UDP protocol (which is still used in the majority of queries Quad9 processes) is unencrypted in almost all cases.

Some of the inherent limitations of TCP-based DNS protocols are addressed directly in QUIC’s design. TCP carries metadata that TLS alone cannot protect including packet sequence numbers, connection flags, and other transport-level information that remains visible on the network path regardless of whether the payload is encrypted. In QUIC, more of the transport is protected than in TCP+TLS including packet numbers and parts of the header, which reduces how much can be inferred by an on-path observer.

QUIC also reduces connection setup time. A new TLS-over-TCP connection requires the TCP handshake to complete before the TLS handshake can begin. QUIC merges these steps, reaching an encrypted session in fewer round trips. DNS is latency-sensitive by nature, so lower connection setup overhead has a real effect on response times. QUIC also allows clients to move between networks without unnecessary renegotiation overhead, so an active session survives a network change where a TCP-based transport would not.

DNS over HTTP/3

DoH3 is DNS over HTTPS (RFC 8484) carried over HTTP/3, which runs on top of QUIC. For anyone already using Quad9’s DoH endpoint at https://dns.quad9.net/dns-query, no configuration change is needed.

Quad9 signals its HTTP/3 availability through several standard mechanisms. Clients configured with only the resolver’s IP address can use DDR (Discovery of Designated Resolvers) by querying SVCB records at _dns.resolver.arpa to learn which encrypted transports are supported. Clients that already know the resolver hostname use SVCB records for dns.quad9.net as the primary source of protocol discovery; HTTPS records for the same name are also published for consistency. For clients that initially connect over HTTP/2, Quad9 returns an alt-svc header indicating that HTTP/3 is available, which the client may use to attempt an upgrade. Clients that implement any of these mechanisms can upgrade to DoH3 automatically. Notably, modern versions of Chrome or Chromium-based systems perform this update without intervention by the end user.

DoH3 has meaningful deployment across the broader web ecosystem already. Browsers and CDN infrastructure have been supporting HTTP/3 for some time, which means the client-side libraries and tooling are mature. Quad9 supporting it means users do not have to trade away that infrastructure maturity in exchange for a resolver that takes privacy seriously.

DNS over QUIC

DoQ, defined in RFC 9250, is a different design choice. Rather than layering DNS inside HTTP, it carries DNS queries directly over QUIC. There is no HTTP stack involved; the protocol is purpose-built for DNS. Clients connect on port 853, the same port used by DNS over TLS.

DoQ is still earlier in its adoption than DoH and DoT. Quad9 is making it available globally with the aim of contributing to broader adoption - we believe more choices for user privacy are always a better outcome. Client developers, router firmware maintainers, and privacy-focused software authors need production infrastructure to build and test against; a specification without a widely-deployed implementation is harder for the ecosystem to pick up. Quad9’s approach with DoQ mirrors its earlier approach with DoT: deploy it in production, at scale, to give the people building DNS clients something real to work with.

Using DoH3 and DoQ

For DoH3, no changes are needed. Clients that implement DDR, DNS SVCB, HTTPS discovery, or Alt-Svc handling can discover and use HTTP/3 automatically without changing the configured DoH endpoint.

For DoQ, use the hostname for the Quad9 service variant you want on port 853.

Both protocols are available across all Quad9 variants. The filtering resolver, the non-filtering resolver, and the ECS-enabled endpoint all support DoH3,DoQ, DOH (version 2), DOT, and DNSCrypt equally.

What Comes Next

DNS protocol adoption tends to move gradually. DoT had a long runway from specification to widespread client support. DoH moved faster, largely because it ran on infrastructure that already existed for other purposes, namely web browsers. QUIC-based protocols have a head start on that front as well. QUIC libraries and tooling are already deployed at scale for web traffic, which lowers the barrier for DNS clients to add support.

Quad9 will continue tracking how the ecosystem around DoH3 and DoQ develops. If you work on resolver client software or DNS tooling and want to test against a production DoQ deployment, now is a good time to try Quad9’s implementations, and please let us know if you encounter any issues in the process.