rfc9664v1.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 October 2024
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 Extension Mechanisms for DNS (EDNS(0)) This document describes an EDNS(0) option that can be used between
option that can be used by DNS Update requestors and DNS servers to DNS Update Requesters and authoritative DNS servers to include a
include a lease lifetime in a DNS Update or response, allowing a lifetime (lease duration) in a DNS Update or DNS Update Response,
server to garbage collect stale resource records that have been added allowing a server to garbage collect stale Resource Records that have
by DNS Updates. been added by DNS Updates if they are not renewed.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
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.
skipping to change at line 50 skipping to change at line 50
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
in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
2. Conventions and Terminology Used in This Document 2. Conventions and Terminology Used in This Document
2.1. Abbreviations 2.1. Terminology
3. Mechanisms 3. Mechanisms
4. Update Message Format 4. Lease Update Request and Response Format
4.1. Types of DNS Update Request Messages 4.1. Types of Lease Update Requests
4.2. Requestor Behavior 4.2. Requester Behavior
4.3. Server Behavior 4.3. Server Behavior
5. Refresh Messages 5. Refresh Requests
5.1. Refresh Message Format 5.1. Refresh Request Format
5.2. Requestor Behavior 5.2. Requester Behavior
5.2.1. Coalescing Refresh Messages 5.2.1. Coalescing Refresh Requests
5.3. Server Behavior 5.3. Server Behavior
6. Retransmission Strategy 6. Retransmission Strategy
7. Garbage Collection 7. Garbage Collection
8. Security Considerations 8. Security Considerations
9. IANA Considerations 9. IANA Considerations
10. References 10. References
10.1. Normative References 10.1. Normative References
10.2. Informative References 10.2. Informative References
Acknowledgments Acknowledgments
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
A Dynamic DNS Update [RFC2136] allows for a mapping from a persistent Dynamic Update in the Domain Name System (DNS Update) [RFC2136]
hostname to a dynamic IP address. This capability is particularly allows for a mapping from a persistent hostname to an IP address that
beneficial to mobile hosts, whose IP address may frequently change changes over time. This capability is particularly beneficial to
with location. However, the mobile nature of such hosts often means mobile hosts, whose IP addresses may frequently change with location.
that dynamically updated resource records are not properly deleted. However, the mobile nature of such hosts often means that Resource
For instance, consider a mobile user who publishes address records Records (RRs) added using DNS Update are not properly deleted. For
via dynamic update. If this user moves their laptop out of range of instance, consider a mobile user who publishes address RRs via DNS
the Wi-Fi access point, the address record containing stale Update. If this user moves their laptop out of range of the Wi-Fi
information may remain on the server indefinitely. Thus, an access point, the address RR containing stale information may remain
extension to Dynamic Update is required to tell the server to on the authoritative DNS server indefinitely. Thus, an extension to
automatically delete resource records if they are not refreshed after DNS Update is required to tell the server to automatically delete RRs
a period of time. after a period of time if they are not refreshed.
2. Conventions and Terminology Used in This Document 2. Conventions and Terminology Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.1. Abbreviations 2.1. Terminology
DNS-SD: DNS-based Service Discovery [RFC6763] DNS-SD: DNS-based Service Discovery [RFC6763]
EDNS(0): Extension Mechanisms for DNS [RFC6891] 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 3. Mechanisms
The EDNS(0) Update Lease option is included in a standard DNS Update The Update Lease option is included in a standard DNS Update Request
message [RFC2136] within an EDNS(0) OPT pseudo-RR [RFC6891]. [RFC2136] within an EDNS(0) OPT pseudo-RR [RFC6891].
4. Update Message Format 4. Lease Update Request and Response Format
Dynamic DNS Update Leases Requests and Responses are formatted as Lease Update Requests and Responses are formatted as standard DNS
standard DNS Dynamic Update messages [RFC2136]. This update MUST Update messages [RFC2136]. Such messages MUST include the EDNS(0)
include the EDNS(0) OPT RR, as described in [RFC6891]. This OPT RR OPT RR [RFC6891]. This OPT RR MUST include an EDNS(0) Option as
MUST include an EDNS(0) Option as shown below. shown below.
The Update Lease EDNS(0) option is formatted as follows: The Update Lease EDNS(0) option is formatted as follows:
+===============+============+====================================+ +===============+===========+======================================+
| Field Name | Field Type | Description | | Field Name | Field | Description |
+===============+============+====================================+ | | Type | |
| OPTION-CODE | u_int16_t | UPDATE-LEASE (2) | +===============+===========+======================================+
+---------------+------------+------------------------------------+ | OPTION-CODE | u_int16_t | UPDATE-LEASE (2) |
| OPTION-LENGTH | u_int16_t | 4 or 8 | +---------------+-----------+--------------------------------------+
+---------------+------------+------------------------------------+ | OPTION-LENGTH | u_int16_t | 4 (LEASE) or 8 (LEASE + KEY-LEASE) |
| LEASE | u_int32_t | desired lease (request) or granted | +---------------+-----------+--------------------------------------+
| | | lease (response), in seconds | | LEASE | u_int32_t | desired lease duration (Lease Update |
+---------------+------------+------------------------------------+ | | | Request) or granted lease duration |
| KEY-LEASE | u_int32_t | optional desired (or granted) | | | | (Lease Update response), in seconds |
| | | lease for KEY records, in seconds | +---------------+-----------+--------------------------------------+
+---------------+------------+------------------------------------+ | KEY-LEASE | u_int32_t | optional desired (or granted) lease |
| | | duration for KEY RRs, in seconds |
+---------------+-----------+--------------------------------------+
Table 1 Table 1
Update Requests contain, in the LEASE field of the OPT RDATA, an Lease Update Requests contain, in the LEASE field of the OPT RDATA,
unsigned 32-bit integer indicating the lease lifetime, in seconds, an unsigned 32-bit integer indicating the lease duration in seconds,
desired by the requestor, represented in network (big-endian) byte desired by the Requester, represented in network (big-endian) byte
order. In Update Responses, this field contains the actual lease order. In Lease Update Responses, this field contains the actual
granted by the server. The lease granted by the server may be less lease duration granted by the authoritative DNS server. The lease
than, greater than, or equal to the value requested by the requestor. 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 EDNS(0) UPDATE-LEASE option: the basic There are two variants of the Update Lease option: The 4-byte variant
(4-byte) variant and the extended (8-byte) variant. and the 8-byte variant.
In the basic (4-byte) variant, the LEASE indicated in the Update In the 4-byte variant, the LEASE indicated in the Update Lease option
Lease option applies to all resource records in the Update section. applies to all RRs in the Update section.
In the extended (8-byte) variant, the Update Lease communicates two In the 8-byte variant, the Update Lease communicates two lease
lease lifetimes. The LEASE indicated in the Update Lease option durations. The LEASE indicated in the Update Lease option applies to
applies to all resource records in the Update section _except_ for all RRs in the Update section _except_ for KEY RRs. The KEY-LEASE
KEY records. The KEY-LEASE indicated in the Update Lease option indicated in the Update Lease option applies to KEY RRs in the Update
applies to KEY records in the Update section. section.
The KEY record can be given a special lease time because this record More information about how the two variants are used is given in
is used in the DNS-SD Service Registration Protocol [RFC9665] to Section 4.3.
reserve a name (or names) when the service is not present.
In the case of a KEY record and some other record, obviously the KEY KEY RRs are given a special lease duration because these RRs are used
LEASE applies to the key, and the LEASE applies to the other record. in the DNS-SD Service Registration Protocol [RFC9665] to reserve a
If more than one record that is not a KEY record is added by the name (or names) when the service is not present.
update, the LEASE (not the KEY LEASE) is applied to all such records.
Records that are removed are permanently removed.
4.1. Types of DNS Update Request Messages 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.
This document describes two types of updates: Registrations and 4.1. Types of Lease Update Requests
Refreshes. A Registration is a DNS Update Request that is intended
to add information not already present on the DNS server. A Refresh This document describes two types of Lease Update Requests:
is intended simply to renew the lease on a previous Registration Registrations and Refreshes. A Registration Request is a Lease
without changing anything. Both messages are DNS Update messages, so Update Request that is intended to add information not already
the term "DNS Update message" is to specify behavior that is the same present on the authoritative DNS server. A Refresh Request is
for both types of DNS Update messages. 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 to specify behavior
that is the same for both types of DNS Update.
In some cases, it may be necessary to add new information without In some cases, it may be necessary to add new information without
removing old information. For the purpose of this document, such removing old information. For the purpose of this document, such
messages are Registrations, although in effect, they may also refresh Lease Update Requests are Registrations, although in effect, they may
whatever information is unchanged from a previous registration. also refresh whatever information is unchanged from a previous
registration.
4.2. Requestor Behavior 4.2. Requester Behavior
DNS Update requestors MUST send an Update Lease option with any DNS DNS Update Requesters MUST send an Update Lease option with any DNS
Update that is not intended to be present indefinitely. The Update Update that updates RRs that are not intended to be present
Lease option SHOULD specify a time interval that is no shorter than indefinitely. The Update Lease option SHOULD specify a lease
1800 seconds (30 minutes). Requestors MAY specify a shorter lease if duration that is no shorter than 1800 seconds (30 minutes).
they anticipate that the records being updated will change in less Requesters MAY specify a shorter lease duration if they anticipate
than 30 minutes. Requestors that expect the updated records to be that the RRs being updated will change more frequently than every 30
relatively static SHOULD request appropriately longer leases. minutes. Requesters that expect the updated RRs to be relatively
static SHOULD request appropriately longer lease durations.
If the DNS response received by the requestor does not include an If the DNS Response received by the Requester does not include an
Update Lease option, this is an indication that the DNS server does Update Lease option, this is an indication that the authoritative DNS
not support the Update Lease option. In this case, the requestor server does not support the Update Lease option. In this case, the
SHOULD continue sending Refresh messages (see below) as if the server Requester SHOULD continue sending Refresh Requests (see below) as if
had returned an identical update lease option in its response. the server had returned an identical Update Lease option in its
Response.
If the DNS response does include an Update Lease option, the If the DNS Response does include an Update Lease option, the
requestor MUST use the interval or intervals returned in this option Requester MUST use the durations returned in this option when
when determining when to send Refresh messages. This is true both if determining when to send Refresh Requests. This is true both if the
the interval or intervals returned by the server are shorter and if durations returned by the server are shorter and if they are longer.
they are longer.
When sending a Registration, the requestor MUST delay the initial When sending a Registration Request, the Requester MUST delay the
transmission by a random amount of time across the range of 0-3000 initial transmission by a random amount of time across the range of
milliseconds, with a granularity of no more than 10 milliseconds. 0-3000 milliseconds, with a granularity of no more than 10
This prevents synchronization of multiple devices of the same type at milliseconds. This prevents synchronization of multiple devices of
a site upon recovery from a power failure. This requirement applies the same type at a site upon recovery from a power failure. This
only to the initial Registration on startup; since Refreshes include requirement applies only to the initial Registration Request on
a random factor as well, any synchronization that occurs after such startup; since Refresh Requests include a random factor as well, any
an event should quickly randomize. synchronization that occurs after such an event should quickly
randomize.
Note: the 10 ms granularity is a scheduling requirement intended to | The 10 ms granularity is a scheduling requirement intended to
result in an even spread of requests so that every request doesn't | result in an even spread of Requests so that every Request
come an exact number of seconds after startup. This requirement | doesn't come an exact number of seconds after startup. This
should not be construed as requiring anything of the link layer on | requirement should not be construed as requiring anything of
which the packet is transmitted: the link layer may well impose its | the link layer on which the packet is transmitted: the link
own constraints on the timing at which a message is sent, and this | layer may well impose its own constraints on the timing at
document does not claim to override such constraints. | which a message is sent, and this document does not claim to
| override such constraints.
Note: the use of a 3000 ms (3-second) random interval as opposed to | The use of a 3000 ms (3-second) random delay as opposed to some
some other random interval is to allow for enough time to | other random delay is to allow for enough time to meaningfully
meaningfully spread the load when many devices renew at once, without | spread the load when many devices renew at once, without
delaying so long that the delay in discovery of devices becomes | 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 | obvious to an end user. A 3-second random delay means that if
are, for example, 100 devices, and the random number generator spread | there are, for example, 100 devices, and the random number
is even, we would have one renewal every 30 ms. In practice, on | generator spread is even, we would have one renewal every 30
relatively constrained devices acting as Service Registration | ms. In practice, on relatively constrained devices acting as
Protocol (SRP) servers, we are seeing the processing time for an SRP | Service Registration Protocol (SRP) servers, we are seeing the
registration taking on the order of 7 ms, so this seems reasonable. | processing time for an SRP registration taking on the order of
| 7 ms, so this seems reasonable.
4.3. Server Behavior 4.3. Server Behavior
DNS servers implementing the Update Lease option MUST include an Authoritative DNS servers implementing the Update Lease option MUST
Update Lease option in response to any successful DNS Update include an Update Lease option in response to any successful DNS
(RCODE=0) that includes an Update Lease option. Servers MAY return a Update (RCODE=0) that includes an Update Lease option. Servers MAY
different lease interval or intervals than specified by the return lease durations different from those specified by the
requestor, granting relatively longer or shorter leases to reduce Requester, granting longer leases to reduce network traffic due to
network traffic due to Refreshes or to reduce stale data, Refreshes or shorter leases to reduce the lifetime of stale data.
respectively.
Note that both the 4-byte and 8-byte variant are valid on both Although both the 4-byte and 8-byte variants are valid on both
clients and servers, but clients and servers may exist that do not requesters and servers, older (pre-standard) requesters and servers
support the newer 8-byte variant. Therefore, clients and servers may exist that support only the 4-byte variant. Therefore,
that do support this variant must account for the possibility that requesters and servers that (as required by this specification)
the server with which they are communicating does not. 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 client that receives a 4-byte variant from a server when it sent an A server that receives an 8-byte variant from a requester MUST
8-byte variant MUST treat the 4-byte variant as specifying both the respond with an 8-byte variant giving the granted lease times.
lease time and the key lease time. A server that supports the 8-byte
variant MUST treat the 4-byte variant as specifying both the lease
time and the key lease time. When a server receives a 4-byte
variant, it MUST respond with a 4-byte variant. In this case, the
key and the other records expire at the same time.
5. Refresh Messages 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 Refresh message is a DNS Update message that is sent to the server 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 after an initial DNS Update has been sent in order to prevent the
update's records from being garbage collected. update's RRs from being garbage collected.
5.1. Refresh Message Format 5.1. Refresh Request Format
Refresh messages are formatted like Dynamic Update Leases Requests Refresh Requests are formatted like Update Lease Requests and Update
and Responses (see Section 4). The Refresh message is constructed Lease Responses (see Section 4). The Refresh Request is constructed
with the assumption that the result of the previous Registration or with the assumption that the previous Registration or Refresh is
Refresh is still in effect. In the case that the records added in a still in effect. In the case that the RRs added in a previous update
previous update were for some reason garbage collected, the Refresh were for some reason garbage collected (e.g., because of a server
message will result in those records being added again. reboot that resulted in loss of state), the Refresh Request will
result in those RRs being added again.
The Refresh message SHOULD NOT include any update prerequisites that The Refresh Request SHOULD NOT include any DNS Update prerequisites
would fail if the requestor'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 records affected by the previous Registration or Refresh fail if the RRs affected by the previous Registration or Refresh are
are no longer present; that is, the Refresh should also work as a no longer present; that is, the Refresh Request should also work as a
Registration. There may be cases where this is not possible; in Registration Request. There may be cases where this is not possible;
which case, the response from the server can be used to determine how in which case, the response from the server can be used to determine
to proceed when the Refresh fails. how to proceed when the Refresh Request fails.
An update message that changes the server state resulting from a A Lease Update Request that changes the authoritative DNS server
previous Refresh or Registration is a Registration, not a Refresh. state resulting from a previous Refresh or Registration is a
Registration Request, not a Refresh Request.
The Update Lease option in a Refresh message contains the desired new The Update Lease option in a Refresh Request contains the desired new
lease for Requests, and the actual granted lease for Responses. The lease duration for Requests, and the actual granted lease for
LEASE interval indicated in the Update Lease option applies to all Responses. The lease duration provided in LEASE in the Update Lease
resource records in the Update section of the Refresh request, except option applies to all RRs in the Update section of the Refresh
that if a KEY-LEASE interval is included as well, that interval Request, except that when the 8-byte Update Lease variant is sent,
applies to any KEY records included in the Update section. the duration specified in KEY-LEASE applies to any KEY RRs included
in the Update section.
5.2. Requestor Behavior 5.2. Requester Behavior
A requestor that intends for its records from a previous Registration A Requester that intends for its RRs from a previous Registration or
or Refresh to remain active MUST send a Refresh message before the Refresh to remain active MUST send a Refresh Request before the lease
lease elapses; otherwise, the records will be removed by the server. expires; otherwise, the RRs will be removed by the server.
In order to prevent records expiring, requestors MUST refresh In order to prevent Registrations expiring, Requesters MUST refresh
resource records before they expire. At the time of registration, them. When a Lease Update Request succeeds, the requester computes a
the client computes an interval that is 80% of the lease time plus a time limit that is 80% of the lease duration plus a random offset
random offset between 0% and 5% of the lease time. The random offset between 0% and 5% of the lease duration. The random offset is to
is to prevent refreshes from being synchronized. When this interval prevent refreshes from being synchronized. When this time limit has
has expired, the client MUST refresh the message if the data in the expired, the requester MUST send a Refresh Request if the data in the
initial Registration should continue to be advertised. initial Registration should continue to be advertised.
For Refresh messages, 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
As with the Registration, the requestor MUST use the intervals Request. As with the Registration Request, the Requester MUST use
specified by the server when determining when to send the next the durations returned by the server in the Lease Update Response
Refresh message. when determining when to send the next Refresh Request.
When sending Refresh messages, the requestor MUST include an Update When sending Refresh Requests, the Requester MUST include an Update
Lease option, as it did for the initial Registration. The Update Lease option, as it did in the initial Registration Request. The
Lease option MAY either specify the same intervals as in the initial Update Lease option MAY either specify the same durations as in the
Registration or use the values returned by the server in the previous initial Registration Request or use the values returned by the server
Update Response, whether it was a response to a Registration or a in the previous Lease Update Response. As with responses to
Refresh. As with responses to Registrations, the requestor MUST use Registration Requests, the Requester MUST use the lease durations
the interval or intervals returned by the server in the response when returned by the server in the response when determining when to send
determining when to send the next Refresh message. the next Refresh Request.
5.2.1. Coalescing Refresh Messages 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.
If the requestor has performed multiple successful Registrations with 5.2.1. Coalescing Refresh Requests
a single server, the requestor MAY include Refreshes for all such
Registrations to that server in a single message. This effectively
places all records for a requestor on the same expiration schedule,
reducing network traffic due to Refreshes.
In doing so, the requestor includes in the Refresh message all If the Requester has performed multiple Registrations with a single
existing updates to the server, including those not yet close to server for different RRs, the Requester MAY send a Refresh Request
expiration, so long as at least one resource record in the message containing RRs from all such Registrations to that server in a single
has elapsed at least 75% of its original lease. If the requestor Refresh Request. This effectively places all RRs for a Requester on
uses UDP, the requestor MUST NOT coalesce Refresh messages if doing the same expiration schedule, reducing network traffic due to
so would cause truncation of the message; in this case, the requestor Refreshes.
should either send multiple messages or use TCP to send the entire
update at once.
Requestors SHOULD NOT send Refresh messages when all of the records In doing so, the Requester includes in the Refresh Request all
in the Refresh have more than 50% of their lease interval remaining existing RRs previously successfylly registered on the server,
before expiry. However, there may be cases where the requestor needs including those not yet close to expiration, so long as at least one
to send an early Refresh, and it MAY do so. For example, a power- RR updated in the Refresh Request has elapsed at least 75% of its
constrained (sleepy) device may need to send an update when the radio original lease duration. If the Requester uses UDP, the Requester
is powered so as to avoid having to power it up later. 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.
Another case where this may be needed is if the lease interval Requesters SHOULD NOT send a Refresh Request when all of the RRs in
registered with the server is no longer appropriate and the Requestor the Refresh Request would have more than 50% of their lease duration
wishes to negotiate a different lease interval. However, in this remaining before expiry. However, there may be cases where the
case, if the server does not honor the requested interval in its Requester needs to send an early Refresh Request, and it MAY do so.
response, the requestor MUST NOT retry this negotiation. 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 5.3. Server Behavior
Upon receiving a valid Refresh Request, the server MUST send an Upon receiving a valid Refresh Request, the server MUST send an
acknowledgment. This acknowledgment is identical to the Update acknowledgment. This acknowledgment is a Lease Update Response as
Response format described in Section 4 and contains the new lease of described in Section 4 and contains the new lease duration of the
the resource records being Refreshed. The server MUST NOT increment Registration being Refreshed. The server MUST NOT increment the
the serial number of a zone as the result of a Refresh. 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 client expects. However, the server's state may not match what the requester expects.
In this case, a Refresh may actually appear to be a Registration, In this case, a Refresh Request may actually appear to be a
from the server's perspective. If the Refresh changes the contents Registration Request, from the server's perspective. If the Refresh
of the zone, the server MUST update the zone serial number. Request changes the contents of the zone, the server MUST update the
zone serial number.
6. Retransmission Strategy 6. Retransmission Strategy
The DNS protocol, including DNS updates, can operate over UDP or TCP. The DNS protocol, including DNS updates, can operate over UDP or TCP.
When using UDP, reliable transmission must be guaranteed by When using UDP, reliable transmission must be guaranteed by
retransmitting if a DNS UDP message is not acknowledged in a retransmitting if a DNS UDP message is not acknowledged in a
reasonable interval. Section 4.2.1 of [RFC1035] provides some reasonable amount of time. Section 4.2.1 of the DNS specification
guidance on this topic, as does Section 1 of [RFC1536]. [RFC1035] provides some guidance on this topic, as does Section 1 of
Section 3.1.3 of [RFC8085] also provides useful guidance that is the IETF's guide to common DNS implementation errors [RFC1536].
particularly relevant to DNS. Section 3.1.3 of the UDP Usage Guidelines [RFC8085] also provides
useful guidance that is particularly relevant to DNS.
7. Garbage Collection 7. Garbage Collection
If the Update Lease of a resource record elapses without being If the lease duration of an RR elapses without being refreshed, the
refreshed, the server MUST NOT return the expired record in answers authoritative DNS server MUST NOT return that RR in answers to
to queries. The server MAY delete the record from its database. The queries. The server MAY delete that RR from its database. The lease
lease interval or intervals returned by the server to the requestor durations returned by the server to the Requester are used in
are used in determining when the lease on a resource record has determining when the lease on an RR has expired.
expired.
For all resource records other than a KEY record included in a DNS For all RRs other than a KEY RR included in a Lease Update Request,
Update request, the Update Lease is the LEASE value in the Update the lease duration is the LEASE value in the Update Lease option.
Lease option. For KEY records, if the optional KEY-LEASE value was For KEY RRs, if the optional KEY-LEASE value was included, this
included, this interval is used rather than the interval specified in duration is used rather than the duration specified in the LEASE. If
the LEASE. If the KEY-LEASE was not specified, the interval the KEY-LEASE was not specified, the duration specified in the LEASE
specified in the LEASE is used. is used for all RRs in the Lease Update Request.
8. Security Considerations 8. Security Considerations
Section 8 of [RFC2136] describes problems that can occur around DNS Section 8 of the DNS Update specification [RFC2136] describes
updates. Servers implementing this specification should follow these problems that can occur around DNS updates. Servers implementing
recommendations. this specification should follow these recommendations.
Several additional issues can arise when relying on the Update Lease Several additional issues can arise when relying on the Update Lease
option. First, a too-long lease time is not much different than no option.
lease time: the records associated with this lease time will
effectively never be cleaned up. Servers implementing the Update First, a too-long lease duration is not much different from no lease
Lease should have a default upper bound on the maximum acceptable duration: the RRs associated with such a Registration will
value both for the LEASE and KEY-LEASE values sent by the client. effectively never be cleaned up. Servers implementing Update Lease
Servers MAY provide a way for the operator to change this upper should have a default upper bound on the maximum acceptable value
limit. Default values for these limits of 24 hours and 7 days, both for the LEASE and KEY-LEASE values sent by the requester.
respectively, are RECOMMENDED. 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 The second issue is that a too-short lease can result in increased
server load as requestors rapidly renew the lease. A delay in server load as Requesters rapidly renew such Registrations. A delay
renewing could result in the data being removed prematurely. Servers in renewing could result in the registered RRs being removed
implementing Update Lease MUST have a default minimum lease interval prematurely. Servers implementing Update Lease MUST have a default
that avoids this issue. We RECOMMEND a minimum of 30 seconds for minimum lease duration that avoids this issue. A minimum of 30
both the LEASE and KEY-LEASE intervals. However, in most cases, much seconds for both the LEASE and KEY-LEASE durations is RECOMMENDED.
longer lease times (for example, an hour) are 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 There may be some cost associated with renewing leases. A malicious
(or buggy) client could renew at a high rate in order to overload the (or buggy) requester could renew at a high rate in order to overload
server more than it would be overloaded by query traffic. This risk the server more than it would be overloaded by query traffic. This
is present for a regular DNS update as well. The server MUST enforce risk is present for an authoritative server handling normal (no-
a minimum interval between updates. After a Refresh or Registration lease) DNS Updates as well. Servers should follow established
has been successfully processed and acknowledged, another Update of industry best practices to guard against flooding attacks, both for
either type from the client during that interval MUST be silently malicious flooding of DNS messages over UDP and for similar flooding
ignored by the server. attacks using TCP [SYN] [RFC4953].
Some authentication strategy should be used when accepting DNS Some authentication strategy should be used when accepting DNS
updates. A shared secret [RFC8945] or public key signing (e.g., updates. Shared secret [RFC8945] or public key signing (e.g., SIG(0)
SIG(0) [RFC2931]) should be required. Keys should have limited [RFC2931]) should be required. Keys should have limited authority:
authority: compromise of a key should not result in compromise of the compromise of a key should not result in compromise of the entire
entire contents of one or more zones managed by the server. Key contents of one or more zones managed by the server. Key management
management strategy is out of scope for this document. An example of strategy is out of scope for this document. Service Registration
a key management strategy can be found in [RFC9665], which uses Protocol [RFC9665] uses DNS Update Leases with "First Come, First
"First Come, First Served Naming" rather than an explicit trust Served Naming" rather than an explicit trust establishment process to
establishment process to confer update permission to a set of confer update permission to a set of RRs.
records.
9. IANA Considerations 9. IANA Considerations
IANA has updated the "DNS EDNS0 Option Codes (OPT)" registry IANA has updated the "DNS EDNS0 Option Codes (OPT)" registry
[EDNS0Codes] as regards value 2 as follows: [EDNS0Reg] as regards value 2 as follows:
Value: 2 Value: 2
Name: Update Lease Name: Update Lease
Status: Standard Status: Standard
Reference: RFC 9664 Reference: RFC 9664
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at line 472 skipping to change at line 539
[RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. [RFC1536] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
Miller, "Common DNS Implementation Errors and Suggested Miller, "Common DNS Implementation Errors and Suggested
Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993, Fixes", RFC 1536, DOI 10.17487/RFC1536, October 1993,
<https://www.rfc-editor.org/info/rfc1536>. <https://www.rfc-editor.org/info/rfc1536>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>. 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 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D., [RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
Gudmundsson, O., and B. Wellington, "Secret Key Gudmundsson, O., and B. Wellington, "Secret Key
Transaction Authentication for DNS (TSIG)", STD 93, Transaction Authentication for DNS (TSIG)", STD 93,
RFC 8945, DOI 10.17487/RFC8945, November 2020, RFC 8945, DOI 10.17487/RFC8945, November 2020,
<https://www.rfc-editor.org/info/rfc8945>. <https://www.rfc-editor.org/info/rfc8945>.
[RFC9665] Lemon, T. and S. Cheshire, "Service Registration Protocol [RFC9665] Lemon, T. and S. Cheshire, "Service Registration Protocol
for DNS-Based Service Discovery", RFC 9665, for DNS-Based Service Discovery", RFC 9665,
DOI 10.17487/RFC9665, October 2024, DOI 10.17487/RFC9665, October 2024,
<https://www.rfc-editor.org/info/rfc9665>. <https://www.rfc-editor.org/info/rfc9665>.
[EDNS0Codes] [EDNS0Reg] IANA, "DNS EDNS0 Option Codes (OPT)",
IANA, "DNS EDNS0 Option Codes (OPT)",
<https://www.iana.org/assignments/dns-parameters>. <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 Acknowledgments
Thanks to Marc Krochmal and Kiren Sekar for their work in 2006 on the 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 precursor to this document. Thanks also to Roger Pantos and Chris
Sharp for their contributions. Thanks to Chris Box, Esko Dijk, Sharp for their contributions. Thanks to Chris Box, Esko Dijk,
Jonathan Hui, Peter van Dijk, Abtin Keshvarzian, Nathan Dyck, Steve Jonathan Hui, Peter van Dijk, Abtin Keshvarzian, Nathan Dyck, Steve
Hanna, Gabriel Montenegro, Kangping Dong, and Tim Wicinski for their Hanna, Gabriel Montenegro, Kangping Dong, and Tim Wicinski for their
working group reviews of this document. Thanks to David Dong, Olafur working group reviews of this document. Thanks to David Dong, Olafur
Gudmundsson, Brian Trammel, and Shivan Sahib for their directorate Gudmundsson, Brian Trammel, and Shivan Sahib for their directorate
reviews and IANA reviews. reviews and IANA reviews.
 End of changes. 64 change blocks. 
275 lines changed or deleted 351 lines changed or added

This html diff was produced by rfcdiff 1.48.