DNS TTL

DNS TTL is the number of seconds that a record in the DNS may be cached before the source of the information has to be consulted again. It is part of the fixed header that every DNS resource record carries. This header also holds the record’s type and class. The zone administrator sets the TTL, not the client that reads it. “The TTL is assigned by the administrator for the zone where the data originates” (RFC 1034, section 3.6).

Two things it is not. It is not an HTTP setting. It says nothing about how long a page, an image or an API response may be cached. The Cache-Control header and the HTTP TTL govern that instead. And it is not a purge. It only caps how long an answer that has already been handed out may be reused. So lowering it clears nothing that is already sitting in a cache. DNS has no equivalent of a cache purge to force one. For CDN work that makes it a scheduling number, not a tuning knob. The TTL on your hostname record decides how long a cutover, a rollback or a DNS-level failover takes.

How it works

1. It is a field on the record. RFC 1035, section 4.1.3 defines TTL as “a 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded”. Section 3.2.1 words the same field as “the time interval that the resource record may be cached before the source of the information should again be consulted”. But it calls the field signed. RFC 9499 records that “[RFC1035] erroneously stated that this is a signed integer; that was fixed by [RFC2181]” (RFC 9499, section 5). RFC 8767, section 4 amends the RFC 1035 definition outright. It changes the wording to “a 32-bit unsigned integer number of seconds that specifies the duration that the resource record MAY be cached before the source of the information MUST again be consulted”.
2. Range and zero. A TTL is “an unsigned number, with a minimum value of 0, and a maximum value of 2147483647. That is, a maximum of 2^31 - 1”. RFC 8767 calls that span the 68 years: “the 68 years allowed by the full 31 bits of Section 8 of [RFC2181]” (RFC 2181, section 8; RFC 8767, section 4). RFC 2181 told implementations to treat a received value with the top bit set as zero. RFC 8767 changed that. It notes “Interpreting values that have the high-order bit set as being positive, rather than 0, is a change from [RFC2181]”. A TTL of zero means the record “can only be used for the transaction in progress, and should not be cached” (RFC 1035, section 3.2.1).
3. Caches expire it; they do not tick it down. The TTL is “a time limit on how long an RR can be kept in a cache” (RFC 1034, section 3.6). In practice a resolver converts the interval into an absolute expiry time when it stores the record: “Instead of counting the TTLs down individually, the resolver just ignores or discards old RRs when it runs across them in the course of a search” (RFC 1034, section 5.3.2).
4. An answer from a cache carries the time that is left, not the configured value. RFC 1034 walks through exactly this case. A cached response differs from the authoritative one: the AA bit is clear, and “the TTLs are different… The difference between the authoritative TTL and the TTL here is due to aging of the data in a cache” (RFC 1034, section 6.2.1).
5. It is a ceiling, not a floor and not a promise. “Implementations are always free to place an upper bound on any TTL received, and treat any larger values as if they were that upper bound. The TTL specifies a maximum time to live, not a mandatory time to live” (RFC 2181, section 8). RFC 9499 gives the reason: “a cache operator might decide to shorten the time to live for operational purposes, for example, if there is a policy to disallow TTL values over a certain number” (RFC 9499, section 5).
6. More than one cache holds the answer. On a typical host “the resolver and its cache will be part of the host operating system”, and less capable hosts “implement the resolver as a subroutine to be linked in with every program” (RFC 1035, section 2.2). A recursive resolver, the operating system and the application can therefore each be holding the same answer. That is why the wait after a record change is often longer than the record’s own TTL.
7. One TTL per record set. “The use of differing TTLs in an RRSet is hereby deprecated, the TTLs of all RRs in an RRSet must be the same” (RFC 2181, section 5.2).
8. A record with no TTL of its own inherits the zone default. RFC 2308 extended the zone file format with a $TTL directive: “All resource records appearing after the directive, and which do not explicitly include a TTL value, have their TTL set to the TTL given in the $TTL directive” (RFC 2308, section 4). RFC 9499 notes the same idea in server software: “There is also the concept of a ‘default TTL’ for a zone, which can be a configuration parameter in the server software” (RFC 9499, section 5). A CDN hostname that was never given an explicit TTL is running on whatever that default is.
9. Names that do not exist are cached too. An authoritative server “MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists”. That SOA record carries the TTL for the negative answer: “the TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer” (RFC 2308, section 3).

Why it matters for a CDN

Putting a CDN in front of a hostname is normally a DNS change. You point the name at the provider with a CNAME. Akamai states the requirement plainly for a custom-certificate edge hostname: “You need to change the existing DNS record of your hostname to be a CNAME record that points to the edge hostname”. It then states the consequence: “This depends on the time to live (TTL) set on the existing DNS record for the hostname in question. This is commonly set to one day, which means it would take up to 24 hours before your end users are directed to the Edge network” (Akamai, Go live). The TTL on the old record, not the new one, is what bounds the changeover.

