Reading DNS by hand — Domain Security Fundamentals

Every finding in the rest of this course is something you confirm with dig. A control panel shows you what it stored; dig shows you what the internet can actually see, and the difference between those two is where a surprising number of problems live.

Reading an answer

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41255
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;example.com.            IN   A
;; ANSWER SECTION:
example.com.        69   IN   A    104.20.23.154
example.com.        69   IN   A    172.66.147.243

status: NOERROR — the query succeeded. NXDOMAIN means the name does not exist; SERVFAIL means the server could not answer, which under a validating resolver often means DNSSEC failed.
flags — qr response, rd recursion desired, ra recursion available. The one to look for is aa, authoritative answer, which appears only when you are talking to a server that holds the zone.
ANSWER: 2 — two records returned. Counts here let you spot an empty NOERROR at a glance.
The TTL column, 69, is time remaining if you asked a resolver, or the configured value if you asked an authoritative server.

Checked 2026-09-12.

The commands worth knowing

Command	Use
`dig +short TXT example.com`	Just the data. Right for scripts and quick checks.
`dig +noall +answer A example.com`	The answer section with TTLs, without the rest.
`dig +trace example.com`	Walk from the root yourself. Shows where an answer comes from.
`dig @ns1.example.com A www.example.com`	Ask one specific server. The only way to know what you actually published.
`dig +norecurse @a.gtld-servers.net NS example.com`	The parent’s delegation, not the child’s copy.
`dig +dnssec A example.com`	Include RRSIG records and the ad flag.
`dig -x 198.51.100.25`	Reverse DNS.

The habit worth forming

When something looks wrong, ask the authoritative server directly before anything else. It separates "I published the wrong thing" from "I published the right thing and a cache has not caught up", and those two have completely different responses.

Three ways a check misleads you

Your resolver is not their resolver. A corporate resolver may have split-horizon views, local overrides, or a filtering policy. Confirm against a public resolver and against the authoritative server before concluding anything about the outside world.
Not all of your nameservers necessarily agree. If a zone transfer has failed, one secondary can be serving stale data while the rest are correct. Query each listed nameserver individually and compare SOA serials — a divergence there is the single clearest symptom.
ANY does not mean all. Many servers refuse or minimise ANY queries. An empty ANY response is not evidence that a name has no records.

# do the serials agree across every authoritative server?
for ns in $(dig +short NS example.com); do
  printf '%-28s ' "$ns"
  dig +short @"$ns" SOA example.com | awk '{print $3}'
done

Knowledge check

You publish a new TXT record. dig against your authoritative nameserver shows it. dig against 8.8.8.8 returns NOERROR with no answer. Ten minutes later 8.8.8.8 still shows nothing. What is the most likely explanation?

The record is wrong, because a correct record would appear immediately.
The resolver cached the earlier absence of the record, and it will keep doing so for the zone’s negative-caching TTL.
The change has not propagated to your other nameservers yet.
TXT records take longer to appear than other record types.

Not this — The record is wrong, because a correct record would appear immediately. The authoritative server is serving it, so what you published is present and correct. The discrepancy is downstream of publication.

Correct — The resolver cached the earlier absence of the record, and it will keep doing so for the zone’s negative-caching TTL. Something queried that name before the record existed, so the resolver cached the NXDOMAIN or empty answer. The duration is the last field of the SOA, not any record TTL — which is why this wait can be a different length from the one you expected.

Not this — The change has not propagated to your other nameservers yet. Worth checking, and it would show as differing SOA serials between your nameservers. But it would not produce a consistent empty answer from a public resolver that had previously cached the absence.

Not this — TXT records take longer to appear than other record types. No record type is treated differently in caching or distribution. The type has no bearing on this.