rfc9664.original.xml   rfc9664.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc category="std" submissionType="IETF" docName="draft-ietf-dnssd-update-lease
-08" ipr="trust200902"
xmlns:xi="http://www.w3.org/2001/XInclude" version="3"
scripts="Common,Latin" sortRefs="false" consensus="true"
symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
<front>
<title abbrev='Dynamic DNS Update Leases'>
An EDNS(0) option to negotiate Leases on DNS Updates
</title>
<author initials='S' surname='Cheshire' fullname='Stuart Cheshire'> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="I
ETF" docName="draft-ietf-dnssd-update-lease-latest" number="9664" updates="" obs
oletes="" ipr="trust200902" version="3" sortRefs="false" consensus="true" symRef
s="true" tocDepth="3" tocInclude="true" xml:lang="en">
<front>
<title abbrev='DNS Update Lease'>An EDNS(0) Option to Negotiate Leases on DN
S Updates</title>
<seriesInfo name="RFC" value="9664"/>
<author initials='S.' surname='Cheshire' fullname='Stuart Cheshire'>
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<postal> <postal>
<street>One Apple Park Way</street> <street>One Apple Park Way</street>
<city>Cupertino</city> <city>Cupertino</city>
<region>California</region> <region>CA</region>
<code>95014</code> <code>95014</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 408 974 3207</phone> <phone>+1 408 974 3207</phone>
<email>cheshire@apple.com</email> <email>cheshire@apple.com</email>
</address> </address>
</author> </author>
<author initials="T" surname="Lemon" fullname="Ted Lemon"> <author initials="T." surname="Lemon" fullname="Ted Lemon">
<organization>Apple Inc</organization> <organization>Apple Inc.</organization>
<address> <address>
<postal> <postal>
<street>P.O. Box 958</street> <street>P.O. Box 958</street>
<city>Brattleboro</city> <city>Brattleboro</city>
<region>Vermont</region> <region>VT</region>
<country>United States of America</country> <country>United States of America</country>
<code>05302</code> <code>05302</code>
</postal> </postal>
<email>mellon@fugue.com</email> <email>mellon@fugue.com</email>
</address> </address>
</author> </author>
<date>2023-07-07</date> <date month="October" year="2024"/>
<area>Internet</area> <area>INT</area>
<workgroup>Internet Engineering Task Force</workgroup> <workgroup>dnssd</workgroup>
<keyword>DNS Update</keyword> <keyword>DNS Update</keyword>
<abstract> <abstract>
<t>This document describes an EDNS(0) option that can be used by DNS Updat <t>This document describes an EDNS(0) option that can be used between DNS
e requestors and Update Requesters and authoritative DNS servers to include a lifetime (lea
DNS servers to include a lease lifetime in a DNS Update or response, allow se duration) in a DNS
ing a server to garbage collect stale Update or DNS Update Response, allowing a server to garbage collect stale
resource records that have been added by DNS Updates</t> Resource Records
that have been added by DNS Updates if they are not renewed.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
dnssd-wg.github.io/draft-ietf-dnssd-update-lease/draft-ietf-dnssd-update-lease.h
tml"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease/"/>.
</t>
<t>
Discussion of this document takes place on the
DNSSD Working Group mailing list (<eref target="mailto:dnssd@ietf.org"/>
),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/dnssd/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/dnssd/"
/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease"
/>.</t>
</note>
</front> </front>
<middle> <middle>
<section> <section>
<name>Introduction</name> <name>Introduction</name>
<t>Dynamic DNS Update <xref target="RFC2136"/> allows for a mapping from a <t>Dynamic Update in the Domain Name System (DNS Update) <xref
persistent target="RFC2136"/> allows for a mapping from a persistent hostname to an
hostname to a dynamic IP address. This capability is particularly IP address that changes over time. This capability is particularly
beneficial to mobile hosts, whose IP address may frequently change beneficial to mobile hosts, whose IP addresses 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
that dynamically updated resource records are not properly Resource Records (RRs) added using DNS Update are not properly
deleted. Consider, for instance, a mobile user who publishes address deleted. For instance, consider a mobile user who publishes address RRs
records via dynamic update. If this user moves via DNS Update. If this user moves their laptop out of range of the
their laptop out of range of the Wi-Fi access point, Wi-Fi access point, the address RR containing stale information may
the address record containing stale information remain on the authoritative DNS server indefinitely. Thus, an extension
may remain on the server indefinitely. to DNS Update is required to tell the server to automatically delete RRs
An extension to Dynamic Update is after a period of time if they are not refreshed.</t>
thus required to tell the server to automatically delete resource
records if they are not refreshed after a period of time.</t>
</section> </section>
<section> <section>
<name>Conventions and Terminology Used in this Document</name> <name>Conventions and Terminology Used in This Document</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOU The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
LD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as described NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
in BCP 14 <xref target="RFC2119"/> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC8174"/> when, and only when, they appear in all capital "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
s, as shown here. be interpreted as
</t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section> <section>
<name>Abbreviations</name> <name>Terminology</name>
<dl> <dl>
<dt>DNS-SD</dt><dd>DNS-based service discovery <xref target="RFC6763"/> <dt>DNS-SD:</dt><dd>DNS-based Service Discovery <xref target="RFC6763"/
</dd> ></dd>
<dt>EDNS(0)</dt><dd>Extension Mechanisms for DNS, version 0 <xref targe <dt>EDNS(0):</dt><dd>Extension Mechanisms for DNS <xref target="RFC6891
t="RFC6891"/></dd> "/></dd>
<dt>Update Lease option:</dt><dd>Update Lease EDNS(0) option</dd>
<dt>Lease:</dt><dd>An agreement by an authoritative DNS server to conti
nue to publish a record from the time of registration
until the lease duration has elapsed and then stop publishing it</dd>
<dt>Lease Duration:</dt><dd>The time between the start and end of a lea
se</dd>
<dt>Lease Update Request:</dt><dd>DNS Update Request containing an Upd
ate Lease option</dd>
<dt>Lease Update Response:</dt><dd>DNS Update Response containing an U
pdate Lease option</dd>
<dt>RR:</dt><dd>Resource Record</dd>
<dt>Registration Request:</dt><dd>A Lease Update Request that is constr
ucted with the purpose of adding new
information that is not thought to already be present on the authoritat
ive DNS server</dd>
<dt>Registration:</dt><dd>The result of a successful Registration Reque
st</dd>
<dt>Refresh Request:</dt><dd>A Lease Update Request that extends the le
ase duration on an existing Registration</dd>
<dt>Refresh:</dt><dd>The result of a successful Refresh Request</dd>
</dl> </dl>
</section> </section>
</section> </section>
<section> <section>
<name>Mechanisms</name> <name>Mechanisms</name>
<t>The EDNS(0) Update Lease option is included in a standard DNS Update me ssage <xref <t>The Update Lease option is included in a standard DNS Update Request <x ref
target="RFC2136"/> within an EDNS(0) OPT pseudo-RR <xref target="RFC6891"/ >.</t> target="RFC2136"/> within an EDNS(0) OPT pseudo-RR <xref target="RFC6891"/ >.</t>
</section> </section>
<section anchor="update"> <section anchor="update">
<name>Update Message Format</name> <name>Lease Update Request and Response Format</name>
<t> <t>
Dynamic DNS Update Leases Requests and Responses are formatted as standard Lease Update Requests and Responses are formatted as standard DNS
DNS Dynamic Update messages <xref target="RFC2136"/>. Such messages <bcp14>MUST</bcp14
Update messages <xref target="RFC2136"/>. This update MUST include the EDN > include the EDNS(0) OPT RR
S(0) OPT RR, as <xref target="RFC6891"/>. This OPT RR <bcp14>MUST</bcp14> include an EDNS
described in <xref target="RFC6891"/>. This OPT RR MUST include an EDNS(0 (0) Option as shown
) Option as shown
below.</t> below.</t>
<t>The Update Lease EDNS(0) option is formatted as follows:</t> <t>The Update Lease EDNS(0) option is formatted as follows:</t>
<figure align="center" anchor="lease_opt" suppress-title="true"><artwork align=" <table anchor="lease_opt">
center"><![CDATA[ <name></name>
Field Name Field Type Description <thead>
OPTION-CODE u_int16_t UPDATE-LEASE (2) <tr>
OPTION-LENGTH u_int16_t 4 or 8 <th>Field Name</th>
LEASE u_int32_t desired lease (request) or <th>Field Type</th>
granted lease (response), in seconds <th>Description</th>
KEY-LEASE u_int32_t optional desired (or granted) </tr>
lease for KEY records, in seconds </thead>
]]></artwork></figure> <tbody>
<tr>
<td>OPTION-CODE</td>
<td>u_int16_t</td>
<t>Update Requests contain, in the LEASE field of the OPT RDATA, an <td>UPDATE-LEASE (2)</td>
unsigned 32-bit integer indicating the lease lifetime, in seconds, desired </tr>
by the requestor, represented in network (big-endian) byte order. <tr>
In Update Responses, this field contains the actual <td>OPTION-LENGTH</td>
lease granted by the server. The lease granted by the <td>u_int16_t</td>
<td>4 (LEASE) or 8 (LEASE + KEY-LEASE)</td>
</tr>
<tr>
<td>LEASE</td>
<td>u_int32_t</td>
<td>desired lease duration (Lease Update Request) or granted lease duratio
n (Lease Update response), in seconds</td>
</tr>
<tr>
<td>KEY-LEASE</td>
<td>u_int32_t</td>
<td>optional desired (or granted) lease duration for KEY RRs, in seconds</
td>
</tr>
</tbody>
</table>
<t>Lease Update Requests contain, in the LEASE field of the OPT RDATA, an
unsigned 32-bit integer indicating the lease duration in seconds, desired
by the Requester, represented in network (big-endian) byte order.
In Lease Update Responses, this field contains the actual
lease duration granted by the authoritative DNS server. The lease duration
s granted by the
server may be less than, greater than, or equal to the value server may be less than, greater than, or equal to the value
requested by the requestor.</t> requested by the Requester.</t>
<t>There are two variants of the EDNS(0) UPDATE-LEASE option, <t>There are two variants of the Update Lease option:
the basic (4-byte) variant and the extended (8-byte) variant.</t> The 4-byte variant and the 8-byte variant.</t>
<t>In the basic (4-byte) variant, the LEASE indicated in the <t>In the 4-byte variant, the LEASE indicated in the
Update Lease option applies to all resource records in the Update section. Update Lease option applies to all RRs in the Update section.</t>
</t>
<t>In the extended (8-byte) variant, the Update Lease communicates two lea <t>In the 8-byte variant, the Update Lease communicates two lease duration
se lifetimes. s.
The LEASE indicated in the Update Lease option applies to all resource rec The LEASE indicated in the Update Lease option applies to all RRs in the
ords in the Update section <em>except</em> for KEY RRs. The KEY-LEASE indicated in th
Update section *except* for KEY records. The KEY-LEASE indicated in the U e Update Lease
pdate Lease option applies to KEY RRs in the Update section.</t>
option applies to KEY records in the Update section.</t>
<t>The reason the KEY record can be given a special lease time is that thi <t>More information about how the two variants are used is given in
s record is used <xref target="server-behavior" format="default"/>.</t>
in the DNS-SD Service Registration Protocol <xref target="I-D.ietf-dnssd-s
rp"/> to reserve
a name (or names) when the service is not present.</t>
<t>In the case of a KEY record and some other record, obviously the KEY LE <t>
ASE applies to KEY RRs are given a special lease duration because these RRs are used
the key, and the LEASE applies to the other record. If more than one recor in the DNS-SD Service Registration Protocol <xref target="RFC9665"/> to r
d that is not eserve
a KEY record is added by the update, the LEASE (not the KEY LEASE) is appl a name (or names) when the service is not present.
ied to all such </t>
records. Records that are removed are permanently removed.</t>
<t>In the case of a KEY RR and some other RR, obviously the KEY lease dura
tion applies to
the KEY RR, and the lease duration applies to the other RR. If more than o
ne 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.</t>
<section anchor="update-refresh"> <section anchor="update-refresh">
<name>Types of DNS Update Request messages</name> <name>Types of Lease Update Requests</name>
<t>This document describes two types of updates: Registrations and Refres <t>This document describes two types of Lease Update Requests: Registrati
hes. A ons and
Registration is a DNS Update Request that is intended to add information Refreshes. A Registration Request is a Lease Update Request that is inten
not already ded to
present on the DNS server. A Refresh is intended simply to renew the leas add information not already present on the authoritative DNS server. A Re
e on a previous fresh Request is
Registration without changing anything. Both messages are DNS Update mess intended simply to renew the lease on a previous Registration without
ages, so the changing anything. Registrations and Refreshes are both Lease Update Requ
term "DNS Update message" is to specify behavior that is the same for bot ests, so the term
h types of "Lease Update Request" is to specify behavior that is the same for both
DNS Update message.</t> types of DNS Update.</t>
<t>In some cases it may be necessary to add new information without remov <t>In some cases, it may be necessary to add new information without
ing old information. removing old information. For the purpose of this document, such
For the purpose of this document, such messages are referred to as Regist Lease Update Requests are Registrations, although in effect, they
rations, although may also refresh whatever information is unchanged from a previous
in effect they may also refresh whatever information is unchanged from a registration.</t>
previous registration.</t>
</section> </section>
<section anchor="requestor"> <section anchor="requester">
<name>Requestor Behavior</name> <name>Requester Behavior</name>
<t>DNS Update requestors MUST send an Update Lease option with any DNS Up <t>DNS Update Requesters <bcp14>MUST</bcp14> send an Update Lease
date that is option with any DNS Update that updates RRs that are not intended to be p
not intended to be present indefinitely. The Update Lease option SHOULD s resent
pecify a time indefinitely. The Update Lease option <bcp14>SHOULD</bcp14> specify a
interval that is no shorter than 1800 seconds (30 minutes). Requestors MA lease duration that is no shorter than 1800 seconds (30
Y specify a minutes). Requesters <bcp14>MAY</bcp14> specify a shorter lease duration
shorter lease if they anticipate that the records being updated will chan if
ge sooner than they anticipate that the RRs being updated will change more frequently th
30 minutes. Requestors that expect the updated records to be relatively an
static SHOULD every 30 minutes. Requesters that expect the updated RRs to be
request appropriately longer leases.</t> relatively static <bcp14>SHOULD</bcp14> request appropriately longer
lease durations.</t>
<t>If the DNS response received by the requestor does not include an Upda <t>If the DNS Response received by the Requester does not include an
te Lease option, Update Lease option, this is an indication that the authoritative DNS ser
this is an indication that the DNS server does not support the Update Lea ver does
se option. The not support the Update Lease option. In this case, the Requester
requestor SHOULD in this case continue sending Refresh messages (see belo <bcp14>SHOULD</bcp14> continue sending Refresh Requests (see below) as
w) as if the if the server had returned an identical Update Lease option in its
server had returned an identical update lease option in its response.</t> Response.</t>
<t>If the DNS response does include an Update Lease option, the requestor <t>If the DNS Response does include an Update Lease option, the
MUST use the Requester <bcp14>MUST</bcp14> use the durations returned in this
interval(s) returned in this option when determining when to send Refresh option when determining when to send Refresh Requests. This is true
messages. This both if the durations returned by the server are shorter and if they
is true both if the interval(s) returned by the server are shorter and if are longer.</t>
they are
longer.</t>
<t>When sending a Registration, the requestor MUST delay the initial tran <t>When sending a Registration Request, the Requester <bcp14>MUST</bcp14>
smission by a delay the initial transmission by a random amount of time across the
random amount of time across the range of 0-3000 milliseconds, with a gra range of 0-3000 milliseconds, with a granularity of no more than 10
nularity of no milliseconds. This prevents synchronization of multiple devices of the
more than 10 milliseconds. This prevents synchronization of multiple devi same type at a site upon recovery from a power failure. This
ces of the same requirement applies only to the initial Registration Request on startup;
type at a site upon recovery from a power failure. This requirement appli since
es only to the Refresh Requests include a random factor as well, any synchronization tha
initial Registration on startup: since Refreshes include a random factor t
as well, any occurs after such an event should quickly randomize.</t>
synchronization that occurs after such an event should quickly randomize.
</t>
<t>Note: the requirement for 10ms granularity is a scheduling requirement <aside>
intended to <t>The 10 ms granularity is a scheduling requirement intended to
result in an even spread of requests, so that every request doesn't come result in an even spread of Requests so that every Request doesn't come
an exact number an exact number
of seconds after startup. This requirement should not be construed as req of seconds after startup. This requirement should not be construed as r
uiring anything equiring anything
of the link layer on which the packet is transmitted: the link layer may of the link layer on which the packet is transmitted: the link layer ma
well impose its y well impose its
own constraints on the timing at which a message is sent, and this docume own constraints on the timing at which a message is sent, and this docu
nt does not ment does not
claim to override such constraints.</t> claim to override such constraints.</t>
</aside>
<aside>
<t>The use of a 3000 ms (3-second) random delay as opposed to some
other random delay is to allow for enough time to meaningfully spread t
he load when
many devices renew at once, without delaying so long that the delay in
discovery of
devices becomes obvious to an end user. A 3-second random delay means t
hat if there are,
for example, 100 devices, and the random number generator spread is eve
n, we would have
one renewal every 30 ms. In practice, on relatively constrained device
s acting as Service Registration Protocol (SRP)
servers, we are seeing the processing time for an SRP registration taki
ng on the order
of 7 ms, so this seems reasonable.</t>
</aside>
<t>Note: the reason for the 3000ms (three second) random interval as oppo
sed to some
other random interval is to allow for enough time to meaningfully spread
the load when
many devices renew at once, without delaying so long that the delay in di
scovery of
devices becomes obvious to an end user. A 3-second random delay means tha
t if there are
for example 100 devices, and the random number generator spread is even,
we would have
one renewal every 30ms. In practice, on relatively constrained devices a
cting as SRP
servers, we are seeing the processing time for an SRP registration taking
on the order
of 7ms, so this seems reasonable.</t>
</section> </section>
<section> <section anchor="server-behavior">
<name>Server Behavior</name> <name>Server Behavior</name>
<t>DNS Servers implementing the Update Lease option MUST include an Updat
e Lease option <t>Authoritative DNS servers implementing the Update Lease option
in response to any successful DNS Update (RCODE=0) that includes an Updat <bcp14>MUST</bcp14> include an Update Lease option in response to any
e Lease option. successful DNS Update (RCODE=0) that includes an Update Lease option.
Servers MAY return different lease interval(s) than specified by the requ Servers <bcp14>MAY</bcp14> return lease durations different from those
estor, granting specified by the Requester,
relatively longer or shorter leases to reduce network traffic due to Refr granting longer leases to reduce network traffic due to Refreshes
eshes, or or shorter leases to reduce the lifetime of stale data.</t>
reduce stale data, respectively.</t>
<t>Note that both the 4-byte and 8-byte variant are valid on both client <t>Although both the 4-byte and 8-byte variants are valid on
s and servers, but both requesters and servers, older (pre-standard) requesters and servers
clients and servers may exist that do not support the newer 8-byte varian may exist
t. Therefore, that support only the 4-byte variant. Therefore, requesters and servers
clients and servers that do support this variant must account for the pos that (as required by this specification) support both variants
sibility that must account for the possibility that the peer with which they are commu
the server with which they are communicating does not.</t> nicating
<t>A client that receives a 4-byte variant from a server when it sent an may be an older implementation that supports only the 4-byte variant.</t
8-byte variant >
MUST treat the 4-byte variant as specifying both the lease time and the k
ey lease time. <t>A server that receives an 8-byte variant from a requester
A server that supports the 8-byte variant MUST treat the 4-byte variant a <bcp14>MUST</bcp14> respond with an 8-byte variant giving the granted lea
s specifying se times.</t>
both the lease time and the key lease time. When a server receives a 4-by
te variant, it <t>A server that receives a 4-byte variant from a requester
MUST respond with a 4-byte variant. In this case the key and the other re <bcp14>MUST</bcp14> treat the 4-byte variant as
cords expire at specifying both the lease duration and the KEY lease duration
the same time.</t> and <bcp14>MUST</bcp14> respond with a 4-byte variant.
In this case, the key and the other RRs expire at the same time.</t>
<t>A requester that receives a 4-byte variant from a server when it sent
an 8-byte variant in its request <bcp14>MUST</bcp14> treat the 4-byte var
iant as
specifying both the lease duration and the KEY lease duration.</t>
</section> </section>
</section> </section>
<section anchor="refresh"> <section anchor="refresh">
<name>Refresh Messages</name> <name>Refresh Requests</name>
<t>A Refresh message is a DNS Update message that is sent to the server af <t>A Refresh Request is a DNS Update Request that is sent to the server af
ter an initial ter an initial
DNS Update has been sent, in order to prevent the update's records from be DNS Update has been sent in order to prevent the update's RRs from being g
ing garbage arbage
collected.</t> collected.</t>
<section> <section>
<name>Refresh Message Format</name> <name>Refresh Request Format</name>
<t>Refresh messages are formatted like Dynamic Update Leases Requests an <t>Refresh Requests are formatted like Update Lease Requests
d Responses (see and Update Lease Responses (see <xref target="update" format="default"/>
<xref target="update"/> "Update Message Format"). The Refresh message is ). The Refresh Request is constructed
constructed with the assumption that the result of the previous Registra with the assumption that the previous Registration or
tion or Refresh is Refresh is still in effect. In the case that
still in effect. The Refresh message will, in the case that the records the RRs added in a previous update were for some reason garbage
added in a collected (e.g., because of a server reboot that resulted in loss of sta
previous update were for some reason garbage collected, result in those te),
records being the Refresh Request will result in those RRs being added again.</t>
added again.</t>
<t>The Refresh message SHOULD NOT include any update prerequisites that w <t>The Refresh Request <bcp14>SHOULD NOT</bcp14> include any DNS Update
ould fail if prerequisites that will fail if the Requester's previous Registration
the requestor's previous Registration or Refresh is still in effect. It a or Refresh is still in effect. It also <bcp14>SHOULD NOT</bcp14>
lso SHOULD NOT include prerequisites that would fail if the RRs affected by the
include prerequisites that would fail if the records affected by the prev previous Registration or Refresh are no longer present; that is, the
ious Registration or Refresh Request should also work as a Registration Request. There may be
Refresh are no longer present--that is, the Refresh should also work as a cases where
Registration. this is not possible; in which case, the response from the server can
There may be cases where this is not possible, in which case the response be used to determine how to proceed when the Refresh Request fails.</t>
from
the server can be used to determine how to proceed when the Refresh fails
.</t>
<t>An update message that changes the server state resulting from a previ <t>A Lease Update Request that changes the authoritative DNS server state
ous Refresh or resulting from a previous Refresh or
Registration is a Registration, not a Refresh.</t> Registration is a Registration Request, not a Refresh Request.</t>
<t>The Update Lease option in a Refresh message contains the desired new <t>The Update Lease option in a Refresh Request contains the desired new
lease for lease duration for
Requests, and the actual granted lease for Responses. The LEASE interval Requests, and the actual granted lease for Responses. The lease duration
indicated in the provided in LEASE in the
Update Lease option applies to all resource records in the Update section Update Lease option applies to all RRs in the Update section of the Refre
of the Refresh sh
request, except that if a KEY-LEASE interval is included as well, that in Request, except that when the 8-byte Update Lease variant is sent, the du
terval applies ration specified in KEY-LEASE applies
to any KEY records included in the Update section.</t> to any KEY RRs included in the Update section.</t>
</section> </section>
<section> <section>
<name>Requestor Behavior</name> <name>Requester Behavior</name>
<t>A requestor that intends that its records from a previous update, whet <t>A Requester that intends for its RRs from a previous Registration or R
her a Registration efresh to remain active <bcp14>MUST</bcp14>
or a Refresh, remain active, MUST send a Refresh message before the lease send a Refresh Request before the lease expires; otherwise, the RRs
elapses, or else the records
will be removed by the server.</t> will be removed by the server.</t>
<t>In order to prevent records expiring, requestors MUST refresh resource <t>In order to prevent Registrations expiring, Requesters
records before they <bcp14>MUST</bcp14> refresh them. When
expire. At the time of registration, the client computes an interval that a Lease Update Request succeeds, the requester computes a time limit that
is 80% of the lease is 80%
time plus a random offset between 0 and 5% of the lease time. The random of the lease duration plus a random offset between 0% and 5% of the lease
offset is to prevent duration. The random offset is to prevent refreshes from being
refreshes from being synchronized. When this interval has expired, the cl synchronized. When this time limit has expired, the requester
ient MUST refresh the <bcp14>MUST</bcp14> send a Refresh Request if the data in the initial
message if the data in the initial Registration should continue to be adv Registration should continue to be advertised.</t>
ertised.</t>
<t>For Refresh messages, the server is expected to return an Update Lease <t>For Refresh Requests, the server is expected to return an Update
option, if Lease option, if supported, just as with the initial Registration Request
supported, just as with the initial Registration. As with the Registratio . As
n, the with the Registration Request, the Requester <bcp14>MUST</bcp14> use the
requestor MUST use the interval(s) specified by the server when determini durations returned by the server in the Lease Update Response when determ
ng when to send ining when to send the
the next Refresh message.</t> next Refresh Request.</t>
<t>When sending Refresh messages, the requestor MUST include an Update Le <t>When sending Refresh Requests, the Requester <bcp14>MUST</bcp14> inclu
ase option, as de an Update Lease option, as
it did for the initial Registration. The Update Lease option MAY either s it did in the initial Registration Request.
pecify the same
intervals as in the initial Registration, or MAY use the values returned The Update Lease option <bcp14>MAY</bcp14> either specify the same
by the server durations as in the initial Registration Request or use the values return
in the previous Update Response, whether it was a response to a Registrat ed by the server
ion a in the previous Lease Update Response.
Refresh. As with responses to Registrations, the requestor MUST use the i As with responses to Registration Requests, the Requester <bcp14>MUST</bc
ntervals p14> use the lease durations
returned by the server in the response when determining when to send the next Refresh returned by the server in the response when determining when to send the next Refresh
message.</t> Request.</t>
<t>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 <xref target="retransmission"/>.</t>
<section> <section>
<name>Coalescing Refresh Messages</name> <name>Coalescing Refresh Requests</name>
<t>If the requestor has performed multiple successful Registrations wi <t>If the Requester has performed multiple Registrations with a single
th a single server, server for different RRs,
the requestor MAY include Refreshes for all such Registrations to that the Requester <bcp14>MAY</bcp14> send a Refresh Request containing RRs
server in a single from all such Registrations to that server in a single
message. This effectively places all records for a requestor on the sa Refresh Request. This effectively places all RRs for a Requester on th
me expiration e same expiration
schedule, reducing network traffic due to Refreshes.</t> schedule, reducing network traffic due to Refreshes.</t>
<t>In doing so, the requestor includes in the Refresh message all exist ing updates to <t>In doing so, the Requester includes in the Refresh Request all exist ing RRs previously successfylly registered on
the server, including those not yet close to expiration, so long as at least one the server, including those not yet close to expiration, so long as at least one
resource record in the message has elapsed at least 75% of its original RR updated in the Refresh Request has elapsed at least 75% of its origi
lease. If the nal lease duration. If the
requestor uses UDP, the requestor MUST NOT coalesce Refresh messages if Requester uses UDP, the Requester <bcp14>MUST NOT</bcp14> coalesce Refr
doing so would esh Requests if doing so would
cause truncation of the message; in this case, the requestor should eit cause truncation of the Request; in this case, the Requester either sen
her send multiple ds multiple
messages or should use TCP to send the entire update at once.</t> Requests or uses TCP to send the complete Refresh Request at once.</t>
<t>Requestors SHOULD NOT send a Refresh messages when all of the record <t>Requesters <bcp14>SHOULD NOT</bcp14> send a Refresh Request when all
s in the of the RRs in the
Refresh have more than 50% of their lease interval remaining before exp Refresh Request would have more than 50% of their lease duration remain
iry. However, ing before expiry. However,
there may be cases where the requestor needs to send an early Refresh, there may be cases where the Requester needs to send an early Refresh R
and it MAY do equest, and it <bcp14>MAY</bcp14> do
so. For example, a power-constrained (sleepy) device may need to send a so. For example, a power-constrained (sleepy) device may need to send a
n update when the radio Refresh Request when the radio
is powered so as to avoid having to power it up later.</t> is powered so as to avoid having to power it up later.</t>
<t>Another case where this may be needed is if the lease interval regis <t>Another case where this may be needed is when the lease duration reg
tered with the istered with the
server is no longer appropriate and the Requestor wishes to negotiate a server is no longer appropriate and the Requester wishes to negotiate a
different different
lease interval. However, in this case, if the server does not honor the lease duration. However, in this case, if the server does not honor the
requested requested
interval in its response, the requestor MUST NOT retry this negotiation lease duration in its response, the Requester <bcp14>MUST NOT</bcp14> r
.</t> etry this negotiation.</t>
</section> </section>
</section> </section>
<section> <section>
<name>Server Behavior</name> <name>Server Behavior</name>
<t>Upon receiving a valid Refresh Request, the server MUST send an ackno <t>Upon receiving a valid Refresh Request, the server <bcp14>MUST</bcp14
wledgment. This > send an acknowledgment. This
acknowledgment is identical to the Update Response format described in < acknowledgment is a Lease Update Response as described in <xref
xref target="update"/> and contains the new lease duration of the Registratio
target="update"/> "Update Message Format", and contains the new lease of n
the resource being Refreshed. The server <bcp14>MUST NOT</bcp14> increment the seria
records being Refreshed. The server MUST NOT increment the serial numbe l number of a zone
r of a zone as the result of a Refresh Request if the operation does not result in a
as the result of a Refresh.</t> ny change to the zone contents.</t>
<t>However, the server's state may not match what the client expects. In <t>However, the server's state may not match what the requester expects.
this case, a In this case, a
Refresh may actually appear to be a Registration, from the server's persp Refresh Request may actually appear to be a Registration Request, from th
ective. If the e server's perspective. If the
Refresh changes the contents of the zone, the server MUST update the zone Refresh Request changes the contents of the zone, the server <bcp14>MUST<
serial /bcp14> update the zone serial
number.</t> number.</t>
</section> </section>
</section> </section>
<section> <section anchor="retransmission">
<name>Retransmission Strategy</name> <name>Retransmission Strategy</name>
<t>The DNS protocol, including DNS updates, can operate over UDP or TCP. W hen using UDP, reliable <t>The DNS protocol, including DNS updates, can operate over UDP or TCP. W hen using UDP, reliable
transmission must be guaranteed by retransmitting if a DNS UDP message is not acknowledged in a transmission must be guaranteed by retransmitting if a DNS UDP message is not acknowledged in a
reasonable interval. <xref target="RFC1035" section="4.2.1" sectionFormat= reasonable amount of time.
"of"/> provides some Section <xref target="RFC1035" section="4.2.1" sectionFormat="bare"/>
guidance on this topic, as does <xref target="RFC1536" section="1" section of the DNS specification <xref target="RFC1035"/>
Format="of"/>. provides some guidance on this topic, as does
<xref target="RFC8085" section="3.1.3" sectionFormat="of"/> also provides Section <xref target="RFC1536" section="1" sectionFormat="bare"/>
useful guidance that of the IETF's guide to common DNS implementation errors <xref target="RFC1
is particularly relevant to DNS.</t> 536"/>.
Section <xref target="RFC8085" section="3.1.3" sectionFormat="bare"/>
of the UDP Usage Guidelines <xref target="RFC8085"/>
also provides useful guidance that is particularly relevant to DNS.</t>
</section> </section>
<section> <section>
<name>Garbage Collection</name> <name>Garbage Collection</name>
<t>If the Update Lease of a resource record elapses without being refreshe <t>If the lease duration of an RR elapses without being refreshed, the aut
d, the server horitative DNS server
MUST NOT return the expired record in answers to queries. The server MAY d <bcp14>MUST NOT</bcp14> return that RR in answers to queries. The server <
elete the record bcp14>MAY</bcp14> delete that RR
from its database. The lease interval(s) returned by the server to the req from its database. The lease durations returned by the server to the Reque
uestor are used ster are used
in determining when the lease on a resource record has expired.</t> in determining when the lease on an RR has expired.</t>
<t>For all resource records other than a KEY record included in a DNS Upda <t>For all RRs other than a KEY RR included in a Lease Update Request, the
te request, the lease duration is the LEASE value in the Update Lease option. For KEY RRs,
Update Lease is the LEASE value in the Update Lease option. For KEY record if the
s, if the optional KEY-LEASE value was included, this duration is used rather than t
optional KEY-LEASE value was included, this interval is used rather than t he duration
he interval specified in the LEASE. If the KEY-LEASE was not specified, the duration s
specified in LEASE. If KEY-LEASE was not specified, the interval specified pecified in the LEASE is
in LEASE is used for all RRs in the Lease Update Request.
used.
</t> </t>
</section> </section>
<section title="Security Considerations"> <section>
<t><xref target="RFC2136" section="8" sectionFormat="of"/> describes probl <name>Security Considerations</name>
ems that can occur
<t>Section <xref target="RFC2136" section="8" sectionFormat="bare"/> of
the DNS Update specification <xref target="RFC2136"/> describes problems t
hat can occur
around DNS updates. Servers implementing this specification should follow these recommendations.</t> around DNS updates. Servers implementing this specification should follow these recommendations.</t>
<t>Several additional issues can arise when relying on the Update Lease op <t>Several additional issues can arise when relying on the Update Lease op
tion. First, a tion.</t>
too-long lease time is not much different than no lease time: the records
associated with <t>First, a
this lease time will effectively never be cleaned up. Servers implementing too-long lease duration is not much different from no lease duration: the
Update Lease RRs associated with
such a Registration will effectively never be cleaned up. Servers implemen
ting Update Lease
should have a default upper bound on the maximum acceptable value both for the LEASE and should have a default upper bound on the maximum acceptable value both for the LEASE and
KEY-LEASE values sent by the client. Servers MAY provide a way for the ope KEY-LEASE values sent by the requester.
rator to change Default values for these limits of 24 hours and 7 days, respectively,
this upper limit. Default values for these limits of 24 hours and 7 days, are <bcp14>RECOMMENDED</bcp14>.
respectively, Servers <bcp14>MAY</bcp14> provide a way for the operator to change this u
are RECOMMENDED.</t> pper limit.</t>
<t>The second issue is that a too-short lease can result in increased serv er load as <t>The second issue is that a too-short lease can result in increased serv er load as
requestors rapidly renew the lease. A delay in renewing could result in th Requesters rapidly renew such Registrations. A delay in renewing could res
e data being ult in the registered RRs being
removed prematurely. Servers implementing Update Lease MUST have a defaul removed prematurely. Servers implementing Update Lease <bcp14>MUST</bcp14
t minimum lease > have a default minimum lease
interval that avoids this issue. We RECOMMEND a minimum of 30 seconds for duration that avoids this issue. A minimum of 30 seconds for both the LEA
both the LEASE SE
and KEY-LEASE intervals. However, in most cases, much longer lease times ( and KEY-LEASE durations is <bcp14>RECOMMENDED</bcp14>.
for example, an hour) However, in most cases, much longer lease durations (for example, an hour)
are RECOMMENDED.</t> <bcp14>SHOULD</bcp14> be used.
Servers <bcp14>MAY</bcp14> provide a way for the operator to change this l
ower limit.</t>
<t>There may be some cost associated with renewing leases. A malicious (or <t>There may be some cost associated with renewing leases. A malicious
buggy) client (or buggy) requester could renew at a high rate in order to overload the
could renew at a high rate in order to overload the server more than it wo server more than it would be overloaded by query traffic. This risk is
uld be present for an authoritative server handling normal (no-lease) DNS Updates
overloaded by query traffic. This risk is present for regular DNS update a as well.
s well. The Servers should follow established
server MUST enforce a minimum interval between updates. After a Refresh or industry best practices to guard against flooding attacks,
Registration both for malicious flooding of DNS messages over UDP
has been successfully processed and acknowledged, another Update of either and for similar flooding attacks using TCP
type from the <xref target="SYN" format="default"/> <xref target="RFC4953" format="defau
client during that interval MUST be silently ignored by the server.</t> lt"/>.</t>
<t>Some authentication strategy should be used when accepting DNS updates. <t>Some authentication strategy should be used when accepting DNS
Shared secret updates. Shared secret <xref target="RFC8945"/> or public key signing
<xref target="RFC8945"/> or public key signing (e.g. SIG(0) <xref target=" (e.g., SIG(0) <xref target="RFC2931"/>) should be required. Keys should
RFC2931"/>) should be required. Keys should have limited have limited authority: compromise of a key should not result in
authority: compromise of a key should not result in compromise of the enti compromise of the entire contents of one or more zones managed by the
re contents of one server. Key management strategy is out of scope for this document.
or more zones managed by the server. Key management strategy is out of sco Service Registration Protocol <xref target="RFC9665"/>
pe for this document. uses DNS Update Leases with "First Come, First Served Naming" rather
An example of a key management strategy can be found in <xref target="I-D. than an explicit trust establishment process to confer update
ietf-dnssd-srp"/>, permission to a set of RRs.</t>
which uses "first come, first-served naming" rather than an explicit trust
establishment process,
to confer update permission to a set of records.</t>
</section> </section>
<section> <section>
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>The EDNS(0) OPTION CODE 2 has already been assigned for this DNS extens <t>IANA has updated the "DNS EDNS0 Option Codes (OPT)" registry <xref targ
ion. This et="EDNS0Reg"/> as regards value 2 as follows:</t>
document appears in the DNS EDNS0 Option Codes (OPT) registry <xref target
="EDNS0Codes"/> with the name 'UL' and the status 'On-hold,' and a
document reference to an older version of this document. When this documen
t has been
approved, the IANA is asked to update the registry as follows:</t>
<sourcecode>
OLD:
Value: 2
Name: UL
Status: On-hold
Reference: http://files.dns-sd.org/draft-sekar-dns-ul.txt
NEW: <dl newline="false" spacing="compact">
Value: 2 <dt>Value:</dt> <dd>2</dd>
Name: Update Lease <dt>Name:</dt> <dd>Update Lease</dd>
Status: Standard <dt>Status:</dt> <dd>Standard</dd>
Reference: [this document] <dt>Reference:</dt> <dd>RFC 9664</dd>
</sourcecode> </dl>
</section>
<section>
<name>Acknowledgments</name>
<t>Thanks to Marc Krochmal and Kiren Sekar for their work in 2006 on the p
recursor to this
document. Thanks also to Roger Pantos and Chris Sharp for their contribut
ions. Thanks to
Chris Box, Esko Dijk, Jonathan Hui, Peter van Dijk, Abtin Keshvarzian, Nat
han Dyck, Steve
Hanna, Gabriel Montenegro, Kangping Dong, and Tim Wicinski for their worki
ng group reviews of this document.
Thanks to David Dong, Olafur Gudmundsson, Brian Trammel, and Shivan Sahib
for their directorate
reviews and IANA reviews.</t>
</section> </section>
</middle> </middle>
<back> <back>
<!-- This needLines directive is to keep the Authors' Addresses heading from bei
ng split from the list -->
<!-- <displayreference target="I-D.sctl-service-registration" to="RegProt"/>
-->
<!-- <displayreference target="I-D.ietf-dnssd-hybrid" to="I-D.ietf-dnssd-hyb
rid"/> appears to not work in xml2rfc 2.6.2 -->
<references title="Normative References">
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.1035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.2136.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.6891.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8174.xml"/>
</references>
<references title="Informative References"> <references>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <name>References</name>
.1536.xml"/> <references>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC <name>Normative References</name>
.2931.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.103
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC 5.xml"/>
.6763.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC 9.xml"/>
.8085.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.213
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC 6.xml"/>
.8945.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.689
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I- 1.xml"/>
D.ietf-dnssd-srp.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
<reference anchor="EDNS0Codes" target="https://www.iana.org/assignments/dn 4.xml"/>
s-parameters/dns-parameters.xml"> </references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.153
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.293
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.495
3.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.676
3.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.808
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.894
5.xml"/>
<!-- [I-D.ietf-dnssd-srp] companion document RFC 9665-->
<reference anchor="RFC9665" target="https://www.rfc-editor.org/info/rfc966
5">
<front>
<title>Service Registration Protocol for DNS-Based Service Discovery</t
itle>
<author fullname="Ted Lemon" initials="T." surname="Lemon">
<organization>Apple Inc.</organization>
</author>
<author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
<organization>Apple Inc.</organization>
</author>
<date month="October" year="2024"/>
</front>
<seriesInfo name="RFC" value="9665"/>
<seriesInfo name="DOI" value="10.17487/RFC9665"/>
</reference>
<reference anchor="EDNS0Reg" target="https://www.iana.org/assignments/dns-
parameters">
<front> <front>
<title>DNS EDNS0 Option Codes (OPT)</title> <title>DNS EDNS0 Option Codes (OPT)</title>
<author/> <author>
<date month="April" year="2023"/> <organization>IANA</organization>
</author>
</front> </front>
</reference> </reference>
<reference anchor="SYN"
target="https://www.cisco.com/web/about/ac123/ac147/archived_i
ssues/ipj_9-4/ipj_9-4.pdf">
<front>
<title>Defenses Against TCP SYN Flooding Attacks</title>
<author initials="W." surname="Eddy" fullname="Wesley Eddy">
<organization>Verizon Federal Network Systems</organization>
<address>
<email>weddy@grc.nasa.gov</email>
</address>
</author>
<date year="2006" month="December"/>
<keyword>TCP</keyword>
</front>
<refcontent>The Internet Protocol Journal</refcontent>
<refcontent>Cisco Systems</refcontent>
<refcontent>Volume 9</refcontent>
<refcontent>Number 4</refcontent>
</reference>
</references>
</references> </references>
<section numbered="false">
<name>Acknowledgments</name>
<t>Thanks to <contact fullname="Marc Krochmal"/> and <contact
fullname="Kiren Sekar"/> for their work in 2006 on the precursor to this
document. Thanks also to <contact fullname="Roger Pantos"/> and
<contact fullname="Chris Sharp"/> for their contributions. Thanks to
<contact fullname="Chris Box"/>, <contact fullname="Esko Dijk"/>,
<contact fullname="Jonathan Hui"/>, <contact fullname="Peter van
Dijk"/>, <contact fullname="Abtin Keshvarzian"/>, <contact
fullname="Nathan Dyck"/>, <contact fullname="Steve Hanna"/>, <contact
fullname="Gabriel Montenegro"/>, <contact fullname="Kangping Dong"/>,
and <contact fullname="Tim Wicinski"/> for their working group reviews
of this document. Thanks to <contact fullname="David Dong"/>, <contact
fullname="Olafur Gudmundsson"/>, <contact fullname="Brian Trammel"/>,
and <contact fullname="Shivan Sahib"/> for their directorate reviews and
IANA reviews.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 74 change blocks. 
491 lines changed or deleted 581 lines changed or added

This html diff was produced by rfcdiff 1.48.