<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" submissionType="IETF" docName="draft-ietf-dnssd-update-lease-latest" number="9664" updates="" obsoletes="" ipr="trust200902" sortRefs="false" consensus="true" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en" prepTime="2025-06-11T16:09:34" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dnssd-update-lease-latest" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9664" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="DNS Update Lease">An EDNS(0) Option to Negotiate Leases on DNS Updates</title>
    <seriesInfo name="RFC" value="9664" stream="IETF"/>
    <author initials="S." surname="Cheshire" fullname="Stuart Cheshire">
      <organization showOnFrontPage="true">Apple Inc.</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino</city>
          <region>CA</region>
          <code>95014</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 408 974 3207</phone>
        <email>cheshire@apple.com</email>
      </address>
    </author>
    <author initials="T." surname="Lemon" fullname="Ted Lemon">
      <organization showOnFrontPage="true">Apple Inc.</organization>
      <address>
        <postal>
          <street>P.O. Box 958</street>
          <city>Brattleboro</city>
          <region>VT</region>
          <country>United States of America</country>
          <code>05302</code>
        </postal>
        <email>mellon@fugue.com</email>
      </address>
    </author>
    <date month="06" year="2025"/>
    <area>INT</area>
    <workgroup>dnssd</workgroup>
    <keyword>DNS Update</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document describes an EDNS(0) option that can be used between DNS
      Update Requesters and authoritative DNS servers to include a lifetime (lease duration) in a DNS
      Update or DNS Update Response, allowing a server to garbage collect stale Resource Records
      that have been added by DNS Updates if they are not renewed.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9664" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-and-terminology">Conventions and Terminology Used in This Document</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-mechanisms">Mechanisms</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-lease-update-request-and-re">Lease Update Request and Response Format</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-types-of-lease-update-reque">Types of Lease Update Requests</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requester-behavior">Requester Behavior</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-server-behavior">Server Behavior</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-refresh-requests">Refresh Requests</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-refresh-request-format">Refresh Request Format</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requester-behavior-2">Requester Behavior</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2.2.2">
                  <li pn="section-toc.1-1.5.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.5.2.2.2.1.1"><xref derivedContent="5.2.1" format="counter" sectionFormat="of" target="section-5.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-coalescing-refresh-requests">Coalescing Refresh Requests</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-server-behavior-2">Server Behavior</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retransmission-strategy">Retransmission Strategy</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-garbage-collection">Garbage Collection</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t indent="0" pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t indent="0" pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Dynamic Update in the Domain Name System (DNS Update) <xref target="RFC2136" format="default" sectionFormat="of" derivedContent="RFC2136"/> allows for a mapping from a persistent hostname to an
      IP address that changes over time. This capability is particularly
      beneficial to mobile hosts, whose IP addresses may frequently change
      with location. However, the mobile nature of such hosts often means that
      Resource Records (RRs) added using DNS Update are not properly
      deleted. For instance, consider a mobile user who publishes address RRs
      via DNS Update. If this user moves their laptop out of range of the
      Wi-Fi access point, the address RR containing stale information may
      remain on the authoritative DNS server indefinitely.  Thus, an extension
      to DNS Update is required to tell the server to automatically delete RRs
      after a period of time if they are not refreshed.</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-conventions-and-terminology">Conventions and Terminology Used in This Document</name>
      <t indent="0" pn="section-2-1">
    The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
      </t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-2.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <dl indent="3" newline="false" spacing="normal" pn="section-2.1-1">
          <dt pn="section-2.1-1.1">DNS-SD:</dt>
          <dd pn="section-2.1-1.2">DNS-based Service Discovery <xref target="RFC6763" format="default" sectionFormat="of" derivedContent="RFC6763"/></dd>
          <dt pn="section-2.1-1.3">EDNS(0):</dt>
          <dd pn="section-2.1-1.4">Extension Mechanisms for DNS <xref target="RFC6891" format="default" sectionFormat="of" derivedContent="RFC6891"/></dd>
          <dt pn="section-2.1-1.5">Update Lease option:</dt>
          <dd pn="section-2.1-1.6">Update Lease EDNS(0) option</dd>
          <dt pn="section-2.1-1.7">Lease:</dt>
          <dd pn="section-2.1-1.8">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 pn="section-2.1-1.9">Lease Duration:</dt>
          <dd pn="section-2.1-1.10">The time between the start and end of a lease</dd>
          <dt pn="section-2.1-1.11">Lease Update Request:</dt>
          <dd pn="section-2.1-1.12">DNS Update Request containing an Update Lease option</dd>
          <dt pn="section-2.1-1.13">Lease Update Response:</dt>
          <dd pn="section-2.1-1.14">DNS Update Response containing an Update Lease option</dd>
          <dt pn="section-2.1-1.15">RR:</dt>
          <dd pn="section-2.1-1.16">Resource Record</dd>
          <dt pn="section-2.1-1.17">Registration Request:</dt>
          <dd pn="section-2.1-1.18">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 pn="section-2.1-1.19">Registration:</dt>
          <dd pn="section-2.1-1.20">The result of a successful Registration Request</dd>
          <dt pn="section-2.1-1.21">Refresh Request:</dt>
          <dd pn="section-2.1-1.22">A Lease Update Request that extends the lease duration on an existing Registration</dd>
          <dt pn="section-2.1-1.23">Refresh:</dt>
          <dd pn="section-2.1-1.24">The result of a successful Refresh Request</dd>
        </dl>
      </section>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-mechanisms">Mechanisms</name>
      <t indent="0" pn="section-3-1">The Update Lease option is included in a standard DNS Update Request <xref target="RFC2136" format="default" sectionFormat="of" derivedContent="RFC2136"/> within an EDNS(0) OPT pseudo-RR <xref target="RFC6891" format="default" sectionFormat="of" derivedContent="RFC6891"/>.</t>
    </section>
    <section anchor="update" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-lease-update-request-and-re">Lease Update Request and Response Format</name>
      <t indent="0" pn="section-4-1">
      Lease Update Requests and Responses are formatted as standard DNS Update
      messages <xref target="RFC2136" format="default" sectionFormat="of" derivedContent="RFC2136"/>. Such messages <bcp14>MUST</bcp14>
      include the EDNS(0) OPT RR <xref target="RFC6891" format="default" sectionFormat="of" derivedContent="RFC6891"/>.  This OPT RR
      <bcp14>MUST</bcp14> include an Update Lease EDNS(0) Option as shown
      below:</t>
      <table anchor="lease_opt" align="center" pn="table-1">
        <name/>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Field Name</th>
            <th align="left" colspan="1" rowspan="1">Field Type</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">OPTION-CODE</td>
            <td align="left" colspan="1" rowspan="1">u_int16_t</td>
            <td align="left" colspan="1" rowspan="1">UPDATE-LEASE (2)</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">OPTION-LENGTH</td>
            <td align="left" colspan="1" rowspan="1">u_int16_t</td>
            <td align="left" colspan="1" rowspan="1">4 (LEASE) or 8 (LEASE + KEY-LEASE)</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">LEASE</td>
            <td align="left" colspan="1" rowspan="1">u_int32_t</td>
            <td align="left" colspan="1" rowspan="1">desired lease duration (Lease Update Request) or granted lease duration (Lease Update response), in seconds</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">KEY-LEASE</td>
            <td align="left" colspan="1" rowspan="1">u_int32_t</td>
            <td align="left" colspan="1" rowspan="1">optional desired (or granted) lease duration for KEY RRs, in seconds</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-4-3">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 durations granted by the
      server may be less than, greater than, or equal to the value
      requested by the Requester.</t>
      <t indent="0" pn="section-4-4">There are two variants of the Update Lease option:
      The 4-byte variant and the 8-byte variant.</t>
      <t indent="0" pn="section-4-5">In the 4-byte variant, the LEASE indicated in the
      Update Lease option applies to all RRs in the Update section.</t>
      <t indent="0" pn="section-4-6">In the 8-byte variant, the Update Lease communicates two lease durations.
      The LEASE indicated in the Update Lease option applies to all RRs in the
      Update section <em>except</em> for KEY RRs.  The KEY-LEASE indicated in the Update Lease
      option applies to KEY RRs in the Update section.</t>
      <t indent="0" pn="section-4-7">More information about how the two variants are used is given in
      <xref target="server-behavior" format="default" sectionFormat="of" derivedContent="Section 4.3"/>.</t>
      <t indent="0" pn="section-4-8">
	KEY RRs are given a special lease duration because these RRs are used
	in the DNS-SD Service Registration Protocol <xref target="RFC9665" format="default" sectionFormat="of" derivedContent="RFC9665"/> to reserve
	a name (or names) when the service is not present.
      </t>
      <t indent="0" pn="section-4-9">In the case of a KEY RR and some other RR, obviously the KEY lease duration applies to
      the KEY RR, and the lease duration applies to the other RR. If more than one RR that is not
      a KEY RR is added by the Lease Update Request, the lease duration (not the KEY lease duration) is applied to all such
      RRs. RRs that are removed are permanently removed.</t>
      <section anchor="update-refresh" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-types-of-lease-update-reque">Types of Lease Update Requests</name>
        <t indent="0" pn="section-4.1-1">This document describes two types of Lease Update Requests: Registrations and
	Refreshes. A Registration Request is a Lease Update Request that is intended to
	add information not already present on the authoritative DNS server. A Refresh Request is
	intended simply to renew the lease on a previous Registration without
	changing anything. Registrations and Refreshes are both Lease Update Requests, so the term
	"Lease Update Request" is used to specify behavior that is the same for both
	types of DNS Updates.</t>
        <t indent="0" pn="section-4.1-2">In some cases, it may be necessary to add new information without
	removing old information.  For the purpose of this document, such
	Lease Update Requests are Registrations, although in effect, they
	may also refresh whatever information is unchanged from a previous
	registration.</t>
      </section>
      <section anchor="requester" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-requester-behavior">Requester Behavior</name>
        <t indent="0" pn="section-4.2-1">DNS Update Requesters <bcp14>MUST</bcp14> send an Update Lease
	option with any DNS Update that updates RRs that are not intended to be present
	indefinitely. The Update Lease option <bcp14>SHOULD</bcp14> specify a
	lease duration that is no shorter than 1800 seconds (30
	minutes). Requesters <bcp14>MAY</bcp14> specify a shorter lease duration if
	they anticipate that the RRs being updated will change more frequently than
	every 30 minutes.  Requesters that expect the updated RRs to be
	relatively static <bcp14>SHOULD</bcp14> request appropriately longer
	lease durations.</t>
        <t indent="0" pn="section-4.2-2">If the DNS Response received by the Requester does not include an
	Update Lease option, this is an indication that the authoritative DNS server does
	not support the Update Lease option. In this case, the Requester
	<bcp14>SHOULD</bcp14> continue sending Refresh Requests (see below) as
	if the server had returned an identical Update Lease option in its
	Response.</t>
        <t indent="0" pn="section-4.2-3">If the DNS Response does include an Update Lease option, the
	Requester <bcp14>MUST</bcp14> use the durations returned in this
	option when determining when to send Refresh Requests. This is true
	both if the durations returned by the server are shorter and if they
	are longer.</t>
        <t indent="0" pn="section-4.2-4">When sending a Registration Request, the 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; since
	Refresh Requests include a random factor as well, any synchronization that
	occurs after such an event should quickly randomize.</t>
        <aside pn="section-4.2-5">
          <t indent="0" pn="section-4.2-5.1">The 10 ms granularity is a scheduling requirement intended to
	  result in an even spread of Requests so that every 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>
        </aside>
        <aside pn="section-4.2-6">
          <t indent="0" pn="section-4.2-6.1">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 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,
	  for example, 100 devices, and the random number generator spread is even, we would have
	  one renewal every 30 ms.  In practice, on relatively constrained devices acting as Service Registration Protocol (SRP)
	  servers, we are seeing the processing time for an SRP registration taking on the order
	  of 7 ms, so this seems reasonable.</t>
        </aside>
      </section>
      <section anchor="server-behavior" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-server-behavior">Server Behavior</name>
        <t indent="0" pn="section-4.3-1">Authoritative DNS servers implementing the Update Lease option
	<bcp14>MUST</bcp14> include an Update Lease option in response to any
	successful DNS Update (RCODE=0) that includes an Update Lease option.
	Servers <bcp14>MAY</bcp14> return lease durations different from those
	specified by the Requester,
	granting longer leases to reduce network traffic due to Refreshes
	or shorter leases to reduce the lifetime of stale data.</t>
        <t indent="0" pn="section-4.3-2">Although both the 4-byte and 8-byte variants are valid on
        both requesters and servers, older (pre-standard) requesters and servers may exist
        that support only the 4-byte variant. Therefore, requesters and servers
        that (as required by this specification) support both variants
        must account for the possibility that the peer with which they are communicating
        may be an older implementation that supports only the 4-byte variant.</t>
        <t indent="0" pn="section-4.3-3">A server that receives an 8-byte variant from a requester
	<bcp14>MUST</bcp14> respond with an 8-byte variant giving the granted lease times.</t>
        <t indent="0" pn="section-4.3-4">A server that receives a 4-byte variant from a requester
	<bcp14>MUST</bcp14> treat the 4-byte variant as
	specifying both the lease duration and the KEY lease duration
	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 indent="0" pn="section-4.3-5">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" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-refresh-requests">Refresh Requests</name>
      <t indent="0" pn="section-5-1">A Refresh Request is a DNS Update Request that is sent to the server after an initial
      DNS Update has been sent in order to prevent the update's RRs from being garbage
      collected.</t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-5.1">
        <name slugifiedName="name-refresh-request-format">Refresh Request Format</name>
        <t indent="0" pn="section-5.1-1">Refresh Requests and their corresponding responses are formatted
        like Update Lease Requests and Update Lease Responses (see <xref target="update" format="default" sectionFormat="of" derivedContent="Section 4"/>). The Refresh Request is
        constructed with the assumption that the previous Registration or
        Refresh is still in effect. In the case that the RRs added in a
        previous update were for some reason garbage collected (e.g., because
        of a server reboot that resulted in loss of state), the Refresh
        Request will result in those RRs being added again.</t>
        <t indent="0" pn="section-5.1-2">The Refresh Request <bcp14>SHOULD NOT</bcp14> include any DNS Update
	prerequisites that will fail if the Requester's previous Registration
	or Refresh is still in effect. It also <bcp14>SHOULD NOT</bcp14>
	include prerequisites that would fail if the RRs affected by the
	previous Registration or Refresh are no longer present; that is, the
	Refresh Request should also work as a Registration Request.  There may be cases where
	this is not possible; in which case, the response from the server can
	be used to determine how to proceed when the Refresh Request fails.</t>
        <t indent="0" pn="section-5.1-3">A Lease Update Request that changes the authoritative DNS server
	state resulting from a previous Refresh or Registration is a
	Registration Request, not a Refresh Request.</t>
        <t indent="0" pn="section-5.1-4">In a Refresh Request, the Update Lease option contains the desired
	new lease duration, and in the corresponding response, the Update
	Lease option contains the actual granted lease. The lease duration
	provided in LEASE in the Update Lease option applies to all RRs in the
	Update section of the Refresh Request, except that when the 8-byte
	Update Lease variant is sent, the duration specified in KEY-LEASE
	applies to any KEY RRs included in the Update section.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-5.2">
        <name slugifiedName="name-requester-behavior-2">Requester Behavior</name>
        <t indent="0" pn="section-5.2-1">A Requester that intends for its RRs from a previous Registration or Refresh to remain active <bcp14>MUST</bcp14>
	send a Refresh Request before the lease expires; otherwise, the RRs
	will be removed by the server.</t>
        <t indent="0" pn="section-5.2-2">In order to prevent Registrations expiring, Requesters
	<bcp14>MUST</bcp14> refresh them. When
	a Lease Update Request succeeds, the requester computes a time limit that is 80%
	of the lease duration plus a random offset between 0% and 5% of the lease
	duration. The random offset is to prevent refreshes from being
	synchronized. When this time limit has expired, the requester
	<bcp14>MUST</bcp14> send a Refresh Request if the data in the initial
	Registration should continue to be advertised.</t>
        <t indent="0" pn="section-5.2-3">For Refresh Requests, the server is expected to return an Update
	Lease option, if supported, just as with the initial Registration Request. As
	with the Registration Request, the Requester <bcp14>MUST</bcp14> use the
	durations returned by the server in the Lease Update Response when determining when to send the
	next Refresh Request.</t>
        <t indent="0" pn="section-5.2-4">When sending Refresh Requests, the Requester <bcp14>MUST</bcp14>
	include an Update Lease option, as it did in the initial Registration
	Request. The Update Lease option <bcp14>MAY</bcp14> either specify the
	same durations as in the initial Registration Request or use the
	values returned by the server in the previous Lease Update Response or
	other desired values as appropriate.  As with responses to
	Registration Requests, the Requester <bcp14>MUST</bcp14> use the lease
	durations returned by the server in the response when determining when
	to send the next Refresh Request.</t>
        <t indent="0" pn="section-5.2-5">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" format="default" sectionFormat="of" derivedContent="Section 6"/>.</t>
        <section numbered="true" removeInRFC="false" toc="include" pn="section-5.2.1">
          <name slugifiedName="name-coalescing-refresh-requests">Coalescing Refresh Requests</name>
          <t indent="0" pn="section-5.2.1-1">If the Requester has performed multiple Registrations with a single 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
          Refresh Request. This effectively places all RRs for a Requester on the same expiration
          schedule, reducing network traffic due to Refreshes.</t>
          <t indent="0" pn="section-5.2.1-2">In doing so, the Requester includes in the Refresh Request all existing RRs previously successfully registered on
	  the server, including those not yet close to expiration, so long as at least one
	  RR updated in the Refresh Request has elapsed at least 75% of its original lease duration. If the
	  Requester uses UDP, the Requester <bcp14>MUST NOT</bcp14> coalesce Refresh Requests if doing so would
	  cause truncation of the Request; in this case, the Requester either sends multiple
	  Requests or uses TCP to send the complete Refresh Request at once.</t>
          <t indent="0" pn="section-5.2.1-3">Requesters <bcp14>SHOULD NOT</bcp14> send a Refresh Request when all of the RRs in the
	  Refresh Request would have more than 50% of their lease duration remaining before expiry. However,
	  there may be cases where the Requester needs to send an early Refresh Request, and it <bcp14>MAY</bcp14> do
	  so. For example, a power-constrained (sleepy) device may need to send a Refresh Request when the radio
	  is powered so as to avoid having to power it up later.</t>
          <t indent="0" pn="section-5.2.1-4">Another case where this may be needed is when the lease duration registered with the
	  server is no longer appropriate and the Requester wishes to negotiate a different
	  lease duration. However, in this case, if the server does not honor the requested
	  lease duration in its response, the Requester <bcp14>MUST NOT</bcp14> retry this negotiation.</t>
        </section>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-5.3">
        <name slugifiedName="name-server-behavior-2">Server Behavior</name>
        <t indent="0" pn="section-5.3-1">Upon receiving a valid Refresh Request, the server <bcp14>MUST</bcp14> send an acknowledgment. This
        acknowledgment is a Lease Update Response as described in <xref target="update" format="default" sectionFormat="of" derivedContent="Section 4"/> and contains the new lease duration of the Registration
        being Refreshed.  The server <bcp14>MUST NOT</bcp14> increment the serial number of a zone
        as the result of a Refresh Request if the operation does not result in any change to the zone contents.</t>
        <t indent="0" pn="section-5.3-2">However, the server's state may not match what the requester expects.  In this case, a
	Refresh Request may actually appear to be a Registration Request, from the server's perspective. If the
	Refresh Request changes the contents of the zone, the server <bcp14>MUST</bcp14> update the zone serial
	number.</t>
      </section>
    </section>
    <section anchor="retransmission" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-retransmission-strategy">Retransmission Strategy</name>
      <t indent="0" pn="section-6-1">The DNS protocol, including DNS updates, can operate over UDP or TCP. For communication using UDP, reliable
      transmission must be guaranteed by retransmitting when a DNS UDP message is not acknowledged in a
      reasonable amount of time.
      Section <xref target="RFC1035" section="4.2.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc1035#section-4.2.1" derivedContent="RFC1035"/>
      of the DNS specification <xref target="RFC1035" format="default" sectionFormat="of" derivedContent="RFC1035"/>
      provides some guidance on this topic, as does
      Section <xref target="RFC1536" section="1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc1536#section-1" derivedContent="RFC1536"/>
      of the IETF's guide to common DNS implementation errors <xref target="RFC1536" format="default" sectionFormat="of" derivedContent="RFC1536"/>.
      Section <xref target="RFC8085" section="3.1.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8085#section-3.1.3" derivedContent="RFC8085"/>
      of the UDP Usage Guidelines <xref target="RFC8085" format="default" sectionFormat="of" derivedContent="RFC8085"/>
      also provides useful guidance that is particularly relevant to DNS.</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-garbage-collection">Garbage Collection</name>
      <t indent="0" pn="section-7-1">If the lease duration of an RR elapses without being refreshed, the authoritative DNS server
      <bcp14>MUST NOT</bcp14> return that RR in answers to queries. The server <bcp14>MAY</bcp14> delete that RR
      from its database. The lease durations returned by the server to the Requester are used
      in determining when the lease on an RR has expired.</t>
      <t indent="0" pn="section-7-2">For all RRs other than a KEY RR included in a Lease Update Request, the
      lease duration is the LEASE value in the Update Lease option. For KEY RRs, if the
      optional KEY-LEASE value was included, this duration is used rather than the duration
      specified in the LEASE. If the KEY-LEASE was not specified, the duration specified in the LEASE is
      used for all RRs in the Lease Update Request.
      </t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">Section <xref target="RFC2136" section="8" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2136#section-8" derivedContent="RFC2136"/> of
      the DNS Update specification <xref target="RFC2136" format="default" sectionFormat="of" derivedContent="RFC2136"/> describes problems that can occur
      around DNS updates.  Servers implementing this specification should follow these recommendations.</t>
      <t indent="0" pn="section-8-2">Several additional issues can arise when relying on the Update Lease option.</t>
      <t indent="0" pn="section-8-3">First, a
      too-long lease duration is not much different from no lease duration: the RRs associated with
      such a Registration will effectively never be cleaned up. Servers implementing Update Lease
      should have a default upper bound on the maximum acceptable value both for the LEASE and
      KEY-LEASE values sent by the requester.
      Default values for these limits of 24 hours and 7 days, respectively,
      are <bcp14>RECOMMENDED</bcp14>.
      Servers <bcp14>MAY</bcp14> provide a way for the operator to change this upper limit.</t>
      <t indent="0" pn="section-8-4">The second issue is that a too-short lease can result in increased server load as
      Requesters rapidly renew such Registrations. A delay in renewing could result in the registered RRs being
      removed prematurely.  Servers implementing Update Lease <bcp14>MUST</bcp14> have a default minimum lease
      duration that avoids this issue.  A minimum of 30 seconds for both the LEASE
      and KEY-LEASE durations is <bcp14>RECOMMENDED</bcp14>.
      However, in most cases, much longer lease durations (for example, an hour)
      <bcp14>SHOULD</bcp14> be used.
      Servers <bcp14>MAY</bcp14> provide a way for the operator to change this lower limit.</t>
      <t indent="0" pn="section-8-5">There may be some cost associated with renewing leases. A malicious
      (or buggy) 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 an authoritative server handling normal (no-lease) DNS Updates as well.
      Servers should follow established
      industry best practices to guard against flooding attacks,
      both for malicious flooding of DNS messages over UDP
      and for similar flooding attacks using TCP
      <xref target="SYN" format="default" sectionFormat="of" derivedContent="SYN"/> <xref target="RFC4953" format="default" sectionFormat="of" derivedContent="RFC4953"/>.</t>
      <t indent="0" pn="section-8-6">Some authentication strategy should be used when accepting DNS
      updates.  Shared secret <xref target="RFC8945" format="default" sectionFormat="of" derivedContent="RFC8945"/> or public key signing
      (e.g., SIG(0) <xref target="RFC2931" format="default" sectionFormat="of" derivedContent="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.
      Service Registration Protocol <xref target="RFC9665" format="default" sectionFormat="of" derivedContent="RFC9665"/>
      uses DNS Update Leases with "First Come, First Served Naming" rather
      than an explicit trust establishment process to confer update
      permission to a set of RRs.</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">IANA has updated the "DNS EDNS0 Option Codes (OPT)" registry <xref target="EDNS0Reg" format="default" sectionFormat="of" derivedContent="EDNS0Reg"/> as regards value 2 as follows:</t>
      <dl newline="false" spacing="compact" indent="3" pn="section-9-2">
        <dt pn="section-9-2.1">Value:</dt>
        <dd pn="section-9-2.2">2</dd>
        <dt pn="section-9-2.3">Name:</dt>
        <dd pn="section-9-2.4">Update Lease</dd>
        <dt pn="section-9-2.5">Status:</dt>
        <dd pn="section-9-2.6">Standard</dd>
        <dt pn="section-9-2.7">Reference:</dt>
        <dd pn="section-9-2.8">RFC 9664</dd>
      </dl>
    </section>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035" quoteTitle="true" derivedAnchor="RFC1035">
          <front>
            <title>Domain names - implementation and specification</title>
            <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
            <date month="November" year="1987"/>
            <abstract>
              <t indent="0">This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="13"/>
          <seriesInfo name="RFC" value="1035"/>
          <seriesInfo name="DOI" value="10.17487/RFC1035"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC2136" target="https://www.rfc-editor.org/info/rfc2136" quoteTitle="true" derivedAnchor="RFC2136">
          <front>
            <title>Dynamic Updates in the Domain Name System (DNS UPDATE)</title>
            <author fullname="P. Vixie" initials="P." role="editor" surname="Vixie"/>
            <author fullname="S. Thomson" initials="S." surname="Thomson"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="J. Bound" initials="J." surname="Bound"/>
            <date month="April" year="1997"/>
            <abstract>
              <t indent="0">Using this specification of the UPDATE opcode, it is possible to add or delete RRs or RRsets from a specified zone. Prerequisites are specified separately from update operations, and can specify a dependency upon either the previous existence or nonexistence of an RRset, or the existence of a single RR. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2136"/>
          <seriesInfo name="DOI" value="10.17487/RFC2136"/>
        </reference>
        <reference anchor="RFC6891" target="https://www.rfc-editor.org/info/rfc6891" quoteTitle="true" derivedAnchor="RFC6891">
          <front>
            <title>Extension Mechanisms for DNS (EDNS(0))</title>
            <author fullname="J. Damas" initials="J." surname="Damas"/>
            <author fullname="M. Graff" initials="M." surname="Graff"/>
            <author fullname="P. Vixie" initials="P." surname="Vixie"/>
            <date month="April" year="2013"/>
            <abstract>
              <t indent="0">The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.</t>
              <t indent="0">This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="75"/>
          <seriesInfo name="RFC" value="6891"/>
          <seriesInfo name="DOI" value="10.17487/RFC6891"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC1536" target="https://www.rfc-editor.org/info/rfc1536" quoteTitle="true" derivedAnchor="RFC1536">
          <front>
            <title>Common DNS Implementation Errors and Suggested Fixes</title>
            <author fullname="A. Kumar" initials="A." surname="Kumar"/>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <author fullname="C. Neuman" initials="C." surname="Neuman"/>
            <author fullname="P. Danzig" initials="P." surname="Danzig"/>
            <author fullname="S. Miller" initials="S." surname="Miller"/>
            <date month="October" year="1993"/>
            <abstract>
              <t indent="0">This memo describes common errors seen in DNS implementations and suggests some fixes. This memo provides information for the Internet community. It does not specify an Internet standard.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1536"/>
          <seriesInfo name="DOI" value="10.17487/RFC1536"/>
        </reference>
        <reference anchor="RFC2931" target="https://www.rfc-editor.org/info/rfc2931" quoteTitle="true" derivedAnchor="RFC2931">
          <front>
            <title>DNS Request and Transaction Signatures ( SIG(0)s )</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <date month="September" year="2000"/>
            <abstract>
              <t indent="0">This document describes the minor but non-interoperable changes in Request and Transaction signature resource records ( SIG(0)s ) that implementation experience has deemed necessary. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2931"/>
          <seriesInfo name="DOI" value="10.17487/RFC2931"/>
        </reference>
        <reference anchor="RFC4953" target="https://www.rfc-editor.org/info/rfc4953" quoteTitle="true" derivedAnchor="RFC4953">
          <front>
            <title>Defending TCP Against Spoofing Attacks</title>
            <author fullname="J. Touch" initials="J." surname="Touch"/>
            <date month="July" year="2007"/>
            <abstract>
              <t indent="0">Recent analysis of potential attacks on core Internet infrastructure indicates an increased vulnerability of TCP connections to spurious resets (RSTs), sent with forged IP source addresses (spoofing). TCP has always been susceptible to such RST spoofing attacks, which were indirectly protected by checking that the RST sequence number was inside the current receive window, as well as via the obfuscation of TCP endpoint and port numbers. For pairs of well-known endpoints often over predictable port pairs, such as BGP or between web servers and well-known large-scale caches, increases in the path bandwidth-delay product of a connection have sufficiently increased the receive window space that off-path third parties can brute-force generate a viable RST sequence number. The susceptibility to attack increases with the square of the bandwidth, and thus presents a significant vulnerability for recent high-speed networks. This document addresses this vulnerability, discussing proposed solutions at the transport level and their inherent challenges, as well as existing network level solutions and the feasibility of their deployment. This document focuses on vulnerabilities due to spoofed TCP segments, and includes a discussion of related ICMP spoofing attacks on TCP connections. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4953"/>
          <seriesInfo name="DOI" value="10.17487/RFC4953"/>
        </reference>
        <reference anchor="RFC6763" target="https://www.rfc-editor.org/info/rfc6763" quoteTitle="true" derivedAnchor="RFC6763">
          <front>
            <title>DNS-Based Service Discovery</title>
            <author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
            <author fullname="M. Krochmal" initials="M." surname="Krochmal"/>
            <date month="February" year="2013"/>
            <abstract>
              <t indent="0">This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6763"/>
          <seriesInfo name="DOI" value="10.17487/RFC6763"/>
        </reference>
        <reference anchor="RFC8085" target="https://www.rfc-editor.org/info/rfc8085" quoteTitle="true" derivedAnchor="RFC8085">
          <front>
            <title>UDP Usage Guidelines</title>
            <author fullname="L. Eggert" initials="L." surname="Eggert"/>
            <author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
            <author fullname="G. Shepherd" initials="G." surname="Shepherd"/>
            <date month="March" year="2017"/>
            <abstract>
              <t indent="0">The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t>
              <t indent="0">Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.</t>
              <t indent="0">Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.</t>
              <t indent="0">This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="145"/>
          <seriesInfo name="RFC" value="8085"/>
          <seriesInfo name="DOI" value="10.17487/RFC8085"/>
        </reference>
        <reference anchor="RFC8945" target="https://www.rfc-editor.org/info/rfc8945" quoteTitle="true" derivedAnchor="RFC8945">
          <front>
            <title>Secret Key Transaction Authentication for DNS (TSIG)</title>
            <author fullname="F. Dupont" initials="F." surname="Dupont"/>
            <author fullname="S. Morris" initials="S." surname="Morris"/>
            <author fullname="P. Vixie" initials="P." surname="Vixie"/>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/>
            <author fullname="O. Gudmundsson" initials="O." surname="Gudmundsson"/>
            <author fullname="B. Wellington" initials="B." surname="Wellington"/>
            <date month="November" year="2020"/>
            <abstract>
              <t indent="0">This document describes a protocol for transaction-level authentication using shared secrets and one-way hashing. It can be used to authenticate dynamic updates to a DNS zone as coming from an approved client or to authenticate responses as coming from an approved name server.</t>
              <t indent="0">No recommendation is made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out-of-band mechanism.</t>
              <t indent="0">This document obsoletes RFCs 2845 and 4635.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="93"/>
          <seriesInfo name="RFC" value="8945"/>
          <seriesInfo name="DOI" value="10.17487/RFC8945"/>
        </reference>
        <reference anchor="RFC9665" target="https://www.rfc-editor.org/info/rfc9665" quoteTitle="true" derivedAnchor="RFC9665">
          <front>
            <title>Service Registration Protocol for DNS-Based Service Discovery</title>
            <author fullname="Ted Lemon" initials="T." surname="Lemon">
              <organization showOnFrontPage="true">Apple Inc.</organization>
            </author>
            <author fullname="Stuart Cheshire" initials="S." surname="Cheshire">
              <organization showOnFrontPage="true">Apple Inc.</organization>
            </author>
            <date month="June" year="2025"/>
          </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" quoteTitle="true" derivedAnchor="EDNS0Reg">
          <front>
            <title>DNS EDNS0 Option Codes (OPT)</title>
            <author>
              <organization showOnFrontPage="true">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" quoteTitle="true" derivedAnchor="SYN">
          <front>
            <title>Defenses Against TCP SYN Flooding Attacks</title>
            <author initials="W." surname="Eddy" fullname="Wesley Eddy">
              <organization showOnFrontPage="true">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" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">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>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="S." surname="Cheshire" fullname="Stuart Cheshire">
        <organization showOnFrontPage="true">Apple Inc.</organization>
        <address>
          <postal>
            <street>One Apple Park Way</street>
            <city>Cupertino</city>
            <region>CA</region>
            <code>95014</code>
            <country>United States of America</country>
          </postal>
          <phone>+1 408 974 3207</phone>
          <email>cheshire@apple.com</email>
        </address>
      </author>
      <author initials="T." surname="Lemon" fullname="Ted Lemon">
        <organization showOnFrontPage="true">Apple Inc.</organization>
        <address>
          <postal>
            <street>P.O. Box 958</street>
            <city>Brattleboro</city>
            <region>VT</region>
            <country>United States of America</country>
            <code>05302</code>
          </postal>
          <email>mellon@fugue.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
