Why DNS is the most underestimated single point of failure in your infrastructure

If you are responsible for infrastructure at a midsize enterprise, you have probably spent a considerable amount of time and money removing single points of failure.


Workloads may be distributed across multiple data centers or availability zones. Databases are replicated. Network and power paths are redundant. There is a disaster recovery plan, and hopefully it has been tested rather than simply documented. You may have invested in several different technologies, all designed to add another nine to your availability.


Now consider a much simpler question: Who operates your DNS?

For a surprising number of organizations, DNS is simply whatever came with the domain registrar, hosting provider, or cloud platform. It works, it costs little or nothing, and because it rarely causes an obvious problem, there has never been much reason to question it.


The problem is that DNS is not just another service sitting somewhere in your infrastructure. It is the mechanism users, applications, and APIs rely on to find that infrastructure in the first place.


You can build redundancy into almost every other layer of the stack and still have a single point of failure sitting right at the front of it.

The dependency nobody draws on the architecture diagram

DNS is easy to take for granted because, when it is working properly, it is almost invisible.


The Domain Name System translates human-readable domain names into the IP addresses computers use to communicate. That process happens constantly and sits underneath websites, email systems, mobile application backends, SaaS integrations, APIs, and VPN endpoints.


Most of the time, nobody gives it much thought. But that position in the infrastructure has an important consequence: DNS availability is a prerequisite for almost everything else.


If your authoritative DNS stops responding, it does not matter that the web servers behind it are healthy or that the database has been successfully replicated to another region. Users cannot reach an application if they cannot resolve the name that tells them where the application lives.


A multi-region architecture can therefore be fully operational at the infrastructure level while being effectively unavailable to its users.


There is another dependency that is less obvious until something goes wrong. DNS is often involved in how internal systems find one another and how employees reach monitoring platforms, remote-access systems, and incident-response tools. A DNS or network failure can therefore affect not only the application but some of the tools engineers need to investigate and recover it.


This is one reason apparently straightforward infrastructure failures can become surprisingly difficult to resolve. The failure affects the service, then starts affecting the mechanisms used to fix the service.

The math of downtime has changed

This would matter less if downtime were inexpensive. It isn’t.


The ITIC 2024 Hourly Cost of Downtime Survey found that a single hour of downtime now exceeds $300,000 for more than 90% of midsize and large enterprises. Some 41% reported hourly costs ranging from $1 million to more than $5 million.


Gartner’s widely cited baseline puts the average cost of downtime at approximately $5,600 per minute, or around $336,000 per hour.


The Uptime Institute’s Annual Outage Analysis tells a similar story from a different perspective. According to its research, 54% of operators said their most recent significant outage cost more than $100,000, while one in five reported costs exceeding $1 million.


Those numbers are worth comparing with what organizations typically spend on DNS.


Registrar-bundled DNS may cost nothing at all. Even a professionally managed DNS service generally costs far less per month than an organization could lose during a few minutes of serious downtime.


That makes DNS an unusual part of the resilience equation. The potential cost of failure is enormous, while the cost of introducing additional resilience is comparatively small. Yet it is still one of the areas most likely to be overlooked.

Three outages that show just how important DNS can become

There is no shortage of real-world evidence. Some of the largest internet outages of the past decade have involved DNS, and importantly, they have happened to organizations with enormous engineering resources.


The details differ, but the underlying lesson is remarkably consistent: when name resolution becomes unavailable, the effects can spread far beyond the DNS service itself.

Dyn, October 2016: when one provider takes half the internet with it

On October 21, 2016, managed DNS provider Dyn was hit by a large distributed denial-of-service attack powered by the Mirai botnet.


The attack came in three major waves and continued for much of the day. Because Dyn provided DNS services for a long list of major internet properties, the disruption was felt across the internet.


Twitter, Spotify, Reddit, GitHub, Netflix, PayPal, Amazon, and CNN were among the services that became unreachable or intermittent for users. The U.S. Department of Justice later stated that Sony alone reported losses of $2.7 million.


The interesting part of the Dyn incident was not simply the scale of the attack. It was the architectural exposure it revealed.


As Bitsight observed at the time, websites were particularly vulnerable to an attack against a DNS provider because many organizations hosted their domains with only one provider. Their applications might have been distributed and resilient, but the mechanism users depended on to find those applications was concentrated in one place.


The Dyn outage prompted many larger enterprises to rethink that architecture and accelerated interest in dual-provider and multi-provider DNS strategies.


A decade later, plenty of organizations still rely on a single DNS provider.

Meta, October 2021: one change makes an entire company difficult to find

Five years later, the industry was given a very different example.


On October 4, 2021, a command issued during routine backbone maintenance severed Meta’s backbone connections. According to Meta, a bug in its internal audit tooling failed to catch the error before the command was executed.


As the network failure unfolded, Meta’s DNS servers became unable to reach the company’s data centers and withdrew their BGP route advertisements. From the outside world, Facebook, Instagram, and WhatsApp effectively disappeared from the internet for roughly six hours.


Meta later attributed the outage to a faulty configuration change.


