When an authentic DNS
answer is old.

A service can receive an authentic DNS answer after the domain operator has changed the address. Understanding that possibility requires three separate questions: who signed the data, how long a resolver may reuse it, and whether the application can still use the destination safely.

My 2008 paper, Current Issues in DNS, examined DNS threats, infrastructure configuration and maintenance. Its discussion of browser pinning and rebinding also considered the gap between a record’s advertised lifetime and the behaviour of the software using it. Those historical examples are not measurements of present-day browsers. They motivate a continuing engineering question: what does a time limit actually govern?

Separate authentication from a fresh observation

DNS maps names to records used by other services. A recursive resolver performs lookups for its clients and can retain the answers. Caching reduces repeated work, but the resolver and the authoritative server need not have the same information at every instant.

RFC 4033 describes DNSSEC’s origin-authentication and integrity services. Its sections 4 and 8.1 distinguish those services from availability and distinguish a record’s time to live, or TTL, from its signature’s validity interval. Successful validation does not establish that the authoritative server has published no later replacement.

This matters when a business changes suppliers or withdraws an endpoint. A signature establishes a relationship between data and a trusted key. The operational decision also needs an account of which destination remains suitable and who is responsible for keeping it available during the transition.

Follow one cached answer through a change

Consider an original hypothetical example, not a result from the 2008 study. At 10:00, a resolver receives and validates an address record. The record’s received TTL, the signature record’s received TTL and the signature’s Original TTL field are all 300 seconds. The signature is valid until 10:30. Assume its inception time has passed, the trust chain and other checks succeed, and the resolver’s clock is accurate.

At 10:01, the authoritative server changes the address. At 10:03, a client asks the resolver for the name. If the resolver has retained the original answer without refreshing it, that answer has 120 seconds of its initial cache lifetime left. It can still be returned with successful DNSSEC validation even though it differs from the authoritative server’s current answer.

The calculation follows the upper bound in RFC 4035, section 5.3.3. At validation, the cache TTL must not exceed the smallest of the received record-set TTL, received signature TTL, signed Original TTL and remaining signature lifetime. Here that minimum is 300 seconds; after 180 seconds, 120 remain. A resolver may choose a shorter lifetime. If the same initial response instead had a signature expiring at 10:02, its initial bound would be 120 seconds, despite the 300-second TTL fields.

Lowering the TTL on the authoritative server at 10:01 cannot, by itself, rewrite the countdown already held by this resolver. A planned migration should therefore account for the answers distributed before the change. A claim that a five-minute TTL guarantees every application will switch within five minutes would require additional evidence about application caches, established connections and any exceptional resolver behaviour.

State what happens when refresh fails

RFC 8767, published in 2020, permits recursive resolvers to use stale data when authoritative refresh fails. It describes separate limits on client waiting, query processing, retry frequency and stale retention. This is an availability measure with a freshness cost, not an extension of the cryptographic signature’s validity.

Return to the example. At 10:06, the initial 300-second cache lifetime has ended. Suppose refresh fails and the resolver’s configured serve-stale behaviour permits an old answer. The signature’s 10:30 expiration remains a separate boundary. At 10:31, that signature cannot pass current-time validation merely because the resolver retained the record. RFC 8767 explicitly warns about validation failures from expired signatures and about the security consequences of prolonging old address information. Disabling validation is not a remedy proposed here.

Two customers can reasonably value that trade-off differently. One may prefer an older address that still reaches a working service during an outage. Another may be withdrawing a destination that must no longer receive new requests. The resolver cannot infer the business consequence from the existence of a signature alone. The service design must make its assumptions explicit.

Test the transition, not just the steady state

A useful controlled exercise would start with a signed test zone and an isolated application under the operator’s control. Populate a cache, change the destination, interrupt authoritative refresh and restore it. Repeat with different cache lifetimes, signature-expiry times and stale-data settings. Record the exact resolver and client versions, configuration and clock assumptions.

The measurements should distinguish an answer returned, an answer validated, a connection made to the intended destination and the application work completed. Keep the authoritative change time and every observed answer. Count requests reaching the superseded destination, validation failures, refresh attempts and time to recovery separately. A fast response to the old address and a slow response to the replacement have different operational meanings.

This is a proposed test, not a report of new experiments or a diagnosis of any particular website. The research question is how to make a dependable promise across the whole change. Authentication, cache management, endpoint retirement and application behaviour each contribute evidence. A service owner needs to show how those parts fit together before promising either continuity or prompt withdrawal.