An EDNS(0) Option to Negotiate Leases on DNS Updates
RFC 9664
Stuart Cheshire
Apple Inc.
Ted Lemon
Apple Inc.
2025-06
INT
dnssd
DNS Update
This document describes an EDNS(0) option that can be used between DNS Update Requesters and authoritative DNS servers to include a lifetime (lease duration) in a DNS Update or DNS Update Response, allowing a server to garbage collect stale Resource Records that have been added by DNS Updates if they are not renewed.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9664.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
- 1. Introduction
- 2. Conventions and Terminology Used in This Document
  - 2.1. Terminology
- 3. Mechanisms
- 4. Lease Update Request and Response Format
  - 4.1. Types of Lease Update Requests
  - 4.2. Requester Behavior
  - 4.3. Server Behavior
- 5. Refresh Requests
  - 5.1. Refresh Request Format
  - 5.2. Requester Behavior
    - 5.2.1. Coalescing Refresh Requests
  - 5.3. Server Behavior
- 6. Retransmission Strategy
- 7. Garbage Collection
- 8. Security Considerations
- 9. IANA Considerations
- 10. References
  - 10.1. Normative References
  - 10.2. Informative References
- Acknowledgments
- Authors' Addresses
Introduction
Dynamic Update in the Domain Name System (DNS Update) [RFC2136] allows for a mapping from a persistent hostname to an IP address that changes over time. This capability is particularly beneficial to mobile hosts, whose IP addresses may frequently change with location. However, the mobile nature of such hosts often means that Resource Records (RRs) added using DNS Update are not properly deleted. For instance, consider a mobile user who publishes address RRs via DNS Update. If this user moves their laptop out of range of the Wi-Fi access point, the address RR containing stale information may remain on the authoritative DNS server indefinitely. Thus, an extension to DNS Update is required to tell the server to automatically delete RRs after a period of time if they are not refreshed.
Conventions and Terminology Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Terminology
DNS-SD:
DNS-based Service Discovery [RFC6763]
EDNS(0):
Extension Mechanisms for DNS [RFC6891]
Update Lease option:
Update Lease EDNS(0) option
Lease:
An agreement by an authoritative DNS server to continue to publish a record from the time of registration until the lease duration has elapsed and then stop publishing it
Lease Duration:
The time between the start and end of a lease
Lease Update Request:
DNS Update Request containing an Update Lease option
Lease Update Response:
DNS Update Response containing an Update Lease option
RR:
Resource Record
Registration Request:
A Lease Update Request that is constructed with the purpose of adding new information that is not thought to already be present on the authoritative DNS server
Registration:
The result of a successful Registration Request
Refresh Request:
A Lease Update Request that extends the lease duration on an existing Registration
Refresh:
The result of a successful Refresh Request
Mechanisms
The Update Lease option is included in a standard DNS Update Request [RFC2136] within an EDNS(0) OPT pseudo-RR [RFC6891].
Lease Update Request and Response Format
Lease Update Requests and Responses are formatted as standard DNS Update messages [RFC2136]. Such messages MUST include the EDNS(0) OPT RR [RFC6891]. This OPT RR MUST include an Update Lease EDNS(0) Option as shown below:
Field Name | Field Type | Description
OPTION-CODE | u_int16_t | UPDATE-LEASE (2)
OPTION-LENGTH | u_int16_t | 4 (LEASE) or 8 (LEASE + KEY-LEASE)
LEASE | u_int32_t | desired lease duration (Lease Update Request) or granted lease duration (Lease Update response), in seconds
KEY-LEASE | u_int32_t | optional desired (or granted) lease duration for KEY RRs, in seconds
Lease Update Requests contain, in the LEASE field of the OPT RDATA, an unsigned 32-bit integer indicating the lease duration in seconds, desired by the Requester, represented in network (big-endian) byte order. In Lease Update Responses, this field contains the actual lease duration granted by the authoritative DNS server. The lease durations granted by the server may be less than, greater than, or equal to the value requested by the Requester.
There are two variants of the Update Lease option: The 4-byte variant and the 8-byte variant.
In the 4-byte variant, the LEASE indicated in the Update Lease option applies to all RRs in the Update section.
In the 8-byte variant, the Update Lease communicates two lease durations. The LEASE indicated in the Update Lease option applies to all RRs in the Update section except for KEY RRs. The KEY-LEASE indicated in the Update Lease option applies to KEY RRs in the Update section.
More information about how the two variants are used is given in Section 4.3.
KEY RRs are given a special lease duration because these RRs are used in the DNS-SD Service Registration Protocol [RFC9665] to reserve a name (or names) when the service is not present.
In the case of a KEY RR and some other RR, obviously the KEY lease duration applies to the KEY RR, and the lease duration applies to the other RR. If more than one RR that is not a KEY RR is added by the Lease Update Request, the lease duration (not the KEY lease duration) is applied to all such RRs. RRs that are removed are permanently removed.
Types of Lease Update Requests
This document describes two types of Lease Update Requests: Registrations and Refreshes. A Registration Request is a Lease Update Request that is intended to add information not already present on the authoritative DNS server. A Refresh Request is intended simply to renew the lease on a previous Registration without changing anything. Registrations and Refreshes are both Lease Update Requests, so the term "Lease Update Request" is used to specify behavior that is the same for both types of DNS Updates.
In some cases, it may be necessary to add new information without removing old information. For the purpose of this document, such Lease Update Requests are Registrations, although in effect, they may also refresh whatever information is unchanged from a previous registration.
Requester Behavior
DNS Update Requesters MUST send an Update Lease option with any DNS Update that updates RRs that are not intended to be present indefinitely. The Update Lease option SHOULD specify a lease duration that is no shorter than 1800 seconds (30 minutes). Requesters MAY specify a shorter lease duration if they anticipate that the RRs being updated will change more frequently than every 30 minutes. Requesters that expect the updated RRs to be relatively static SHOULD request appropriately longer lease durations.
If the DNS Response received by the Requester does not include an Update Lease option, this is an indication that the authoritative DNS server does not support the Update Lease option. In this case, the Requester SHOULD continue sending Refresh Requests (see below) as if the server had returned an identical Update Lease option in its Response.
If the DNS Response does include an Update Lease option, the Requester MUST use the durations returned in this option when determining when to send Refresh Requests. This is true both if the durations returned by the server are shorter and if they are longer.
When sending a Registration Request, the Requester MUST delay the initial transmission by a random amount of time across the range of 0-3000 milliseconds, with a granularity of no more than 10 milliseconds. This prevents synchronization of multiple devices of the same type at a site upon recovery from a power failure. This requirement applies only to the initial Registration Request on startup; since Refresh Requests include a random factor as well, any synchronization that occurs after such an event should quickly randomize.
The 10 ms granularity is a scheduling requirement intended to result in an even spread of Requests so that every Request doesn't come an exact number of seconds after startup. This requirement should not be construed as requiring anything of the link layer on which the packet is transmitted: the link layer may well impose its own constraints on the timing at which a message is sent, and this document does not claim to override such constraints.
The use of a 3000 ms (3-second) random delay as opposed to some other random delay is to allow for enough time to meaningfully spread the load when many devices renew at once, without delaying so long that the delay in discovery of devices becomes obvious to an end user. A 3-second random delay means that if there are, for example, 100 devices, and the random number generator spread is even, we would have one renewal every 30 ms. In practice, on relatively constrained devices acting as Service Registration Protocol (SRP) servers, we are seeing the processing time for an SRP registration taking on the order of 7 ms, so this seems reasonable.
Server Behavior
Authoritative DNS servers implementing the Update Lease option 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 specified by the Requester, granting longer leases to reduce network traffic due to Refreshes or shorter leases to reduce the lifetime of stale data.
Although both the 4-byte and 8-byte variants are valid on both requesters and servers, older (pre-standard) requesters and servers may exist that support only the 4-byte variant. Therefore, requesters and servers that (as required by this specification) support both variants must account for the possibility that the peer with which they are communicating may be an older implementation that supports only the 4-byte variant.
A server that receives an 8-byte variant from a requester MUST respond with an 8-byte variant giving the granted lease times.
A server that receives a 4-byte variant from a requester MUST treat the 4-byte variant as specifying both the lease duration and the KEY lease duration and MUST respond with a 4-byte variant. In this case, the key and the other RRs expire at the same time.
A requester that receives a 4-byte variant from a server when it sent an 8-byte variant in its request MUST treat the 4-byte variant as specifying both the lease duration and the KEY lease duration.
Refresh Requests
A Refresh Request is a DNS Update Request that is sent to the server after an initial DNS Update has been sent in order to prevent the update's RRs from being garbage collected.
Refresh Request Format
Refresh Requests and their corresponding responses are formatted like Update Lease Requests and Update Lease Responses (see Section 4). The Refresh Request is constructed with the assumption that the previous Registration or Refresh is still in effect. In the case that the RRs added in a previous update were for some reason garbage collected (e.g., because of a server reboot that resulted in loss of state), the Refresh Request will result in those RRs being added again.
The Refresh Request SHOULD NOT include any DNS Update prerequisites that will fail if the Requester's previous Registration or Refresh is still in effect. It also SHOULD NOT include prerequisites that would fail if the RRs affected by the previous Registration or Refresh are no longer present; that is, the Refresh Request should also work as a Registration Request. There may be cases where this is not possible; in which case, the response from the server can be used to determine how to proceed when the Refresh Request fails.
A Lease Update Request that changes the authoritative DNS server state resulting from a previous Refresh or Registration is a Registration Request, not a Refresh Request.
In a Refresh Request, the Update Lease option contains the desired new lease duration, and in the corresponding response, the Update Lease option contains the actual granted lease. The lease duration provided in LEASE in the Update Lease option applies to all RRs in the Update section of the Refresh Request, except that when the 8-byte Update Lease variant is sent, the duration specified in KEY-LEASE applies to any KEY RRs included in the Update section.
Requester Behavior
A Requester that intends for its RRs from a previous Registration or Refresh to remain active MUST send a Refresh Request before the lease expires; otherwise, the RRs will be removed by the server.
In order to prevent Registrations expiring, Requesters MUST refresh them. When a Lease Update Request succeeds, the requester computes a time limit that is 80% of the lease duration plus a random offset between 0% and 5% of the lease duration. The random offset is to prevent refreshes from being synchronized. When this time limit has expired, the requester MUST send a Refresh Request if the data in the initial Registration should continue to be advertised.
For Refresh Requests, the server is expected to return an Update Lease option, if supported, just as with the initial Registration Request. As with the Registration Request, the Requester MUST use the durations returned by the server in the Lease Update Response when determining when to send the next Refresh Request.
When sending Refresh Requests, the Requester MUST include an Update Lease option, as it did in the initial Registration Request. The Update Lease option MAY either specify the same durations as in the initial Registration Request or use the values returned by the server in the previous Lease Update Response or other desired values as appropriate. As with responses to Registration Requests, the Requester MUST use the lease durations returned by the server in the response when determining when to send the next Refresh Request.
If the Requester sends a Refresh Request message and does not receive a response from the authoritative DNS server, then the Requester should implement a reasonable retry strategy to attempt to refresh the record registrations before they expire. Given that 15% - 20% of the lease lifetime still remains, these retransmissions do not need to be overly aggressive. For example, the Requester could retry nine more times, spaced uniformly at equal intervals from the time of the first failed Refresh attempt until the expiration time of the records. After the expiration time of the records, the Refresh Request effectively turns into a new Registration Request, and further retransmissions after this proceed as described in Section 6.
Coalescing Refresh Requests
If the Requester has performed multiple Registrations with a single server for different RRs, the Requester MAY send a Refresh Request containing RRs from all such Registrations to that server in a single Refresh Request. This effectively places all RRs for a Requester on the same expiration schedule, reducing network traffic due to Refreshes.
In doing so, the Requester includes in the Refresh Request all existing RRs previously successfully registered on the server, including those not yet close to expiration, so long as at least one RR updated in the Refresh Request has elapsed at least 75% of its original lease duration. If the Requester uses UDP, the Requester MUST NOT coalesce Refresh Requests if doing so would cause truncation of the Request; in this case, the Requester either sends multiple Requests or uses TCP to send the complete Refresh Request at once.
Requesters SHOULD NOT send a Refresh Request when all of the RRs in the Refresh Request would have more than 50% of their lease duration remaining before expiry. However, there may be cases where the Requester needs to send an early Refresh Request, and it MAY do so. For example, a power-constrained (sleepy) device may need to send a Refresh Request when the radio is powered so as to avoid having to power it up later.
Another case where this may be needed is when the lease duration registered with the server is no longer appropriate and the Requester wishes to negotiate a different lease duration. However, in this case, if the server does not honor the requested lease duration in its response, the Requester MUST NOT retry this negotiation.
Server Behavior
Upon receiving a valid Refresh Request, the server MUST send an acknowledgment. This acknowledgment is a Lease Update Response as described in Section 4 and contains the new lease duration of the Registration being Refreshed. The server MUST NOT increment the serial number of a zone as the result of a Refresh Request if the operation does not result in any change to the zone contents.
However, the server's state may not match what the requester expects. In this case, a Refresh Request may actually appear to be a Registration Request, from the server's perspective. If the Refresh Request changes the contents of the zone, the server MUST update the zone serial number.
Retransmission Strategy
The DNS protocol, including DNS updates, can operate over UDP or TCP. For communication using UDP, reliable transmission must be guaranteed by retransmitting when a DNS UDP message is not acknowledged in a reasonable amount of time. Section 4.2.1 of the DNS specification [RFC1035] provides some guidance on this topic, as does Section 1 of the IETF's guide to common DNS implementation errors [RFC1536]. Section 3.1.3 of the UDP Usage Guidelines [RFC8085] also provides useful guidance that is particularly relevant to DNS.
Garbage Collection
If the lease duration of an RR 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. The lease durations returned by the server to the Requester are used in determining when the lease on an RR has expired.
For all RRs other than a KEY RR included in a Lease Update Request, the lease duration is the LEASE value in the Update Lease option. For KEY RRs, if the optional KEY-LEASE value was included, this duration is used rather than the duration specified in the LEASE. If the KEY-LEASE was not specified, the duration specified in the LEASE is used for all RRs in the Lease Update Request.
Security Considerations
Section 8 of the DNS Update specification [RFC2136] describes problems that can occur around DNS updates. Servers implementing this specification should follow these recommendations.
Several additional issues can arise when relying on the Update Lease option.
First, a too-long lease duration is not much different from no lease duration: the RRs associated with such a Registration will effectively never be cleaned up. Servers implementing Update Lease should have a default upper bound on the maximum acceptable value both for the LEASE and KEY-LEASE values sent by the requester. Default values for these limits of 24 hours and 7 days, respectively, are RECOMMENDED. Servers MAY provide a way for the operator to change this upper limit.
The second issue is that a too-short lease can result in increased server load as Requesters rapidly renew such Registrations. A delay in renewing could result in the registered RRs being removed prematurely. Servers implementing Update Lease MUST have a default minimum lease duration that avoids this issue. A minimum of 30 seconds for both the LEASE and KEY-LEASE durations is RECOMMENDED. However, in most cases, much longer lease durations (for example, an hour) SHOULD be used. Servers MAY provide a way for the operator to change this lower limit.
There may be some cost associated with renewing leases. A malicious (or buggy) requester could renew at a high rate in order to overload the server more than it would be overloaded by query traffic. This risk is present for an authoritative server handling normal (no-lease) DNS Updates as well. Servers should follow established industry best practices to guard against flooding attacks, both for malicious flooding of DNS messages over UDP and for similar flooding attacks using TCP [SYN] [RFC4953].
Some authentication strategy should be used when accepting DNS updates. Shared secret [RFC8945] or public key signing (e.g., SIG(0) [RFC2931]) should be required. Keys should have limited authority: compromise of a key should not result in compromise of the entire contents of one or more zones managed by the server. Key management strategy is out of scope for this document. Service Registration Protocol [RFC9665] uses DNS Update Leases with "First Come, First Served Naming" rather than an explicit trust establishment process to confer update permission to a set of RRs.
IANA Considerations
IANA has updated the "DNS EDNS0 Option Codes (OPT)" registry [EDNS0Reg] as regards value 2 as follows:
Value:
2
Name:
Update Lease
Status:
Standard
Reference:
RFC 9664
References
Normative References
[RFC1035]

