Your DNS may be in the same failure domain as your CDN or Cloud Provider
You have redundant servers. Multiple availability zones. Health checks. A CDN. A WAF. Perhaps even a second cloud region ready to take traffic. But there is a question that is surprisingly easy to overlook:
Who runs your DNS?
If the answer is the same company that provides your CDN, edge security or other critical internet services, you may have more redundancy on paper than you do in practice. Your infrastructure might be spread across several locations, but users still depend on one provider to find it.
That creates a failure domain that many organizations only discover when something goes wrong.
The problem: redundancy inside one provider is still dependency on one provider
DNS is one of the first steps in almost every connection to an internet facing application.
A user requests: www.example.com. DNS tells their resolver where that service can be found. Only then can the user connect to the application.
A simplified request looks like this:
User
|
v
DNS lookup
|
v
Authoritative DNS
|
v
CDN / WAF / Edge
|
v
Application
Now imagine that the authoritative DNS, CDN and WAF are all delivered by Provider A.
PROVIDER A
+———————-+
User ——–>| Authoritative DNS |
| CDN |
| WAF |
| Edge services |
+———-+———–+
|
v
Your application
You may have several services, but they share a common dependency.
If Provider A suffers a sufficiently serious platform, control plane, configuration or network incident, several layers of your resilience strategy can be affected at the same time.
Your application itself may still be completely healthy. Your users may simply be unable to reach it.
Why this matters
The November 2025 Cloudflare outage provided a useful example.
On 18 November, Cloudflare experienced significant failures across its network after a database permissions change triggered a problem with a configuration file used by its Bot Management system. The resulting failure affected multiple Cloudflare services and disrupted access to a large number of websites and online services.
The important lesson is not that Cloudflare is unreliable. It is that any provider can have an outage.
AWS can fail. Azure can fail. A CDN can fail. A DNS provider can fail. Internal configuration changes can have unexpected consequences. The architectural question is therefore not:
“Is our provider reliable?”
It is:
“What happens to us when our provider is unavailable?”
That is a much more useful resilience question.
Who should be thinking about this?
This matters to any organization where public DNS is required to reach an important application or service. It becomes particularly important for financial services organizations subject to the Digital Operational Resilience Act, or DORA.
DORA places significant emphasis on understanding ICT dependencies and managing third party and concentration risk. If several critical services depend on the same ICT provider, simply having individually resilient products from that provider does not necessarily remove the concentration risk. For infrastructure and risk teams, that creates a practical question:
Could we continue operating if one of our major internet infrastructure providers became unavailable?
DNS should be part of that assessment.
Technical background: where DNS sits in the request path
DNS is sometimes treated as a background infrastructure service. In reality, it is part of the application delivery path.
Consider a typical cloud application:
+—————-+
| DNS |
+——-+——–+
|
v
+—————-+
| CDN / WAF |
+——-+——–+
|
+———-+———-+
| |
v v
Cloud Region A Cloud Region B
| |
v v
Application Application
The application layer is resilient. There are two regions. The CDN may also operate from a globally distributed network. But if DNS and the CDN are provided through the same platform, there is still a shared dependency above both application regions.
Adding another application server does not remove it.
Adding another cloud region does not remove it.
The architecture only becomes genuinely independent when there is another way for users to resolve and reach the service.
What does a shared DNS failure domain look like?
There are several ways organizations end up in this position.
DNS was bundled with another service:
A team adopts a CDN, cloud platform or security service and uses the DNS service included with it. It is convenient, easy to deploy and usually works extremely well. Over time, more services move onto the same platform. Eventually DNS, CDN, WAF, bot management and edge services may all share the same provider. Nobody deliberately designed a single point of failure. It simply developed over time.
Multi cloud is mistaken for complete independence:
An organization might run workloads in AWS and Azure and consider itself multi cloud. But look at the path above those clouds.
Provider A DNS
|
Provider A CDN
|
+————+————+
| |
v v
AWS Azure
The compute layer is diversified. The access layer is not. If Provider A becomes unavailable, having two healthy clouds underneath it may not help.
DNS failover exists, but inside the same provider:
DNS failover is useful, but it solves a different problem. It can detect that an application endpoint is unavailable and change DNS records to point users towards another healthy endpoint.
For example:
Primary application fails
|
v
Health check detects failure
|
v
DNS record changes
|
v
Traffic moves to secondary application
But ask one more question:
Who operates the DNS service performing that failover?
If the answer is the same provider experiencing the incident, the failover mechanism itself may be inside the affected failure domain.
That is why DNS failover and DNS provider redundancy should be considered separately.
Common symptoms of DNS dependency problems
A shared failure domain is not always obvious during an incident.
Your monitoring may show:
Origin server: UP
Database: UP
Secondary region: UP
Application health: UP
Yet customers report that the service is unavailable.
From outside the environment, you might see:
$ dig www.example.com
;; connection timed out; no servers could be reached
Or DNS may resolve successfully while another service on the same provider’s edge platform is failing. The frustrating part for operations teams is that the infrastructure they control can remain perfectly healthy throughout the incident.
There is nothing to restart. There is no failed VM to replace. The problem exists upstream.
The solution: put DNS in a separate failure domain
The aim is not necessarily to replace your current CDN, cloud provider or DNS service. It is to remove the assumption that one provider must always be available. One approach is to introduce an independent authoritative DNS provider.
The architecture then becomes:
+——————–+
| Primary DNS |
| Provider A |
+———+———-+
|
User / Resolver ———–+
|
+———+———-+
| Independent DNS |
| Total Uptime |
+———+———-+
|
v
Application services
Both DNS providers can answer authoritative queries for the domain.
If one DNS provider experiences an outage, resolvers still have authoritative name servers available through the other provider.
That is a fundamentally different resilience model.
Secondary DNS: a practical place to start
For organizations that do not want to redesign their existing DNS environment, Secondary DNS can be one of the simplest ways to introduce provider diversity. Your existing DNS remains in place.
A second provider receives and maintains a copy of the DNS zone.
Existing DNS
|
Zone transfer
|
v
Independent Secondary DNS
At the domain level, authoritative name servers from both providers are published.
example.com
ns1.existing-provider.com
ns2.existing-provider.com
ns1.independent-dns.com
ns2.independent-dns.com
Resolvers can therefore obtain an authoritative answer without relying exclusively on one DNS network.
With Total Uptime Cloud DNS, Secondary DNS can mirror zones from an existing DNS server onto Total Uptime’s global DNS network. That means organizations can add another DNS failure domain without immediately removing or replacing their incumbent provider.
Add application failover as the next layer
Independent DNS protects against DNS provider dependency. DNS failover addresses another problem: what happens when the application endpoint itself fails?
Total Uptime Cloud DNS can monitor public facing servers from multiple geographic locations and automatically alter DNS records when the configured monitoring criteria indicate that an endpoint is unavailable.
A simplified design looks like this:
Cloud DNS
|
Health monitoring
/ \
/ \
v v
Primary service Backup service
HEALTHY HEALTHY
|
v
Traffic
Primary fails:
Cloud DNS
|
Health monitoring
/ \
/ \
v v
Primary service Backup service
DOWN UP
|
v
Traffic
This can be used across clouds, ISPs or data centers because DNS is not tied to a particular compute platform.
That distinction matters. The objective is not simply to have a backup server. It is to make sure the mechanism responsible for directing users to that backup can still operate when another supplier has a problem.
A financial services example
Consider a financial services company running an online customer platform. The application is deployed across two cloud regions.
The company has invested in:
- – redundant application servers
- – database replication
- – a CDN
- – a WAF
- – application health monitoring
- – a secondary cloud region
At first glance, the platform looks highly resilient. But DNS, CDN and WAF are all provided by the same supplier.
Customer
|
v
Provider A DNS
|
v
Provider A CDN + WAF
|
+———————+
| |
v v
Primary cloud Secondary cloud
The organization has resilience at the application level but concentration at the access layer.
A more resilient architecture could introduce independent DNS:
+——————+
| Provider A DNS |
+——————+
+
+——————+
| Total Uptime DNS |
+——————+
|
v
Application path
/ \
/ \
v v
Primary cloud Secondary cloud
Now the resilience discussion is different. Instead of asking whether individual components are redundant, the organization can demonstrate that it has considered the failure of an entire provider.
For teams working on DORA readiness, that is an important distinction.
How to assess your current DNS failure domain
You can perform a useful first assessment without changing anything. Start by listing the services involved in delivering an application to an external user.
For example:
– Registrar
– Authoritative DNS
– CDN
– WAF
– DDoS protection
– Load balancing
– Cloud hosting
– Application hosting
– Monitoring
Then add the provider responsible for each one.
You may find something like this:
Authoritative DNS Provider A
CDN Provider A
WAF Provider A
DDoS protection Provider A
Cloud hosting Provider B
Monitoring Provider C
That makes the concentration much easier to see.
Then ask:
If Provider A disappeared for an hour, which services would still work?
Do not just check whether the application servers remain healthy.Test whether a new user, with nothing already cached, could still resolve the domain and reach the application. That is the test that matters.
DNS resilience best practices checklist
Use this as a starting point when reviewing public DNS for critical services.
- – Map every authoritative DNS provider used by critical domains.
- – Identify whether DNS shares a provider with your CDN, WAF or edge platform.
- – Document shared ICT dependencies and failure domains.
- – Use more than one authoritative DNS provider where the business impact justifies it.
- – Place secondary DNS on a genuinely independent network.
- – Confirm that DNS zones remain synchronised between providers.
- – Test DNS provider failure rather than assuming redundancy works.
- – Monitor critical application endpoints from multiple geographic locations.
- – Configure failover only to endpoints that have been confirmed healthy.
- – Review DNS TTLs as part of your failover design.
- – Use DNSSEC where appropriate and make sure it is correctly supported across the DNS architecture.
- – Test failover regularly and record the results.
- – Include DNS dependencies in DORA ICT risk and concentration risk reviews.
- – Document who owns DNS during an incident and how changes are authorized.
- – Review DNS architecture whenever a new CDN, WAF, cloud or edge service is introduced.
Is your DNS really independent?
You may already have multiple clouds, redundant applications and failover infrastructure. But if your DNS sits with the same provider as your CDN, WAF or other edge services, there could still be a single failure domain in front of all of it.
Total Uptime Cloud DNS gives you an independent DNS layer, separate from your existing cloud, CDN and application infrastructure.
You don’t necessarily need to replace what you have today. Secondary DNS can add provider diversity to your existing DNS architecture, while DNS failover can help keep users connected when an application, cloud or data center becomes unavailable.
If you’re not sure whether your current DNS architecture has this dependency, talk to us.
Speak to our team about adding independent DNS resilience to your existing infrastructure.
