How DNS Works: Recursive Resolution, Caching and TTLs, Diagrammed

You change an A record, run dig, and see the new address. Your colleague in another office still gets the old one an hour later. A new subdomain works for you and returns NXDOMAIN for a customer. None of this is random: it follows from how DNS resolution and caching work, and once you can draw the path a query takes, you can predict it.

This post follows one lookup from the browser to the authoritative server and back, with a diagram, then covers TTLs, negative caching, delegation, transport and the failure modes you meet in production.

The four roles in every lookup

A lookup touches up to four kinds of servers. Each knows a different part of the answer.

The root is not one machine. There are 13 root server identities, a through m.root-servers.net, run by 12 independent organizations, and anycast spreads them across more than 2,000 instances worldwide, according to root-servers.org in November 2026.

A lookup, step by step

Say your browser needs app.example.com and nothing is cached anywhere:

1. The browser checks its own cache, then asks the operating system's stub resolver.
2. The stub sends a query with the "recursion desired" flag to the configured recursive resolver: what is the A record for app.example.com?
3. The resolver has nothing cached, so it asks a root server. The root does not know the answer, but it knows who runs com, so it returns a referral: the NS records for com plus their addresses (glue).
4. The resolver asks a com TLD server, which returns another referral: the name servers for example.com.
5. The resolver asks one of those authoritative servers, which returns the answer: app.example.com. 300 IN A 203.0.113.10.
6. The resolver caches every record it learned for its TTL and returns the answer to the stub, which hands it to the browser.

The stub makes a recursive query: it wants a final answer. The resolver makes iterative queries: each server returns either the answer or a pointer to someone closer to it. Root and TLD servers never chase answers for you.

You can watch the iterative part with dig +trace, which starts at the root instead of using your resolver's cache (output trimmed):

$ dig +trace app.example.com
.                  518400  IN  NS  a.root-servers.net.
com.               172800  IN  NS  a.gtld-servers.net.
example.com.       172800  IN  NS  ns1.example.net.
app.example.com.   300     IN  A   203.0.113.10

Modern resolvers also apply QNAME minimisation (RFC 9156): they ask the root only about com and the TLD only about example.com, so servers higher up never see the full name you looked up.

Caching and TTLs

Every record carries a time to live in seconds. A resolver that caches app.example.com with a TTL of 300 answers from cache for the next five minutes, counting down, and only then asks the authoritative server again. Browsers and operating systems keep their own short caches on top.

This is what people call propagation. Nothing is pushed anywhere when you change a record. Each resolver that cached the old value keeps serving it until its copy expires, so the worst case is roughly the old TTL, not the new one. Resolvers also clamp very long TTLs: Unbound, for example, caps cached records at one day by default.

Practical rules for changes:

• Lower the TTL before a planned change. If a record has a TTL of 86400, set it to 300 at least a day before the migration, wait for the old TTL to pass, make the change, then raise it again.
• Use short TTLs only where you need fast failover. A 60-second TTL means more queries to your provider and more cache misses for users, each costing a full lookup.
• Changing name servers is slower. The parent zone's NS records for example.com carry their own TTL, 172800 seconds (two days) in com, and you cannot shorten it.

DNS-based failover depends on these numbers. The AWS multi-region architecture diagram and the disaster recovery architecture diagram show where a health-checked DNS record fits and why its TTL bounds your recovery time.

Negative caching: the NXDOMAIN trap

Resolvers cache "does not exist" too. When a name is missing, the authoritative server returns NXDOMAIN with the zone's SOA record, and the resolver caches that negative answer for the smaller of the SOA record's TTL and its MINIMUM field (RFC 2308).

The classic failure: someone queries api.example.com before the record exists, a resolver caches NXDOMAIN for an hour, you create the record, and that resolver keeps saying it does not exist until the hour is up. Check the negative TTL with dig example.com SOA before you announce a new hostname, and create records before anyone tests them.

Delegation, glue and lame servers

A zone exists in DNS because its parent delegates to it. The com zone holds NS records saying which servers are authoritative for example.com. If those name servers live inside the zone they serve, such as ns1.example.com, the parent also holds their addresses as glue records; otherwise resolvers could not find them.

