Why a short DNS TTL cannot guarantee a clean server cutover

Tech · DNS and server migrations

The countdown does not certify freshness

Before switching off an old server, find out which answer your users are receiving.

1. A short reply can contain old dataIts TTL is not a timestamp showing when the address was obtained.
2. Resolver policy changes the outcomeExpired records can provide a fallback when refreshing fails, if that behavior is enabled.
3. Observe both ends of the moveA successful check of the new server does not establish that the old one is unused.

A migration team changes a website’s address, watches the DNS countdown reach zero and prepares to switch off the old machine. The new site works from the office. Then someone elsewhere still reaches the previous server. “Propagation” is an easy explanation, but it hides the question that would make the incident diagnosable: which component supplied that address, and why?

One documented possibility is serve-stale. RFC 8767 permits a recursive resolver to reuse expired DNS data when it cannot refresh it authoritatively. The mechanism trades freshness for availability during a resolution problem. A low TTL therefore cannot, by itself, certify a clean endpoint cutover.

Two resolvers can see the same migration differently

This is a synthetic example, not a measured outage. It applies the cache-and-refresh distinction in ISC’s explanation of serve-stale. Imagine a simple hostname moving from server A to server B. There is one address record, no alias chain and no application connection reuse in the example.

1. Before the move. Resolver One has cached A. Resolver Two will query later. The migration team publishes B at the authoritative service.
2. After the cached record expires. Resolver One cannot obtain a fresh authoritative answer. Assume it retains the expired A record and is configured to use stale fallback.
3. At the next lookup. Resolver One can return A. Resolver Two successfully obtains B. Two users can therefore reach different endpoints even though the team’s own lookup looks correct.

The point is not to predict how long that disagreement lasts. It is to replace a vague claim that “DNS has updated” with an observation tied to a particular resolver and time. The example’s outcome changes if the first resolver refreshes successfully, has no retained record or does not serve stale answers.

Thirty seconds on the reply is a different measurement

RFC 8767 requires a positive TTL on expired records returned this way and recommends 30 seconds. Its maximum stale-retention timer is separate. Do not read a 30-second reply as evidence that the record was fetched 30 seconds ago, or that every resolver must discard its retained copy after another half-minute.

The BIND 9.20.20 reference makes the distinction concrete. stale-answer-ttl controls the returned TTL; max-stale-ttl limits retention beyond normal expiry. Its documented defaults are 30 seconds and one day respectively, but stale retention and stale answering must also be enabled. These are implementation settings, not a universal Internet waiting period.

• Original record TTL. The ordinary refresh boundary for the cached DNS record.
• Stale-retention limit. How long the resolver keeps an expired record available for fallback.
• Returned stale TTL. The reuse interval communicated with a particular fallback reply.

This is why changing one number in a DNS control panel cannot describe the whole migration. The authoritative operator publishes records; recursive operators control their own fallback behavior. They are different decision-makers.

Configuration can matter as much as the resolver’s name

BIND also separates retaining expired records from returning them. The same reference documents runtime overrides and a serve-stale log category. Seeing a package name in an infrastructure inventory does not establish its effective policy.

Unbound’s documentation describes both an immediate expired-cache response mode and a mode that first gives resolution time to succeed. Since version 1.23.0, its default mode for serve-expired follows the latter approach; the illustrated client timeout is 1,800 milliseconds. After a stale reply, resolution can continue and update the cache. This is not a claim that every Unbound installation enables the feature.

A useful support question is consequently more specific than “do you cache DNS?” Ask whether expired answers are retained and served, which mode is active, and what evidence exists for the affected name. Version and effective configuration belong beside the result.

Look for an explicit stale-answer explanation

RFC 8914 defines Extended DNS Error code 3, Stale Answer, for a resolver that used cached data after failing to resolve within its time limits. EDE adds diagnostic information without replacing the ordinary DNS response code. It is optional: missing EDE is not proof of a fresh answer.

Cloudflare’s 1.1.1.1 troubleshooting guide lists that code and shows how EDE appears in the OPT PSEUDOSECTION of a full dig response when supplied. Saving only the IP address discards precisely the context that may explain it. Keep the complete output, resolver address, queried name, record type and timestamp.

An EDE label describes that reply. It does not prove every resolver has the same problem, identify the original fetch time or establish that the destination server is healthy. Conversely, an old-looking IP without the label needs investigation, not an automatic serve-stale diagnosis.

Build the handoff from evidence before changing anything

1. Record the intended change. Name the hostname, record type, previous destination, new destination and publication time. Distinguish moving a website from moving the authoritative DNS service.
2. Compare like with like. Ask the affected recursive resolver and the authoritative servers about the same name and type. Preserve the full responses. Differences between authoritative servers themselves require attention before blaming a recursive cache.
3. Keep the path attached to the result. A working authoritative query from your laptop does not prove the affected resolver could reach that authority. If you operate the resolver, correlate its logs; otherwise provide the provider with the timestamped evidence.
4. Observe the endpoints separately. Check whether legitimate requests still reach the previous server and whether the new endpoint serves the intended application. Choose a retirement plan from that evidence and your operational requirements, not from one successful lookup.

Ordinary cached TTLs still matter. Amazon’s Route 53 migration procedure separates lowering NS TTLs, waiting for previously cached values to expire, changing nameservers and monitoring traffic. That procedure concerns a DNS-provider migration; its timings should not be copied wholesale into an A-record endpoint move. Lowering a value now does not retroactively change the copy a resolver already holds.

This response-by-response approach also matters when DNS supplies an ECH configuration before TLS or when diagnosing a failed robots.txt request separately from the page itself. Identify the observation before interpreting it.

Questions about stale DNS during a migration

Standards and implementation sources

Seven primary sources checked 8 September 2026

• RFC8767
• BIND9.20.20
• Unbound serving stale data
• RFC8914
• Cloudflare EDE documentation
• Amazon Route 53 — migrating an in-use domain
• ISC — Serve-Stale Update, November 2020

Documentation analysis with a synthetic migration example. No live resolver was disrupted, and no DNS setting was changed for this article.