Fix: NXDOMAIN

NXDOMAIN (Non-Existent Domain) is DNS giving a firm no: an authoritative nameserver was asked for a name and answered that it does not exist. Every connection to that name fails instantly, so an NXDOMAIN on a production hostname is a full outage for whatever depends on it. The cause is always one of a small set: the record is missing, the wrong servers are being asked, or a stale negative answer is cached somewhere between you and the truth.

NXDOMAIN

What this error means

When a client resolves a hostname, its resolver walks the DNS tree to the servers authoritative for the domain and asks for the record. NXDOMAIN is the authoritative response code meaning no records of any type exist for this exact name. It is different from a name that exists but lacks the requested type (that is NODATA), and different from a failure to get any answer (timeout or SERVFAIL).

Two properties make NXDOMAIN incidents confusing. First, negative caching: resolvers cache the “does not exist” answer for a TTL derived from the zone’s SOA record, so the error can outlive its cause. Second, delegation: the answer only means “does not exist according to whoever answered,” and if the registrar delegates the domain to nameservers other than the ones you manage, you are editing records nobody is asking about.

Common causes

• A typo in the hostname in application config, a connection string, or the DNS record itself.
• The record was never created, or was deleted during a migration or a Terraform apply that pruned it.
• The domain’s registrar points at the wrong nameservers, so your edits land in a zone that is not authoritative.
• The domain expired at the registrar, which replaces the delegation and kills every name under it at once.
• Split-horizon DNS: the name exists only in a private zone, and clients outside that view get NXDOMAIN.
• A stale negative cache: the record exists now, but resolvers still serve the NXDOMAIN they cached earlier.
• Search-domain confusion on Linux, where a short name expands to something like service.internal.example.com that genuinely does not exist.

How to fix it

STABILIZE first. If the domain has expired, renew it immediately; that single action restores everything. Otherwise, if a critical record was deleted, recreate it with a short TTL.

1. Ask an authoritative nameserver directly, bypassing every cache. First find the delegation, then query one of the listed servers.

dig NS example.com +short
dig @ns1.example-dns.com app.example.com A

2. Compare that with what public and local resolvers say, to see where the answer diverges.

dig @1.1.1.1 app.example.com A
dig app.example.com A
whois example.com | grep -iE "expir|status"

DIAGNOSE with the pattern. Authoritative server says NXDOMAIN: the record really is missing from the zone that matters, so create it (and if you edited a different DNS console, the NS output just told you the registrar points elsewhere). Authoritative server returns the record but resolvers say NXDOMAIN: that is negative caching or a resolver stuck on old delegation, and it heals within the negative TTL. Whois shows the domain expired or in clientHold: nothing else matters until the registrar side is fixed. Name resolves publicly but fails from inside a VPC: split horizon, so the record needs adding to the private zone that VPC uses.

FIX by creating the record where the delegation actually points, with a modest TTL so mistakes heal fast:

app.example.com.    300    IN    A    203.0.113.10

Then flush the caches you control so recovery does not wait on TTLs. On the affected Linux hosts:

resolvectl flush-caches

Public resolvers such as Cloudflare (1.1.1.1/purge-cache) and Google (developers.google.com/speed/public-dns/cache) offer purge pages for a specific name, which shortens the tail of the incident for external users. Keep negative TTLs sane: the SOA minimum field controls how long an NXDOMAIN is cached, and values above an hour turn every DNS mistake into a long outage.

How to prevent it

• Monitor resolution of your critical hostnames from outside your network, alerting on NXDOMAIN specifically.
• Put domain expiry on auto-renew with a monitored payment method, and alert 30 days out anyway.
• Manage DNS as code so records cannot silently vanish, and review plans that delete records with the same care as ones that delete servers.
• After changing nameservers, verify delegation at the registrar with dig NS before making record edits.
• Keep SOA negative TTLs short (300 to 900 seconds) so a mistaken deletion does not linger in caches for hours.

When to call a senior engineer

Call for help when NXDOMAIN is intermittent (which points at inconsistent zone data across nameservers or a broken split-horizon setup), when a domain migration or registrar transfer has left delegation in a confused state, or when DNSSEC is involved and validating resolvers reject what non-validating ones accept. Erzon engineers can trace the resolution path hop by hop, reconcile zones and delegation with evidence, and leave you with DNS monitoring that catches the next missing record before your customers do.