DNS
Name Resolution

The Resolution Path

When an application resolves a name, the query passes through layers, each cached independently: the application or library cache, then the OS stub resolver (on Linux the lookup order — DNS, the hosts file — is set by nsswitch.conf, and /etc/hosts can short-circuit DNS entirely), then a recursive resolver. The recursive resolver is the workhorse: on a cache miss it walks the hierarchy on the client's behalf — root, then the TLD servers, then the zone's authoritative servers — and caches the answer for its TTL.

"Propagation" Is a Misnomer

There is no propagation. An authoritative change takes effect immediately at the authoritative server. What you observe as delay is caches holding the old answer until their TTL expires. Three consequences follow, and they turn a vague "wait for DNS" into concrete actions:

1. Lower the TTL in advance of a planned change, so caches expire quickly around the cutover.
2. Query the authoritative server directly after a change to confirm it is correct, then attribute any remaining lag to caching layers — not to "the internet catching up."
3. Remember that negative answers are cached too. A nonexistent name (NXDOMAIN) is cached per the zone's SOA negative-TTL, so a name you queried before creating it can stay "nonexistent" in caches afterward — which looks like a config failure but is negative caching.

Record Types You'll Meet

A few behaviours that cause confusion: CNAME chains add lookups and must terminate at an A/AAAA; a name can have multiple A records, which clients pick from and cache — so this is crude round-robin, not real load balancing or failover; and MX and SRV carry priorities that clients are expected to honour.

Resolver Topologies

Recursive vs authoritative are different jobs, and mixing up which one you are querying is a common troubleshooting error. A recursive resolver answers any query by chasing the hierarchy and caching; an authoritative server answers only for its own zones and does no chasing.

Forwarders: an internal resolver may forward unresolved queries to an upstream resolver instead of going to the root itself. Split-horizon (split DNS): the same name returns different answers depending on who asks — internal clients get internal addresses, external clients get public ones. Expect this inside organizations; "it resolves differently from home vs the office" is usually split DNS, not a fault. Public resolvers reachable at well-known anycast addresses sit topologically "everywhere," so two clients using the same resolver IP may hit different physical instances — which is why an intermittent failure can affect some users of "the same" resolver and not others.

Troubleshooting DNS

The method is one comparison: identify which resolver answered, and check it against the authoritative answer. If they differ, the fault is in the resolver layer — a cache, the wrong server, or an override — not the zone data.

Read the response status, because each points at a different cause:

A few faults and their signatures: the app resolves "wrong" while dig looks right (a different cache/resolver or a hosts entry — check nsswitch and the app's own config); a created record still "not found" (negative caching, or you're querying a cache not the authoritative server); works for small answers but fails for large ones or zone transfers (DNS uses UDP/53 normally but falls back to TCP/53 for large answers — a firewall permitting only UDP/53 breaks this); and SERVFAIL only for DNSSEC-signed zones (a validation failure — bad signatures, clock skew, or a broken chain of trust). The exact commands (dig, dig +trace, dig @server, resolvectl status, nslookup) are grouped on the Diagnostic Command Card.

Security Notes

Framed as specific threats and the residual risk each control leaves — never as a blanket "secure":

Rogue DHCP/DNS and resolver hijacking can point clients at attacker-controlled resolvers, a man-in-the-middle on every lookup. Mitigations live partly at Layer 2 (DHCP snooping) and partly in controlling and validating resolver configuration. Residual: none of this helps if a legitimate resolver is itself compromised.

DNSSEC lets a validating resolver cryptographically confirm that records came from the zone's owner and were not modified — mitigating spoofed and cache-poisoned answers. It provides authenticity and integrity, not confidentiality: queries and answers are still visible on the wire, and it only helps for signed zones reached through a validating resolver.

Encrypted transport — DoT, DoH, and DoQ — hides query contents from on-path observers. It does the opposite job from DNSSEC: it protects confidentiality, not the authenticity of the answer. DoH in particular blends into ordinary HTTPS, which complicates enterprise DNS visibility and filtering.

DNS as an exfiltration/C2 channel. Because DNS is almost always permitted outbound, attackers tunnel data through it. Monitoring query patterns — volume, name entropy, unusual record types — is a detection control, and it is a concrete reason egress control and DNS query logging matter. Filtering resolvers (Protective DNS / RPZ) can block resolution to known-malicious domains, which is the approach NIST's DNS security guidance (SP 800-81, currently revision 3 — verify the current revision) pairs with encrypted DNS so that encryption doesn't cost you all filtering visibility.