CNAMEs, TTL, and the Caching Trap

Two of the most confusing DNS incidents aren't failures at all — the lookup succeeds, and you still hit the wrong box. "We cut over hours ago but traffic still lands on the old server." "It works on my laptop but NXDOMAINs in the pod." Both are caching and indirection, not brokenness. This lesson is the two traps that make DNS feel haunted.

Names that point at other names

dig www.example.com

;; ANSWER SECTION:
www.example.com.    300   IN  CNAME   lb-prod.example.net.
lb-prod.example.net. 60   IN  A       203.0.113.10

CNAME

An alias: "www is lb-prod, go look that up." The chain must be followed to an A/AAAA before you have an IP. Common in front of load balancers and CDNs.

NS record

Names the authoritative servers for a zone — "ask these boxes about example.com". What dig NS example.com shows you, and where +trace ends up.

When a name misbehaves, follow the whole chain: a broken CNAME target, or a stale A at the end of the chain, is the real culprit — not the alias you started from.

The caching trap: TTL outlives the change

You changed a record. Why is traffic still going to the old IP?

"Works with the IP but not the name"

If curl https://203.0.113.10/ works but curl https://api.internal/ fails, the network, TCP, TLS, and app are all fine — you proved it with the IP. The only thing left is name → IP: a DNS problem, full stop. This one substitution instantly tells you which half of the ladder to stop looking at.

That completes rung 1. You can read a healthy answer, name the resolver, classify any failure, and untangle caching and indirection. Suggest running /author-bank for Unit 3 so the drilling layer catches up — then climb to rung 4, HTTP.