Domain names - implementation and specification
P. Mockapetris
November 1987
STD 13
RFC 1035
DOI 10.17487/RFC1035
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC2136]

Dynamic Updates in the Domain Name System (DNS UPDATE)
P. Vixie, Ed.
S. Thomson
Y. Rekhter
J. Bound
April 1997
RFC 2136
DOI 10.17487/RFC2136
[RFC6891]

Extension Mechanisms for DNS (EDNS(0))
J. Damas
M. Graff
P. Vixie
April 2013
STD 75
RFC 6891
DOI 10.17487/RFC6891
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC1536]

Common DNS Implementation Errors and Suggested Fixes
A. Kumar
J. Postel
C. Neuman
P. Danzig
S. Miller
October 1993
RFC 1536
DOI 10.17487/RFC1536
[RFC2931]

DNS Request and Transaction Signatures ( SIG(0)s )
D. Eastlake 3rd
September 2000
RFC 2931
DOI 10.17487/RFC2931
[RFC4953]

Defending TCP Against Spoofing Attacks
J. Touch
July 2007
RFC 4953
DOI 10.17487/RFC4953
[RFC6763]

DNS-Based Service Discovery
S. Cheshire
M. Krochmal
February 2013
RFC 6763
DOI 10.17487/RFC6763
[RFC8085]

