Lower the TTL on the records you will change well before the cutover, wait at least one old TTL for caches to drain, make the change, then raise the TTL again. TTL is a ceiling on how long a cache may keep a record, not a guarantee about how fast everyone sees your change.
What TTL actually means
RFC 1034 defines the TTL as the maximum time a resource record may stay in a cache. A TTL of zero prohibits caching. It does not govern the authoritative data in your zone, which is refreshed under the zone's own policy. The RFC also notes that typical values run to days and that an administrator can lower the TTL before a planned change.
That last point is the whole technique. The catch is that the old, long TTL is already sitting in caches. Lowering it today does nothing for a resolver that cached the record yesterday with a 24 hour TTL until that copy expires.
A cutover plan
- Inventory the records. List every name that will change: A, AAAA, CNAME, MX, TXT for mail authentication, and any NS or DS records if you are changing DNS hosts.
- Note the current TTLs. The longest one sets how far ahead you must start.
- Lower the TTLs. Pick a value such as a few minutes for records you will flip. Lower only what you need to.
- Wait one full old TTL. After that, every compliant cache holds the short TTL.
- Make the change. Keep the old target running, because a few clients will still reach it for a while.
- Verify from several resolvers. Query your authoritative servers directly first, then a couple of public resolvers.
- Raise the TTL again. Short TTLs mean more queries to your authoritative servers and more exposure if they have an outage.
Things TTL will not fix
- Negative answers. If a name did not exist when someone looked it up, that answer is cached too. See negative caching and NXDOMAIN delays.
- Resolvers that ignore or cap TTLs. Some caches clamp very low or very high values. Treat your TTL as a request, and plan for stragglers.
- Application caches. Many runtimes and HTTP clients keep their own address cache or hold connections open. A long lived connection never asks DNS again.
- DS and NS changes. Changing name servers or DNSSEC delegation data involves the parent zone, which has its own TTLs. Do this slowly and read how to configure DNSSEC first.
The security angle
Short TTLs help you recover quickly from a bad change, and they help you move off a compromised host. They also make a record change by an attacker take effect fast. Pair a short TTL window with change control on your registrar and DNS provider accounts, and remove records you no longer use so they cannot be taken over.
Where Safeguard fits
Safeguard does not manage this layer of your infrastructure. It scans the dependencies and SBOMs of the software you ship, uses reachability analysis to show which vulnerable code paths are actually used, and can enforce policies and gates in CI. A free scan is at gold.safeguard.sh/scan.
Quick check
How long should I wait after lowering a TTL?
At least as long as the old TTL, so that caches holding the previous long value have expired.
Does a TTL of zero mean the record never changes?
No. It means the record must not be cached, so every lookup goes back to the source.
Sources
Last reviewed: 19 October 2026.
