DNS TTL (time to live)

DNS TTL (time to live) is the number of seconds a recursive resolver may keep a DNS record in its cache before it has to ask the authoritative server again. A low TTL makes changes visible faster at the cost of more queries; a high TTL does the reverse. The number you set is a ceiling, and resolvers, operating systems and applications all treat it as advice.

That last part is what most explanations skip, so this page measures it. Everything below was queried live on 2026-09-08 against the domains' own nameservers, four public resolvers, and the DNS hosts our customers actually use.

Domainee is a custom domains API for SaaS with a native MCP server — 50 domains and 100 GB free.

What the number does

Every record in a zone carries a TTL. When a resolver fetches the record it stores the answer with a countdown, and every client that asks during the countdown gets the cached copy with the remaining seconds, not the original value. We happened to query example.com, which publishes a 300-second TTL, while its operators were moving it between hosting providers, and caught the lag in the act:

$ dig +noall +answer example.com A @a.iana-servers.net
example.com.   300   IN   A   23.192.228.80
example.com.   300   IN   A   23.192.228.84

$ dig +noall +answer example.com A @1.1.1.1
example.com.    92   IN   A   104.20.23.154
example.com.    92   IN   A   172.66.147.243

The authoritative server already publishes the new addresses. Cloudflare's resolver is still handing out the old ones, with 92 seconds left on a countdown that started at 300, and every client behind it gets the old addresses until it hits 0 and the resolver fetches a fresh copy. That is the only moment a change you made can appear. So the TTL is not "how long propagation takes". It is the longest any single cache may lag behind you, and DNS propagation is the sum of every cache between you and a user, each on its own countdown.

What 300, 600, 1800, 3600 and 14400 mean

People search for these five numbers because they are the values registrars pick for you. Converted:

TTL	In plain time	Where you meet it
60	1 minute	The lowest most hosts allow; domainee.dev's own apex publishes 60
300	5 minutes	Cloudflare "Auto", Route 53's suggested value while changing a record
600	10 minutes	Porkbun's default and its floor
1800	30 minutes	Namecheap "Automatic"
3600	1 hour	GoDaddy's default
14400	4 hours	cPanel Zone Editor default, Squarespace Domains default
86400	1 day	Typical for NS and MX records and for many SOA minimums

The practical reading: anything at 300 or below is a record you expect to change, 3600 is a record you expect to be stable for months, and 14400 is a default from an era when zone edits were rare and queries were expensive. There is no correctness problem with any of them. The problem is being on 14400 the day you need to move.

Registrar and DNS host defaults, checked

The default matters more than the ideal, because most people never touch the field. From each provider's own documentation, checked 2026-09-08:

Provider	Default TTL	Lowest allowed	Note
Cloudflare	Auto = 300	60 (30 on Enterprise)	Proxied records are fixed at 300 and cannot be edited; maximum 1 day
GoDaddy	1 hour	not stated	"The default setting is 1 hour" on the add-record page
Namecheap	Automatic = 30 min	not stated	ALIAS records default to 5 minutes
Porkbun	600	600	Floor and default are the same number
Squarespace Domains	4 hours	editable per record	Formerly Google Domains
cPanel Zone Editor	14400	varies by host	The origin of most "why is my change taking four hours" tickets
Route 53	you choose	0	Docs recommend 300 while changing, longer once stable

Sources: Cloudflare TTL reference, GoDaddy, Namecheap, Porkbun, Squarespace, Route 53.

For a SaaS onboarding customer domains this table is the propagation forecast. A customer on Cloudflare or Porkbun will typically verify inside ten minutes. A customer on a cPanel host who has never seen the TTL column can take four hours, and nothing on your side changes that.

Resolvers do not obey the TTL you set

This is the measurement that surprises people. google.com publishes its NS records with a TTL of 345,600 seconds, four days. Asked for the same record at the same moment, four public resolvers returned four different countdowns:

Resolver	TTL returned	What it means
Authoritative (ns1.google.com)	345600	The published value
Google Public DNS 8.8.8.8	3116	Capped, then counting down
Cloudflare 1.1.1.1	339010	Honoured, counting down
Quad9 9.9.9.9	37884	Honoured, counting down
OpenDNS 208.67.222.222	345600	Fresh fetch, full value

