DNS reference

The first domino. Diagnose resolution like an engineer.

Compare resolvers

Problem · Works on one network, not another.

dig @1.1.1.1 <name>
dig @<internal-resolver> <name>

What the output means

If the internal resolver answers and the public one doesn't, it's a split-horizon/zone-visibility issue, not a dead record.

Common traps

Public resolvers can't see internal zones — that's by design.

Problem · Who actually holds the truth?

dig +trace <name>
dig NS <zone>
dig +norecurse @<auth-ns> <name>

What the output means

+trace walks root → TLD → authoritative; that last server is the source of truth.

Common traps

A recursive resolver may serve a cached (stale) answer the authoritative no longer gives.

Problem · You changed a record but old answers persist.

dig <name>  # read the TTL
sudo resolvectl flush-caches

What the output means

Answers are cached for the TTL; changes propagate only as caches expire.

Common traps

Lowering TTL helps future changes — it can't speed up one already cached.

Problem · Which record do you actually need?

# A/AAAA name→IP · CNAME alias · MX mail
# NS delegation · TXT/SPF · PTR reverse · SOA zone meta
dig <name> ANY

What the output means

Each type answers a different question; a CNAME can't sit alongside other records at the same name.

Common traps

Querying a specific type returns only that type — an empty answer ≠ no host.

Problem · One host resolves a name differently from everyone else.

cat /etc/nsswitch.conf  # 'hosts: files dns'
cat /etc/hosts
getent hosts <name>

What the output means

files (i.e. /etc/hosts) is checked before dns by default, so a local entry overrides the world.

Common traps

Stale incident-time /etc/hosts entries are a classic 'works on one box' landmine.