DNS answers are cached at every layer — the browser, the OS, the local resolver and public resolvers — for the duration of the record’s TTL. A record change is not visible everywhere immediately; it becomes visible as caches expire, which is why migrations lower the TTL in advance.
Before you start
You should understand record types and basic resolution. This article covers caching behavior and TTL strategy.
Step-by-step walkthrough
Step 1: Positive caching honors the TTL
A successful answer is cached for the TTL, so a change propagates as each cache expires. A high TTL means fewer queries but slower propagation; a low TTL means faster changes but more load on the authoritative servers and more lookups.
Step 2: Negative caching remembers failures
A failure, such as a nonexistent name, is also cached, for the TTL of the SOA record’s minimum field. This is why a newly created record can appear missing for a while: resolvers cached the earlier “not found”. Negative caching reduces repeated failures but delays recovery.
Step 3: Lower the TTL before a migration
To plan a change, reduce the TTL well before the switch so old entries expire quickly, make the change, then raise the TTL again. This bounds the window where some clients see the old answer and others see the new one.
Worked scenario
The TTL explains the propagation window.
dig example.com A +noall +answer
# example.com. 300 IN A 93.184.216.34 <- cached for 300 seconds
dig example.com A +noall +answer # may still show 93.184.216.34 after a changeWalk through the example
The 300 is the TTL, so resolvers keep that answer for five minutes. After you change the record, a client that cached it keeps the old address until the TTL expires, which is why some users see the change before others. Lowering the TTL beforehand shortens that window.
Common mistake
Assuming a DNS change is instant, then debugging “wrong” answers that are simply cached for the TTL. Another is setting a very low TTL permanently, which raises query volume and makes the authoritative servers a dependency for every lookup.
Verify the behavior
Query a record, note the TTL, change the record at the authoritative server, and re-query to observe the cached value persisting until expiry. Query from two resolvers and compare, and test negative caching by querying a name before creating it.
Interview exercise
How do you make a DNS change propagate quickly?
Answer and reasoning
Lower the TTL several hours or a day before the change, so cached entries expire soon after you make it, then raise the TTL once the change is stable. This limits how long any resolver can serve the old answer. Without lowering the TTL first, clients can keep the old record for the full original TTL.
Continue learning
Compare records in DNS record types and resolution in DNS resolution. Read the RFC 1034 domain concepts and try the Networking interview questions.