The memory effect
If every DNS query for google.com hit Google's authoritative servers directly, those servers would be overwhelmed within seconds. DNS solves this with caching. When a recursive resolver fetches a record, the authoritative server includes a TTL (Time To Live) value — a number in seconds — that tells the resolver how long to remember the answer before asking again.
example.com. 300 IN A 93.184.216.34
^^^
TTL: cache this answer for 300 seconds (5 minutes)
This creates a fundamental trade-off:
| TTL Value | Propagation Speed | DNS Query Load |
|---|---|---|
| High (86400s = 24h) | Slow — changes take up to 24h to reach all clients | Low — servers are rarely queried |
| Low (60s = 1 min) | Fast — changes visible within a minute | High — servers are queried constantly |
This is why when you change a website's IP address, some users see the new site immediately while others still reach the old one for hours — they are reading from a cached copy of the old record. The maximum time it takes for a change to be visible everywhere is equal to the TTL that was set before the change was made.
Best practice for planned changes: Lower the TTL to 300 seconds (or less) at least one full TTL cycle before making the change. After the change is confirmed stable, raise the TTL back to a higher value.
Negative caching also exists: if a resolver queries for a name that doesn't exist (NXDOMAIN), it caches that negative result for the duration specified in the SOA's minimum TTL field. This prevents repeated queries for non-existent names from hammering authoritative servers.