DNS TTLs and Caching Explained

The short answer

Every DNS record carries a TTL, or time to live: a whole number of seconds that tells caches how long they may reuse the record. When a recursive resolver fetches www.example.com with a TTL of 3600, it can hand that same answer to every client that asks during the next hour without contacting the authoritative servers again. When the hour is up, the cached copy expires and the next query triggers a fresh lookup. The field is defined in RFC 1035, the DNS implementation specification, and clarified in RFC 2181, Clarifications to the DNS Specification.

TTL is a promise about the past, not the future.

A TTL you set today only affects caches that fetch the record after the change. Anything already cached keeps the old answer, with the old TTL, until it expires. That single fact explains most "DNS propagation" surprises.

What a TTL actually is

In the wire format, the TTL is a 32-bit field attached to every resource record. RFC 2181 limits the usable range to 0 through 2,147,483,647 seconds, but real values sit far below that: a few seconds for aggressive failover setups, and a day or two for stable infrastructure. A TTL of 0 means "use this answer for the current transaction only and do not cache it", which is legal but rarely a good idea.

TTLs belong to RRsets, not to individual values. An RRset is all the records that share a name, class and type, such as the three A records for www.example.com. RFC 2181 says the records in one RRset must have the same TTL, and resolvers treat a set as a unit: it is cached together and it expires together. If your zone file gives two A records for the same name different TTLs, many servers will quietly use the lowest one for the whole set.

In a BIND-style zone file, the $TTL directive sets the default for records that do not name their own TTL, and any record can override it. That directive was introduced by RFC 2308, which covers negative caching, because the SOA minimum field that older zones used as a default was repurposed. The full story is in Negative Caching and the SOA Minimum.

The most useful thing to know when you troubleshoot is that a cache counts down. An authoritative server always returns the configured TTL. A recursive resolver returns the time remaining on its cached copy, so the number you see from a resolver drops with every query until it reaches zero and the resolver fetches again.

Ask your recursive resolver twice, about 40 seconds apart:

$ dig +noall +answer www.example.com A @192.0.2.53
www.example.com.        3600    IN      A       203.0.113.10

$ dig +noall +answer www.example.com A @192.0.2.53
www.example.com.        3561    IN      A       203.0.113.10

Ask the authoritative server directly: always the configured value:

$ dig +noall +answer +norecurse www.example.com A @ns1.example.net
www.example.com.        3600    IN      A       203.0.113.10

If the first resolver answer already shows something like 2875 instead of 3600, someone else on that resolver asked recently and you are seeing their cached copy. That is normal, and it is the reason two people can get different answers for the same name at the same moment.

Where DNS answers get cached

People usually picture one cache, the recursive resolver, but an answer can be held in several layers between an application and the authoritative servers. Each layer can hold the record for up to its remaining TTL, and some layers apply their own rules on top.

ApplicationBrowsers and some language runtimes keep their own short-lived caches

Operating systemStub resolver caches such as systemd-resolved or the Windows DNS Client

Local forwarderHome routers, dnsmasq, or an office DNS appliance

Recursive resolverISP, enterprise, or public resolver that walks the hierarchy

Authoritative serverPublishes the record and its configured TTL; it does not cache it

Because each layer counts down independently, flushing one cache is not always enough. Clearing your laptop's cache does nothing about the copy in your office resolver, and restarting a browser does not touch the operating system. When a change is not visible, work outward one layer at a time, or query the authoritative servers directly to see the truth. The walkthrough in How a DNS Lookup Works, Step by Step shows where each layer sits in a real lookup.

How resolvers bend the rules

The TTL is the upper bound on how long a well-behaved cache keeps an answer. Resolvers are allowed to keep it for less time, and in practice they often adjust it in a few predictable ways.

Maximum caps. Most resolver software has a configurable ceiling. BIND, for example, defaults its maximum cache TTL to one week, so a record published with a 30-day TTL will still be refetched within seven days.
Minimum floors. Some operators raise very small TTLs to a floor to protect their resolvers and upstream servers. This is not standard behavior, but it exists, and it means a 5-second TTL is not a guarantee of 5-second failover.
Prefetching. Resolvers such as Unbound can refresh a popular record shortly before it expires, so clients never wait for a full lookup. Prefetching keeps answers warm; it does not extend them past the TTL.
Serving stale data. RFC 8767, Serving Stale Data to Improve DNS Resiliency, lets a resolver return an expired answer when it cannot reach any authoritative server. This keeps names working during an authoritative outage, but it also means an old answer can briefly outlive its TTL.
Many caches behind one address. Large public resolvers run many independent cache instances behind a single anycast address. Two queries a second apart can land on different instances and show different remaining TTLs, or even different answers during a change.

DNSSEC adds one more limit. A signed RRset carries an original TTL inside its RRSIG record, and RFC 4035, the DNSSEC protocol modifications, tells validating resolvers not to cache the data longer than that original TTL or past the signature's expiration time. If signatures are close to expiring, cached answers will expire with them.

Choosing TTL values

There is no single correct TTL. Long TTLs reduce load on your authoritative servers, cut lookup latency for users, and keep names resolving from cache if your DNS provider has an outage. Short TTLs let you move traffic quickly. Pick values per record based on how often the record really changes and how fast you need a change to take effect. The values below are common starting points, not rules.