Google's cap is documented and exact. Its FAQ says cached TTLs "are generally limited to six hours even if the actual TTL is longer", and querying com. NS (published at 172,800 seconds) through 8.8.8.8 returned precisely 21600 twice in a row. Set a one-day TTL and the largest resolver on the internet quietly treats it as six hours.

Two conclusions, and they pull in opposite directions. First, a long TTL does not buy you as much as you think, because the biggest resolvers cap it. Second, a long TTL still costs you the full amount somewhere, because other resolvers honour it, and the slowest cache is your propagation time. Resolvers may also serve a stale record past its TTL when the authoritative server is unreachable, under RFC 8767, so during an outage a "5-minute" record can live much longer.

The client caches too

The resolver is not the last cache. Browsers keep an internal host cache, operating systems keep one, and some runtimes ignore the TTL entirely. The Java case is the famous one: per the InetAddress documentation, a JVM with a security manager caches successful lookups forever unless networkaddress.cache.ttl is set, and without one it caches for an implementation-dependent period. Failed lookups are cached for 10 seconds by default. A 60-second TTL is meaningless to a process that decided never to ask again, which is why a DNS-based failover often "works everywhere except the Java service".

Node's dns.lookup() goes through the operating system's getaddrinfo and never sees a TTL, so caching is whatever the OS does. If you want DNS failover to work inside your own application, the TTL is not enough; the client has to re-resolve, and you have to check that it does. The DNS cache and DNS flush entries cover clearing each layer.

Negative caching: the TTL of a record that does not exist

A missing record has a TTL too, and it is the one that stalls custom domain onboarding. When a resolver asks for a name and gets NXDOMAIN, RFC 2308 lets it cache that "does not exist" answer for the lower of the zone's SOA minimum field and the SOA record's own TTL. Measured for the DNS hosts customers arrive from:

DNS host (zone measured)	SOA TTL	SOA minimum	Negative cache
Cloudflare (domainee.dev, name.com)	1800	1800	30 min
Route 53 (netflix.com, porkbun.com)	900	1800 / 86400	15 min
GoDaddy (godaddy.com, on Akamai)	3600	3600	1 hour
Namecheap (namecheap.com)	3600	3600	1 hour
Squarespace (squarespace.com)	1800	900	15 min
OVH, IONOS	86400	600	10 min
Google Cloud DNS (google.com)	50	60	50 s
GitHub's zone	900	86400	15 min

Here is the trap. A customer opens your "connect your domain" page, clicks Verify before adding the CNAME, and your server asks its resolver for app.customer.com. The resolver caches the NXDOMAIN. The customer then adds the record correctly, clicks Verify again, and your resolver keeps answering "does not exist" for up to an hour on a GoDaddy or Namecheap zone. The customer did everything right and your UI says "DNS not propagated yet" for an hour. That is not propagation. It is your own resolver remembering the failed first click.

The fix is to verify against the domain's authoritative nameservers directly, which have no cache to be wrong, and to treat the recursive answer as advisory:

$ dig +short NS customer.com
ns1.customer-dns.example.
$ dig +noall +answer app.customer.com CNAME @ns1.customer-dns.example
app.customer.com.   300   IN   CNAME   edge.yoursaas.example.

If the authoritative answer is right and the public resolvers are still stale, the record is live and the caches will catch up. The DNS verification entry covers the same problem for TXT ownership checks, where the negative cache bites just as hard, and the runbook for customer domain issues puts this check in order with the others.

Lowering the TTL before a change

The correct procedure is well known and almost always done too late. The rule: the TTL that governs a change is the TTL that was in place when caches last fetched the record, not the one you set at the same time as the change. Lowering the TTL is itself an edit that propagates on the old value.

With a record currently at 14400 and a move scheduled for Friday:

When	Action	Why
Thursday 09:00	Lower TTL to 300, change nothing else	Caches holding the old 14400 copy will fetch this version by 13:00 at the latest
Thursday 13:00 or later	Safe to change the value	Every cache now holds a 300-second copy
Friday 09:00	Change the value	Worst case for honouring resolvers is 09:05
Friday 09:05 to 15:00	Verify from several resolvers	Google Public DNS may still cap; client caches are separate
Following week	Raise the TTL back	Only once you are sure the new value stays

