{"id":7292,"date":"2019-11-14T13:30:52","date_gmt":"2019-11-14T19:30:52","guid":{"rendered":"https:\/\/dcmblogmulti.wpengine.com\/?p=7292"},"modified":"2026-10-18T15:29:24","modified_gmt":"2026-10-18T15:29:24","slug":"how-to-avoid-dns-outages","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/how-to-avoid-dns-outages\/","title":{"rendered":"What is a DNS Outage, and How Can You Prevent It?"},"content":{"rendered":"

A DNS outage is the failure that makes a healthy site look dead. Your origin answers, your CDN is fine, and nobody can reach either because the hostname stopped resolving. This guide explains what DNS downtime is, which mistakes cause it, how to diagnose it, and how to set up DNS monitoring<\/a> that catches it before your customers do.<\/p>\n

\"\"
Network operations desk with a terminal showing a failed DNS lookup while the web server status remains healthy<\/figcaption><\/figure>\n

What Is a DNS Outage (DNS Downtime)?<\/h2>\n

A DNS outage is a period during which a domain name cannot be resolved to an IP address. Clients send a query for www.example.com<\/code>, no server in the resolution chain returns a usable answer, and the browser shows DNS_PROBE_FINISHED_NXDOMAIN<\/code>, SERVFAIL<\/code>, or “server not found.” DNS downtime is the same event measured as a duration.<\/p>\n

The important word is chain<\/em>. A lookup passes through the stub resolver in the client’s operating system, a recursive resolver that does the lookup work and caches the answer (usually the ISP’s or a public one such as 8.8.8.8), the root servers, the TLD servers for .com<\/code>, and finally your authoritative nameservers. Any link can break. Most of the time the break is on your side: the authoritative servers, the delegation that points to them, or the records they serve.<\/p>\n

Two properties make DNS outages different from an ordinary server outage.<\/p>\n

First, they are often partial. Resolvers cache answers for the record’s TTL, so users behind a resolver with a warm cache keep working while new visitors fail. One region or one ISP breaks first, and your own laptop may load the site without complaint.<\/p>\n

Second, they hide from most monitoring. An HTTP uptime check that resolves through a caching resolver keeps reporting 200 OK until that cache expires. By then the cost of downtime<\/a> is already accumulating in abandoned carts, bounced email, and failed API calls.<\/p>\n

What Causes DNS Outages?<\/h2>\n

DDoS attacks get the headlines, but most DNS outages trace back to a change somebody made. BlueCat’s analysis puts misconfiguration ahead of every other cause, and the public incident reports from large providers agree. Here are the failure modes that recur, with named incidents where the details are public.<\/p>\n

\"Diagram
Where DNS outages happen: each hop in the resolution chain has its own typical failure.<\/figcaption><\/figure>\n

Zone Misconfiguration and Bad Record Changes<\/h3>\n

A wrong IP in an A record, a CNAME pointing at a hostname that no longer exists, a deleted MX record, or a TXT record that pushes the response past the UDP size limit. These errors usually enter during manual edits in a provider console and publish instantly.<\/p>\n

Automation makes the same mistake faster. According to Amazon’s post-event summary, the AWS us-east-1 incident of October 2025 began when a race condition in the system that manages DynamoDB’s DNS records left the regional endpoint with an empty record. Services across the region that depend on DynamoDB failed in sequence for hours.<\/p>\n

What catches it:<\/strong> an expected value for each record type in Dotcom-Monitor DNS monitoring. You define the A, CNAME, MX, or TXT value the zone should serve. A mismatch or missing record flips the monitor to DOWN and alerts within one check interval.<\/p>\n

Delegation and Glue Errors<\/h3>\n

Your zone can be perfect and still unreachable if the parent zone points at the wrong nameservers. This usually happens during migrations. The NS records at the registrar are updated but the glue records still carry old IPs, or the new provider’s servers are not yet authoritative when the delegation changes (lame delegation). Microsoft attributed a 2019 Azure incident of roughly two hours to a delegation change made while migrating a legacy DNS system to Azure DNS.<\/p>\n

What catches it:<\/strong> NS set consistency checks and lame delegation detection. Each Dotcom-Monitor check traces the full path from root to TLD to authoritative server, so a mismatch between the parent’s NS set and the zone’s own NS records shows up as a failed hop, not a vague timeout.<\/p>\n

Authoritative Nameservers Unreachable<\/h3>\n

This is the classic total outage. Every nameserver for the zone is down, overloaded, or unroutable. The 2016 attack on Dyn used a botnet of compromised IoT devices to flood Dyn’s managed DNS, and for hours large parts of the US and Europe could not resolve Twitter, Reddit, Spotify, and dozens of other customers. Facebook’s October 2021 outage reached the same result by another path. A configuration change withdrew the BGP routes to its backbone, its authoritative nameservers became unreachable, and every Facebook, Instagram, and WhatsApp hostname stopped resolving for about six hours.<\/p>\n

The quieter version is a single authoritative nameserver on one box in one data center. A kernel update or a power event takes it down, and the zone goes with it.<\/p>\n

What catches it:<\/strong> non-cached queries sent directly to each authoritative nameserver from 30+ locations. Because the check never asks a resolver, there is no cache to mask the failure; the first missed interval raises the alert.<\/p>\n

DNSSEC Signature Expiry and Key Rollover Mistakes<\/h3>\n

DNSSEC adds a cryptographic chain (DS at the parent, DNSKEY, RRSIG on each record set) that validating resolvers check on every lookup. If a signature expires or a key rollover publishes the wrong DS record, validating resolvers return SERVFAIL for the whole zone while non-validating resolvers keep working, so the outage looks random. Slack’s September 30, 2021 incident during its DNSSEC rollout is the canonical example; users on some ISPs lost access until signing was rolled back.<\/p>\n

What catches it:<\/strong> DNSSEC chain validation on every check, including RRSIG expiry windows, so an expiring signature alerts days before resolvers start failing it.<\/p>\n

Domain Expiry and Registrar Problems<\/h3>\n

The domain expires because the renewal card lapsed and the reminder went to an ex-employee’s mailbox. Or a registrar account is compromised and the nameservers are changed to someone else’s. Either way the zone data is intact and useless.<\/p>\n

What catches it:<\/strong> record change detection on NS records alerts when the delegation moves. A regular domain health check<\/a> covers registrar lock, expiry date, and the email authentication records next to it.<\/p>\n

GeoDNS and Traffic Steering Misconfiguration<\/h3>\n

Multi-CDN and GeoDNS setups answer differently depending on where the query comes from. A bad steering rule sends one continent to a decommissioned edge. Every check from your office passes. The complaints come from Singapore.<\/p>\n

What catches it:<\/strong> checks that run from 30+ regions at the same time, with multi-resolver verification and p95\/p99 resolution latency per location. One broken region stands out against the rest, and a stale cache is told apart from a wrong authoritative answer.<\/p>\n

How to Avoid DNS Downtime (Outage)<\/h2>\n

Each step below removes one of the single points of failure described above. Most teams already have two or three in place; steps 4, 5, and 7 are the ones usually missing.<\/p>\n

Step 1: Run at least two authoritative nameservers on separate networks.<\/strong> Two nameservers at the same provider on the same anycast network share the same failure modes. Add a secondary DNS provider that pulls the zone by AXFR or API. Dyn customers with a second provider configured stayed up in 2016; the rest went dark.<\/p>\n

Step 2: Lock the registrar account and auto-renew the domain.<\/strong> Enable registrar lock (and registry lock for domains that matter), require two-factor authentication, turn on auto-renew with a card that will not expire first, and send renewal notices to a shared mailbox that outlives any one person.<\/p>\n

Step 3: Set TTLs on purpose.<\/strong> 300 to 3600 seconds is reasonable for records that change. Lower the TTL to 60 seconds at least one full period of the old TTL before a planned migration, make the change, confirm it from several resolvers, then raise the TTL back. A high TTL is no performance win if you cannot roll back a mistake.<\/p>\n

Step 4: Treat zone changes like code changes.<\/strong> Keep zone data in version control (OctoDNS, or the Terraform providers for Route 53, Cloudflare, and NS1), require a review, validate syntax with named-checkzone<\/code> before publishing, and keep the previous version one command away. Most of the incidents above were a single unreviewed change.<\/p>\n

Step 5: Automate DNSSEC key rollovers, or do not sign the zone.<\/strong> A signed zone with manual rollovers is a timer. Use a provider that manages signing automatically, publish DS records through the registrar API, and alert on RRSIG expiry well before the deadline.<\/p>\n

Step 6: Check delegation and glue after every nameserver change.<\/strong> Run dig NS example.com @a.gtld-servers.net<\/code> and compare it with dig NS example.com @ns1.yourprovider.net<\/code>. The two sets must match, and glue IPs must answer authoritatively for the zone. Do this before the old provider is switched off, not after.<\/p>\n

Step 7: Monitor authoritative DNS from outside, non-cached.<\/strong> Everything above reduces the chance of an outage. Only external monitoring tells you one has started. Query each authoritative server directly, from multiple regions, at one-minute intervals, and compare the answers with the values you expect. The DNS server monitoring<\/a> section below walks through the setup.<\/p>\n

How to Diagnose DNS Outages?<\/h2>\n

Diagnosis means finding which hop in the chain is failing. Work from the outside in: client, resolver, authoritative, delegation.<\/p>\n

Start with a ping test<\/a> against the hostname and then against the server’s IP. If the IP answers and the hostname does not, the server is up and resolution is broken. That one comparison rules out half the possible causes.<\/p>\n

Next, ask a public resolver and your own authoritative server the same question:<\/p>\n

dig example.com A @8.8.8.8\r\ndig example.com A @ns1.yourprovider.net<\/code><\/pre>\n
If the authoritative server answers correctly and the public resolver does not, the problem is caching, propagation, or a delegation the resolver cannot follow. If the authoritative server itself times out or returns SERVFAIL or REFUSED, the problem is on that server. Repeat for each nameserver in the NS set; one bad server out of four produces intermittent failures, not a clean outage.<\/p>\n
Then trace the delegation from the root:<\/p>\n
dig +trace example.com A<\/code><\/pre>\n
With +trace<\/code>, dig skips the local resolver and performs the full lookup itself, starting at the root. The output shows every referral from the root servers to .com<\/code> to your nameservers. The hop where the referral stops, loops, or returns an unexpected NS set is the broken one. For DNSSEC problems, add +dnssec<\/code> and look for a missing or expired RRSIG, or run the domain through DNSViz, which draws the chain of trust and flags the broken link.<\/p>\n
Finally, check from somewhere else. A query that works from your office and fails from a cloud VM in another region points at GeoDNS, a regional resolver outage, or anycast routing, not the zone itself.<\/p>\n
Troubleshooting<\/h3>\n
\n\n\n\n\n\n\n\n\n\n\n\n
Symptom<\/th>\nLikely cause<\/th>\nWhat to do<\/th>\n<\/tr>\n<\/thead>\n
NXDOMAIN<\/code> for a record that exists<\/td>\nRecord deleted, typo in the name, or wrong zone edited<\/td>\nQuery the authoritative server directly; restore from version control or the provider’s change history<\/td>\n<\/tr>\n
SERVFAIL<\/code> from validating resolvers only (8.8.8.8, 1.1.1.1, Quad9)<\/td>\nDNSSEC signature expired or DS record mismatch after a rollover<\/td>\nCheck with dig +dnssec<\/code> or DNSViz; re-sign the zone or temporarily remove the DS at the registrar<\/td>\n<\/tr>\n
Timeouts from every resolver<\/td>\nAuthoritative nameservers unreachable: outage, DDoS, or routing withdrawal<\/td>\nFail over to the secondary provider; confirm each nameserver by IP from an outside network<\/td>\n<\/tr>\n
Works in some regions, fails in others<\/td>\nGeoDNS or steering rule error, regional anycast node down, or partial propagation<\/td>\nCompare answers per region; fix the steering rule or pull the bad node from the pool<\/td>\n<\/tr>\n
Correct now, but users still get the old IP<\/td>\nOld answer cached up to the previous TTL<\/td>\nWait it out, or ask major resolvers to flush the record (Google and Cloudflare both offer a flush form)<\/td>\n<\/tr>\n
Email bouncing while the site works<\/td>\nMX record missing or pointing at the wrong host; SPF record too long and truncated; DMARC policy set to p=reject<\/code> before SPF and DKIM were aligned<\/td>\nQuery MX and TXT records directly; shorten or flatten SPF; move DMARC back to p=none<\/code> until alignment reports are clean<\/td>\n<\/tr>\n
Whole domain gone, nameservers changed<\/td>\nDomain expired or registrar account compromised<\/td>\nRenew immediately or contact the registrar’s abuse line; enable registrar lock afterward<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
Flushing a local cache or restarting a router helps one user, not your customers. If your monitoring shows the authoritative servers answering correctly from every region, the complaint is almost always a stale cache on the user’s resolver.<\/p>\n
Set Up DNS Server Monitoring<\/h2>\n
Most “DNS uptime” checks query a public resolver and report whatever it cached. That proves a resolver had an answer, not that your nameservers are serving the right one. Monitoring that shortens outages has to query the authoritative servers directly, verify the answer against an expected value, run from the regions your users are in, and alert the team that owns DNS. Here is how that looks in Dotcom-Monitor.<\/p>\n
Step 1: Create a DNS monitoring task for each critical hostname.<\/strong> Start with the apex, www<\/code>, the API hostname, and the MX hosts. For each, select the record type and enter the expected value. Mismatches, missing records, and NXDOMAIN, SERVFAIL, or REFUSED responses mark the check as failed.<\/p>\n
Step 2: Point the check at the authoritative nameservers.<\/strong> Non-cached mode queries your NS set directly and traces the path from root through the TLD to the final answer, with timing at each hop. If you also run HTTP or API monitors, the guide on how Dotcom-Monitor resolves DNS in every check<\/a> explains which resolve mode to use for each.<\/p>\n
Step 3: Enable DNSSEC validation and record change detection.<\/strong> The DNSSEC option validates the DS, DNSKEY, and RRSIG chain on each run and warns on signatures approaching expiry. Record change detection alerts on any unexpected change to A, AAAA, CNAME, MX, NS, or TXT values, which covers accidental edits and account compromise alike.<\/p>\n
Step 4: Pick locations and interval.<\/strong> Choose locations that match your customer base (Dotcom-Monitor offers 30+ across six continents) and set a one-minute interval for the apex and API hostnames. Resolution latency is tracked per location at p50, p95, and p99, which is where regional resolver overload and anycast problems appear first. The glossary entry on DNS performance<\/a> covers what normal looks like.<\/p>\n
Step 5: Route alerts by failure type.<\/strong> Send record changes and DNSSEC failures to the DNS owners via PagerDuty or OpsGenie, and slow response times to a Slack or Teams channel. Use alert filtering to suppress expected churn on records a CDN rotates.<\/p>\n
Step 6: Add the surrounding checks.<\/strong> DNS blacklist, ICMP ping, and traceroute tasks are included in the same Internet Infrastructure plan, so a “nameserver unreachable” alert arrives with the traceroute that shows where the path died.<\/p>\n
For how other platforms handle authoritative queries, DNSSEC, and checks from multiple locations, see our roundup of the best DNS monitoring tools<\/a>. One caveat. Dotcom-Monitor monitors DNS from the outside; it is not a managed DNS provider and does not perform failover for you. Pair it with a provider that supports secondary DNS or failover with health checks, and use the monitor as the independent check that the failover actually happened.<\/p>\n
Conclusion<\/h2>\n
A DNS outage is rarely an act of God. It is usually a change somebody made, such as a typo in a zone, a delegation moved too early, a signature nobody renewed, or a steering rule that routed a continent into a wall. Redundant nameservers, locked registrar accounts, deliberate TTLs, reviewed zone changes, and automated DNSSEC remove most of the ways those changes become outages.<\/p>\n
The remaining risk is detection time. Resolver caches guarantee you will not see a DNS failure from inside your own network until it is already old. External, non-cached monitoring of your authoritative servers is the one control that shortens the incident instead of only making it less likely.<\/p>\n
If your current uptime checks resolve through a caching resolver, start there. Dotcom-Monitor DNS monitoring<\/a> comes with a free 30-day trial, no credit card required. A DNS task with all record types, DNSSEC validation, and all 30+ locations is included in the Internet Infrastructure plan from $39.95 per month.<\/section>\n","protected":false},"excerpt":{"rendered":"
A DNS outage is when your domain stops resolving to an IP, so users can’t reach a healthy site. Learn the causes, how to diagnose it, and how to prevent it.<\/p>\n","protected":false},"author":21,"featured_media":34652,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-7292","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/posts\/7292","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/comments?post=7292"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/posts\/7292\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/media\/34652"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/media?parent=7292"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/categories?post=7292"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/tags?post=7292"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}