dig: NOERROR with an empty answer is not an error

A full dig response has a header, a question, and up to three sections of records. Most people read the answer section and nothing else, which works until the answer section is empty, at which point the header is the only part that tells you what happened.

dig example.com A

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4711
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

Two independent facts on that second line. The status, which says whether the query itself succeeded. And the answer count, which says how many records came back. They do not imply each other, and the case where they disagree is the one that wastes afternoons.

The four statuses, and who each one blames

REFUSED is the one that is almost never a fault in the domain. You have asked an authoritative server to do recursion, or asked a resolver that only serves its own network. Nothing is wrong with the record; you asked the wrong machine.

SERVFAIL is the ambiguous one, and it has two distinct causes worth separating immediately. The resolver could not reach any authoritative server for the zone, which is a delegation or a hosting problem. Or the answer failed DNSSEC validation, which is a signing problem and produces a domain that resolves fine on validating resolvers and fails on others. Rule the second out with one flag:

dig example.com A +cd

+cd disables checking. If the query succeeds with it and fails without it, you have a signing problem, not a hosting one, and no amount of restarting name servers will help.

NOERROR, ANSWER: 0

This is the reading that goes wrong most often, and the distinction has a name: NODATA.

NXDOMAIN means the name does not exist. NOERROR with zero answers means the name exists, and there is no record of the type you asked for. Those are two entirely different situations and they need two entirely different next steps.

dig shop.example.com A     # status: NOERROR, ANSWER: 0
dig shop.example.com CNAME # status: NOERROR, ANSWER: 1

There is the usual explanation. The name is a CNAME, or an AAAA-only host, or a name that exists solely to carry a TXT record. Somebody looking for a missing A record concludes the entry was deleted, recreates it, and now has two records fighting.

The habit worth forming is to ask for everything before concluding anything:

for t in A AAAA CNAME MX TXT NS SOA CAA; do
  printf '%-6s %s\n' "$t" "$(dig +short "$1" "$t" | tr '\n' ' ')"
done

Eight lines of output settles in one second what a sequence of single-type queries takes several minutes to establish.

The flags, and the two that matter

The flags line carries short codes and two of them change how you read everything below.

aa means the answer came from a server authoritative for the zone, so it is the current truth rather than a cached copy. Its absence on a query you sent directly to a nameserver is a signal: that server is not authoritative for the zone it was supposed to serve, which is the classic symptom of a delegation pointing somewhere that no longer hosts the domain.

tc means the response was truncated because it did not fit. dig retries over TCP automatically and you may never notice, but a client or a middlebox that cannot fall back to TCP simply fails. Large TXT sets and DNSSEC-signed zones are where this shows up, and it produces a domain that resolves in most places and mysteriously not in one office with an aggressive firewall.

The others are routine: qr on every response, rd for recursion desired, ra for recursion available, ad when the answer was validated.

Asking the right server, which is the whole skill

Three questions, three different servers, three different answers, and confusing them is why two people looking at the same domain disagree.

# What did I publish? Ask the authoritative server, directly.
dig @ns1.provider.net example.com A

# What is the world getting? Ask a public resolver.
dig @1.1.1.1 example.com A

# What does this machine get? Ask nothing, use its configured resolver.
dig example.com A

During a migration those three routinely disagree for a while, and that is not a fault, it is caches expiring on their own schedule. What is not happening is anything travelling anywhere: the record is already published, the old answer is simply still remembered.

There is a fourth question, and one flag answers it. Against a resolver, +norecurse tells it not to go and look anything up, so you see only what it already has cached:

dig @1.1.1.1 example.com A +norecurse

An empty answer means that resolver has nothing cached, so the next real query will fetch the current record. An answer with a small remaining TTL means it is about to. This is the closest thing there is to a direct reading of a cache's contents, and it turns "how long until this resolver catches up" from a guess into a number.

Two more modifiers, and one warning about the popular one

+short prints only the data, which is what you want in a script and never what you want while diagnosing, because it discards the status, the flags and the TTL.

+trace walks the delegation from the root, asking each level in turn. It is the tool for a delegation problem, and it answers a specific question: does the chain from the root actually arrive at the nameservers you think are hosting the domain.

The warning is that +trace does not use your resolver's cache and does its own iteration, so its result can differ from what a normal lookup returns. That is a feature when you are debugging a delegation and a trap when you are trying to work out why one particular user cannot reach a site. For that question, ask their resolver, not the root.

And when the machine you are on has no dig installed, which is most Windows desktops and a fair number of minimal containers, the fallback tool is the one that ships everywhere, along with the three ways its output misleads: nslookup, read carefully.

The answer section is also where the one structural limit of the record types shows up, and it shows up as an extra line you did not ask for. A name that resolves through an alias returns the alias and then the address, and at the apex of a domain that arrangement is not supposed to be legal at all: what your provider does about that is worth knowing before a migration.