Summary

  • RFC 9664 lets a requester ask for a DNS publication lifetime, but the authoritative server's returned LEASE and KEY-LEASE values—not the request—govern refresh and expiry.
  • A lease limits stale authoritative publication; it does not prove endpoint health, fleet convergence or immediate cache disappearance, so evidence must follow separate clocks through the update, server, authoritative fleet, caches and service.

Imagine an otherwise ordinary registration. A device asks an authoritative DNS server to retain its service records for thirty minutes. The update is authenticated. Its RFC 2136 prerequisites pass. The server returns NOERROR and an Update Lease option granting four hours, which RFC 9664 permits. Twenty minutes later, the endpoint loses power. It sends neither an explicit deletion nor a refresh.

The DNS record can remain a correct authoritative answer for the rest of the granted lease even though the application is gone.

This is an illustrative case, not a reported outage and not a claim about any product's defaults. It exposes the most important fact in the protocol: the request contains a desired duration; the successful response contains the actual duration. A server may grant less time, the same time or more time. The requester must schedule from what came back.

The lease solves a real failure. Dynamic DNS records for mobile or transient systems can become permanent debris when the requester leaves abruptly and never sends a deletion. Expiry turns that indefinite residue into bounded residue. But a bound is not the same thing as liveness, and a valid time promise is not a health check.

One successful exchange carries three different decisions

RFC 9664 does not replace DNS UPDATE. It places an EDNS(0) option in the OPT pseudo-record of an ordinary RFC 2136 request. The underlying update still has a Zone section, optional Prerequisites, the records to add or remove, and Additional Data. RFC 2136 evaluates the prerequisites against the current zone and processes the update atomically: all prerequisites succeed and the update is admitted, or it is rejected.

That admission answers only the first question: may this principal make this change to this zone state?

The Update Lease response answers a second question: for how long will the server continue to publish the accepted records if it receives no renewal?

The network must answer a third question independently: is the service behind those records actually reachable and functioning?

Collapsing the three creates false confidence. TSIG or SIG(0) can authenticate the request and protect its integrity. An update policy can limit the principal to particular names and record types. Neither mechanism inspects the application process, the listening socket, the route to the endpoint or the transaction a user expects to complete. A signed registration for a dead service remains a signed registration for a dead service.

The evidence therefore starts with the bytes. It should retain the exact Zone, Prerequisite, Update and Additional Data sections; the TSIG key name or SIG(0) identity; the policy verdict; the EDNS option length; the desired durations; the response code; and the exact values returned by the server. “Lease accepted” is too lossy. It hides which authority acted and which time it granted.

Four bytes, eight bytes and a name that may outlive the service

The Update Lease option has two forms. The four-byte form carries one unsigned 32-bit LEASE value. That value applies to every record in the Update section, including KEY records. The eight-byte form adds a separate KEY-LEASE: ordinary records use LEASE, while KEY records use the other duration.

The distinction matters in the Service Registration Protocol defined by RFC 9665. SRP can let service records expire while a KEY record continues reserving a name for the same cryptographic claimant. The service disappears from discovery, but another requester cannot immediately take the name. The longer-lived KEY is a custody mechanism for identity continuity, not evidence that the service remains present.

Compatibility can erase the distinction. A server receiving a four-byte request must treat its value as both durations and return four bytes. A requester that sent eight bytes but receives four must also apply the single returned value to both. An operator who expected a short service lease and a longer name reservation must examine the actual response format. Configuration intent is not wire evidence.

Explicit deletions follow another rule: records removed by a Lease Update Request are permanently removed. The lease is not a grace period that resurrects deliberately deleted records at some later deadline.

The response starts the clock that matters

A supporting authoritative server must return an Update Lease option in every successful response to a request that included one. Its returned value is the grant. The requester uses it even if it is inconveniently shorter or surprisingly longer than requested.

If the response contains no option, RFC 9664 treats that absence as an indication that the server does not support Update Lease. For compatibility, the requester should continue sending refreshes as though the requested option had been returned. That behavior keeps the requester from giving up immediately. It does not transform a non-supporting server into one that will garbage-collect the records. The operational verdict must be “refresh compatibility active, server-side expiry unproven,” not “leased registration confirmed.”

For a granted lease, the normal refresh timer is 80 percent of the duration plus a random offset between zero and five percent. The jitter avoids a fleet of devices renewing in lockstep. It also creates a useful recovery margin: when the first refresh is due, roughly 15 to 20 percent of the lease remains for retransmissions.

That computation is merely a deadline. Proof requires the selected random offset, the next-refresh timestamp, send attempts, authenticated response and new granted duration. A scheduler log saying “refresh queued” cannot establish that the authoritative server extended anything.

RFC 9664 also distinguishes a Registration from a Refresh. A Registration adds information not thought to be present. A Refresh renews an existing Registration without changing it. If the authoritative server lost state during a reboot, a correctly constructed Refresh can add the records again. From the server's perspective it has become a content-changing registration, and the zone serial must reflect the change. If contents do not change, the refresh must not increment the serial.

The same message can therefore have different operational effects depending on server state. Evidence needs the before-state, not just the request label.

Expired at authority, alive in cache

When a lease elapses without renewal, the server must stop returning the affected record. It may delete the stored bytes, but physical deletion is optional. Query suppression and database cleanup are not synonyms.

Even that authoritative stop does not erase the record everywhere. An RR's TTL gives recursive resolvers and other caches a separate reuse horizon. A resolver that fetched the record shortly before authoritative expiry may continue answering from cache until the remaining TTL reaches zero. A low TTL can shorten that tail; it cannot make the authoritative lease expire. A short lease can stop new authoritative answers; it cannot recall an answer already cached.

This creates at least four clocks that an incident record should never merge:

  1. the server-granted lease deadline;
  2. the requester's scheduled refresh and retries;
  3. the zone/signing/secondary distribution interval after an expiry changes visible contents; and
  4. each observer's remaining TTL, followed by direct application behavior.

A registrar may also be a hidden primary rather than the server answering public queries. Its lease table can be correct while a signer, journal, secondary or anycast site is behind. The proof path must include direct authoritative queries to each material serving cohort, not only the registrar's successful response.

Bounds are policy, not entitlement

RFC 9664 warns about both extremes. An excessively long lease is little better than no lease because stale records effectively persist. An excessively short lease increases refresh traffic and makes a delayed renewal more likely to remove valid records prematurely. The document recommends default server maxima of 24 hours for ordinary records and seven days for KEY records, while allowing operators to change them. It requires a default minimum and recommends at least 30 seconds, while saying much longer durations such as an hour should usually be used.

Those numbers are not a universal service-level objective. A registrar serving sleepy devices, rapidly moving endpoints or critical discovery records can face different recovery and capacity constraints. The durable rule is that the server owns a declared, observable duration policy and the requester treats the grant as evidence, not as an echo.

The key policy needs the same discipline. RFC 9664 recommends authentication and narrowly limited keys. A compromised credential that can rewrite an entire zone remains dangerous even if every inserted record eventually expires. Leases bound residue; they do not repair excessive authority.

Sources