DNS Failures That Look Like Downtime (and How to Tell)

When a site "goes down," the server itself is often perfectly healthy - the failure is happening in DNS resolution before a single packet reaches your application. These failures are especially disruptive because they're invisible in application logs and server metrics, which is why teams waste time debugging the wrong layer. This guide covers how to tell DNS failures apart from real downtime and the exact dig commands to diagnose each.

Why DNS Failures Get Misdiagnosed as Downtime

Your application server can report 100% healthy uptime while users see connection failures, because the failure happens before the TCP connection is even attempted. Symptoms that should immediately point you at DNS rather than the application layer:

• Some users report the site is down, others say it works fine (classic partial DNS propagation or resolver caching)
• The failure is intermittent and correlates with no deploy or infrastructure change
• Your monitoring from one region shows healthy, but real user reports say otherwise
• The failure started right around a TTL boundary or a nameserver change

NXDOMAIN: The Domain Doesn't Exist (From the Resolver's View)

NXDOMAIN means the queried name has no matching record anywhere in the delegation chain. Check it directly:

dig example.com A +noall +answer +authority

If you see status: NXDOMAIN in a full query:

dig example.com A

Common causes:

• Typo in the queried hostname (verify with a second, independently spelled query)
• A DNS record was deleted or a subdomain was never created
• The domain itself has expired and been removed from the zone - cross-check with domain expiration monitoring
• A CNAME target was deleted while the alias record still exists, causing a dangling reference

SERVFAIL: The Resolver Couldn't Get a Valid Answer

SERVFAIL is different from NXDOMAIN - it means the authoritative servers failed to respond correctly, often due to DNSSEC validation failure or a misconfigured/unreachable nameserver.

dig example.com A

Look for status: SERVFAIL in the header. Narrow down the cause by querying each authoritative nameserver directly:

dig NS example.com +short

Then, for each nameserver returned:

dig @ns1.example.com example.com A

If one nameserver answers correctly and another times out or errors, you have a partial nameserver outage - some resolvers will get correct answers, others won't, which explains inconsistent user reports perfectly.

DNSSEC Breakage as a Cause of SERVFAIL

If DNSSEC is enabled and any part of the chain of trust is broken - an expired RRSIG, a mismatched DS record at the registrar, or a key rollover done incorrectly - validating resolvers return SERVFAIL while non-validating resolvers may return a normal answer. This inconsistency is a strong signal to check DNSSEC specifically:

dig example.com A +dnssec
delv example.com A

delv (part of the BIND utilities package) explicitly validates the chain and reports exactly where trust breaks down, which is far more informative than plain dig for this specific failure mode.

TTL and the Propagation Myth

"DNS propagation" as commonly described - a mysterious 24–48 hour global wait - is largely a myth for modern infrastructure. What actually happens is caching governed by TTL (Time To Live):

dig example.com A +noall +answer

The number before IN A in the output is the TTL in seconds. Each resolver that has cached the record will continue serving the old value until that TTL expires, then re-query.

Key facts that debunk the propagation myth:

• Authoritative nameservers update instantly once you make a change
• The only delay is caching at recursive resolvers along the path, bounded by TTL
• A record with a 3600-second TTL will be fully updated everywhere within one hour of expiry, not 48
• Setting a low TTL (e.g., 300 seconds) before a planned change gives you fast rollback capability during migrations

Practical migration checklist:

• Lower TTL to 300s at least one full TTL cycle before the change
• Make the DNS change and verify via dig @8.8.8.8 and dig @1.1.1.1 against different public resolvers
• Confirm the old TTL has fully expired before considering the migration complete
• Raise TTL back to a normal value (3600s+) once stable, to reduce authoritative query load

Nameserver and Registrar Expiry as Root Causes

Two upstream failures frequently masquerade as "the site is down" when the actual cause is administrative:

• Domain expired at the registrar - the domain is pulled from the parent zone entirely, causing NXDOMAIN everywhere simultaneously. Check with whois example.com or an RDAP query.
• Nameserver hosting account expired or was deleted - if your DNS provider account lapses (unpaid invoice, expired trial), the nameservers may stop answering, causing SERVFAIL or timeouts even though your domain registration itself is fine.

Distinguishing between these two is straightforward:

dig NS example.com +short

If this returns nothing or times out, the delegation itself is broken (registrar-side issue or expired domain). If it returns nameservers but queries to them fail, the DNS hosting provider is the problem.

Comparison: DNS Failure Types at a Glance

Querying Multiple Resolvers to Confirm Scope

Never trust a single resolver's answer when diagnosing a suspected DNS issue. Compare across independent public resolvers:

for r in 8.8.8.8 1.1.1.1 9.9.9.9; do
  echo "=== $r ==="
  dig @$r example.com A +short
done

Consistent answers across all three strongly suggest the problem, if any, is downstream of DNS (application or network). Divergent answers confirm the issue is in DNS resolution or caching itself.

Monitoring Strategy for DNS-Layer Failures

Standard uptime monitoring that only checks HTTP status codes from a single vantage point can miss DNS-layer failures entirely if that vantage point's resolver happens to have a cached, still-valid answer. A robust strategy includes:

• Resolving from multiple independent, geographically distributed locations
• Explicitly checking dig response codes (NXDOMAIN, SERVFAIL, NOERROR), not just whether the site loads
• Tracking domain and nameserver expiry independently of DNS answer content
• Alerting on DNSSEC validation failures separately from plain resolution failures

ServerInspector's checks run from multiple regions specifically so a resolver-caching quirk in one location doesn't hide a real problem visible everywhere else. Combine that with a public status page so your team and customers have a single source of truth during a DNS incident instead of conflicting reports.

FAQ

How do I tell if a failure is DNS or the actual application server?

Compare dig output across multiple public resolvers (8.8.8.8, 1.1.1.1, 9.9.9.9). If they return consistent, correct answers but the connection still fails, the issue is downstream of DNS. If answers differ or return errors, it's a DNS-layer problem.

Is 24–48 hour DNS propagation still a real thing?

Not in the way it's commonly described. Authoritative changes are effective immediately; the only delay is caching bounded by the record's TTL. Set a low TTL before planned changes to minimize this window.

What does SERVFAIL usually mean in practice?

It most often indicates either an unreachable/misconfigured authoritative nameserver or a DNSSEC validation failure somewhere in the chain of trust. Query nameservers individually and use delv to isolate which.

Can an expired domain cause DNS failures without any WHOIS warning?

Yes - once a domain passes into the registrar's grace period, delegation can be pulled from the parent zone, causing NXDOMAIN globally, sometimes before the registrant receives or notices renewal reminders.

Why do some users see the site while others get errors?

This is the signature of partial DNS issues: TTL-based caching means different resolvers hold different states during a transition, or one of several authoritative nameservers is failing while others still answer correctly.