Why Azure DNS and Route 53 Put Nameservers on Different TLDs

Azure DNS assigns nameservers that look like this: ns1-01.azure-dns.com, ns2-01.azure-dns.net, ns3-01.azure-dns.org, ns4-01.azure-dns.info. Four nameservers, four different TLDs. That's not an accident of provisioning or a naming quirk. It's a deliberate resilience decision, and it protects against a narrow kind of failure that most nameserver setups never account for.

The dependency hiding inside every nameserver hostname

A domain's NS records point to nameservers by hostname, not directly by IP address. That hostname still has to be resolved before a client can actually reach it, which means it depends on a chain of DNS infrastructure ultimately rooted in whichever TLD that hostname lives under. A nameserver named ns1.provider.com depends on .com's own resolution infrastructure being healthy, the same registry and TLD-server system every other .com domain relies on.

Most of the time that dependency is invisible, because TLD infrastructure for major TLDs is itself heavily redundant and rarely has problems. But if every nameserver for a domain happens to live under the same TLD, an incident specific to that TLD (not the provider's own network, not the nameservers themselves) could make all of them unreachable at once. Every nameserver could be perfectly healthy and still unreachable, simply because the hostnames pointing at them can't be resolved.

What spreading nameservers across TLDs actually buys you

Putting nameservers on different TLDs means a problem affecting one TLD's resolution infrastructure only knocks out the nameserver hostnames that happen to live under that specific TLD. The others, resolvable through entirely separate TLD infrastructure, stay reachable. The domain as a whole keeps resolving even during an incident that would otherwise have been a single point of failure for every nameserver at once.

It's worth being precise about what this does and doesn't cover. It doesn't protect against a root zone failure, since every TLD ultimately depends on the same root. Root infrastructure is exceptionally redundant, though: thirteen root server identities, each anycast across hundreds of physical locations, compared to any individual TLD's registry. That's the trade-off: negligible root-level risk, accepted in exchange for real protection against a much more plausible single-TLD incident.

This isn't a hypothetical risk

On May 5, 2026, DENIC, the registry that runs Germany's .de TLD, published broken DNSSEC signatures for the .de zone during a routine key rotation, an incident Cloudflare documented in detail. Any validating resolver encountering those signatures was required by the DNSSEC spec to reject them, returning SERVFAIL instead of an answer. Failures climbed for roughly three hours as cached records expired, until resolver operators worked around it with negative trust anchors. .de is one of the largest TLDs on the internet, so this wasn't a fringe case: for those three hours, any nameserver hostname living under .de was effectively unreachable to a large share of the internet's resolvers, regardless of how healthy the actual server behind it was. Albania's .al TLD had a similar DNSSEC-driven outage two months later, in July 2026.

TLD-level incidents aren't limited to configuration errors, either. In 2017, a security researcher gained control of four of the seven authoritative nameservers for the .io TLD, a different failure mode entirely, closer to a hijack than a misconfiguration, but still a risk that touches every domain under that TLD at once.

Contrast that with the root. The root has faced deliberate, large-scale DDoS attacks three separate times on record, in 2002, 2007, and again in 2015, each one attempting to knock out all thirteen root server identities simultaneously. None of them caused a noticeable resolution failure for end users; the redundancy held every time. That's exactly the asymmetry the trade-off above is built on: real, historical failures at the TLD level, and none at the root, despite people actively trying.

Who actually does this

Azure DNS, the example that opened this article, assigns four nameservers per zone spread across four different TLDs by design.

AWS Route 53 does the same thing, spreading a hosted zone's four nameservers across TLDs that usually include .com, .net, .org, and .co.uk.

Cloudflare is a more interesting case, because it does both depending on which tier you're on. Its standard nameservers, the ones assigned to the vast majority of zones, look like bob.ns.cloudflare.com and kate.ns.cloudflare.com: two nameservers under a single TLD. Its Enterprise-only Foundation DNS product offers a separate set of advanced nameservers spread across foundationdns.com, foundationdns.net, and foundationdns.org: three different TLDs. Cloudflare's own stated reason for that split isn't framed around TLD-level failure specifically; their documentation describes it as being about predictable, conflict-free nameserver assignment across related zones. The resilience benefit described above still applies structurally either way, regardless of which reason was the primary motivation.

It isn't universal, though. Google Cloud DNS is a straightforward counterexample: its nameservers (named along the lines of ns-cloud-a1.googledomains.com through ns-cloud-a4) all live under the same domain and the same TLD. That's a deliberate choice too, not an oversight. It's a different judgment call about where engineering effort is best spent, and a reasonable one given how rarely a major TLD has an incident severe enough for this to matter in practice.

A different kind of diversity than the one usually discussed

Nameserver resilience is more commonly discussed in terms of network diversity: nameservers spread across different networks, different autonomous systems, different anycast footprints, so that an outage or DDoS attack against one network doesn't take down every nameserver at once. That's a real and more common concern than TLD diversity, and nameserver reachability monitoring exists partly because network-level failures happen far more often than TLD-level ones.

TLD diversity is a narrower, complementary protection. It targets the resolution chain for the nameserver hostnames themselves, not the network paths used to reach them. A provider can have excellent network diversity and still put every nameserver under one TLD, or vice versa. The two aren't substitutes for each other; they cover different failure domains.

Why this usually isn't something you configure yourself

For almost anyone using a managed DNS provider, TLD diversity is a property of that provider's own infrastructure, inherited automatically the moment you delegate to their nameservers, not a setting exposed anywhere in a dashboard. It becomes a relevant question mainly in two situations: evaluating providers for a use case where nameserver resilience genuinely matters, or deliberately running secondary DNS through a second provider. In that second case, picking a secondary whose nameservers sit on different TLDs than your primary's is a reasonable, if fairly niche, thing to check for.

Checking your own domain's spread

dig NS example.com +short

Look at the TLDs in the returned hostnames. Seeing them all under one TLD isn't necessarily a problem worth acting on, since TLD-level incidents affecting major TLDs are rare, but it's one more data point about where a shared point of failure could exist if you're specifically auditing for it.

How DNS monitoring fits in

TLD diversity narrows one specific way every nameserver for a domain could become unreachable simultaneously, but it doesn't remove the need to actually watch for that happening. Plenty of other causes (a misconfiguration, a provider-side outage unrelated to any TLD, a nameserver dropped from a zone by mistake) produce the exact same symptom regardless of how the nameservers happen to be named. OneDollarDNS's reachability checks catch a nameserver going dark for any of those reasons, including the TLD-level scenario this article describes, rather than only the ones a particular provider's naming scheme was designed to avoid.