<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="IETF" docName="draft-ietf-dnssd-update-lease-08" docName="draft-ietf-dnssd-update-lease-latest" number="9664" updates="" obsoletes="" 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 abbrev='DNS Update Leases'>
      An Lease'>An EDNS(0) option Option to negotiate Negotiate Leases on DNS Updates
    </title> Updates</title>
    <seriesInfo name="RFC" value="9664"/>
    <author initials='S' initials='S.' surname='Cheshire' fullname='Stuart Cheshire'>
      <organization>Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino</city>
          <region>California</region>
          <region>CA</region>
          <code>95014</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone>+1 408 974 3207</phone>
        <email>cheshire@apple.com</email>
      </address>
    </author>

    <author initials="T" initials="T." surname="Lemon" fullname="Ted Lemon">
      <organization>Apple Inc</organization> Inc.</organization>
      <address>
        <postal>
          <street>P.O. Box 958</street>
          <city>Brattleboro</city>
          <region>Vermont</region>
          <region>VT</region>
          <country>United States of America</country>
          <code>05302</code>
        </postal>
        <email>mellon@fugue.com</email>
      </address>
    </author>

    <date>2023-07-07</date>
    <area>Internet</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <date month="October" year="2024"/>
    <area>INT</area>
    <workgroup>dnssd</workgroup>
    <keyword>DNS Update</keyword>
    <abstract>
      <t>This document describes an EDNS(0) option that can be used by between DNS
      Update requestors Requesters and authoritative DNS servers to include a lease lifetime (lease duration) in a DNS
      Update or response, DNS Update Response, allowing a server to garbage collect stale
      resource records Resource Records
      that have been added by DNS Updates</t> Updates if they are not renewed.</t>
    </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.html"/>.
        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/browse/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>

  <middle>

    <section>
      <name>Introduction</name>
      <t>Dynamic DNS Update in the Domain Name System (DNS Update) <xref
      target="RFC2136"/> allows for a mapping from a persistent hostname to a dynamic an
      IP address. address that changes over time. This capability is particularly
      beneficial to mobile hosts, whose IP address addresses may frequently change
      with location. However, the mobile nature of such hosts often means that dynamically updated resource records
      Resource Records (RRs) added using DNS Update are not properly
      deleted. Consider, for For instance, consider a mobile user who publishes address
      records RRs
      via dynamic update. DNS Update. If this user moves their laptop out of range of the
      Wi-Fi access point, the address record RR containing stale information may
      remain on the authoritative DNS server indefinitely.
      An  Thus, an extension
      to Dynamic DNS Update is
      thus required to tell the server to automatically delete resource
      records if they are not refreshed RRs
      after a period of time.</t> time if they are not refreshed.</t>
    </section>

    <section>

      <name>Conventions and Terminology Used in this This Document</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
	"MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

      <section>
	<name>Abbreviations</name>
	<name>Terminology</name>
	<dl>
	  <dt>DNS-SD</dt><dd>DNS-based service discovery
	  <dt>DNS-SD:</dt><dd>DNS-based Service Discovery <xref target="RFC6763"/></dd>
	  <dt>EDNS(0)</dt><dd>Extension
	  <dt>EDNS(0):</dt><dd>Extension Mechanisms for DNS, version 0 DNS <xref target="RFC6891"/></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 continue 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 lease</dd>
          <dt>Lease Update Request:</dt><dd>DNS Update Request containing an Update Lease option</dd>
          <dt>Lease Update Response:</dt><dd>DNS Update Response containing an Update Lease option</dd>
          <dt>RR:</dt><dd>Resource Record</dd>
	  <dt>Registration Request:</dt><dd>A Lease Update Request that is constructed with the purpose of adding new
	  information that is not thought to already be present on the authoritative DNS server</dd>
	  <dt>Registration:</dt><dd>The result of a successful Registration Request</dd>
	  <dt>Refresh Request:</dt><dd>A Lease Update Request that extends the lease duration on an existing Registration</dd>
	  <dt>Refresh:</dt><dd>The result of a successful Refresh Request</dd>
	</dl>
      </section>
    </section>

    <section>
      <name>Mechanisms</name>
      <t>The EDNS(0) Update Lease option is included in a standard DNS Update message Request <xref
      target="RFC2136"/> within an EDNS(0) OPT pseudo-RR <xref target="RFC6891"/>.</t>
    </section>

    <section anchor="update">
      <name>Update Message
      <name>Lease Update Request and Response Format</name>
      <t>
      Dynamic DNS
      Lease Update Leases Requests and Responses are formatted as standard DNS Dynamic
      Update messages <xref target="RFC2136"/>. This update MUST Such messages <bcp14>MUST</bcp14> include the EDNS(0) OPT RR, as
      described in RR
      <xref target="RFC6891"/>.  This OPT RR MUST <bcp14>MUST</bcp14> include an EDNS(0) Option as shown
      below.</t>

      <t>The Update Lease EDNS(0) option is formatted as follows:</t>

