Analysis of Outage 8 May 2026
On 8 May 2026, Quad9 experienced outage intervals up to ~40 minutes for our primary zone “quad9.net” due to a failed validation step between our primary hidden authoritative servers and PCH’s anycast network, which we use for externally-facing DNS authoritative services. The root cause was determined to be due to legacy zone transfer configurations between PCH and Quad9 which were not documented clearly, and recent maintenance changes caused a failure in importing the zones to the authoritative pipeline.
Users utilizing 9.9.9.9 and other IP-based service addresses for DNS resolution were not impacted during this event, except for lookups to hosts under quad9.net. Other zones and recursive services remained operational.
Users attempting to use DNS client encryption with our named records of “dns.quad9.net” or other service names under quad9.net would not have been able to create new connections, as those queries would have been sent to client local resolvers not operated by Quad9. Existing encrypted sessions would have remained operational until re-establishment due to network change or timeout of TTL for the dns.quad9.net hostname.
Users transitioning from IP-address based sessions and using DDR (RFC9462) to upgrade to encryption using name-based addresses may have experienced no issues as those queries would have been answered by Quad9’s recursive resolvers and include IP address hints as part of the response.
Users attempting to use www.quad9.net would have been unable to reach that service for the interval of the outage, and our inbound mail system was also unreachable in that interval.
Depending on timing of lookups by outside recursive resolvers to the names in the quad9.net zone, the varying expiration of TTLs may have meant a significantly shorter outage window.
The first log record of zone failures being evident was computed to be sometime after 2026/05/08 15:50 UTC. Quad9 systems teams began resolution work at 16:03 UTC and coordinated with PCH for a solution that was implemented at 16:45 UTC when the zone data was restored.
Quad9 is in the process of revising our authoritative nameserver set and has planned to shift to a more instrumented configuration in the next few weeks. This fault was unrelated to that already-planned transfer, but the upcoming changes will lead to a better architectural solution which we hope will reduce or eliminate this particular fault path.
We apologize for the outage for those users who were affected, and we take seriously the reliability and performance of our platform. We will continue to review this issue and determine how we can avoid problems and react more quickly to critical issues.
You can find a post-mortem document here.