DNS — NXDOMAIN response for a name that should exist

Diagnose NXDOMAIN by checking the queried name, search domains, resolver configuration and record presence.

beginnerdebuggingdnsnetworking

Symptoms

Name or service not known / NXDOMAIN
It resolves from one machine but not another
A short name fails while the fully qualified name works
The name resolves externally but not internally

Possible causes

The queried name has no matching record
Search domains cause a short name to be queried wrongly
The resolver points at a server without the internal record
The record was created in a different zone or split-horizon view

Diagnosis steps

Inspect the actual query and answer

dig +search app.internal ; dig app.internal

Interpretation

dig shows the name actually queried and the response code, revealing whether search domains changed the query.

Check which resolver is used

cat /etc/resolv.conf

Interpretation

The nameserver and search domains explain why the same name resolves differently across machines.

Query the authoritative server

dig @10.0.0.53 app.internal

Interpretation

Asking the authoritative server directly bypasses caching and local resolver policy that could return NXDOMAIN.

Root cause

The DNS query for that name returned NXDOMAIN because no record matched the name as queried, often due to search domain expansion, a resolver that lacks the internal zone, or a missing record.

Fix

Query the fully qualified name, correct search domain or resolver configuration, and create the record in the zone the client actually queries.

Verify the fix

Resolve the name again from the affected host and confirm an address is returned, and confirm the resolution matches from other hosts.

Symptom walkthrough

A name fails to resolve with NXDOMAIN or name not known, yet the same name works from another machine or from the public internet. DNS answers depend on the name queried and the resolver used, so a short name expanded by search domains, a resolver lacking an internal zone, or a missing record all produce the same symptom with different causes.

Fix in practice

Query the fully qualified name and read dig output to see what was actually asked, check resolv.conf for the nameserver and search domains, and query the authoritative server to bypass caches. Then create or correct the record in the zone the client really uses.

Verification

Resolve the name again from the affected host and confirm an address returns, then confirm resolution is consistent from other hosts. Consistent answers across hosts confirm the fix.

Diagnostic commands

Check the behavior with commands like these:

dig +search app.internal ; dig app.internal
cat /etc/resolv.conf
dig @10.0.0.53 app.internal