Only part of the chain is yours. This is because “the TTL is assigned by the administrator for the zone where the data originates” (RFC 1034, section 3.6). Your CNAME’s TTL governs how long clients keep pointing at that provider. The TTLs on the records the CNAME resolves to sit in the provider’s zone. Those are the provider’s to set, not yours. Lowering your own record to 60 seconds does not shorten those. It is those TTLs that the CDN uses to move traffic between its own addresses.

That gives one trade-off with a number on each side. A long TTL slows change: “if you specify a longer value for TTL, it takes longer for changes to the record (for example, a new IP address) to take effect because recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information” (AWS, Route 53 record values). A short TTL is what makes DNS-level failover and provider switches quick: AWS recommends “a TTL of 60 seconds or less so clients respond quickly to changes in health status” on any record associated with a health check (AWS, Route 53 record values).

The other side is load and latency. AWS gives an example of a longer TTL: 172800 seconds, or two days. At that length, “you reduce the number of calls that DNS recursive resolvers must make to Route 53 to get the latest information in this record. This has the effect of reducing latency and reducing your bill for Route 53 service” (AWS, Route 53 record values). Cloudflare frames the same trade-off from the other end: “Longer TTLs speed up DNS lookups by increasing the chance of cached results, but a longer TTL also means that updates to your records take longer to go into effect” (Cloudflare, Time to Live (TTL)).

Five minutes is where the industry has settled for CDN hostnames. Cloudflare’s Auto setting “is set to 300 seconds (five minutes)” (Cloudflare, Time to Live (TTL)). AWS advises that when you are “changing settings for a domain or subdomain that’s already in use, we recommend that you initially specify a shorter value, such as 300 seconds, and increase the value after you confirm that the new settings are correct” (AWS, Route 53 record values).

What CDNs do

The TTL lives in the zone you control. But the CDN providers that also run authoritative DNS constrain what you may put there. The constraints differ:

• Cloudflare. “By default, all proxied records have a TTL of Auto, which is set to 300 seconds. This value cannot be edited”. The fixed five minutes is deliberate: it “ensures that potential changes to the assigned anycast IP address will take effect quickly, as recursive resolvers will not cache them for longer than 300 seconds (five minutes)”. For records that are DNS-only, “you can choose a TTL between 30 seconds (Enterprise) or 60 seconds (non-Enterprise) and 1 day”. So the floor you can actually reach depends on the plan (Cloudflare, Time to Live (TTL)).
• AWS Route 53. The TTL element on an ordinary record has a “Valid Range: Minimum value of 0. Maximum value of 2147483647”. Alias records are how a zone apex is pointed at CloudFront or an ELB. They have no TTL of their own: “If you’re creating or updating an alias resource record set, omit TTL. Amazon Route 53 uses the value of TTL for the alias target” (AWS, Route 53 API: ResourceRecordSet).
• Akamai Edge DNS. “The minimum supported TTL value for DNS zones on Edge DNS is” 300 seconds (5 minutes). This applies to primary, secondary and alias zones. Alias zones cannot define their own TTL at all. Two caveats on the same page matter before you quote that figure as a hard rule. “Some DNSSEC-signed records may be subject to higher implicit effective TTL due to signature validity windows”. And “Contract-level variations may apply if specifically negotiated; otherwise the global minimum applies” (Akamai, Edge DNS features).

Watch out for

