Why your DNS shouldn’t live inside your cloud provider

On October 19 and 20, 2025, AWS ran into the kind of failure that is easy to assume only happens somewhere else. A latent race condition inside AWS’s own DNS automation wrote an empty DNS record for the DynamoDB endpoint in us-east-1. DynamoDB itself was healthy, but nothing could resolve its name. The cascade lasted roughly 15 hours, impairing EC2, Lambda, STS, and thousands of downstream organizations (AWS post-event summary; ThousandEyes analysis). Four weeks later, a routine database permissions change at Cloudflare produced an oversized configuration file that crashed its core proxy globally for hours (Cloudflare’s post-mortem).

Neither incident was an attack. Both came from automation or configuration failures inside providers that are, by any measure, exceptionally well run. That is what makes these incidents so useful as a resilience lesson. If it can happen to AWS and Cloudflare, the answer cannot simply be to trust the provider. And if your DNS is delegated to the same provider that is having a bad day, you may lose the one tool you need most at that moment: the ability to point traffic somewhere else.

That is the case this post makes. Authoritative DNS should sit independently of your cloud provider. We will also look at why the usual latency argument does not hold up, then walk through three proven patterns and a practical reference architecture.

The escape-hatch problem

DNS is the control plane for failover. When a region degrades, a CDN misbehaves, or an entire provider has an incident, the playbook is straightforward: detect the failure and change where your names resolve, whether that means a standby region, a secondary cloud, or a backup CDN. Every step assumes your DNS provider is still reachable and can still publish changes. If your zones live inside the provider that is failing, both assumptions can break at the same time:

• Your authoritative nameservers can be degraded alongside your application. AWS’s October 2025 incident was, at its core, a DNS failure. The service was up, but it could not be resolved. If the same thing happens to the zones that name your failover targets, your healthy standby infrastructure effectively becomes invisible to the internet.
•  
• Your change path can depend on the failing control plane. Even if the authoritative network is still answering, the APIs and consoles you use to repoint records may sit inside the same blast radius. During Meta’s October 2021 outage, engineers were locked out of their own remediation tools because everything depended on the same broken network (Meta Engineering).
•  

Architects call this a shared-fate dependency. Two systems can look redundant on paper and still fail together because they rely on the same hidden component. Delegating DNS to the provider that also hosts the workload it names is a classic example. You can have a multi-region deployment, a multi-cloud strategy, and a tested DR runbook, but if all of it routes through one control plane, that control plane is still your escape hatch. When it goes down, the escape hatch goes with it.

There is another version of the same trap: the all-in-one platform. If one vendor is simultaneously your CDN, reverse proxy, WAF, and authoritative DNS, one incident can affect every layer at once, including the layer you would use to fail away. Cloudflare’s June 2022 and November 2025 incidents are examples of that concentration risk. GitLab’s public incident records also show full site outages caused by its only DNS/CDN provider in July 2020 and June 2022. We have cataloged the same pattern across a decade of post-mortems in The World’s Biggest DNS Outages.

The latency myth, and why it doesn’t hold

The most common objection to external DNS sounds completely reasonable: “Our app is in AWS, so hosting DNS in Route 53 keeps resolution close to the workload.”

The logic sounds right until you look at how internet-facing DNS resolution actually works:

1. An end user queries a recursive resolver, usually their ISP’s resolver or a public service such as Google’s 8.8.8.8. That resolver is located near the user, not near your application.
2.  
3. The resolver walks the delegation chain and queries your authoritative nameserver.
4.  
5. Every serious authoritative DNS network, including the hyperscalers, serves queries using anycast. The same nameserver IP is announced from dozens of points of presence around the world, and BGP sends each query to the nearest one.
6.  

That means the authoritative lookup is usually a single exchange of less than 50 milliseconds between the user’s resolver and the nearest anycast PoP. Once the answer is returned, the resolver caches it for the length of your TTL, often for hours, so subsequent users do not trigger another authoritative lookup. Two important points follow:

• Hosting your zone in the same cloud as your application does not create a latency advantage. The resolver’s query does not travel to your application region. It goes to the closest anycast node. An independent DNS network with dense PoP coverage can answer just as quickly, and specialist DNS networks routinely match the hyperscalers on public benchmarks such as DNSPerf.
•  
• Same-cloud DNS also does not make the connection to your application any faster. DNS resolution does not carry user traffic. Once the resolver has an answer, the user’s connection goes wherever that answer points. That is why traffic steering belongs in the answer through things like geo-routing and health-checked failover, rather than in placing the nameserver next to the workload.
•  

In other words, co-location gives you the shared-fate risk we just described, not a meaningful performance benefit. You trade an assumed advantage for a very real dependency.

The structural limits of cloud-provider DNS

Even if we set resilience aside, hyperscaler DNS has design constraints that start to matter as soon as you want an independent or multi-provider setup:

• Route 53 cannot act as a secondary DNS provider. It does not support standard zone transfer (AXFR) from an external primary, the protocol mechanism that has synchronized redundant DNS for decades. Replicating zones in or out means relying on API scripting and DIY reconciliation (blog’s comparison). Azure DNS has the same limitation.
•  
• Cloudflare places secondary DNS and zone transfers behind its Enterprise plan, while custom nameservers require Business (Cloudflare’s feature matrix).
•  
• Traffic management is either a separate product or a DIY project. Azure DNS does not provide failover or geo-routing without the separately billed Traffic Manager. Route 53’s routing policies work, but health checks and human support are separate line items.
•  

