A Record Errors: Decoding NXDOMAIN, SERVFAIL, and Resolution Failures

The Error Message Is Usually More Precise Than It Looks

Browser and command-line DNS errors get lumped together in most people's minds as one undifferentiated "the site is down." They're not. DNS resolution has a small, well-defined set of response codes, and each one narrows down what's actually wrong — no A record exists at all, the domain doesn't exist, the authoritative server is broken, or the query timed out entirely. Reading the specific error, rather than reflexively retrying or assuming the worst, gets you to the right fix faster.

This guide works through the errors that actually show up in practice — what causes each one specifically at the A record level, how to tell a real problem from ordinary propagation delay, and the fix for each.

Decoding the Common Browser-Level Errors

NXDOMAIN vs SERVFAIL: Not the Same Failure

These two get conflated constantly, but they represent genuinely different failure modes. NXDOMAIN is a definitive, successful answer — the resolver reached an authoritative source and that source confirmed the name doesn't exist. SERVFAIL is the opposite in an important sense: it means the resolver could not get a definitive answer at all, whether because the authoritative servers didn't respond, a DNSSEC signature failed validation, or the delegation chain is broken somewhere along the root-to-authoritative path.

Real Error vs Normal Propagation Delay

A large share of reported "A record errors" aren't errors at all — they're a snapshot taken mid-propagation, correctly showing a stale answer that hasn't caught up yet. Distinguishing the two matters, because the fix (or lack of one) is completely different.

• Genuine error: a fresh query against a public resolver (8.8.8.8, 1.1.1.1) that has never cached this domain before still returns NXDOMAIN or SERVFAIL — this reflects the authoritative answer right now, not a cache artifact.
• Propagation delay: a query against your own network's resolver shows an old or missing result, but a query against a fresh public resolver shows the correct, current record — this is caching catching up, not a real problem.

DNSSEC Validation Failures

When a domain has DNSSEC enabled, a validating resolver cryptographically checks that the returned A record hasn't been tampered with along the resolution path. If the DNSSEC signatures are misconfigured — an expired signature, a mismatched key, an incomplete chain of trust — a validating resolver will refuse to return the record at all, surfacing as SERVFAIL rather than a normal answer, even though the underlying A record itself might be perfectly correct. This is a distinct failure category from a broken or missing A record, and the fix lives entirely in the DNSSEC configuration (re-signing the zone, fixing DS records at the registrar), not in the A record itself.

Common Root Causes, Ranked

1. Domain typo — by far the most common cause of a genuine NXDOMAIN reported as "broken."
2. A record never created — a new domain or subdomain where DNS setup simply hasn't happened yet.
3. Nameserver delegation mismatch — the registrar points at nameservers that don't actually hold the zone (or hold an empty one), producing SERVFAIL or NXDOMAIN depending on how the mismatch manifests.
4. DNSSEC misconfiguration — a signed zone with broken signatures, surfacing as SERVFAIL for any validating resolver.
5. Authoritative server unreachable — network or hosting issues at the DNS provider itself, producing timeouts rather than a clean response.
6. Stale local cache — not a real error at the authoritative level, but a local device or resolver serving an old negative result past its actual TTL due to a caching bug.

Troubleshooting Matrix

Monitoring for A Record Errors Before Users Report Them

For any domain where downtime has real cost, waiting for a user complaint is the slowest possible detection method. Simple, low-effort monitoring options: a scheduled external DNS query (via a monitoring service or a basic cron job running dig) checked against the expected IP, with alerting on any NXDOMAIN, SERVFAIL, or unexpected-IP result. This catches accidental record deletions, expired domain registrations, and DNSSEC breakage well before it becomes a support ticket.

Related Tools

Reproduce and confirm an A record error with A Record Lookup, which shows the raw resolver response directly. For the full record set and other potential causes, use DNS Lookup. To rule out propagation delay specifically, check DNS Propagation Checker, and to confirm domain registration status, use WHOIS Lookup. If a domain has several A records and only some seem to fail, see Multiple A Records.