<figure align="center" anchor="lease_opt" suppress-title="true"><artwork align="center"><![CDATA[
Field Name       Field Type   Description
----------------------------------------------------------------
OPTION-CODE      u_int16_t    UPDATE-LEASE (2)
OPTION-LENGTH    u_int16_t    4

<table anchor="lease_opt">
  <name></name>
  <thead>
    <tr>
      <th>Field Name</th>
      <th>Field Type</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>OPTION-CODE</td>
      <td>u_int16_t</td>

      <td>UPDATE-LEASE (2)</td>
    </tr>
    <tr>
      <td>OPTION-LENGTH</td>
      <td>u_int16_t</td>
      <td>4 (LEASE) or 8
LEASE            u_int32_t    desired (LEASE + KEY-LEASE)</td>
    </tr>
    <tr>
      <td>LEASE</td>
      <td>u_int32_t</td>
      <td>desired lease (request) duration (Lease Update Request) or granted lease (response), duration (Lease Update response), in seconds
KEY-LEASE        u_int32_t    optional seconds</td>
    </tr>
    <tr>
      <td>KEY-LEASE</td>
      <td>u_int32_t</td>
      <td>optional desired (or granted) lease duration for KEY records, RRs, in seconds
]]></artwork></figure>

      <t>Update 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 lifetime, duration in seconds, desired
      by the requestor, 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 durations granted by the
      server may be less than, greater than, or equal to the value
      requested by the requestor.</t> Requester.</t>

      <t>There are two variants of the EDNS(0) UPDATE-LEASE option,
      the basic (4-byte) Update Lease option:
      The 4-byte variant and the extended (8-byte) 8-byte variant.</t>

      <t>In the basic (4-byte) 4-byte variant, the LEASE indicated in the
      Update Lease option applies to all resource records RRs in the Update section.</t>

      <t>In the extended (8-byte) 8-byte variant, the Update Lease communicates two lease lifetimes. durations.
      The LEASE indicated in the Update Lease option applies to all resource records RRs in the
      Update section *except* <em>except</em> for KEY records. RRs.  The KEY-LEASE indicated in the Update Lease
      option applies to KEY records RRs in the Update section.</t>

      <t>The reason

      <t>More information about how the two variants are used is given in
      <xref target="server-behavior" format="default"/>.</t>

      <t>
	KEY record can be RRs are given a special lease time is that this record is duration because these RRs are used
	in the DNS-SD Service Registration Protocol <xref target="I-D.ietf-dnssd-srp"/> target="RFC9665"/> to reserve
	a name (or names) when the service is not present.</t> present.
      </t>

      <t>In the case of a KEY record RR and some other record, RR, obviously the KEY LEASE lease duration applies to
      the key, KEY RR, and the LEASE lease duration applies to the other record. RR. If more than one record RR that is not
      a KEY record RR is added by the update, Lease Update Request, the LEASE lease duration (not the KEY LEASE) lease duration) is applied to all such
      records. Records
      RRs. RRs that are removed are permanently removed.</t>

      <section anchor="update-refresh">
	<name>Types of DNS Lease Update Request messages</name> Requests</name>
	<t>This document describes two types of updates: Lease Update Requests: Registrations and
	Refreshes. A Registration Request is a DNS Lease Update Request that is intended to
	add information not already present on the authoritative DNS server. A Refresh Request is
	intended simply to renew the lease on a previous Registration without
	changing anything. Both messages Registrations and Refreshes are DNS both Lease Update messages, Requests, so the term "DNS
	"Lease Update message" Request" is to specify behavior that is the same for both
	types of DNS Update message.</t> Update.</t>

	<t>In some cases cases, it may be necessary to add new information without
	removing old information.  For the purpose of this document, such messages
	Lease Update Requests are referred to as Registrations, although in effect effect, they
	may also refresh whatever information is unchanged from a previous
	registration.</t>
      </section>

      <section anchor="requestor">
	<name>Requestor anchor="requester">
	<name>Requester Behavior</name>
	<t>DNS Update requestors MUST Requesters <bcp14>MUST</bcp14> send an Update Lease
	option with any DNS Update that is updates RRs that are not intended to be present
	indefinitely. The Update Lease option SHOULD <bcp14>SHOULD</bcp14> specify a time
	interval
	lease duration that is no shorter than 1800 seconds (30
	minutes). Requestors MAY Requesters <bcp14>MAY</bcp14> specify a shorter lease duration if
	they anticipate that the records RRs being updated will change sooner more frequently than
	every 30 minutes.  Requestors  Requesters that expect the updated records RRs to be
	relatively static SHOULD <bcp14>SHOULD</bcp14> request appropriately longer leases.</t>
	lease durations.</t>

	<t>If the DNS response Response received by the requestor Requester does not include an
	Update Lease option, this is an indication that the authoritative DNS server does
	not support the Update Lease option. The
	requestor SHOULD in In this case case, the Requester
	<bcp14>SHOULD</bcp14> continue sending Refresh messages Requests (see below) as
	if the server had returned an identical update lease Update Lease option in its response.</t>
	Response.</t>

	<t>If the DNS response Response does include an Update Lease option, the requestor MUST
	Requester <bcp14>MUST</bcp14> use the
	interval(s) durations returned in this
	option when determining when to send Refresh messages. Requests. This is true
	both if the interval(s) durations returned by the server are shorter and if they
	are longer.</t>

	<t>When sending a Registration, Registration Request, the requestor MUST Requester <bcp14>MUST</bcp14>
	delay the initial transmission by a random amount of time across the
	range of 0-3000 milliseconds, with a granularity of no more than 10
	milliseconds. This prevents synchronization of multiple devices of the
	same type at a site upon recovery from a power failure. This
	requirement applies only to the initial Registration Request on startup: startup; since Refreshes
	Refresh Requests include a random factor as well, any synchronization that
	occurs after such an event should quickly randomize.</t>

	<t>Note: the requirement for 10ms

	<aside>
	  <t>The 10 ms granularity is a scheduling requirement intended to
	  result in an even spread of requests, Requests so that every request Request doesn't come an exact number
	  of seconds after startup. This requirement should not be construed as requiring anything
	  of the link layer on which the packet is transmitted: the link layer may well impose its
	  own constraints on the timing at which a message is sent, and this document does not
	  claim to override such constraints.</t>

	<t>Note: the reason for the 3000ms (three second)
	</aside>

	<aside>
	  <t>The use of a 3000 ms (3-second) random interval delay as opposed to some
	  other random interval delay 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 discovery of
	  devices becomes obvious to an end user. A 3-second random delay means that if there are are,
	  for example example, 100 devices, and the random number generator spread is even, we would have
	  one renewal every 30ms. 30 ms.  In practice, on relatively constrained devices acting as SRP Service Registration Protocol (SRP)
	  servers, we are seeing the processing time for an SRP registration taking on the order
	  of 7ms, 7 ms, so this seems reasonable.</t>
	</aside>

      </section>

      <section>

      <section anchor="server-behavior">
	<name>Server Behavior</name>
	<t>DNS Servers

	<t>Authoritative DNS servers implementing the Update Lease option MUST
	<bcp14>MUST</bcp14> include an Update Lease option in response to any
	successful DNS Update (RCODE=0) that includes an Update Lease option.
	Servers MAY <bcp14>MAY</bcp14> return different lease interval(s) than durations different from those
	specified by the requestor, Requester,
	granting
	relatively longer or shorter leases to reduce network traffic due to Refreshes, Refreshes
	or shorter leases to reduce the lifetime of stale data, respectively.</t>
        <t>Note that data.</t>

        <t>Although both the 4-byte and 8-byte variant variants are valid on
        both clients requesters and servers, but
	clients older (pre-standard) requesters and servers may exist
        that do not support only the newer 8-byte 4-byte variant. Therefore,
	clients requesters and servers
        that do support (as required by this variant specification) support both variants
        must account for the possibility that the server peer with which they are communicating does not.</t>
        may be an older implementation that supports only the 4-byte variant.</t>

	<t>A client server that receives a 4-byte an 8-byte variant from a server when it sent requester
	<bcp14>MUST</bcp14> respond with an 8-byte variant
	MUST treat the 4-byte variant as specifying both giving the granted lease time and the key lease time.
	A times.</t>

	<t>A server that supports the 8-byte receives a 4-byte variant MUST from a requester
	<bcp14>MUST</bcp14> treat the 4-byte variant as
	specifying both the lease time duration and the key KEY lease time. When a server receives a 4-byte variant, it
	MUST duration
	and <bcp14>MUST</bcp14> respond with a 4-byte variant.
	In this case case, the key and the other records 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 variant as
	specifying both the lease duration and the KEY lease duration.</t>

      </section>
    </section>

    <section anchor="refresh">
      <name>Refresh Messages</name> Requests</name>

      <t>A Refresh message Request is a DNS Update message Request that is sent to the server after an initial
      DNS Update has been sent, sent in order to prevent the update's records RRs from being garbage
      collected.</t>

      <section>
	<name>Refresh Message Request Format</name>

        <t>Refresh messages Requests are formatted like Dynamic Update Leases Lease Requests
        and Update Lease Responses (see <xref target="update"/> "Update Message Format"). target="update" format="default"/>). The Refresh message Request is constructed
        with the assumption that the result of the previous Registration or
        Refresh is still in effect. The Refresh message will, in In the case that
        the records RRs added in a previous update were for some reason garbage collected,
        collected (e.g., because of a server reboot that resulted in loss of state),
        the Refresh Request will result in those records RRs being added again.</t>

	<t>The Refresh message SHOULD NOT Request <bcp14>SHOULD NOT</bcp14> include any update DNS Update
	prerequisites that would will fail if the requestor's Requester's previous Registration
	or Refresh is still in effect. It also SHOULD NOT <bcp14>SHOULD NOT</bcp14>
	include prerequisites that would fail if the records RRs affected by the
	previous Registration or Refresh are no longer present--that present; that is, the
	Refresh Request should also work as a Registration. Registration Request.  There may be cases where
	this is not possible, possible; in which case case, the response from the server can
	be used to determine how to proceed when the Refresh Request fails.</t>

	<t>An update message

	<t>A Lease Update Request that changes the authoritative DNS server state resulting from a previous Refresh or
	Registration is a Registration, Registration Request, not a Refresh.</t> Refresh Request.</t>

	<t>The Update Lease option in a Refresh message Request contains the desired new lease duration for
	Requests, and the actual granted lease for Responses. The lease duration provided in LEASE interval indicated in the
	Update Lease option applies to all resource records RRs in the Update section of the Refresh
	request,
	Request, except that if a KEY-LEASE interval when the 8-byte Update Lease variant is included as well, that interval sent, the duration specified in KEY-LEASE applies
	to any KEY records RRs included in the Update section.</t>
      </section>

      <section>
	<name>Requestor
	<name>Requester Behavior</name>

	<t>A requestor Requester that intends that for its records RRs from a previous update, whether a Registration or a Refresh, Refresh to remain active, MUST active <bcp14>MUST</bcp14>
	send a Refresh message Request before the lease elapses, or else expires; otherwise, the records RRs
	will be removed by the server.</t>

	<t>In order to prevent records Registrations expiring, requestors MUST Requesters
	<bcp14>MUST</bcp14> refresh resource records before they
	expire. At the time of registration, them. When
	a Lease Update Request succeeds, the client requester computes an interval a time limit that is 80%
	of the lease
	time duration plus a random offset between 0 0% and 5% of the lease time.
	duration. The random offset is to prevent refreshes from being
	synchronized. When this interval time limit has expired, the client MUST refresh the
	message requester
	<bcp14>MUST</bcp14> send a Refresh Request if the data in the initial
	Registration should continue to be advertised.</t>

	<t>For Refresh messages, Requests, the server is expected to return an Update
	Lease option, if supported, just as with the initial Registration. Registration Request. As
	with the Registration, Registration Request, the
	requestor MUST Requester <bcp14>MUST</bcp14> use the interval(s) specified
	durations returned by the server in the Lease Update Response when determining when to send the
	next Refresh message.</t> Request.</t>

	<t>When sending Refresh messages, Requests, the requestor MUST Requester <bcp14>MUST</bcp14> include an Update Lease option, as
	it did for in the initial Registration. Registration Request.

	The Update Lease option MAY <bcp14>MAY</bcp14> either specify the same
	intervals
	durations as in the initial Registration, Registration Request or MAY use the values returned by the server
	in the previous Lease Update Response, whether it was a response to a Registration a
	Refresh. Response.
	As with responses to Registrations, Registration Requests, the requestor MUST Requester <bcp14>MUST</bcp14> use the intervals lease durations
	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>
	  <name>Coalescing Refresh Messages</name> Requests</name>
          <t>If the requestor Requester has performed multiple successful Registrations with a single server,
          the requestor MAY include Refreshes server for different RRs,
          the Requester <bcp14>MAY</bcp14> send a Refresh Request containing RRs from all such Registrations to that server in a single
          message.
          Refresh Request. This effectively places all records RRs for a requestor Requester on the same expiration
          schedule, reducing network traffic due to Refreshes.</t>

	  <t>In doing so, the requestor Requester includes in the Refresh message Request all existing updates to RRs previously successfylly registered on
	  the server, including those not yet close to expiration, so long as at least one
	  resource record
	  RR updated in the message Refresh Request has elapsed at least 75% of its original lease. lease duration. If the
	  requestor
	  Requester uses UDP, the requestor MUST NOT Requester <bcp14>MUST NOT</bcp14> coalesce Refresh messages Requests if doing so would
	  cause truncation of the message; Request; in this case, the requestor should Requester either send sends multiple
	  messages
	  Requests or should use uses TCP to send the entire update complete Refresh Request at once.</t>

	  <t>Requestors SHOULD NOT

	  <t>Requesters <bcp14>SHOULD NOT</bcp14> send a Refresh messages Request when all of the records RRs in the
	  Refresh Request would have more than 50% of their lease interval duration remaining before expiry. However,
	  there may be cases where the requestor Requester needs to send an early Refresh, Refresh Request, and it MAY <bcp14>MAY</bcp14> do
	  so. For example, a power-constrained (sleepy) device may need to send an update a Refresh Request when the radio
	  is powered so as to avoid having to power it up later.</t>

	  <t>Another case where this may be needed is if when the lease interval duration registered with the
	  server is no longer appropriate and the Requestor Requester wishes to negotiate a different
	  lease interval. duration. However, in this case, if the server does not honor the requested
	  interval
	  lease duration in its response, the requestor MUST NOT Requester <bcp14>MUST NOT</bcp14> retry this negotiation.</t>
	</section>
      </section>

      <section>
	<name>Server Behavior</name>
        <t>Upon receiving a valid Refresh Request, the server MUST <bcp14>MUST</bcp14> send an acknowledgment. This
        acknowledgment is identical to the a Lease Update Response format as described in <xref
        target="update"/> "Update Message Format", and contains the new lease duration of the resource
        records Registration
        being Refreshed.  The server MUST NOT <bcp14>MUST NOT</bcp14> increment the serial number of a zone
        as the result of a Refresh.</t> Refresh Request if the operation does not result in any change to the zone contents.</t>

	<t>However, the server's state may not match what the client requester expects.  In this case, a
	Refresh Request may actually appear to be a Registration, Registration Request, from the server's perspective. If the
	Refresh Request changes the contents of the zone, the server MUST <bcp14>MUST</bcp14> update the zone serial
	number.</t>
      </section>
    </section>

    <section>

    <section anchor="retransmission">
      <name>Retransmission Strategy</name>
      <t>The DNS protocol, including DNS updates, can operate over UDP or TCP. When using UDP, reliable
      transmission must be guaranteed by retransmitting if a DNS UDP message is not acknowledged in a
      reasonable interval. amount of time.
      Section <xref target="RFC1035" section="4.2.1" sectionFormat="of"/> sectionFormat="bare"/>
      of the DNS specification <xref target="RFC1035"/>
      provides some guidance on this topic, as does
      Section <xref target="RFC1536" section="1" sectionFormat="of"/>. sectionFormat="bare"/>
      of the IETF's guide to common DNS implementation errors <xref target="RFC1536"/>.
      Section <xref target="RFC8085" section="3.1.3" sectionFormat="of"/> sectionFormat="bare"/>
      of the UDP Usage Guidelines <xref target="RFC8085"/>
      also provides useful guidance that is particularly relevant to DNS.</t>
    </section>

    <section>
      <name>Garbage Collection</name>

      <t>If the Update Lease lease duration of a resource record an RR elapses without being refreshed, the authoritative DNS server
      MUST NOT
      <bcp14>MUST NOT</bcp14> return the expired record that RR in answers to queries. The server MAY <bcp14>MAY</bcp14> delete the record that RR
      from its database. The lease interval(s) durations returned by the server to the requestor Requester are used
      in determining when the lease on a resource record an RR has expired.</t>

      <t>For all resource records RRs other than a KEY record RR included in a DNS Lease Update request, Request, the
      Update Lease
      lease duration is the LEASE value in the Update Lease option. For KEY records, RRs, if the
      optional KEY-LEASE value was included, this interval duration is used rather than the interval duration
      specified in the LEASE. If the KEY-LEASE was not specified, the interval duration specified in the LEASE is
      used.
      used for all RRs in the Lease Update Request.
      </t>
    </section>

    <section title="Security Considerations">
      <t><xref

    <section>
      <name>Security Considerations</name>

      <t>Section <xref target="RFC2136" section="8" sectionFormat="of"/> sectionFormat="bare"/> of
      the DNS Update specification <xref target="RFC2136"/> describes problems that can occur
      around DNS updates.  Servers implementing this specification should follow these recommendations.</t>

      <t>Several additional issues can arise when relying on the Update Lease option. First, option.</t>

       <t>First, a
      too-long lease time duration is not much different than from no lease time: duration: the records RRs associated with
      this lease time
      such a Registration will effectively never be cleaned up. Servers implementing Update Lease
      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 operator to change
      this upper limit. requester.
      Default values for these limits of 24 hours and 7 days, respectively,
      are RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.
      Servers <bcp14>MAY</bcp14> provide a way for the operator to change this upper limit.</t>

      <t>The second issue is that a too-short lease can result in increased server load as
      requestors
      Requesters rapidly renew the lease. such Registrations. A delay in renewing could result in the data registered RRs being
      removed prematurely.  Servers implementing Update Lease MUST <bcp14>MUST</bcp14> have a default minimum lease
      interval
      duration that avoids this issue. We RECOMMEND a  A minimum of 30 seconds for both the LEASE
      and KEY-LEASE intervals. durations is <bcp14>RECOMMENDED</bcp14>.
      However, in most cases, much longer lease times 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 lower limit.</t>

      <t>There may be some cost associated with renewing leases. A malicious
      (or buggy) client requester could renew at a high rate in order to overload the
      server more than it would be overloaded by query traffic. This risk is
      present for regular an authoritative server handling normal (no-lease) DNS update Updates as well. The
      server MUST enforce a minimum interval between updates. After a Refresh or Registration
      has been successfully processed and acknowledged, another Update
      Servers should follow established
      industry best practices to guard against flooding attacks,
      both for malicious flooding of either type from the
      client during that interval MUST be silently ignored by the server.</t> DNS messages over UDP
      and for similar flooding attacks using TCP
      <xref target="SYN" format="default"/> <xref target="RFC4953" format="default"/>.</t>

      <t>Some authentication strategy should be used when accepting DNS
      updates.  Shared secret <xref target="RFC8945"/> or public key signing (e.g.
      (e.g., SIG(0) <xref target="RFC2931"/>) should be required. Keys should
      have limited authority: compromise of a key should not result in
      compromise of the entire contents of one or more zones managed by the
      server. Key management strategy is out of scope for this document.
      An example of a key management strategy can be found in
      Service Registration Protocol <xref target="I-D.ietf-dnssd-srp"/>,
      which target="RFC9665"/>
      uses "first come, first-served naming" DNS Update Leases with "First Come, First Served Naming" rather
      than an explicit trust establishment process, process to confer update
      permission to a set of records.</t> RRs.</t>
    </section>

    <section>
      <name>IANA Considerations</name>

      <t>The EDNS(0) OPTION CODE 2

      <t>IANA has already been assigned for this DNS extension. This
      document appears in updated the DNS "DNS EDNS0 Option Codes (OPT) (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 document has been
      approved, the IANA is asked to update the registry target="EDNS0Reg"/> as follows:</t>
      <sourcecode>
    OLD:
        Value: 2
        Name: UL
        Status: On-hold
        Reference: http://files.dns-sd.org/draft-sekar-dns-ul.txt

    NEW:
        Value: regards value 2
        Name: Update Lease
        Status: Standard
        Reference: [this document]
      </sourcecode> as follows:</t>

      <dl newline="false" spacing="compact">
        <dt>Value:</dt> <dd>2</dd>
        <dt>Name:</dt> <dd>Update Lease</dd>
        <dt>Status:</dt> <dd>Standard</dd>
        <dt>Reference:</dt> <dd>RFC 9664</dd>
      </dl>

    </section>

    <section>

  </middle>

  <back>

    <references>
      <name>References</name>
      <references>
     <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2136.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
      <name>Informative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1536.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2931.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4953.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8945.xml"/>

<!-- [I-D.ietf-dnssd-srp] companion document RFC 9665-->
      <reference anchor="RFC9665" target="https://www.rfc-editor.org/info/rfc9665">
	<front>
	  <title>Service Registration Protocol for DNS-Based Service Discovery</title>
	  <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>
          <title>DNS EDNS0 Option Codes (OPT)</title>
          <author>
	    <organization>IANA</organization>
          </author>
        </front>
      </reference>

        <reference anchor="SYN"
		   target="https://www.cisco.com/web/about/ac123/ac147/archived_issues/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>

    <section numbered="false">
      <name>Acknowledgments</name>
      <t>Thanks to Marc Krochmal and Kiren Sekar <contact fullname="Marc Krochmal"/> and <contact
      fullname="Kiren Sekar"/> for their work in 2006 on the precursor to this
      document.  Thanks also to Roger Pantos and Chris Sharp <contact fullname="Roger Pantos"/> and
      <contact fullname="Chris Sharp"/> for their contributions. Thanks to
      Chris Box, Esko Dijk, Jonathan Hui, Peter
      <contact fullname="Chris Box"/>, <contact fullname="Esko Dijk"/>,
      <contact fullname="Jonathan Hui"/>, <contact fullname="Peter van Dijk, Abtin Keshvarzian, Nathan Dyck, Steve
      Hanna, Gabriel Montenegro, Kangping Dong, and Tim Wicinski
      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 David Dong, Olafur Gudmundsson, Brian Trammel, and Shivan Sahib <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>
  </middle>

  <back>
<!-- This needLines directive is to keep the Authors' Addresses heading from being 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-hybrid"/> 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">
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1536.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2931.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8945.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnssd-srp.xml"/>
      <reference anchor="EDNS0Codes" target="https://www.iana.org/assignments/dns-parameters/dns-parameters.xml">
        <front>
          <title>DNS EDNS0 Option Codes (OPT)</title>
          <author/>
          <date month="April" year="2023"/>
        </front>
      </reference>
    </references>

  </back>

</rfc>