rfc9664.original   rfc9664.txt 
Internet Engineering Task Force S. Cheshire Internet Engineering Task Force (IETF) S. Cheshire
Internet-Draft Apple Inc. Request for Comments: 9664 T. Lemon
Intended status: Standards Track T. Lemon Category: Standards Track Apple Inc.
Expires: 8 January 2024 Apple Inc ISSN: 2070-1721 October 2024
7 July 2023
An EDNS(0) option to negotiate Leases on DNS Updates An EDNS(0) Option to Negotiate Leases on DNS Updates
draft-ietf-dnssd-update-lease-08
Abstract Abstract
This document describes an EDNS(0) option that can be used by DNS This document describes an EDNS(0) option that can be used between
Update requestors and DNS servers to include a lease lifetime in a DNS Update Requesters and authoritative DNS servers to include a
DNS Update or response, allowing a server to garbage collect stale lifetime (lease duration) in a DNS Update or DNS Update Response,
resource records that have been added by DNS Updates allowing a server to garbage collect stale Resource Records that have
been added by DNS Updates if they are not renewed.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://dnssd-
wg.github.io/draft-ietf-dnssd-update-lease/draft-ietf-dnssd-update-
lease.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease/.
Discussion of this document takes place on the DNSSD Working Group
mailing list (mailto:dnssd@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/dnssd/. Subscribe at
https://www.ietf.org/mailman/listinfo/dnssd/.
Source for this draft and an issue tracker can be found at
https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at https://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference https://www.rfc-editor.org/info/rfc9664.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 January 2024.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2024 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Conventions and Terminology Used in this Document . . . . . . 3 2. Conventions and Terminology Used in This Document
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology
3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mechanisms
4. Update Message Format . . . . . . . . . . . . . . . . . . . . 3 4. Lease Update Request and Response Format
4.1. Types of DNS Update Request messages . . . . . . . . . . 4 4.1. Types of Lease Update Requests
4.2. Requestor Behavior . . . . . . . . . . . . . . . . . . . 5 4.2. Requester Behavior
4.3. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6 4.3. Server Behavior
5. Refresh Messages . . . . . . . . . . . . . . . . . . . . . . 6 5. Refresh Requests
5.1. Refresh Message Format . . . . . . . . . . . . . . . . . 6 5.1. Refresh Request Format
5.2. Requestor Behavior . . . . . . . . . . . . . . . . . . . 7 5.2. Requester Behavior
5.2.1. Coalescing Refresh Messages . . . . . . . . . . . . . 8 5.2.1. Coalescing Refresh Requests
5.3. Server Behavior . . . . . . . . . . . . . . . . . . . . . 8 5.3. Server Behavior
6. Retransmission Strategy . . . . . . . . . . . . . . . . . . . 9 6. Retransmission Strategy
7. Garbage Collection . . . . . . . . . . . . . . . . . . . . . 9 7. Garbage Collection
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. References
11. Normative References . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References
12. Informative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgments
Authors' Addresses
1. Introduction 1. Introduction
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
Consider, for instance, 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. An extension to access point, the address RR containing stale information may remain
Dynamic Update is thus required to tell the server to automatically on the authoritative DNS server indefinitely. Thus, an extension to
delete resource records if they are not refreshed after a period of DNS Update is required to tell the server to automatically delete RRs
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 BCP "OPTIONAL" in this document are to be interpreted as described in
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, version 0 [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 |
OPTION-CODE u_int16_t UPDATE-LEASE (2) | | Type | |
OPTION-LENGTH u_int16_t 4 or 8 +===============+===========+======================================+
LEASE u_int32_t desired lease (request) or | OPTION-CODE | u_int16_t | UPDATE-LEASE (2) |
granted lease (response), in seconds +---------------+-----------+--------------------------------------+
KEY-LEASE u_int32_t optional desired (or granted) | OPTION-LENGTH | u_int16_t | 4 (LEASE) or 8 (LEASE + KEY-LEASE) |
lease for KEY records, in seconds +---------------+-----------+--------------------------------------+
| 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 |
+---------------+-----------+--------------------------------------+
Figure 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 reason the KEY record can be given a special lease time is that More information about how the two variants are used is given in
this record is used in the DNS-SD Service Registration Protocol Section 4.3.
[I-D.ietf-dnssd-srp] to 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
is intended simply to renew the lease on a previous Registration
without changing anything. Both messages are DNS Update messages, so
the term "DNS Update message" is to specify behavior that is the same
for both types of DNS Update message.
In some cases it may be necessary to add new information without 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 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
removing old information. For the purpose of this document, such removing old information. For the purpose of this document, such
messages are referred to as Registrations, although in effect they Lease Update Requests are Registrations, although in effect, they may
may also refresh whatever information is unchanged from a previous also refresh whatever information is unchanged from a previous
registration. 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 sooner 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. The requestor SHOULD in this server does not support the Update Lease option. In this case, the
case 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(s) returned in this option when Requester MUST use the durations returned in this option when
determining when to send Refresh messages. This is true both if the determining when to send Refresh Requests. This is true both if the
interval(s) returned by the server are shorter and if they are durations returned by the server are shorter and if they are longer.
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 requirement for 10ms granularity is a scheduling | The 10 ms granularity is a scheduling requirement intended to
requirement intended to result in an even spread of requests, so that | result in an even spread of Requests so that every Request
every request doesn't come an exact number of seconds after startup. | doesn't come an exact number of seconds after startup. This
This requirement should not be construed as requiring anything of the | requirement should not be construed as requiring anything of
link layer on which the packet is transmitted: the link layer may | the link layer on which the packet is transmitted: the link
well impose its own constraints on the timing at which a message is | layer may well impose its own constraints on the timing at
sent, and this 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 reason for the 3000ms (three second) random interval as | The use of a 3000 ms (3-second) random delay as opposed to some
opposed to 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 30ms. In practice, on | generator spread is even, we would have one renewal every 30
relatively constrained devices acting as SRP servers, we are seeing | ms. In practice, on relatively constrained devices acting as
the processing time for an SRP registration taking on the order of | Service Registration Protocol (SRP) servers, we are seeing the
7ms, 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 Update (RCODE=0) that includes an Update Lease option. Servers MAY
different lease interval(s) than specified by the requestor, granting return lease durations different from those specified by the
relatively longer or shorter leases to reduce network traffic due to Requester, granting longer leases to reduce network traffic due to
Refreshes, or reduce stale data, respectively. Refreshes or shorter leases to reduce the lifetime of stale data.
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
after an initial DNS Update has been sent, in order to prevent the an 8-byte variant in its request MUST treat the 4-byte variant as
update's records from being garbage collected. specifying both the lease duration and the KEY lease duration.
5.1. Refresh Message Format 5. Refresh Requests
Refresh messages are formatted like Dynamic Update Leases Requests A Refresh Request is a DNS Update Request that is sent to the server
and Responses (see Section 4 "Update Message Format"). The Refresh after an initial DNS Update has been sent in order to prevent the
message is constructed with the assumption that the result of the update's RRs from being garbage collected.
previous Registration or Refresh is still in effect. The Refresh
message will, in the case that the records added in a previous update
were for some reason garbage collected, result in those records being
added again.
The Refresh message SHOULD NOT include any update prerequisites that 5.1. Refresh Request Format
would fail if the requestor's previous Registration or Refresh is
Refresh Requests 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 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 that its records from a previous update, A Requester that intends for its RRs from a previous Registration or
whether a Registration or a Refresh, remain active, MUST send a Refresh to remain active MUST send a Refresh Request before the lease
Refresh message before the lease elapses, or else the records will be expires; otherwise, the RRs will be removed by the server.
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 interval(s) 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 MAY use the values returned by the server in the initial Registration Request or use the values returned by the server
previous Update Response, whether it was a response to a Registration in the previous Lease Update Response. As with responses to
a Refresh. As with responses to Registrations, the requestor MUST Registration Requests, the Requester MUST use the lease durations
use the 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 should use TCP to send the
entire update at once.
Requestors SHOULD NOT send a 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 "Update Message Format", and described in Section 4 and contains the new lease duration of the
contains the new lease of the resource records being Refreshed. The Registration being Refreshed. The server MUST NOT increment the
server MUST NOT increment the serial number of a zone as the result serial number of a zone as the result of a Refresh Request if the
of a Refresh. 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(s) returned by the server to the requestor are used in durations returned by the server to the Requester are used in
determining when the lease on a resource record has expired. determining when the lease on an RR has 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
LEASE. If KEY-LEASE was not specified, the interval specified in the KEY-LEASE was not specified, the duration specified in the LEASE
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
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 effectively never be cleaned up. Servers implementing Update Lease
should have a default upper bound on the maximum acceptable value should have a default upper bound on the maximum acceptable value
both for the LEASE and KEY-LEASE values sent by the client. Servers both for the LEASE and KEY-LEASE values sent by the requester.
MAY provide a way for the operator to change this upper limit.
Default values for these limits of 24 hours and 7 days, respectively, Default values for these limits of 24 hours and 7 days, respectively,
are RECOMMENDED. 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 regular DNS update as well. The server MUST enforce a risk is present for an authoritative server handling normal (no-
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. Shared secret [RFC8945] or public key signing (e.g. SIG(0) updates. Shared secret [RFC8945] or public key signing (e.g., SIG(0)
[RFC2931]) should be required. Keys should have limited authority: [RFC2931]) should be required. Keys should have limited authority:
compromise of a key should not result in compromise of the entire compromise of a key should not result in compromise of the entire
contents of one or more zones managed by the server. Key management contents of one or more zones managed by the server. Key management
strategy is out of scope for this document. An example of a key strategy is out of scope for this document. Service Registration
management strategy can be found in [I-D.ietf-dnssd-srp], 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
The EDNS(0) OPTION CODE 2 has already been assigned for this DNS IANA has updated the "DNS EDNS0 Option Codes (OPT)" registry
extension. This document appears in the DNS EDNS0 Option Codes (OPT) [EDNS0Reg] as regards value 2 as follows:
registry [EDNS0Codes] with the name 'UL' and the status 'On-hold,'
and a document reference to an older version of this document. When
this document has been approved, the IANA is asked to update the
registry as follows:
OLD:
Value: 2
Name: UL
Status: On-hold
Reference: http://files.dns-sd.org/draft-sekar-dns-ul.txt
NEW:
Value: 2
Name: Update Lease
Status: Standard
Reference: [this document]
10. Acknowledgments Value: 2
Name: Update Lease
Status: Standard
Reference: RFC 9664
Thanks to Marc Krochmal and Kiren Sekar for their work in 2006 on the 10. References
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.
11. Normative References 10.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 11, line 41 skipping to change at line 528
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891, for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013, DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>. <https://www.rfc-editor.org/info/rfc6891>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12. Informative References 10.2. Informative References
[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>.
[I-D.ietf-dnssd-srp] [RFC9665] Lemon, T. and S. Cheshire, "Service Registration Protocol
Lemon, T. and S. Cheshire, "Service Registration Protocol for DNS-Based Service Discovery", RFC 9665,
for DNS-Based Service Discovery", Work in Progress, DOI 10.17487/RFC9665, October 2024,
Internet-Draft, draft-ietf-dnssd-srp-20, 29 May 2023, <https://www.rfc-editor.org/info/rfc9665>.
<https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-
srp-20>.
[EDNS0Codes] [EDNS0Reg] IANA, "DNS EDNS0 Option Codes (OPT)",
"DNS EDNS0 Option Codes (OPT)", April 2023, <https://www.iana.org/assignments/dns-parameters>.
<https://www.iana.org/assignments/dns-parameters/dns-
parameters.xml>. [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 Authors' Addresses
Stuart Cheshire Stuart Cheshire
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014 Cupertino, CA 95014
United States of America United States of America
Phone: +1 408 974 3207 Phone: +1 408 974 3207
Email: cheshire@apple.com Email: cheshire@apple.com
Ted Lemon Ted Lemon
Apple Inc Apple Inc.
P.O. Box 958 P.O. Box 958
Brattleboro, Vermont 05302 Brattleboro, VT 05302
United States of America United States of America
Email: mellon@fugue.com Email: mellon@fugue.com
 End of changes. 82 change blocks. 
367 lines changed or deleted 415 lines changed or added

This html diff was produced by rfcdiff 1.48.