Two DNS resolver addresses can share one failure domain
Cloudflare’s July 2025 route withdrawal exposed shared resolver dependencies. Assess actual client fallback and recovery policy before counting DNS addresses.
By 
Paul. Architecture and infrastructure
Two resolver addresses do not establish two independent recovery paths. They can belong to the same service and depend on the same routing configuration. DNS resilience therefore needs a description of shared dependencies and evidence about what the actual client does when its preferred path fails. Counting configured addresses is only the beginning of that investigation.
This November 2026 retrospective starts with Cloudflare's 15 July 2025 postmortem about the 14 July incident. The event and the report have different dates. The incident is immediate background to the July 16 research week, rather than an outage that began on the date of that week's assignment.
Different addresses can disappear together
Cloudflare attributes the failure to an internal configuration error that withdrew resolver routes. Its summary gives service unavailability from 21:52 to 22:54 UTC on July 14; the timeline records the triggering configuration change at 21:48. The report also identifies a BGP hijack visible during the withdrawal and explicitly says it was not the outage's cause.
The affected prefixes included those serving the familiar 1.1.1.1 and 1.0.0.1 addresses. Both addresses could therefore be exposed to the same change. That is the dependency lesson: an address list may describe alternate destinations without describing independent control of those destinations. Geographic distribution does not remove a shared configuration dependency.
The postmortem also reports that DNS-over-HTTPS traffic remained largely unaffected because many clients used cloudflare-dns.com, on different addresses. This narrows the incident claim. It does not show that every resolver interface failed or that every encrypted-DNS client recovered. The endpoint used by a particular client is part of its exposure.
Those are vendor incident findings, not observations from an AL+ network. Their practical value is to direct the questions asked of a proposed design. Which paths share route advertisements? Which share policy changes? Which destinations does each client actually use? An answer about server locations alone cannot establish that a configuration mistake will remain local.
The resolver is one step in reaching the application
The resolver model in RFC 1034, published in November 1987, separates resolvers from authoritative name servers. A recursive resolver helps a client obtain the answer for a name. Authoritative DNS supplies the domain's records, while hosting serves the application reached through those records. These responsibilities are separate. Adding another authoritative provider would not, by itself, make a client's unavailable recursive resolver reachable.
Likewise, a hosting exit plan or a data backup solves another problem. A healthy application and intact records can still be difficult for a client to reach if name resolution fails along its selected path. Before buying redundancy, identify the step that the proposed alternative would actually replace. Otherwise a team can spend effort duplicating a component outside the failure boundary.
For an illustrative business service, the useful question is whether a staff device can resolve the service's name and complete the intended action during the relevant failure. Merely confirming that the application server is healthy answers a narrower question. Conversely, a resolution failure on one device is not proof that the application host or authoritative zone is unavailable.
A secondary entry is a hypothesis about client behavior
A proposed alternative resolver helps only if the client can and does use it under the failure being considered. Investigate which component owns resolution: the operating system, a router, a VPN, an application or an encrypted-DNS configuration. A second address in one layer's settings need not describe every application's effective path.
Do not assume that the words primary and secondary promise immediate sequential failover. Establish the applicable client behavior and then observe it in an authorized evaluation. The important result is the action a user can complete, including the delay before recovery and any policy change. This article performed no DNS query experiment, client test or production configuration change.
A useful future check would distinguish an unreachable destination from a reachable resolver returning an answer the application cannot use. Those conditions can trigger different behavior. Specify the failure being tested rather than treating any unsuccessful name lookup as equivalent. Otherwise a successful recovery in one case can be misreported as protection against every resolver problem.
Cloudflare's setup documentation currently carries a 6 May 2026 update date and separates device and router instructions. It is later, mutable setup guidance, not a record of what every client did in July 2025. Use the exact platform documentation relevant to a current deployment and retain the version and effective settings when evaluating recovery.
One managed policy can be an intentional choice
The strongest counterargument to mixing providers is consistent policy. A business may require one managed resolver service for filtering or visibility. Sending queries to an unrelated public fallback could change those properties. Availability is not the only requirement, and a fallback that bypasses an agreed policy may be unacceptable even when it returns an answer.
That can justify a single managed policy, provided the recovery limitation is explicit. Ask the service owner how availability is maintained within that policy and how staff operate during an interruption. An approved alternative may need equivalent controls. A manual recovery route may be suitable for some work, while another service requires a faster automated path.
Independence also has a cost. Multiple providers introduce settings and policy behavior that someone must maintain. They can still share an access network or another upstream dependency. The aim is to reduce the failure modes that matter to the business, not to claim independence from every possible disruption merely because two organizations appear in a configuration.
For custom software development, request a recovery description tied to the client paths the product actually uses. Name the shared dependencies, the acceptable policy during failure and the evidence needed to confirm fallback. The July incident supports asking those questions; it does not supply a universal guarantee that another address or another provider will keep every client working.