rfc9664v2.txt   rfc9664.txt 
Internet Engineering Task Force (IETF) S. Cheshire Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 9664 T. Lemon Request for Comments: 9664 T. Lemon
Category: Standards Track Apple Inc. Category: Standards Track Apple Inc.
ISSN: 2070-1721 October 2024 ISSN: 2070-1721 May 2025
An EDNS(0) Option to Negotiate Leases on DNS Updates An EDNS(0) Option to Negotiate Leases on DNS Updates
Abstract Abstract
This document describes an EDNS(0) option that can be used between This document describes an EDNS(0) option that can be used between
DNS Update Requesters and authoritative DNS servers to include a DNS Update Requesters and authoritative DNS servers to include a
lifetime (lease duration) in a DNS Update or DNS Update Response, lifetime (lease duration) in a DNS Update or DNS Update Response,
allowing a server to garbage collect stale Resource Records that have allowing a server to garbage collect stale Resource Records that have
been added by DNS Updates if they are not renewed. been added by DNS Updates if they are not renewed.
skipping to change at line 33 skipping to change at line 33
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9664. https://www.rfc-editor.org/info/rfc9664.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
skipping to change at line 136 skipping to change at line 136
3. Mechanisms 3. Mechanisms
The Update Lease option is included in a standard DNS Update Request The Update Lease option is included in a standard DNS Update Request
[RFC2136] within an EDNS(0) OPT pseudo-RR [RFC6891]. [RFC2136] within an EDNS(0) OPT pseudo-RR [RFC6891].
4. Lease Update Request and Response Format 4. Lease Update Request and Response Format
Lease Update Requests and Responses are formatted as standard DNS Lease Update Requests and Responses are formatted as standard DNS
Update messages [RFC2136]. Such messages MUST include the EDNS(0) Update messages [RFC2136]. Such messages MUST include the EDNS(0)
OPT RR [RFC6891]. This OPT RR MUST include an EDNS(0) Option as OPT RR [RFC6891]. This OPT RR MUST include an Update Lease EDNS(0)
shown below. Option as shown below:
The Update Lease EDNS(0) option is formatted as follows:
+===============+===========+======================================+ +===============+===========+======================================+
| Field Name | Field | Description | | Field Name | Field | Description |
| | Type | | | | Type | |
+===============+===========+======================================+ +===============+===========+======================================+
| OPTION-CODE | u_int16_t | UPDATE-LEASE (2) | | OPTION-CODE | u_int16_t | UPDATE-LEASE (2) |
+---------------+-----------+--------------------------------------+ +---------------+-----------+--------------------------------------+
| OPTION-LENGTH | u_int16_t | 4 (LEASE) or 8 (LEASE + KEY-LEASE) | | OPTION-LENGTH | u_int16_t | 4 (LEASE) or 8 (LEASE + KEY-LEASE) |
+---------------+-----------+--------------------------------------+ +---------------+-----------+--------------------------------------+
| LEASE | u_int32_t | desired lease duration (Lease Update | | LEASE | u_int32_t | desired lease duration (Lease Update |
skipping to change at line 301 skipping to change at line 299
specifying both the lease duration and the KEY lease duration. specifying both the lease duration and the KEY lease duration.
5. Refresh Requests 5. Refresh Requests
A Refresh Request is a DNS Update Request that is sent to the server 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 after an initial DNS Update has been sent in order to prevent the
update's RRs from being garbage collected. update's RRs from being garbage collected.
5.1. Refresh Request Format 5.1. Refresh Request Format
Refresh Requests are formatted like Update Lease Requests and Update Refresh Requests and their corresponding responses are formatted like
Lease Responses (see Section 4). The Refresh Request is constructed Update Lease Requests and Update Lease Responses (see Section 4).
with the assumption that the previous Registration or Refresh is The Refresh Request is constructed with the assumption that the
still in effect. In the case that the RRs added in a previous update previous Registration or Refresh is still in effect. In the case
were for some reason garbage collected (e.g., because of a server that the RRs added in a previous update were for some reason garbage
reboot that resulted in loss of state), the Refresh Request will collected (e.g., because of a server reboot that resulted in loss of
result in those RRs being added again. state), the Refresh Request will result in those RRs being added
again.
The Refresh Request SHOULD NOT include any DNS Update prerequisites The Refresh Request SHOULD NOT include any DNS Update prerequisites
that will fail if the Requester's previous Registration or Refresh is that will fail if the Requester's previous Registration or Refresh is
still in effect. It also SHOULD NOT include prerequisites that would still in effect. It also SHOULD NOT include prerequisites that would
fail if the RRs affected by the previous Registration or Refresh are 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 no longer present; that is, the Refresh Request should also work as a
Registration Request. There may be cases where this is not possible; Registration Request. There may be cases where this is not possible;
in which case, the response from the server can be used to determine in which case, the response from the server can be used to determine
how to proceed when the Refresh Request fails. how to proceed when the Refresh Request fails.
A Lease Update Request that changes the authoritative DNS server A Lease Update Request that changes the authoritative DNS server
state resulting from a previous Refresh or Registration is a state resulting from a previous Refresh or Registration is a
Registration Request, not a Refresh Request. Registration Request, not a Refresh Request.
The Update Lease option in a Refresh Request contains the desired new In a Refresh Request, the Update Lease option contains the desired
lease duration for Requests, and the actual granted lease for new lease duration, and in the corresponding response, the Update
Responses. The lease duration provided in LEASE in the Update Lease Lease option contains the actual granted lease. The lease duration
option applies to all RRs in the Update section of the Refresh provided in LEASE in the Update Lease option applies to all RRs in
Request, except that when the 8-byte Update Lease variant is sent, the Update section of the Refresh Request, except that when the
the duration specified in KEY-LEASE applies to any KEY RRs included 8-byte Update Lease variant is sent, the duration specified in KEY-
in the Update section. LEASE applies to any KEY RRs included in the Update section.
5.2. Requester Behavior 5.2. Requester Behavior
A Requester that intends for its RRs from a previous Registration or A Requester that intends for its RRs from a previous Registration or
Refresh to remain active MUST send a Refresh Request before the lease Refresh to remain active MUST send a Refresh Request before the lease
expires; otherwise, the RRs will be removed by the server. expires; otherwise, the RRs will be removed by the server.
In order to prevent Registrations expiring, Requesters MUST refresh In order to prevent Registrations expiring, Requesters MUST refresh
them. When a Lease Update Request succeeds, the requester computes a them. When a Lease Update Request succeeds, the requester computes a
time limit that is 80% of the lease duration plus a random offset time limit that is 80% of the lease duration plus a random offset
skipping to change at line 354 skipping to change at line 353
For Refresh Requests, the server is expected to return an Update For Refresh Requests, the server is expected to return an Update
Lease option, if supported, just as with the initial Registration Lease option, if supported, just as with the initial Registration
Request. As with the Registration Request, the Requester MUST use Request. As with the Registration Request, the Requester MUST use
the durations returned by the server in the Lease Update Response the durations returned by the server in the Lease Update Response
when determining when to send the next Refresh Request. when determining when to send the next Refresh Request.
When sending Refresh Requests, the Requester MUST include an Update When sending Refresh Requests, the Requester MUST include an Update
Lease option, as it did in the initial Registration Request. The Lease option, as it did in the initial Registration Request. The
Update Lease option MAY either specify the same durations as in the Update Lease option MAY either specify the same durations as in the
initial Registration Request or use the values returned by the server initial Registration Request or use the values returned by the server
in the previous Lease Update Response. As with responses to in the previous Lease Update Response or other desired values as
Registration Requests, the Requester MUST use the lease durations appropriate. As with responses to Registration Requests, the
returned by the server in the response when determining when to send Requester MUST use the lease durations returned by the server in the
the next Refresh Request. response when determining when to send the next Refresh Request.
If the Requester sends a Refresh Request message and does not receive If the Requester sends a Refresh Request message and does not receive
a response from the authoritative DNS server, then the Requester a response from the authoritative DNS server, then the Requester
should implement a reasonable retry strategy to attempt to refresh should implement a reasonable retry strategy to attempt to refresh
the record registrations before they expire. Given that 15% - 20% of the record registrations before they expire. Given that 15% - 20% of
the lease lifetime still remains, these retransmissions do not need the lease lifetime still remains, these retransmissions do not need
to be overly aggressive. For example, the Requester could retry nine to be overly aggressive. For example, the Requester could retry nine
more times, spaced uniformly at equal intervals from the time of the more times, spaced uniformly at equal intervals from the time of the
first failed Refresh attempt until the expiration time of the first failed Refresh attempt until the expiration time of the
records. After the expiration time of the records, the Refresh records. After the expiration time of the records, the Refresh
skipping to change at line 381 skipping to change at line 380
5.2.1. Coalescing Refresh Requests 5.2.1. Coalescing Refresh Requests
If the Requester has performed multiple Registrations with a single If the Requester has performed multiple Registrations with a single
server for different RRs, the Requester MAY send a Refresh Request server for different RRs, the Requester MAY send a Refresh Request
containing RRs from all such Registrations to that server in a single containing RRs from all such Registrations to that server in a single
Refresh Request. This effectively places all RRs for a Requester on Refresh Request. This effectively places all RRs for a Requester on
the same expiration schedule, reducing network traffic due to the same expiration schedule, reducing network traffic due to
Refreshes. Refreshes.
In doing so, the Requester includes in the Refresh Request all In doing so, the Requester includes in the Refresh Request all
existing RRs previously successfylly registered on the server, existing RRs previously successfully registered on the server,
including those not yet close to expiration, so long as at least one 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 RR updated in the Refresh Request has elapsed at least 75% of its
original lease duration. If the Requester uses UDP, the Requester original lease duration. If the Requester uses UDP, the Requester
MUST NOT coalesce Refresh Requests if doing so would cause truncation MUST NOT coalesce Refresh Requests if doing so would cause truncation
of the Request; in this case, the Requester either sends multiple of the Request; in this case, the Requester either sends multiple
Requests or uses TCP to send the complete Refresh Request at once. 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 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 the Refresh Request would have more than 50% of their lease duration
remaining before expiry. However, there may be cases where the remaining before expiry. However, there may be cases where the
 End of changes. 7 change blocks. 
25 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.48.