Skip the first step and you have not saved time, you have moved it: the new value lands on a random schedule spread across the next four hours, which is the worst outcome for debugging.

CNAME chains and who owns the fast record

A CNAME is followed to its target, and each hop has its own TTL, so the effective freshness of the answer is the shortest TTL along the chain. This is why the CNAME model is the right one for custom domains. The customer's record (app.customer.com CNAME edge.yoursaas.example) can sit on any TTL they like, because it almost never changes. The record that does change, the A record for your edge, is in your zone on your TTL. Moving your edge to a new address is a change to a record you control at 60 seconds, and no customer has to touch anything.

Put the customer on an A record at the apex instead and the TTL is theirs, the change is theirs, and the ticket is yours. CNAME flattening and ALIAS records restore the CNAME model at the apex where the host supports it; the apex support guide walks the options. Note that Cloudflare pins proxied records to 300 regardless of what you enter, so a customer proxying their CNAME through Cloudflare is on a five-minute TTL whether they know it or not.

Checking what a resolver actually holds

dig prints the remaining TTL as the second column, so querying a few resolvers tells you which caches have the new record and roughly when the rest will:

$ for r in 8.8.8.8 1.1.1.1 9.9.9.9; do dig +noall +answer app.customer.com @$r; done

The DNS propagation checker runs that loop across resolvers on several continents, the DNS record lookup and CNAME lookup show the authoritative value with its published TTL, and the TXT record lookup does the same for verification records. Add +trace to a dig query to walk from the root to the authoritative server with no cache in the path, which is the quickest way to separate "not propagated" from "not published".

In a multi-tenant SaaS

Four settings cover it. Publish your edge's A and AAAA records at 60 to 300 seconds, because those are the records you will move. Tell customers to create their CNAME with whatever their host's default is, since it does not matter, and to create it before clicking Verify, since that does. Verify against authoritative nameservers with a retry loop rather than against a recursive resolver, and show the customer the authoritative answer so the "propagating" message is honest. And when you provision certificates over DNS-01, remember that the validation server has its own resolver with its own negative cache, so publish the TXT record first and start the challenge second.

FAQ

What is a good TTL for DNS records? 300 seconds for anything you expect to change, including every record that points at infrastructure you might move, and 3600 or above for records that stay put for months, such as MX and NS. The measured defaults at the big DNS hosts run from 300 (Cloudflare) to 14400 (cPanel, Squarespace), and none of them is wrong; the mistake is leaving a record on 14400 the week you need to change it.

What does TTL 3600 mean in DNS? Resolvers may cache the record for 3600 seconds, one hour, before asking the authoritative server again. It is GoDaddy's default and a common choice for stable records. A change to a record with a 3600 TTL can take up to an hour to reach every honouring resolver, plus whatever the client on top of that resolver caches.

What does 14400 TTL mean? Four hours. It is the default cPanel's Zone Editor and Squarespace Domains assign to new records, and the reason many customers report that a DNS change "took all afternoon". Lower it to 300 at least four hours before a planned change, then make the change.

Does lowering the TTL speed up propagation? Only for changes made after the lower TTL has itself propagated. Caches that fetched the record under the old TTL keep it for the old duration, so lower the TTL one full old-TTL period before the change. Lowering it at the same time as the change saves nothing.

What TTL should a CNAME record have for a custom domain? Whatever the customer's host defaults to. The CNAME points at a hostname you control and rarely changes; the record that changes is the A record behind that hostname, in your zone, on your TTL. Keep that one at 60 to 300 seconds. If the customer proxies through Cloudflare, their CNAME is pinned at 300 regardless.

Why did my DNS change take longer than the TTL? Three usual causes. A resolver served a stale answer during an authoritative outage (RFC 8767 allows it). A client cached beyond the TTL, most often a Java process with a security manager, which caches forever by default. Or the resolver had cached a negative answer from a lookup made before the record existed, which lasts for the zone's SOA minimum, up to an hour at GoDaddy and Namecheap.