Delegation breaks in two common ways. A lame delegation is a parent pointing at a server that no longer serves the zone, often after a provider migration, and it causes timeouts or SERVFAIL for some users. A mismatch between the NS records at the parent and inside the zone makes behavior depend on which set a resolver happened to cache.

Transport and privacy

Most DNS traffic is UDP on port 53. Answers that do not fit set the truncation flag, and the client retries over TCP, so TCP port 53 must be open too. Since DNS Flag Day 2020, major DNS software defaults to an EDNS buffer size of 1,232 bytes to avoid IP fragmentation, which makes TCP fallback more common for large answers such as DNSSEC-signed records.

Classic DNS is unencrypted. DNS over TLS (port 853), DNS over HTTPS and DNS over QUIC encrypt the hop between the stub and the recursive resolver; the hops from the resolver to root, TLD and authoritative servers are still mostly plain text.

DNSSEC solves a different problem: authenticity, not privacy. Each zone signs its records, and the parent vouches for the child's key, up to the root key that validating resolvers trust. On 11 October 2026 the root zone completed a rollover to a new key-signing key, KSK-2024. A validating resolver that never picked up the new trust anchor fails every lookup with SERVFAIL.

When lookups fail

Asking the authoritative server directly with dig @ns1.example.net app.example.com tells you what the truth is; asking a resolver tells you what users see.

The DNS resolution diagram

How to read it:

• Start at the laptop. Its stub resolver sends one recursive query to the resolver (step 1) and gets one answer back (step 8).
• The resolver does the walking. Steps 2 to 7 are iterative queries: the root and the com servers return referrals, and the authoritative server for example.com returns the record.
• TTLs sit on the answers. The A record comes back with a TTL of 300 seconds; that is how long the resolver will reuse it without asking again.
• The frame groups the hierarchy that you do not run, except for the authoritative server, which is yours or your DNS provider's.
• The Markdown block lists the cache layers and the TTLs that decide how quickly a change reaches users.

Drawing DNS diagrams that answer real questions

• Number the steps. DNS questions are about order: who asks whom, and when the cache answers instead.
• Separate recursive from iterative traffic. One query from the client, several from the resolver. If both look the same, the diagram hides the most important idea.
• Write TTLs on the answers. They explain propagation better than a paragraph does.
• Show ownership. Mark which servers you control. During an incident, that decides who you call.
• Draw the record change as its own diagram. A migration timeline with the TTL lowered, the cut-over and the TTL raised is clearer than annotations on the lookup diagram.

If the order of messages is the point, a sequence diagram works too, with the resolver and each server as lifelines. For the physical side, where resolvers sit in your network, see the network topology diagram guide.

Build it in Archboard

1. Sign in with Google or GitHub and create a diagram.
2. Add a Device node from the Network pack for the laptop and a DNS node for the recursive resolver.
3. Add a Core Frame named for the DNS hierarchy and put three more DNS nodes inside it: root, com TLD and the authoritative server for example.com.
4. Add a Server node from the Network pack for app.example.com, the host the browser connects to after the lookup.
5. Draw the edges in order and number their labels: the client's query and answer, then a query and a response between the resolver and each server. Put the TTL on the final answer.
6. Add a Markdown block from the Core pack with the cache layers and TTL rules.

The example uses 8 diagram nodes, within the Free plan.

FAQ

How long does DNS propagation take? Up to the TTL of the old record, for each resolver that cached it. Nothing is pushed; caches expire. Name server changes take longer because the parent zone's NS records have their own TTL, two days in com.

What is the difference between a recursive and an authoritative DNS server? A recursive resolver finds answers on behalf of clients and caches them. An authoritative server holds the records for a zone and answers only for that zone.

Why do I still see the old IP address after changing a record? A cache between you and the authoritative server still holds the old record: your browser, your operating system or your resolver. Query the authoritative server directly to confirm the change, then wait for the TTL to run out.

Is a very low TTL a problem? It costs more queries to your DNS provider and more full lookups for users, which adds latency on cache misses. Use low TTLs for records you may need to fail over, and longer ones for stable records.

Is DNS traffic encrypted? Not by default. DNS over TLS, HTTPS or QUIC encrypts the hop between your device and the resolver. DNSSEC adds signatures that prove records are authentic, but it does not encrypt anything.

Start free — one seat, no credit card.