DNS Outage Troubleshooting for Operators: Test DNSSEC First

Run dig @1.1.1.1 example.com +cd and compare it against the same query without +cd. If the plain query fails, but the +cd version succeeds, DNSSEC validation is the culprit, not your network or the authoritative server. If both fail, move straight to checking delegation and authoritative reachability, and loop in your registrar or hosting provider once you've confirmed the authoritative chain itself is broken.

TL;DR:

For NXDOMAIN or timeouts, check registration and registrar nameservers first, then parent zone delegation, and query each authoritative server directly before escalating.

For intermittent slowness, run traceroutes to the resolver and authoritative server, identify the answering instance with a CHAOS query, and capture truncated UDP responses.

A record with a 24 hour TTL can remain cached for that long; compare public resolvers, then check SOA serials and registrar versus zone nameservers.

When DNSSEC is implicated, inspect RRSIG expiry and registrar DS records; Extended DNS Error codes distinguish missing DNSKEY records from expired signatures.

When domains won't resolve at all
When DNS is slow or intermittent
When changes don't propagate or appear stale
When records are wrong or DNSSEC is causing SERVFAIL
Advanced diagnostics: command recipes, packet captures, and interpreting EDE codes
Troubleshooting mindset and a concise incident playbook
Author and Netverge perspective on managing DNS outages
Netverge: how our platform helps during DNS incidents
FAQ
Sources

When domains won't resolve at all

A domain that returns NXDOMAIN or times out completely points to one of three places: registration, delegation, or the authoritative servers themselves. Work through them in order instead of guessing.

Check the domain's registration status and registrar nameserver settings through a WHOIS lookup. Expired registrations and nameserver typos account for a large share of "sudden" total outages.
Verify delegation from the parent zone. A lame delegation, where the parent zone points to nameservers that don't actually serve the zone, produces resolution failures that look identical to a dead server.
Run dig @<authoritative-ip> example.com soa directly against each authoritative server to confirm it answers. Follow with dig +trace example.com to see exactly where the resolution chain breaks.
If the authoritative servers are unreachable, failover to a secondary nameserver if one exists. If the registrar record itself is wrong, that's an immediate registrar ticket, not a DNS engineering fix.

Once you've isolated the failure to registration, delegation, or an unreachable authoritative host, the fix is usually administrative rather than technical: correct the registrar entry, or escalate to whoever hosts the authoritative zone.

When DNS is slow or intermittent

Intermittent failures are harder than total outages because the symptom looks the same whether the problem sits in your resolver, the network path, or the authoritative infrastructure.

Run a traceroute to both your resolver's IP and the authoritative server's IP to spot where latency or loss starts.
Query the CHAOS TXT record with dig @resolver id.server CH TXT to identify which resolver instance actually answered, then correlate that instance with your traceroute hop data, a technique detailed in Cloudflare's troubleshooting guide.
Watch for packet loss or retransmissions in ping and tcpdump output. Truncated UDP responses that force a TCP retry are a common hidden cause of perceived slowness.
Uneven load across anycast instances can mimic a partial outage, with some regions clean and others degraded at the same time.

Pro Tip: Capture traffic with tcpdump -i any port 53 -w dns_capture.pcap during the issue window so you have evidence instead of a guess once the symptom clears.

If several regions show simultaneous degradation while others stay healthy, suspect a DDoS or anycast imbalance and start mitigation (rate limiting, route withdrawal) before deep-diving individual queries.

When changes don't propagate or appear stale

TTL misunderstandings cause more "propagation" tickets than actual DNS bugs. A record set with a 24-hour TTL simply won't update everywhere for up to 24 hours, regardless of how correctly you made the change.

Query the record against several public resolvers (not just your own) to see whether the stale answer is universal or just cached locally. If only one resolver is stale, wait out its TTL rather than treating it as a system failure.
Compare the SOA serial number across every authoritative server for the zone. A mismatched serial means your secondaries haven't picked up the latest zone transfer.
Check that the nameserver (NS) set at the registrar matches the NS set published inside the zone itself. A mismatch here, often paired with incorrect glue records, causes resolvers to query the wrong or outdated servers entirely.

When the NS sets disagree, correcting the registrar record and re-checking the SOA serial across all secondaries usually resolves the problem within one TTL cycle.

When records are wrong or DNSSEC is causing SERVFAIL

A SERVFAIL with no obvious cause is one of the most common triggers for an escalation that goes nowhere, because the symptom is identical whether the cause is a syntax error or a broken cryptographic chain.

Run dig example.com +cd against dig example.com without it. A pass with +cd and a failure without it confirms a DNSSEC validation mismatch rather than a network or authoritative connectivity problem.
Check RRSIG expiry dates and compare the DS record published at the registrar against the DNSKEY actually served by the zone.
Review signer pipeline logs for failures, since a pipeline that skips full-zone validation can silently publish expired or malformed signatures.

Extended DNS Error codes give you the specific reason behind a SERVFAIL, such as code 9 for a missing DNSKEY or code 7 for an expired signature, cutting diagnostic time compared to working from the RCODE alone.