There were two particularly important aspects of this incident. The first was what happened to the people trying to fix it. Meta’s internal tools and remote-access systems also depended on the affected infrastructure. Reports at the time indicated that even some physical access systems were affected.


In other words, the failure did not only take services offline. It interfered with the mechanisms engineers needed to recover those services.


The second was the reaction of the wider DNS ecosystem. As users and applications repeatedly tried to reach Meta’s services, global DNS resolvers reportedly saw around 30 times the normal query volume for Meta’s domains.


A single infrastructure problem had created a much wider cascade.


Secondary estimates put Meta’s losses at approximately $60 million in advertising revenue during the outage.

AWS us-east-1, October 2025: when DNS automation deletes its own records

The AWS outage of October 19 and 20, 2025 provides an even more recent example, and perhaps one of the most useful for modern infrastructure teams.


The problem began with a latent race condition inside DynamoDB’s automated DNS management system.


A delayed process overwrote a newer DNS plan with an older one. Cleanup automation then deleted what it believed was the obsolete configuration. Unfortunately, that left an empty DNS record for the endpoint dynamodb.us-east-1.amazonaws.com.


DynamoDB itself had not simply ceased to exist. The service became unresolvable and therefore unreachable to customers and to AWS’s own internal services that depended on it.


AWS later confirmed in its post-event summary that the incident had been triggered by a latent defect within the service’s automated DNS management system.


The direct DynamoDB impairment lasted for approximately three hours, but the effects did not stop there. EC2 instance launches began failing. Load balancer health checks experienced problems. Lambda and IAM sign-in were affected. The cascade took the region approximately 15 to 16 hours to recover fully.


More than a thousand services were reportedly degraded, with organizations and services including Snapchat, Fortnite, Coinbase, Robinhood, Venmo, Ring, United Airlines, and the UK’s HMRC among those affected.


Third-party estimates placed insured losses across approximately 70,000 affected organizations somewhere between $38 million and $581 million.


What makes this example so useful is that the problem was not a lack of sophisticated infrastructure. Quite the opposite. It occurred inside one of the world’s largest and most technically advanced cloud platforms, and it involved automation specifically designed to manage infrastructure reliably.


One empty DNS record was enough to trigger a much wider chain of events.


If DNS automation can become a critical failure point inside AWS, the assumption that DNS simply works deserves to be questioned everywhere else too.

It is rarely hackers. More often, something changed

The Dyn attack makes for a memorable story because it involved a huge botnet attacking critical internet infrastructure. It is also the kind of event people naturally imagine when they think about taking a major online service offline.


But there is another pattern running through many of the significant outages of recent years. Most of them were not attacks.


Cloudflare’s July 2020 backbone outage was caused by a configuration error. Akamai’s July 2021 Edge DNS disruption followed a configuration update that triggered a software bug. Meta’s outage was caused by a configuration change. Cloudflare’s outages in June 2022 and November 2025 were also confirmed by the provider as non-cyberattack events.


In many cases, something quite ordinary happened. Somebody made a change, software behaved in an unexpected way, a procedure failed, or automation did something it was not supposed to do.


The wider industry data supports this.


The Uptime Institute’s 2025 Annual Outage Analysis found that nearly 40% of organizations had suffered a major outage caused by human error during the previous three years. Of those incidents, 85% resulted either from staff failing to follow procedures or from problems with the procedures themselves.


Looking across 25 years of outage data, Uptime estimates that human error is involved in somewhere between two-thirds and four-fifths of downtime incidents.


This changes the way we need to think about DNS resilience.


Protecting DNS is certainly a security issue, but resilience cannot focus only on botnets, DDoS attacks, and malicious actors. It also needs to protect the organization from the far more routine risk of somebody changing something and getting it wrong.


That becomes particularly important when DNS is treated as a background service rather than critical infrastructure. If nobody owns it, nobody regularly reviews it, and it never appears in disaster recovery exercises, changes can easily be made without the same controls applied elsewhere in the infrastructure.

There is also a risk sitting at the registrar

DNS resilience is not only about the infrastructure answering DNS queries. The control plane matters too.


The 2024 Squarespace incident is a useful reminder of this.


When Squarespace migrated approximately ten million Google Domains registrations in July 2024, the process disabled multi-factor authentication and allowed accounts to be created without email verification.


Attackers were subsequently able to hijack the DNS records of dozens of domains.


The incident highlights an aspect of DNS security that can easily be missed when organizations focus only on network architecture. Your registrar account, authentication controls, and the processes governing changes to DNS records are all part of the same attack surface.


A globally distributed DNS network is of limited value if an attacker can simply log into the account controlling it and change the records.

Why “free” DNS is not really free

None of this means that registrar-bundled DNS or DNS provided by a hyperscaler is inherently bad. Some of those services are extremely well engineered.


The problem is not necessarily the quality of the individual provider. It is the architecture you create around it.


When DNS is included as a free feature of another service, three weaknesses tend to appear.


The first is shared fate. If your DNS is operated by your registrar, hosting company, or primary cloud provider, a serious failure or compromise at that organization may affect both your name resolution and other services you depend on.