• Confusing it with HTTP cache TTL. They are different mechanisms on different objects. “The max-age response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds” (RFC 9111, section 5.2.2.1). That governs content. DNS TTL governs names. Content that will not update is a Cache-Control problem. A name that will not move is a DNS TTL problem.
• Treating a TTL cut as a flush. Lowering the TTL only shortens the caching of answers handed out after the change. Copies already cached keep the lifetime they were issued with. That is why the lead time has to be at least one full old-TTL period: “If a change can be anticipated, the TTL can be reduced prior to the change to minimize inconsistency during the change, and then increased back to its former value following the change” (RFC 1034, section 3.6).
• Assuming the recursive resolver is the last cache. Even at Cloudflare’s fixed 300 seconds, “It may take longer than 5 minutes for you to actually experience record changes, as your local DNS cache may take longer to update” (Cloudflare, Time to Live (TTL)). Operating systems, browsers and long-lived application processes hold answers on top of the resolver.
• Resolvers going shorter than you set. A resolver may cap what it received (RFC 2181, section 8). “Some servers are known to ignore the TTL on some RRsets (such as when the authoritative data has a very short TTL) even though this is against the advice in [RFC1035]” (RFC 9499, section 5). A one-second TTL does not buy one-second failover.
• Resolvers going longer than you set. The opposite risk is serve-stale: “If the data is unable to be authoritatively refreshed when the TTL expires, the record MAY be used as though it is unexpired”. A resolver that returns stale records “MUST set the TTL of each expired record in the message to a value greater than 0, with a RECOMMENDED value of 30 seconds” (RFC 8767, section 4). The same amended definition of the field says TTL values “SHOULD be capped on the order of days to weeks, with a recommended cap of 604,800 seconds (7 days)”. So a multi-year TTL is not honoured either.
• Freezing a steering decision. Latency, geolocation and weighted routing are the Geo DNS family of features. They are decided when the authoritative server answers. Until the TTL expires, the resolver keeps handing out that decision instead of asking for a new one. This is because “recursive resolvers use the values in their cache for longer periods before they ask Route 53 for the latest information” (AWS, Route 53 record values). AWS makes the consequence explicit for multivalue answers: “If a resource becomes unavailable after a resolver caches a response, client software typically tries another of the IP addresses in the response”. TTLs also skew weighted distribution: “All of the resource record sets in a group of weighted resource record sets must have the same value for TTL”. Where the group includes weighted alias records pointing at an ELB, AWS recommends 60 seconds on the non-alias members. This is because “Values other than 60 seconds (the TTL for load balancers) will change the effect of the values that you specify for Weight” (AWS, Route 53 API: ResourceRecordSet).
• Negative answers lingering. The SOA MINIMUM field no longer means a zone-wide minimum: “The remaining of the current meanings, of being the TTL to be used for negative responses, is the new defined meaning of the SOA minimum field” (RFC 2308, section 4). Set it large and a mistyped or not-yet-created CDN hostname keeps returning NXDOMAIN long after you fix the zone. RFC 2308 tells resolvers to bound this. It says “it is sensible for a resolver to limit for how long it will cache a negative response as the protocol supports caching for up to 68 years”. It also reports that “Values of one to three hours have been found to work well and would make sensible a default. Values exceeding one day have been found to be problematic” (RFC 2308, section 5). That is guidance to the resolver, not a promise to you: your NXDOMAIN can be cached for whatever the two ends agree on.
• Misreading a TTL you queried. dig prints the TTL of each record it receives. The dig manual documents the switch that controls it, +ttlid: “This option displays [or does not display] the TTL when printing the record”. What it receives from a resolver is the aged value, not your configured one. In the example below, 247 is what is left of a 300-second TTL. If you want the configured figure, query an authoritative server directly and check that the answer comes back flagged authoritative (RFC 1034, section 6.2.1).

Best practice

• Set the TTL from how fast you might need to move traffic, not from habit. On records tied to a health check, use 60 seconds or less (AWS, Route 53 record values). On a CDN hostname you expect to keep, 300 seconds is the settled default (Cloudflare, Time to Live (TTL)). On records that genuinely never move, AWS’s own example of a long value is 172800 seconds (AWS, Route 53 record values).
• Give every record that matters an explicit TTL instead of inheriting the zone’s $TTL default. Then a hostname you may need to move is never quietly running on a day-long value (RFC 2308, section 4).
• Plan a cutover in two steps: lower the TTL at least one full old-TTL period before the change, then raise it once the change is confirmed. This is RFC 1034’s own advice (section 3.6). It is also what Akamai tells customers to do: “To shorten this, you could reduce your DNS TTL in advance of the change, and increase it to the normal TTL after the change” (Akamai, Go live).
• Check your DNS provider’s floor before you promise a rollback time. Cloudflare’s minimum is 30 seconds on Enterprise and 60 seconds otherwise, and proxied records are pinned at 300 seconds (Cloudflare, Time to Live (TTL)). Akamai Edge DNS enforces 300 seconds unless a contract variation is negotiated (Akamai, Edge DNS features).
• Treat the TTL as a planning bound, not a guarantee. Keep an application-level failover path for anything that must switch faster than DNS can: resolvers may shorten a TTL (RFC 2181, section 8) and may serve past it (RFC 8767, section 4).
• Set the SOA MINIMUM field deliberately, since the negative TTL is the smaller of it and the SOA’s own TTL (RFC 2308, section 3). Keep it well under a day, inside the one-to-three-hour band that RFC 2308 reports as workable for negative caching. That avoids a stale NXDOMAIN outliving the fix (RFC 2308, section 5).
• Verify after every change with dig against several public resolvers as well as the authoritative server. Read the TTL column: a decrementing value means you are looking at a cached answer, not at your zone (RFC 1034, section 6.2.1).