A frequent root cause is a mismatch between the record TTL and the RRSIG refresh interval: if the signer refreshes less often than the TTL expires, caches start serving signatures that validators reject. Temporarily disabling validation on your own resolver buys time while the zone gets re-signed, but it's a stopgap, not a fix.

Advanced diagnostics: command recipes, packet captures, and interpreting EDE codes

When the basic checks don't isolate the failure, step through a fixed command sequence rather than improvising.

dig +trace example.com walks the full delegation chain from the root down, showing exactly which hop stops answering.
dig example.com +cd versus the same query without +cd isolates DNSSEC validation failures from everything else.
dig @<authoritative-ip> example.com soa confirms whether a specific authoritative server is reachable and authoritative for the zone.
kdig +tls @resolver example.com or openssl s_client -connect resolver:853 checks whether DNS-over-TLS or DNS-over-HTTPS transport itself is the point of failure.
dig @resolver id.server CH TXT identifies the exact resolver instance that handled a query, useful for correlating failures across a pool of anycast nodes.
A tcpdump -i any port 53 capture, read with filters for truncated UDP and TCP fallback, shows whether responses are being clipped before they reach the client.

The Extended DNS Error field rides alongside the RCODE without changing it, giving resolvers a way to report the specific reason for a SERVFAIL instead of leaving operators to guess. Cloudflare developer docs

NIST SP 800-81r3 treats DNS as a primary telemetry and enforcement point rather than a simple resolution service, which is the reasoning behind pulling EDE codes and packet captures early rather than after escalation. When none of these commands point to a clear local cause, pull BGP routing data or ask your upstream ISP to verify reachability before assuming the fault is yours.

Troubleshooting mindset and a concise incident playbook

Structure matters more than speed in the first minutes of an outage, because wasted motion early costs more time than it saves.

In the first 5 minutes: confirm whether the failure is authoritative, resolver-side, or network routing, using the dig and traceroute commands above.
In the first 15 minutes: validate the scope (one region, one resolver pool, or global) before touching any configuration.
Within 60 minutes: apply the remedial action that matches the confirmed cause, whether that's bringing up a secondary nameserver, correcting a registrar record, or temporarily disabling DNSSEC validation on your own resolver.
After resolution: re-check signatures, test the signing pipeline end to end, and adjust monitoring thresholds so the same failure triggers an earlier alert next time.

Pro Tip: Document the exact command output that confirmed your root cause while the incident is fresh. It turns the next similar outage into a five-minute diagnosis instead of a forty-minute repeat investigation.

A short network incident response guide gives this same isolate-validate-remediate-communicate sequence a formal structure if you want a written runbook to adapt for your own team.

Troubleshooting mindset and a concise incident playbook — overview diagram

Author and Netverge perspective on managing DNS outages

DNS outages rarely announce themselves as DNS problems. They show up as "the site is down," and the diagnostic work of separating authoritative, resolver, and network causes is where most incident time actually goes. Consolidated telemetry and AI-assisted triage shorten that detection loop by surfacing the failing layer before a human finishes typing the first dig command. Our monitoring platform is built around that same isolate-first logic.

— Jim

Netverge: how our platform helps during DNS incidents

We built Netverge to collapse the detection gap described above. Instead of toggling between dig output, traceroute logs, and a separate ticketing tool, our platform correlates DNS telemetry, Vergepoint hardware visibility, and AI-driven triage in one place, so the authoritative-versus-resolver-versus-network question gets answered automatically instead of through fifteen minutes of manual commands.

Netverge

We provide hardware devices that give you physical, first-hop visibility at distributed sites without deploying separate packet capture hardware.
Our autonomous AI agents flag anomalies and draft the likely root cause before a ticket even reaches a human.
Our knowledge graph ties DNS incidents to the rest of your infrastructure context, cutting repeat investigations.

If your team is still stitching together dig output, spreadsheets, and a ticketing system during every DNS incident, our Starter Package starts at $299 per month, or you can start a free trial to see the triage workflow on your own network first.

FAQ

Are there any DNS problems happening today?

There's no single global status page that tracks every DNS outage, since most failures are specific to one provider, zone, or resolver rather than internet-wide. Check your authoritative DNS provider's own status page and run dig +trace against your domain to confirm whether the issue is isolated to your zone.

Why did my DNS suddenly stop working?

Sudden DNS failure is usually caused by an expired domain registration, a nameserver mismatch at the registrar, or an expired DNSSEC signature triggering SERVFAIL responses. Running dig example.com +cd against the same query without +cd quickly tells you whether DNSSEC validation is the cause.

What causes a DNS outage?

Common causes include lame delegation, mismatched nameserver records between the registrar and the zone, expired RRSIG signatures, and signer pipeline bugs that publish malformed signing data. Cloudflare's October 2023 resolver incident is a documented example of a parsing failure in root zone ingestion causing widespread SERVFAIL spikes.

How to fix DNS network problem?

Start by isolating whether the failure is authoritative, resolver-side, or a routing issue using dig +trace and a traceroute to the authoritative IP. Once isolated, the fix is usually specific: correct a registrar record, bring up a secondary nameserver, or temporarily disable DNSSEC validation while a zone gets re-signed.