Record or situation	Common range	Why
Stable A, AAAA, or CNAME records	3600 to 86400 seconds	Rarely change; long caching improves speed and resilience
Records used for DNS-based failover or load steering	30 to 300 seconds	Traffic needs to move within minutes of a health change
MX records	3600 seconds or more	Mail retries on its own, so fast changes are seldom needed
NS records at the zone apex	86400 seconds or more	Delegations change rarely; the parent's TTL also applies
TXT verification tokens and policies	300 to 3600 seconds	Short enough to fix a typo quickly, long enough to avoid churn
Records about to change	60 to 300 seconds, temporarily	Shrinks the window in which caches hold the old answer

Remember that NS records exist in two places. The copy in the parent zone has its own TTL that you do not control; the .com registry, for example, publishes delegation NS records with a two-day TTL. That is one reason a change of DNS provider takes longer to settle than a change of web server. See DNS Delegation and Glue Records for how the two copies interact.

Lowering a TTL before a planned change

The standard technique for a smooth cutover is to shorten the TTL well before the change, then restore it afterwards. The order matters, because the old TTL controls how long caches keep the old answer.

Note the current TTL. Suppose www.example.com has a TTL of 86400 (one day).
Lower the TTL to 300 at least one full old TTL before the change. In this example that means at least 24 hours ahead, so every cache that holds the one-day copy has expired it and picked up the 5-minute version.
Make the change, for example pointing the A record from 203.0.113.10 to 198.51.100.20.
Keep the old server running and serving correct content for at least the short TTL plus a margin, since some caches and clients hold answers longer than they should.
When the new answer is confirmed from several resolvers, raise the TTL back to its normal value.

Practical takeaway

Lowering a TTL at the same moment you change the record does not help. Caches holding the old answer keep it for the old TTL. Plan the TTL reduction one full TTL period in advance, and keep the old destination alive until the short TTL has passed.

The same approach applies, with longer timelines, when you change DNS providers. Moving DNS Providers Without Downtime covers the extra steps for NS records and DNSSEC.

Common TTL mistakes

Very short TTLs everywhere

Setting every record to 60 seconds "just in case" multiplies the queries your authoritative servers receive, adds latency for users whose resolver has to look the name up again, and removes your safety margin during a provider outage. With long TTLs, popular names keep resolving from cache for hours while the provider recovers. With very short TTLs, they fail within a minute.

Forgetting negative answers

If a resolver asks for a name before you create it, the "does not exist" answer is cached too. That negative TTL comes from the zone's SOA record, not from the record you later add, and it is a common cause of "I created it but it still does not resolve". The details are in Negative Caching and the SOA Minimum.

Mismatched TTLs inside an RRset

Giving records of the same name and type different TTLs causes inconsistent caching between implementations. Keep one TTL per RRset.

Blaming propagation for a configuration error

If the authoritative servers still return the old answer, waiting will not help. Always query an authoritative server directly with +norecurse before assuming a cache is the problem. DNS Propagation Myths walks through how to tell the two apart.

How DNS Panopticon helps

Domain Visualizer resolves a domain's public records through public DNS-over-HTTPS resolvers (Cloudflare by default, with Google and Quad9 available), and shows the TTL for each record in the record details and in the graph tooltips. Because those answers come from recursive resolvers, the TTL you see is the time remaining in that resolver's cache, not necessarily the value configured in your zone. When a second resolver is selected and returns a different answer for the same name and type, Domain Visualizer reports a resolver variance finding, which is often the visible sign of a change that some caches have not picked up yet. Visualizer also has an application cache, separate from DNS TTLs: scan results are cached for 24 hours by default, configurable by the administrator from one minute to seven days. Re-running after a DNS TTL has passed may therefore return the same saved scan. Wait for the configured scan cache to expire or ask an administrator to purge the cached scan. Query the authoritative name servers directly when you need to check a change immediately.

Zone Analyzer shows the configured side. Load a zone export and the grid includes a TTL column that you can sort or filter numerically, for example to list every record with a TTL under 600 seconds before a migration, or to find records that were lowered for a change and never raised again.

Website Recon uses TTLs as one of its risk signals: when a name returns more than two IP addresses with a minimum TTL under 300 seconds, it notes a short-TTL address pool. CDNs and load balancers commonly look like this, so it is not evidence of fast flux by itself, a technique abusive hosting uses to rotate addresses quickly. Fast flux shows up as addresses that keep changing across unrelated networks over time, which needs repeated lookups to see.

FAQ

What is a good default DNS TTL?

For records that rarely change, 3600 seconds (one hour) is a common default, and many stable records use a day. Use shorter values, such as 300 seconds, only for records that need fast failover or that you are about to change.

Why does dig show a different TTL each time I run it?

When you query a recursive resolver, it returns the time remaining on its cached copy, which counts down until the record expires and is fetched again. Query the authoritative server with +norecurse to see the configured TTL.

Does lowering the TTL make my change appear faster?

Only if you lower it in advance. Caches that already hold the record keep it for the old TTL, so reduce the TTL at least one full old TTL period before the change, then raise it again afterwards.