This becomes particularly problematic during a disaster recovery event. You might have a secondary environment ready to take traffic, but if the DNS service you need to redirect that traffic is part of the same failure, activating your recovery environment becomes considerably more difficult.


The second problem is operational attention. Services that cost nothing and rarely cause problems have a tendency to disappear into the background. They may not be actively monitored, tested during disaster recovery exercises, or assigned a clear internal owner.


When something eventually goes wrong, valuable time can be lost simply establishing who is responsible, where the service is managed, and how it can be changed safely.


The third problem is change control. Infrastructure teams generally apply strict processes to changes involving production servers, networks, firewalls, and databases. DNS does not always receive the same treatment.


Yet a single incorrect record can make a healthy production application unreachable.


If DNS changes are made casually because the system is perceived as simple or low risk, the organization has created an operational weakness at one of the most important points in the application delivery path.


This is how an organization can end up with multi-region compute, replicated storage, redundant networking, and a well-documented disaster recovery plan while still having a single point of failure.


It just happens to be a single point of failure that rarely appears on the architecture diagram.

What should you look for in a DNS provider?

If this prompts you to review your DNS architecture, the starting point should not be a long feature comparison. The more useful question is whether the service reduces the dependencies and operational risks that make DNS vulnerable in the first place.

Independent, redundant infrastructure

Authoritative DNS should run on globally distributed infrastructure, ideally using anycast so DNS queries can be answered from multiple locations around the world.


Independence is just as important as geographic distribution. If resilience is the objective, your DNS should not automatically share the same failure domain as your registrar, hosting provider, or primary cloud.


For organizations where DNS availability is particularly critical, the architecture should ideally tolerate the complete failure of one DNS provider. That is where secondary DNS and dual-provider DNS strategies become important.

A meaningful SLA

Look beyond general claims about reliability.


If DNS is critical infrastructure, the provider should be prepared to make a contractual commitment to its availability. A 100% uptime service level agreement backed by a clearly explained network design is very different from an uptime percentage presented as a marketing statistic.

Safe and auditable changes

The network is only part of DNS resilience.


Given how frequently infrastructure outages are caused by configuration and human error, the way changes are managed matters just as much.


Look for full audit logs, appropriate role-based access controls, and the ability to understand exactly what changed, who changed it, and when. The ability to restore or roll back DNS configurations can be particularly valuable when a seemingly harmless change produces an unexpected result.

Control-plane security

Multi-factor authentication should be standard, not optional.


Depending on your requirements, registry lock and DNSSEC signing may also be important components of the overall security model.


The Squarespace incident demonstrated why this matters. Protecting DNS infrastructure without protecting the accounts and processes used to control it leaves a significant part of the risk unresolved.

API-first automation

DNS should be capable of fitting into the same operational processes as the rest of your infrastructure.


A well-documented API, along with Terraform or other infrastructure-as-code support, allows DNS changes to be reviewed, automated, and managed with the same discipline applied to other production systems.


Automation does not eliminate risk, as the AWS incident demonstrated, but properly controlled automation can reduce the number of casual manual changes made directly in a production environment.

Monitoring and automated failover

DNS can do more than simply tell users where an application lives.


When integrated health monitoring is available, DNS can also respond to changes in application health.


HTTP, TCP, ping, or content-based checks can identify when an endpoint is no longer healthy. Automated DNS failover can then direct users to an alternative endpoint rather than waiting for somebody to notice the outage, open a support ticket, and manually update a DNS record.


For organizations running multiple sites, clouds, or disaster recovery environments, this can turn DNS into an active part of the resilience architecture rather than a passive directory service.

Human support when something goes wrong

There is one final consideration that tends to look unimportant during procurement and extremely important during an outage: Who can you actually speak to?

When DNS is unavailable and downtime is costing the organization thousands of dollars per minute, waiting in a generic support queue or working through a chatbot is very different from being able to reach an engineer who understands DNS and the underlying infrastructure.


Technology matters, but during a real incident, access to people who can diagnose the problem matters too.

The cheapest nine you may ever buy

DNS presents an unusual infrastructure equation. The potential risk is enormous, while the cost of mitigation is comparatively small.


The evidence from Dyn, Meta, AWS, and many of the outages in between shows the same thing in different ways. DNS can become a critical point of failure even inside highly resilient, technically sophisticated environments. And the cause is not always a dramatic cyberattack. More often, it is an ordinary configuration change, a software bug, an automation problem, or a dependency that nobody realized was there.


That is why DNS deserves the same resilience thinking applied to the rest of the application delivery stack.


Total Uptime operates independent managed DNS infrastructure for exactly this reason. Our Cloud DNS service runs across a globally distributed anycast network and is backed by a 100% uptime SLA. It supports DNS failover, secondary DNS, API access, and DNSSEC, with engineers available when you need help.


But regardless of which DNS provider you use, there is a useful question every infrastructure team should be able to answer:


If your current DNS provider became unavailable tomorrow, could your users still reach your applications, and could your team still redirect them somewhere else?

If the answer is no, your infrastructure may still have a single point of failure. It is simply one that has been hiding in plain sight.