DNS TTL

A resolver that receives an answer stores it for at most the TTL and serves it from cache to every client that asks in the meantime. During that window your authoritative server is never consulted.

The countdown starts when the resolver caches the answer, not when you publish it. Different resolvers around the world are therefore at different points in the window at any moment.

A short TTL means faster change and more queries against your nameservers. A long TTL means the opposite. Neither is universally right.

Caching also provides resilience: with a long TTL, an outage at your nameservers is invisible to anyone whose resolver holds a valid answer.

Records that never change — a verification string, a long-standing MX set — are comfortable at hours or a day.

Records behind a service that fails over — an address record in front of a load balancer — are usually set to minutes, so a failover is seen quickly.

Very low values, under thirty seconds, buy little: many resolvers enforce their own minimum, and the query volume rises sharply.

The negative answer TTL, which governs how long a 'this name does not exist' answer is cached, is set separately in the SOA record and is easy to forget when a new subdomain does not appear.

The sequence that works: reduce the TTL to a few minutes, wait for at least the old TTL to elapse so every cached copy has expired, then make the change.

Done that way, the switch is visible within the new short TTL rather than within the old long one.

Done in the other order — change first, lower the TTL afterwards — the old long TTL still governs the copies already cached, and the lowering has no effect on them.

Restore the normal TTL once the change has settled, so you are not paying for query volume you do not need.

Some resolvers impose a minimum, refusing to re-query more often than their own floor regardless of what you published.

Some impose a maximum, capping very long TTLs so that a stale record cannot persist indefinitely.

Operating systems and browsers maintain their own caches in front of the resolver, with their own policies. A browser that has pinned a connection may not re-resolve at all.

So the TTL is a strong hint that most of the internet follows most of the time, and a migration plan should expect a tail of clients that lag behind.