None of this is accidental. Hyperscaler DNS is designed as a building block inside a larger cloud ecosystem. That is useful when everything stays inside that ecosystem, but it is exactly the kind of coupling a resilience strategy needs to break.

Three patterns for DNS independence

Pattern 1: Independent primary DNS

The simplest option is to keep your zones with an independent managed DNS provider and point your registrar’s delegation there. Your applications can live anywhere, whether that is one cloud, three clouds, or on-premises infrastructure, while DNS stays outside those blast radii.

For most organizations, this is the right default. You keep normal DNS functionality, gain provider independence, and, with a provider that supports health-checked records and geo-routing, turn DNS into an active traffic management layer. DNS-level failover can then work across clouds and CDNs, not just inside one vendor’s regional model.

Pattern 2: Secondary DNS / multi-provider DNS

The belt-and-suspenders approach became much more common after the 2016 Dyn attack: run two authoritative DNS providers at the same time and publish both nameserver sets in your delegation. Resolvers distribute queries across both providers. If one has a total outage, the other continues answering with the same data.

The classic implementation uses a hidden primary. You manage zone data in one system of record, which could be your own BIND, AD, or Infoblox server and is never exposed to the internet. Both public providers then transfer the zone via AXFR and serve it from their anycast networks. Because AXFR is a standard protocol that has been used for decades, the providers do not need to integrate with each other. That is why AXFR support, or the lack of it in Route 53, is one of the first things to check.

Multi-provider DNS protects you from a provider-level DNS failure. What it does not do on its own is fail the application over. For that, you need pattern 3.

Pattern 3: CDN-bypass and cross-cloud failover

For applications sitting behind a CDN or proxy platform, the November 2025 Cloudflare outage exposed a very specific gap. If the CDN is the only name in your DNS, you have no route around it when that platform fails. The CDN-bypass pattern keeps a DNS-native path to your origin ready. Your primary record still points to the CDN under normal conditions, but health checks monitor the application through the CDN, not just the origin. That matters because the origin can be perfectly healthy while the proxy in front of it is down. If the CDN path fails, DNS can automatically repoint traffic directly to the origin or to an alternate CDN.

IBM’s NS1 team published a first-party account of surviving the November 2025 outage using exactly this approach, with DNS-layer automation steering traffic away from the failing CDN (IBM’s write-up). The same pattern generalizes to cross-cloud failover. Health-checked records can shift traffic from AWS to Azure, or from the cloud to an on-premises standby, with TTLs kept low at 30 to 60 seconds so resolvers pick up the change quickly.

A practical reference architecture

Put all of that together and a practical architecture for a typical AWS-heavy or multi-cloud environment can look like this:

1. Delegation: Nameservers at the registrar point to an independent managed DNS provider. For pattern 2, they point to the nameserver sets of two providers.
2.  
3. Zones: Zones are managed at the independent primary using an API/Terraform-native workflow, so DNS changes stay inside your IaC process. From there, they can optionally be transferred via AXFR to a secondary provider from a hidden primary.
4.  
5. Records: Use normal TTLs measured in hours for static records that do not need failover. For critical endpoints, use health-checked failover records with TTLs of 30 to 60 seconds. A failover chain might move from the primary region to a secondary cloud and then to a status page on a third host. Use geo or latency routing where you actively serve from multiple regions.
6.  
7. Monitoring: Run health checks from outside your primary cloud and test the full delivery path through the CDN/WAF, as well as the origin independently. That lets you tell the difference between “origin down” and “edge down,” which is what makes CDN-bypass work.
8.  
9. Runbook: The failover path has to work without access to the failing provider’s console. Test that explicitly. A failover route you cannot reach during an incident is a diagram, not a control.
10.  
11. Governance: Protect registrar and DNS accounts with MFA, registry lock, and an audit log with rollback. The 2024 Squarespace/Google Domains hijacks showed that the registrar layer is part of your DNS attack surface (Krebs on Security).
12.  

A useful question to ask at every layer of the stack is: “If this provider has its worst day of the decade, what breaks, and can I still reroute?” If rerouting depends on the same provider that just failed, you have found the dependency that needs attention.

The bottom line

The October and November 2025 outages were not anomalies. They were simply the latest entries in a long catalog of major infrastructure providers taking themselves down through routine changes and latent bugs. Concentration risk is not a criticism of AWS, Azure, or Cloudflare. It is arithmetic. The more layers one provider operates for you, the more of your incident response depends on that provider being available on its worst day.

Independent, cloud-agnostic DNS costs little, adds no measurable latency, and preserves the one capability every failover plan assumes you will still have: the ability to change where your name points when everything else is on fire.

Total Uptime is an independent managed DNS provider built for exactly this: cloud-agnostic authoritative DNS with health-checked failover, per-record geo-routing, secondary DNS with hidden-primary support, and one-click zone restore. It is backed by a 100% uptime SLA and engineers who answer the phone. If you’re reviewing your DNS architecture, talk to us about a multi-provider setup.