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 Extension Mechanisms for DNS (EDNS(0))
Update requestors and DNS servers to include a lease lifetime in a option that can be used by DNS Update requestors and DNS servers to
DNS Update or response, allowing a server to garbage collect stale include a lease lifetime in a DNS Update or response, allowing a
resource records that have been added by DNS Updates server to garbage collect stale resource records that have been added
by DNS Updates.
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. Abbreviations
3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mechanisms
4. Update Message Format . . . . . . . . . . . . . . . . . . . . 3 4. Update Message Format
4.1. Types of DNS Update Request messages . . . . . . . . . . 4 4.1. Types of DNS Update Request Messages
4.2. Requestor Behavior . . . . . . . . . . . . . . . . . . . 5 4.2. Requestor Behavior
4.3. Server Behavior . . . . . . . . . . . . . . . . . . . . . 6 4.3. Server Behavior
5. Refresh Messages . . . . . . . . . . . . . . . . . . . . . . 6 5. Refresh Messages
5.1. Refresh Message Format . . . . . . . . . . . . . . . . . 6 5.1. Refresh Message Format
5.2. Requestor Behavior . . . . . . . . . . . . . . . . . . . 7 5.2. Requestor Behavior
5.2.1. Coalescing Refresh Messages . . . . . . . . . . . . . 8 5.2.1. Coalescing Refresh Messages
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 A Dynamic DNS Update [RFC2136] allows for a mapping from a persistent
hostname to a dynamic IP address. This capability is particularly hostname to a dynamic IP address. This capability is particularly
beneficial to mobile hosts, whose IP address may frequently change beneficial to mobile hosts, whose IP address may frequently change
with location. However, the mobile nature of such hosts often means with location. However, the mobile nature of such hosts often means
that dynamically updated resource records are not properly deleted. that dynamically updated resource records are not properly deleted.
Consider, for instance, a mobile user who publishes address records For instance, consider a mobile user who publishes address records
via dynamic update. If this user moves their laptop out of range of via dynamic update. If this user moves their laptop out of range of
the Wi-Fi access point, the address record containing stale the Wi-Fi access point, the address record containing stale
information may remain on the server indefinitely. An extension to information may remain on the server indefinitely. Thus, an
Dynamic Update is thus required to tell the server to automatically extension to Dynamic Update is required to tell the server to
delete resource records if they are not refreshed after a period of automatically delete resource records if they are not refreshed after
time. a period of time.
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. Abbreviations
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]
3. Mechanisms 3. Mechanisms
The EDNS(0) Update Lease option is included in a standard DNS Update The EDNS(0) Update Lease option is included in a standard DNS Update
message [RFC2136] within an EDNS(0) OPT pseudo-RR [RFC6891]. message [RFC2136] within an EDNS(0) OPT pseudo-RR [RFC6891].
4. Update Message Format 4. Update Message Format
Dynamic DNS Update Leases Requests and Responses are formatted as Dynamic DNS Update Leases Requests and Responses are formatted as
standard DNS Dynamic Update messages [RFC2136]. This update MUST standard DNS Dynamic Update messages [RFC2136]. This update MUST
include the EDNS(0) OPT RR, as described in [RFC6891]. This OPT RR include the EDNS(0) OPT RR, as described in [RFC6891]. This OPT RR
MUST include an EDNS(0) Option as shown below. MUST include an EDNS(0) Option as 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 Type | Description |
OPTION-CODE u_int16_t UPDATE-LEASE (2) +===============+============+====================================+
OPTION-LENGTH u_int16_t 4 or 8 | OPTION-CODE | u_int16_t | UPDATE-LEASE (2) |
LEASE u_int32_t desired lease (request) or +---------------+------------+------------------------------------+
granted lease (response), in seconds | OPTION-LENGTH | u_int16_t | 4 or 8 |
KEY-LEASE u_int32_t optional desired (or granted) +---------------+------------+------------------------------------+
lease for KEY records, in seconds | LEASE | u_int32_t | desired lease (request) or granted |
| | | lease (response), in seconds |
+---------------+------------+------------------------------------+
| KEY-LEASE | u_int32_t | optional desired (or granted) |
| | | lease for KEY records, in seconds |
+---------------+------------+------------------------------------+
Figure 1 Table 1
Update Requests contain, in the LEASE field of the OPT RDATA, an Update Requests contain, in the LEASE field of the OPT RDATA, an
unsigned 32-bit integer indicating the lease lifetime, in seconds, unsigned 32-bit integer indicating the lease lifetime, in seconds,
desired by the requestor, represented in network (big-endian) byte desired by the requestor, represented in network (big-endian) byte
order. In Update Responses, this field contains the actual lease order. In Update Responses, this field contains the actual lease
granted by the server. The lease granted by the server may be less granted by the server. The lease granted by the server may be less
than, greater than, or equal to the value requested by the requestor. than, greater than, or equal to the value requested by the requestor.
There are two variants of the EDNS(0) UPDATE-LEASE option, the basic There are two variants of the EDNS(0) UPDATE-LEASE option: the basic
(4-byte) variant and the extended (8-byte) variant. (4-byte) variant and the extended (8-byte) variant.
In the basic (4-byte) variant, the LEASE indicated in the Update In the basic (4-byte) variant, the LEASE indicated in the Update
Lease option applies to all resource records in the Update section. Lease option applies to all resource records in the Update section.
In the extended (8-byte) variant, the Update Lease communicates two In the extended (8-byte) variant, the Update Lease communicates two
lease lifetimes. The LEASE indicated in the Update Lease option lease lifetimes. The LEASE indicated in the Update Lease option
applies to all resource records in the Update section *except* for applies to all resource records in the Update section _except_ for
KEY records. The KEY-LEASE indicated in the Update Lease option KEY records. The KEY-LEASE indicated in the Update Lease option
applies to KEY records in the Update section. applies to KEY records in the Update section.
The reason the KEY record can be given a special lease time is that The KEY record can be given a special lease time because this record
this record is used in the DNS-SD Service Registration Protocol is used in the DNS-SD Service Registration Protocol [RFC9665] to
[I-D.ietf-dnssd-srp] to reserve a name (or names) when the service is reserve a name (or names) when the service is not present.
not present.
In the case of a KEY record and some other record, obviously the KEY In the case of a KEY record and some other record, obviously the KEY
LEASE applies to the key, and the LEASE applies to the other record. LEASE applies to the key, and the LEASE applies to the other record.
If more than one record that is not a KEY record is added by the If more than one record that is not a KEY record is added by the
update, the LEASE (not the KEY LEASE) is applied to all such records. update, the LEASE (not the KEY LEASE) is applied to all such records.
Records that are removed are permanently removed. Records that are removed are permanently removed.
4.1. Types of DNS Update Request messages 4.1. Types of DNS Update Request Messages
This document describes two types of updates: Registrations and This document describes two types of updates: Registrations and
Refreshes. A Registration is a DNS Update Request that is intended Refreshes. A Registration is a DNS Update Request that is intended
to add information not already present on the DNS server. A Refresh to add information not already present on the DNS server. A Refresh
is intended simply to renew the lease on a previous Registration is intended simply to renew the lease on a previous Registration
without changing anything. Both messages are DNS Update messages, so without changing anything. Both messages are DNS Update messages, so
the term "DNS Update message" is to specify behavior that is the same the term "DNS Update message" is to specify behavior that is the same
for both types of DNS Update message. for both types of DNS Update messages.
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 referred to as Registrations, although in effect they messages are Registrations, although in effect, they may also refresh
may also refresh whatever information is unchanged from a previous whatever information is unchanged from a previous registration.
registration.
4.2. Requestor Behavior 4.2. Requestor Behavior
DNS Update requestors MUST send an Update Lease option with any DNS DNS Update requestors MUST send an Update Lease option with any DNS
Update that is not intended to be present indefinitely. The Update Update that is not intended to be present indefinitely. The Update
Lease option SHOULD specify a time interval that is no shorter than Lease option SHOULD specify a time interval that is no shorter than
1800 seconds (30 minutes). Requestors MAY specify a shorter lease if 1800 seconds (30 minutes). Requestors MAY specify a shorter lease if
they anticipate that the records being updated will change sooner they anticipate that the records being updated will change in less
than 30 minutes. Requestors that expect the updated records to be than 30 minutes. Requestors that expect the updated records to be
relatively static SHOULD request appropriately longer leases. relatively static SHOULD request appropriately longer leases.
If the DNS response received by the requestor does not include an If the DNS response received by the requestor 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 DNS server does
not support the Update Lease option. The requestor SHOULD in this not support the Update Lease option. In this case, the requestor
case continue sending Refresh messages (see below) as if the server SHOULD continue sending Refresh messages (see below) as if the server
had returned an identical update lease option in its response. 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 requestor MUST use the interval or intervals returned in this option
determining when to send Refresh messages. This is true both if the when determining when to send Refresh messages. This is true both if
interval(s) returned by the server are shorter and if they are the interval or intervals returned by the server are shorter and if
longer. they are longer.
When sending a Registration, the requestor MUST delay the initial When sending a Registration, the requestor MUST delay the initial
transmission by a random amount of time across the range of 0-3000 transmission by a random amount of time across the range of 0-3000
milliseconds, with a granularity of no more than 10 milliseconds. milliseconds, with a granularity of no more than 10 milliseconds.
This prevents synchronization of multiple devices of the same type at This prevents synchronization of multiple devices of the same type at
a site upon recovery from a power failure. This requirement applies a site upon recovery from a power failure. This requirement applies
only to the initial Registration on startup: since Refreshes include only to the initial Registration on startup; since Refreshes include
a random factor as well, any synchronization that occurs after such a random factor as well, any synchronization that occurs after such
an event should quickly randomize. an event should quickly randomize.
Note: the requirement for 10ms granularity is a scheduling Note: 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 doesn't
every request doesn't come an exact number of seconds after startup. come an exact number of seconds after startup. This requirement
This requirement should not be construed as requiring anything of the should not be construed as requiring anything of the link layer on
link layer on which the packet is transmitted: the link layer may which the packet is transmitted: the link layer may well impose its
well impose its own constraints on the timing at which a message is own constraints on the timing at which a message is sent, and this
sent, and this document does not claim to override such constraints. document does not claim to override such constraints.
Note: the reason for the 3000ms (three second) random interval as Note: the use of a 3000 ms (3-second) random interval as opposed to
opposed to some other random interval is to allow for enough time to some other random interval is to allow for enough time to
meaningfully spread the load when many devices renew at once, without meaningfully 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 there
are for example 100 devices, and the random number generator spread are, for example, 100 devices, and the random number generator spread
is even, we would have one renewal every 30ms. In practice, on is even, we would have one renewal every 30 ms. In practice, on
relatively constrained devices acting as SRP servers, we are seeing relatively constrained devices acting as Service Registration
the processing time for an SRP registration taking on the order of Protocol (SRP) servers, we are seeing the processing time for an SRP
7ms, so this seems reasonable. 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 DNS servers implementing the Update Lease option MUST include an
Update Lease option in response to any successful DNS Update Update Lease option in response to any successful DNS Update
(RCODE=0) that includes an Update Lease option. Servers MAY return (RCODE=0) that includes an Update Lease option. Servers MAY return a
different lease interval(s) than specified by the requestor, granting different lease interval or intervals than specified by the
relatively longer or shorter leases to reduce network traffic due to requestor, granting relatively longer or shorter leases to reduce
Refreshes, or reduce stale data, respectively. network traffic due to Refreshes or to reduce stale data,
respectively.
Note that both the 4-byte and 8-byte variant are valid on both Note that both the 4-byte and 8-byte variant are valid on both
clients and servers, but clients and servers may exist that do not clients and servers, but clients and servers may exist that do not
support the newer 8-byte variant. Therefore, clients and servers support the newer 8-byte variant. Therefore, clients and servers
that do support this variant must account for the possibility that that do support this variant must account for the possibility that
the server with which they are communicating does not. the server with which they are communicating does not.
A client that receives a 4-byte variant from a server when it sent an A client that receives a 4-byte variant from a server when it sent an
8-byte variant MUST treat the 4-byte variant as specifying both the 8-byte variant MUST treat the 4-byte variant as specifying both the
lease time and the key lease time. A server that supports the 8-byte 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 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 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 variant, it MUST respond with a 4-byte variant. In this case, the
and the other records expire at the same time. key and the other records expire at the same time.
5. Refresh Messages 5. Refresh Messages
A Refresh message is a DNS Update message that is sent to the server A Refresh message is a DNS Update message 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 records from being garbage collected.
5.1. Refresh Message Format 5.1. Refresh Message Format
Refresh messages are formatted like Dynamic Update Leases Requests Refresh messages are formatted like Dynamic Update Leases Requests
and Responses (see Section 4 "Update Message Format"). The Refresh and Responses (see Section 4). The Refresh message is constructed
message is constructed with the assumption that the result of the with the assumption that the result of the previous Registration or
previous Registration or Refresh is still in effect. The Refresh Refresh is still in effect. In the case that the records added in a
message will, in the case that the records added in a previous update previous update were for some reason garbage collected, the Refresh
were for some reason garbage collected, result in those records being message will result in those records being added again.
added again.
The Refresh message SHOULD NOT include any update prerequisites that The Refresh message SHOULD NOT include any update prerequisites that
would fail if the requestor's previous Registration or Refresh is would fail if the requestor'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 records affected by the previous Registration or Refresh
are no longer present--that is, the Refresh should also work as a are no longer present; that is, the Refresh should also work as a
Registration. There may be cases where this is not possible, in Registration. There may be cases where this is not possible; in
which case the response from the server can be used to determine how which case, the response from the server can be used to determine how
to proceed when the Refresh fails. to proceed when the Refresh fails.
An update message that changes the server state resulting from a An update message that changes the server state resulting from a
previous Refresh or Registration is a Registration, not a Refresh. previous Refresh or Registration is a Registration, not a Refresh.
The Update Lease option in a Refresh message contains the desired new The Update Lease option in a Refresh message contains the desired new
lease for Requests, and the actual granted lease for Responses. The lease for Requests, and the actual granted lease for Responses. The
LEASE interval indicated in the Update Lease option applies to all LEASE interval indicated in the Update Lease option applies to all
resource records in the Update section of the Refresh request, except resource records in the Update section of the Refresh request, except
that if a KEY-LEASE interval is included as well, that interval that if a KEY-LEASE interval is included as well, that interval
applies to any KEY records included in the Update section. applies to any KEY records included in the Update section.
5.2. Requestor Behavior 5.2. Requestor Behavior
A requestor that intends that its records from a previous update, A requestor that intends for its records from a previous Registration
whether a Registration or a Refresh, remain active, MUST send a or Refresh to remain active MUST send a Refresh message before the
Refresh message before the lease elapses, or else the records will be lease elapses; otherwise, the records will be removed by the server.
removed by the server.
In order to prevent records expiring, requestors MUST refresh In order to prevent records expiring, requestors MUST refresh
resource records before they expire. At the time of registration, resource records before they expire. At the time of registration,
the client computes an interval that is 80% of the lease time plus a the client computes an interval that is 80% of the lease time plus a
random offset between 0 and 5% of the lease time. The random offset random offset between 0% and 5% of the lease time. The random offset
is to prevent refreshes from being synchronized. When this interval is to prevent refreshes from being synchronized. When this interval
has expired, the client MUST refresh the message if the data in the has expired, the client MUST refresh the message 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 messages, 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) As with the Registration, the requestor MUST use the intervals
specified by the server when determining when to send the next specified by the server when determining when to send the next
Refresh message. Refresh message.
When sending Refresh messages, the requestor MUST include an Update When sending Refresh messages, the requestor MUST include an Update
Lease option, as it did for the initial Registration. The Update Lease option, as it did for the initial Registration. The Update
Lease option MAY either specify the same intervals as in the initial Lease option MAY either specify the same intervals as in the initial
Registration, or MAY use the values returned by the server in the Registration or use the values returned by the server in the previous
previous Update Response, whether it was a response to a Registration Update Response, whether it was a response to a Registration or a
a Refresh. As with responses to Registrations, the requestor MUST Refresh. As with responses to Registrations, the requestor MUST use
use the intervals returned by the server in the response when the interval or intervals returned by the server in the response when
determining when to send the next Refresh message. determining when to send the next Refresh message.
5.2.1. Coalescing Refresh Messages 5.2.1. Coalescing Refresh Messages
If the requestor has performed multiple successful Registrations with If the requestor has performed multiple successful Registrations with
a single server, the requestor MAY include Refreshes for all such a single server, the requestor MAY include Refreshes for all such
Registrations to that server in a single message. This effectively Registrations to that server in a single message. This effectively
places all records for a requestor on the same expiration schedule, places all records for a requestor on the same expiration schedule,
reducing network traffic due to Refreshes. reducing network traffic due to Refreshes.
In doing so, the requestor includes in the Refresh message all In doing so, the requestor includes in the Refresh message all
existing updates to the server, including those not yet close to existing updates to the server, including those not yet close to
expiration, so long as at least one resource record in the message expiration, so long as at least one resource record in the message
has elapsed at least 75% of its original lease. If the requestor has elapsed at least 75% of its original lease. If the requestor
uses UDP, the requestor MUST NOT coalesce Refresh messages if doing uses UDP, the requestor MUST NOT coalesce Refresh messages if doing
so would cause truncation of the message; in this case, the requestor so would cause truncation of the message; in this case, the requestor
should either send multiple messages or should use TCP to send the should either send multiple messages or use TCP to send the entire
entire update at once. update at once.
Requestors SHOULD NOT send a Refresh messages when all of the records Requestors SHOULD NOT send Refresh messages when all of the records
in the Refresh have more than 50% of their lease interval remaining in the Refresh have more than 50% of their lease interval remaining
before expiry. However, there may be cases where the requestor needs before expiry. However, there may be cases where the requestor needs
to send an early Refresh, and it MAY do so. For example, a power- to send an early Refresh, and it MAY do so. For example, a power-
constrained (sleepy) device may need to send an update when the radio constrained (sleepy) device may need to send an update when the radio
is powered so as to avoid having to power it up later. is powered so as to avoid having to power it up later.
Another case where this may be needed is if the lease interval Another case where this may be needed is if the lease interval
registered with the server is no longer appropriate and the Requestor registered with the server is no longer appropriate and the Requestor
wishes to negotiate a different lease interval. However, in this wishes to negotiate a different lease interval. However, in this
case, if the server does not honor the requested interval in its case, if the server does not honor the requested interval in its
response, the requestor MUST NOT retry this negotiation. response, the requestor 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 identical to the Update
Response format described in Section 4 "Update Message Format", and Response format described in Section 4 and contains the new lease of
contains the new lease of the resource records being Refreshed. The the resource records being Refreshed. The server MUST NOT increment
server MUST NOT increment the serial number of a zone as the result the serial number of a zone as the result of a Refresh.
of a Refresh.
However, the server's state may not match what the client expects. However, the server's state may not match what the client expects.
In this case, a Refresh may actually appear to be a Registration, In this case, a Refresh may actually appear to be a Registration,
from the server's perspective. If the Refresh changes the contents from the server's perspective. If the Refresh changes the contents
of the zone, the server MUST update the zone serial number. 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
skipping to change at page 9, line 25 skipping to change at line 369
reasonable interval. Section 4.2.1 of [RFC1035] provides some reasonable interval. Section 4.2.1 of [RFC1035] provides some
guidance on this topic, as does Section 1 of [RFC1536]. guidance on this topic, as does Section 1 of [RFC1536].
Section 3.1.3 of [RFC8085] also provides useful guidance that is Section 3.1.3 of [RFC8085] also provides useful guidance that is
particularly relevant to DNS. particularly relevant to DNS.
7. Garbage Collection 7. Garbage Collection
If the Update Lease of a resource record elapses without being If the Update Lease of a resource record elapses without being
refreshed, the server MUST NOT return the expired record in answers refreshed, the server MUST NOT return the expired record in answers
to queries. The server MAY delete the record from its database. The to queries. The server MAY delete the record from its database. The
lease interval(s) returned by the server to the requestor are used in lease interval or intervals returned by the server to the requestor
determining when the lease on a resource record has expired. are used in determining when the lease on a resource record has
expired.
For all resource records other than a KEY record included in a DNS For all resource records other than a KEY record included in a DNS
Update request, the Update Lease is the LEASE value in the Update Update request, the Update Lease is the LEASE value in the Update
Lease option. For KEY records, if the optional KEY-LEASE value was Lease option. For KEY records, if the optional KEY-LEASE value was
included, this interval is used rather than the interval specified in included, this interval is used rather than the interval specified in
LEASE. If KEY-LEASE was not specified, the interval specified in the LEASE. If the KEY-LEASE was not specified, the interval
LEASE is used. specified in the LEASE is used.
8. Security Considerations 8. Security Considerations
Section 8 of [RFC2136] describes problems that can occur around DNS Section 8 of [RFC2136] describes problems that can occur around DNS
updates. Servers implementing this specification should follow these updates. Servers implementing this specification should follow these
recommendations. 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. First, a too-long lease time is not much different than no
lease time: the records associated with this lease time will lease time: the records associated with this lease time will
effectively never be cleaned up. Servers implementing Update Lease effectively never be cleaned up. Servers implementing the Update
should have a default upper bound on the maximum acceptable value Lease should have a default upper bound on the maximum acceptable
both for the LEASE and KEY-LEASE values sent by the client. Servers value both for the LEASE and KEY-LEASE values sent by the client.
MAY provide a way for the operator to change this upper limit. Servers MAY provide a way for the operator to change this upper
Default values for these limits of 24 hours and 7 days, respectively, limit. Default values for these limits of 24 hours and 7 days,
are RECOMMENDED. respectively, are RECOMMENDED.
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 requestors rapidly renew the lease. A delay in
renewing could result in the data being removed prematurely. Servers renewing could result in the data being removed prematurely. Servers
implementing Update Lease MUST have a default minimum lease interval implementing Update Lease MUST have a default minimum lease interval
that avoids this issue. We RECOMMEND a minimum of 30 seconds for that avoids this issue. We RECOMMEND a minimum of 30 seconds for
both the LEASE and KEY-LEASE intervals. However, in most cases, much both the LEASE and KEY-LEASE intervals. However, in most cases, much
longer lease times (for example, an hour) are RECOMMENDED. longer lease times (for example, an hour) are RECOMMENDED.
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) client could renew at a high rate in order to overload the
server more than it would be overloaded by query traffic. This risk server more than it would be overloaded by query traffic. This risk
is present for regular DNS update as well. The server MUST enforce a is present for a regular DNS update as well. The server MUST enforce
minimum interval between updates. After a Refresh or Registration a minimum interval between updates. After a Refresh or Registration
has been successfully processed and acknowledged, another Update of has been successfully processed and acknowledged, another Update of
either type from the client during that interval MUST be silently either type from the client during that interval MUST be silently
ignored by the server. ignored by the server.
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. A shared secret [RFC8945] or public key signing (e.g.,
[RFC2931]) should be required. Keys should have limited authority: SIG(0) [RFC2931]) should be required. Keys should have limited
compromise of a key should not result in compromise of the entire authority: compromise of a key should not result in compromise of the
contents of one or more zones managed by the server. Key management entire contents of one or more zones managed by the server. Key
strategy is out of scope for this document. An example of a key management strategy is out of scope for this document. An example of
management strategy can be found in [I-D.ietf-dnssd-srp], which uses a key management strategy can be found in [RFC9665], which uses
"first come, first-served naming" rather than an explicit trust "First Come, First Served Naming" rather than an explicit trust
establishment process, to confer update permission to a set of establishment process to confer update permission to a set of
records. 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) [EDNS0Codes] 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 461
[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>.
skipping to change at page 12, line 19 skipping to change at line 486
[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] [EDNS0Codes]
"DNS EDNS0 Option Codes (OPT)", April 2023, IANA, "DNS EDNS0 Option Codes (OPT)",
<https://www.iana.org/assignments/dns-parameters/dns- <https://www.iana.org/assignments/dns-parameters>.
parameters.xml>.
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. 60 change blocks. 
217 lines changed or deleted 189 lines changed or added

This html diff was produced by rfcdiff 1.48.