Quad9 Enables DNSSEC on All Service Endpoints

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. 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. 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 one resolver address 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. This service address had 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 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 will now return SERVFAIL for DNSSEC failures, whether caused by misconfiguration or a tampered response. This brings that service address in line with all other Quad9 addresses.

Users who specifically chose 9.9.9.10 as a non-validating reference for testing or diagnostics 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.