| RFC : | rfc9664 |
| Title: | Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media |
| Date: | June 2025 |
| Status: | PROPOSED STANDARD |
Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 9664 T. Lemon
Category: Standards Track Apple Inc.
ISSN: 2070-1721 June 2025
An EDNS(0) Option to Negotiate Leases on DNS Updates
Abstract
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
1. 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.
2. 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.
2.1. 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
3. Mechanisms
The Update Lease option is included in a standard DNS Update Request
[RFC2136] within an EDNS(0) OPT pseudo-RR [RFC6891].
4. 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 | Description |
| | Type | |
+===============+===========+======================================+
| 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 |
+---------------+-----------+--------------------------------------+
Table 1
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.
4.1. 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.
4.2. 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.
4.3. 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.
5. 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.
5.1. 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.
5.2. 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.
5.2.1. 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.
5.3. 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.
6. 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.
7. 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.
8. 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.
9. 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
10. References
10.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
Miller, "Common DNS Implementation Errors and Suggested
Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993,
<https://www.rfc-editor.org/info/rfc1536>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, DOI 10.17487/RFC4953, July 2007,
<https://www.rfc-editor.org/info/rfc4953>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
Gudmundsson, O., and B. Wellington, "Secret Key
Transaction Authentication for DNS (TSIG)", STD 93,
RFC 8945, DOI 10.17487/RFC8945, November 2020,
<https://www.rfc-editor.org/info/rfc8945>.
[RFC9665] Lemon, T. and S. Cheshire, "Service Registration Protocol
for DNS-Based Service Discovery", RFC 9665,
DOI 10.17487/RFC9665, June 2025,
<https://www.rfc-editor.org/info/rfc9665>.
[EDNS0Reg] IANA, "DNS EDNS0 Option Codes (OPT)",
<https://www.iana.org/assignments/dns-parameters>.
[SYN] Eddy, W., "Defenses Against TCP SYN Flooding Attacks", The
Internet Protocol Journal, Cisco Systems, Volume 9, Number
4, December 2006,
<https://www.cisco.com/web/about/ac123/ac147/
archived_issues/ipj_9-4/ipj_9-4.pdf>.
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
Phone: +1 408 974 3207
Email: cheshire@apple.com
Ted Lemon
Apple Inc.
P.O. Box 958
Brattleboro, VT 05302
United States of America
Email: mellon@fugue.com
ERRATA