UDP Usage Guidelines
L. Eggert
G. Fairhurst
G. Shepherd
March 2017
BCP 145
RFC 8085
DOI 10.17487/RFC8085
[RFC8945]

Secret Key Transaction Authentication for DNS (TSIG)
F. Dupont
S. Morris
P. Vixie
D. Eastlake 3rd
O. Gudmundsson
B. Wellington
November 2020
STD 93
RFC 8945
DOI 10.17487/RFC8945
[RFC9665]

Service Registration Protocol for DNS-Based Service Discovery
Ted Lemon
Apple Inc.
Stuart Cheshire
Apple Inc.
June 2025
RFC 9665
DOI 10.17487/RFC9665
[EDNS0Reg]

DNS EDNS0 Option Codes (OPT)
IANA
[SYN]

Defenses Against TCP SYN Flooding Attacks
Wesley Eddy
Verizon Federal Network Systems
weddy@grc.nasa.gov
December 2006
TCP
The Internet Protocol Journal
Cisco Systems
Volume 9
Number 4
Acknowledgments
Thanks to Marc Krochmal and Kiren Sekar for their work in 2006 on the precursor to this document. Thanks also to Roger Pantos and Chris Sharp for their contributions. Thanks to Chris Box, Esko Dijk, Jonathan Hui, Peter van Dijk, Abtin Keshvarzian, Nathan Dyck, Steve Hanna, Gabriel Montenegro, Kangping Dong, and Tim Wicinski for their working group reviews of this document. Thanks to David Dong, Olafur Gudmundsson, Brian Trammel, and Shivan Sahib for their directorate reviews and IANA reviews.
Authors' Addresses
Stuart Cheshire
Apple Inc.
One Apple Park Way
Cupertino
CA
95014
United States of America
+1 408 974 3207
cheshire@apple.com
Ted Lemon
Apple Inc.
P.O. Box 958
Brattleboro
VT
United States of America
05302
mellon@fugue.com