DNS TTL and migrations
“You need to move a service to a new IP with no downtime. How do DNS TTLs affect the plan, and what goes wrong if you ignore them?”
What this tests
- That a DNS change is an overlap, not a switch
- Planning around caches you do not control
- Client behaviour beyond the resolver (pinned connections, runtime caches)
Answers by level
Read the beginner answer first and notice what is missing.
There is no "propagation": authoritative servers answer the new value immediately, but every resolver that cached the old value keeps serving it until its copy’s TTL expires. So the plan is about overlap: days before the move, lower the TTL from its usual value (say 3600 s or 86400 s) to 60 s — and wait at least one *old* TTL so that every cache has picked up the short TTL. Then make the change; within about a minute nearly every resolver refreshes. Then raise the TTL again to reduce load on the authoritative servers.
Both endpoints must serve traffic throughout the overlap: the old IP for clients with stale caches, the new one for refreshed clients. That means the old host stays up (or proxies to the new one) for at least one full old TTL after the change, and both accept the same TLS certificate and the same data — a database that lives in one place, or a replication plan. Only then decommission.
Ignore this and you get a partial outage that is invisible from your desk: half the customers hit a dead IP and see timeouts, your resolver already refreshed so "it works for me", and it self-heals hours later for no visible reason. The fix at that point is to bring the old address back, not to "flush caches" — you cannot flush the resolvers of the internet.
Green flags · Red flags
- Says "lower the TTL one old-TTL ahead of time" and explains why the wait is needed
- Keeps both endpoints serving through the overlap
- Knows the failure is partial and self-healing, and looks fine from a refreshed vantage point
- Mentions client-side caching and pooled connections that outlive DNS
- Prefers a stable address in DNS with backends moving behind it
- Talks about "propagation taking 48 hours" as a fact of nature
- Plans to switch the record and shut the old server down at once
- Suggests flushing caches as a remedy for other people’s resolvers
- Unaware that connection pools pin to an IP