DNS Resolution and Record Types: Cache Chain, Records, Debug Commands

What DNS does: turning names into records

DNS is a distributed name → record lookup system. It survives global traffic through hierarchical delegation and heavy caching: the closer the cache hit, the faster the lookup — and the harder it is to make a change take effect immediately.

Common record types

The cache chain a lookup walks

1. The browser's own cache (usually short-lived);
2. The OS cache and the hosts file;
3. A local recursive resolver (ISP or a public DNS);
4. On a miss, step down the tree: root → TLD → authoritative.

Because caches live on other people's machines, the TTL is the fastest propagation you can control.

Choosing TTLs

• Stable records (MX, long-lived A): hours — fewer lookups;
• Records you plan to change: lower the TTL to around 300s first, change, then raise it again;
• Failover setups: shorter TTLs switch faster, but query volume rises and some networks clamp low values anyway.

Three frequent traps

1. CNAME at the apex: most registries forbid it — use ALIAS/ANAME or plain A records;
2. "I changed it and nothing happened": stale local cache — retest from another network or public DNS instead of editing repeatedly;
3. A without AAAA: dual-stack clients take unpredictable paths — either configure both or state that IPv6 is unsupported.

Debug commands

dig example.com A +short          # A record
dig example.com AAAA +short       # IPv6
dig example.com NS +short         # authoritative servers
dig @8.8.8.8 example.com A        # compare against a resolver
dig example.com A +trace          # follow the whole chain

Real-world scenarios: three DNS puzzles

1. "Some users still hit the old IP during a cutover": TTL and layered caches at work — lower the TTL and leave a window before switching.
2. "Mail fails while the A record is fine": mail uses MX and SPF/DKIM TXT records, unrelated to A — do not edit the wrong record.
3. "Resolves locally but fails abroad": possibly split-horizon answers or resolvers out of sync; compare authoritative vs recursive with dig from multiple locations.

Common questions

Why does it work for others but not me? Different caches and resolvers — flush locally or compare from another network. Does DNS affect page speed? Yes, mostly on the first visit; dns-prefetch helps. Is public DNS always faster? No — it depends on the path from your network, so measure before choosing.

An order for debugging resolution failures

1. Verify layer by layer: query the authoritative server to confirm the record itself, then a public resolver to check recursion, then locally to rule out stale cache. The layer that fails tells you whether it is your record, upstream or your own environment.
2. Cache and propagation: after a change, mind the propagation setting. Too long and changes are slow to take effect; too short and query load rises — choose a middle ground by change frequency.
3. Resolution is not reachability: a successful lookup only yields an address, not a reachable port. Test resolution and connectivity separately instead of conflating them.
4. Multiple addresses: with several addresses per name, which one a client picks is not fully controllable, so consider that some clients still use a failed address.
5. Internal zones: internal names depend on internal resolvers, and hybrid environments often show "works in the office, not in the cloud" — confirm the resolver configuration is deployed everywhere.

Separating resolution, connectivity and port checks is one of the most valuable habits in network troubleshooting.