An EDNS(0) Option to Negotiate Leases on DNS Updates
Extracted elements (24)
KEY RRs are given a separate lease duration (KEY-LEASE) because they are used in the DNS-SD Service Registration Protocol (RFC 9665) to reserve a name when the service is not present, requiring a potentially longer lifetime than other RRs.
Refresh timing at 80% of the lease duration (plus a 0–5% random offset) leaves a 15–20% window for retransmission attempts if the initial Refresh Request fails, without requiring overly aggressive retry behavior.
The 3000 ms (3-second) random delay for initial Registration Requests was chosen to spread load meaningfully when many devices renew simultaneously (e.g., after power failure), without causing user-perceptible discovery delays. At 100 devices with even distribution, this yields one renewal every 30 ms.
Older (pre-standard) requesters and servers may support only the 4-byte variant of the Update Lease option. Implementations supporting both variants must account for peers that only support the 4-byte variant. A requester receiving a 4-byte response to an 8-byte request MUST treat it as specifying both lease durations.
A Requester that intends for its RRs to remain active MUST send a Refresh Request before the lease expires. After a successful Lease Update, the requester computes a refresh time at 80% of the lease duration plus a random offset of 0–5% of the lease duration.
A server that receives an 8-byte variant MUST respond with an 8-byte variant. A server that receives a 4-byte variant MUST treat it as specifying both LEASE and KEY-LEASE durations and MUST respond with a 4-byte variant.
Authoritative DNS servers MUST include an Update Lease option in response to any successful DNS Update (RCODE=0) that includes an Update Lease option. Servers MAY return lease durations different from those requested.
DNS Update Requesters MUST send an Update Lease option with any DNS Update that updates RRs not intended to be present indefinitely. The Update Lease option SHOULD specify a lease duration of no shorter than 1800 seconds (30 minutes).
If a lease duration elapses without being refreshed, the authoritative DNS server MUST NOT return that RR in answers to queries. The server MAY delete that RR from its database.
If the DNS Response does not include an Update Lease option, the Requester SHOULD continue sending Refresh Requests as if the server had returned an identical Update Lease option, treating the server as non-supporting.
If the DNS Response includes an Update Lease option, the Requester MUST use the durations returned in that option when determining when to send Refresh Requests, regardless of whether those durations are shorter or longer than requested.
If using UDP, the Requester MUST NOT coalesce Refresh Requests if doing so would cause truncation; in that case, the Requester must either send multiple requests or use TCP.
Lease Update Requests and Responses MUST include the EDNS(0) OPT RR, which MUST include an Update Lease EDNS(0) option.
Requesters SHOULD NOT send a Refresh Request when all RRs in the request would have more than 50% of their lease duration remaining before expiry, though early refresh MAY be performed when needed (e.g., for power-constrained devices).
Upon receiving a valid Refresh Request, the server MUST send an acknowledgment (Lease Update Response) containing the new lease duration. The server MUST NOT increment the zone serial number if the Refresh Request does not change zone contents.
When sending a Registration Request, the Requester MUST delay the initial transmission by a random amount between 0–3000 milliseconds with granularity of no more than 10 milliseconds, to prevent synchronization of multiple devices upon recovery from a power failure.
When sending Refresh Requests, the Requester MUST include an Update Lease option. The Requester MUST use the lease durations returned by the server in the Lease Update Response when determining when to send the next Refresh Request.
The Update Lease EDNS(0) option (OPTION-CODE 2) is included in DNS Update messages within an OPT pseudo-RR. It carries a LEASE field (u_int32_t, 4 bytes) and an optional KEY-LEASE field (u_int32_t, 4 bytes), with OPTION-LENGTH of 4 or 8 respectively.
IANA has updated the 'DNS EDNS0 Option Codes (OPT)' registry to assign value 2 the name 'Update Lease' with status 'Standard', referencing RFC 9664.
Malicious or buggy requesters could renew leases at a high rate to overload the server. Servers should follow established industry best practices against flooding attacks, both over UDP and TCP (SYN flooding).
Servers MUST enforce a minimum lease duration to prevent excessive server load from rapid renewals. A minimum of 30 seconds is RECOMMENDED for both LEASE and KEY-LEASE, though much longer durations (e.g., one hour) SHOULD be used in most cases.
Servers SHOULD enforce an upper bound on LEASE and KEY-LEASE values to prevent effectively-permanent registrations. Default upper limits of 24 hours for LEASE and 7 days for KEY-LEASE are RECOMMENDED.
Some authentication strategy SHOULD be used when accepting DNS updates. Shared secret (TSIG, RFC 8945) or public key signing (SIG(0), RFC 2931) should be required. Keys should have limited authority so that key compromise does not affect entire zones.
The Update Lease option encodes OPTION-CODE as a 16-bit unsigned integer (value 2), OPTION-LENGTH as a 16-bit unsigned integer (4 or 8), LEASE as a 32-bit unsigned integer in network byte order (seconds), and optionally KEY-LEASE as a 32-bit unsigned integer in network byte order (seconds).