DNS TTL (time to live)
How many seconds a DNS resolver caches a record before re-querying the authoritative server. Lower TTL means faster changes; higher TTL means less load and faster lookups.
TTL (time to live) is a number on every DNS record that tells caching resolvers "you can cache this answer for X seconds before checking again." It's a trade-off between freshness and load.
What different TTL values mean in practice
| TTL | Use case |
|---|---|
| 30–300 sec | Records that change often. Production failover targets. Custom-domain CNAMEs during onboarding. |
| 600–3600 sec | Most production records. Balance of cache hits + tolerable propagation delay. |
| 7200–86400 sec | Records that almost never change. Mail servers, root zone records. |
| 86400+ | Generally too long. Even root zones often use ~1 hour. |
Why TTL matters for custom domains
When a customer adds a domain to your SaaS, they're going to:
- Add the CNAME.
- Refresh your "verify" button.
- See "DNS not propagated yet."
- Refresh again. And again. And again.
If their DNS provider's default TTL is 3600 or higher, the verification may genuinely take an hour. If you can guide them to a 300-second TTL during setup, the experience is far better.
Some providers default to absurd values. GoDaddy used to default to 1 hour. Cloudflare defaults to "Auto" (300 seconds). Always check.
How TTL is propagated
The TTL is the maximum the resolver should cache. Recursive resolvers can cache for shorter than the TTL (rare) but generally cache for exactly the TTL. The TTL in the answer the resolver returns to its clients is decremented as time passes, so a fresh query with TTL=3600 might return TTL=3200 ten minutes later (if 400 seconds of caching has happened).
This means even after you change a record, clients reading from a stale cache see a smaller and smaller remaining TTL until 0, then re-query.