DNS from Request to Response

Why this matters

DNS is the most-cached system in your stack and the one engineers least understand — TTLs you set today govern how fast a failover takes effect tomorrow. Negative caching means a typo'd record propagates a no-answer for 5 minutes by default, and recursive resolvers in front of your users won't refresh just because you fixed it.

Demo

Trace a DNS query end-to-end through the recursive resolver chain.

Try it yourself

1. Run dig +trace example.com and label each hop: root, TLD, authoritative.
2. Query a non-existent subdomain twice — note the SOA minimum TTL controlling negative cache duration.
3. Drop a record's TTL from 3600 to 60 in a non-prod zone and time how long old answers persist on a public resolver.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, explain how DNS resolution works like I'm new to it — what happens between typing a URL and getting an IP?

2. Why it works (the mechanism)

Walk me through a recursive DNS query step by step: stub resolver, recursive resolver, root, TLD, authoritative — including caching at each tier.

3. Advanced — application & what's next

Given a planned datacenter failover at 02:00 UTC, what TTL strategy do you set 24 hours before and 1 hour before the cutover, and why?

References

• RFC 1034 — DNS concepts
• RFC 2308 — Negative caching of DNS queries