Do DNS resolvers respect your TTL? A week of real traffic

"How long until my DNS change is live?" The textbook answer is "up to the TTL". The folklore answer is "up to 48 hours, because resolvers ignore TTLs". We run authoritative nameservers, so instead of repeating either, we measured what resolvers actually do.

1 What a TTL promises

Every DNS record carries a time to live in seconds (RFC 1035, clarified in RFC 2181). A resolver that caches the answer may reuse it for that long, then has to ask again. Two things follow:

• A change becomes visible within one TTL of being published, for resolvers that follow the rule. The TTL that matters is the one the resolver saw before the change, not the new one.
• Load on the authoritative side is roughly one query per resolver per TTL for each popular name. Raising a TTL from 60 to 3600 seconds should cut that by up to 60 times.

Resolvers are allowed some freedom. Many cap very long TTLs at a configured maximum, evict entries early when the cache is full, or refresh popular names shortly before they expire (Unbound's prefetch option, for example). Some also serve expired answers when the authoritative servers cannot be reached (RFC 8767).

2 How we measured it

We took one week of example data from the PrimeDNS nameservers. For every combination of resolver address, query name and record type, we sorted the queries by time and measured the gap between each query and the previous one, then compared each gap with the record's TTL. Only successful answers (NOERROR) with a TTL above zero were counted.

Each gap went into one of four groups:

• Under 5 seconds: retries and the same query sent to both nameservers at once. Normal resolver behaviour, kept separate.
• Before half the TTL: the resolver came back clearly early. This is what we call "early" below.
• Between half and the full TTL: early, but this range includes legitimate prefetching.
• After the TTL: the resolver waited as promised.

3 What resolvers actually do

About 10% of all gaps were retries under 5 seconds. The remaining repeat queries split like this:

The folklore is wrong as a rule: the large majority of resolvers wait for the TTL. It is right that some do not, and the interesting part is which ones.

3.1 Long TTLs are cut short more often

Short TTLs are honoured almost perfectly. From fifteen minutes upwards, early repeat queries grow, and for TTLs between one hour and one day a third of them come in before half the TTL. That fits how resolvers are run: caches have finite memory and evict entries that have not been used for a while, and many operators cap the maximum TTL below what zone owners set. A one-day TTL is a ceiling, not a guarantee.

3.2 Early repeat queries come from a small group

Of all resolver addresses that asked for the same record more than once, 13% came back early at least once. A small group dominates: the ten busiest of those addresses produced 38% of all early repeat queries, and the top hundred produced 75%.

By network (only networks with enough traffic in the sample to be meaningful):

The big public resolvers, which serve the most users, are among the most consistent, even though each of them runs many caches behind many addresses. The high shares come from a handful of resolver deployments, whose configuration we cannot see (a low maximum TTL, a small cache, or many caches behind one address would all produce this pattern). Our nameservers serve many dynamic DNS names with short TTLs and many users in Poland, so other operators will see different mixes. The shape, a well-behaved majority and a concentrated tail, is the useful part.

4 What this means when you change a record

1. Lower the TTL before the change, not with it. Resolvers cached the old TTL. Drop it to 300 seconds or less at least one old TTL before the change (with a one-day TTL, a day ahead), and raise it again afterwards.
2. Expect the bulk of users within one TTL. Over 90% of repeat queries respect it. The long tail is mostly clients and applications that cache on their own (browsers, Java runtimes, long-running processes), which DNS cannot reach at all.
3. Keep the old target working for a while. Leave the old server answering for a few TTLs after a migration, so stragglers fail gracefully instead of hard.
4. Do not use very long TTLs to cut load. Above an hour the gain shrinks because resolvers cut long TTLs short anyway. One hour is a sensible default for records that rarely change.
5. Short TTLs are fine where you need them. Dynamic DNS and failover records with 60 seconds were honoured almost perfectly in our data; the cost is more queries, not unpredictability.

You can watch a cached answer count down from any machine. The TTL in the answer of a recursive resolver is the time left in its cache; ask twice a few seconds apart:

dig +noall +answer www.example.com A @ns1.primedns.net   # the TTL as published
dig +noall +answer www.example.com A @1.1.1.1            # time left in this resolver's cache
sleep 10; dig +noall +answer www.example.com A @1.1.1.1  # roughly 10 seconds less

4.1 Can you force a resolver to refresh?

Not from your side of DNS. The protocol has no way for an authoritative server to tell resolvers to drop a cached answer; resolvers only ever ask. (DNS NOTIFY exists, but it only tells secondary nameservers that a zone changed.) What you can do is clear the cache in places you can reach:

• Large public resolvers have a page where anyone can flush a single name: Google Public DNS Flush Cache, Cloudflare 1.1.1.1 Purge Cache and OpenDNS CacheCheck.
• Your own resolver can drop the name directly:

unbound-control flush www.example.com       # Unbound
rndc flushname www.example.com              # BIND
rec_control wipe-cache www.example.com      # PowerDNS Recursor
pihole restartdns                           # Pi-hole / dnsmasq

• The computer and the browser keep their own short cache:

ipconfig /flushdns                                              # Windows
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder   # macOS
resolvectl flush-caches                                         # Linux with systemd-resolved
chrome://net-internals/#dns  then "Clear host cache"            # Chrome

Resolvers run by internet providers cannot be flushed from outside. Their users get the new value when the old TTL runs out, which is why lowering the TTL in advance is still the only reliable method.

5 How PrimeDNS handles this

The numbers in this article come from the same query data that drives PrimeDNS Observability. For your own zones the panel shows query volume, response codes, the resolvers and networks that query you, and a TTL advisor that lists frequently queried records with a TTL under 300 seconds, the candidates for raising the TTL to cut query load. When you plan a migration, you can see which names are actually being asked for before you touch them. Most DNS hosts show you the records you configured; this shows how the internet uses them.

To check a change as it spreads, use the Propagate button next to each record in the panel. It sends the same query at once to the PrimeDNS nameservers and a set of large public resolvers. For each one you see the answer it returns right now, how long it took, and whether it matches the value you just saved, right next to the record you edited:

• Both nameservers match: the change is published. If one of them does not, wait a moment and check again before anything else.
• A resolver shows Mismatch: it still has the old answer in its cache. The TTL in its answer is the time left before it asks again, which is the remaining wait for its users.
• All match: the large public resolvers have the new value. Users of other resolvers follow within the old TTL, as the data above shows for the large majority.

See the Observability guide for what each chart shows.

Data: one week of example data from the PrimeDNS nameservers, aggregated per network. No customer domains or resolver addresses are published. Network names are those registered for the autonomous systems and belong to their owners.