DNS TTL explained, and when to use a 1-second TTL

TTL is how long resolvers may reuse an answer. When to lower it, why some resolvers clamp it, and how Cloud DNS supports a 1-second minimum.

TTL is a promise to recursive resolvers: you may remember this answer for this long. A 24-hour TTL on a record you might move is a 24-hour outage you pre-authorised.

Not every record wants a low TTL

MX, SPF and stable documentation hostnames can stay high. Application apex, CDN hostnames and failover targets should be low enough to match your RTO. Cloud DNS supports a one-second minimum.

Lower it before the window

Drop TTLs days before a migration, not during it. Otherwise the old high TTL is still in the wild while you are changing records.

Clamping is real

Some resolvers refuse to honour very low TTLs. Health-aware answers still help: even a clamped cache is less likely to point at a dead target if you stopped publishing it.

Query volume is the cost

Low TTL means more queries. That is why Anycast authority exists. A registrar DNS product that discourages low TTLs is often protecting its own capacity, not your RTO.

Frequently Asked Questions

No. Use low TTLs where you need change. Leave stable records longer.

Yes, with signature lifetimes planned so validation and low TTLs remain compatible.

Lookups happen more often. Anycast Cloud DNS is built for that. The application handshake is still the larger cost.

Run this on Cloud DNS.

Get started with our Management Console in less than 2 minutes, or connect with an expert to supercharge your business today.