<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629-xhtml.ent">[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="IETF" docName="draft-ietf-dnssd-update-lease-08" 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 UpdateLeases'> AnLeases'>An EDNS(0)optionOption tonegotiateNegotiate Leases on DNSUpdates </title>Updates</title> <seriesInfo name="RFC" value="9664"/> <authorinitials='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> <authorinitials="T"initials="T." surname="Lemon" fullname="Ted Lemon"> <organization>AppleInc</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 anEDNS(0)Extension Mechanisms for DNS (EDNS(0)) option that can be used by DNS Update requestors and DNS servers to include a lease lifetime in a DNS Update or response, allowing a server to garbage collect stale resource records that have been added by DNSUpdates</t>Updates.</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<t>A Dynamic DNS Update <xref target="RFC2136"/> allows for a mapping from a persistent hostname to a dynamic IP address. This capability is particularly beneficial to mobile hosts, whose IP address may frequently change with location. However, the mobile nature of such hosts often means that dynamically updated resource records are not properly deleted.Consider, forFor instance, consider a mobile user who publishes address records via dynamic update. If this user moves their laptop out of range of the Wi-Fi access point, the address record containing stale information may remain on the server indefinitely.AnThus, an extension to Dynamic Update isthusrequired to tell the server to automatically delete resource records if they are not refreshed after a period of time.</t> </section> <section> <name>Conventions and Terminology Used inthisThis 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 inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> <section> <name>Abbreviations</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 forDNS, version 0DNS <xref target="RFC6891"/></dd> </dl> </section> </section> <section> <name>Mechanisms</name> <t>The EDNS(0) Update Lease option is included in a standard DNS Update message <xref target="RFC2136"/> within an EDNS(0) OPT pseudo-RR <xref target="RFC6891"/>.</t> </section> <section anchor="update"> <name>Update Message Format</name> <!--[rfced] We had two related questions about these sentences: a) We were unsure if some singular/plural changes should be made with regard to "Leases". See suggested text below. b) Should the use of "DNS" be made uniform? That is, "Dynamic DNS Update Leases Requests and Responses" or "Dynamic Update Leases Requests and Responses"? Original 1: Dynamic DNS Update Leases Requests and Responses are formatted as standard DNS Dynamic Update messages [RFC2136]. This update MUST include the EDNS(0) OPT RR, as described in [RFC6891]. Perhaps ("Leases" becomes "Lease" and "This update" becomes "These updates"): Dynamic DNS Update Lease Requests and Responses are formatted as standard DNS Dynamic Update messages [RFC2136]. These updates MUST include the EDNS(0) OPT RR, as described in [RFC6891]. or perhaps ("Leases" becomes "Lease" and "These updates" becomes "This new format"): Dynamic DNS Update Lease Requests and Responses are formatted as standard DNS Dynamic Update messages [RFC2136]. This new format MUST include the EDNS(0) OPT RR, as described in [RFC6891]. Original 2: Refresh messages are formatted like Dynamic Update Leases Requests and Responses... Perhaps ("Leases" becomes "Lease"): Refresh messages are formatted like Dynamic Update Lease Requests and Responses... --> <t> Dynamic DNS Update Leases Requests and Responses are formatted as standard DNS Dynamic Update messages <xref target="RFC2136"/>. This updateMUST<bcp14>MUST</bcp14> include the EDNS(0) OPT RR, as described in <xref target="RFC6891"/>. This OPT RRMUST<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 or8 LEASE u_int32_t desired8</td> </tr> <tr> <td>LEASE</td> <td>u_int32_t</td> <td>desired lease (request) or granted lease (response), inseconds KEY-LEASE u_int32_t optionalseconds</td> </tr> <tr> <td>KEY-LEASE</td> <td>u_int32_t</td> <td>optional desired (or granted) lease for KEY records, inseconds ]]></artwork></figure>seconds</td> </tr> </tbody> </table> <t>Update Requests contain, in the LEASE field of the OPT RDATA, an unsigned 32-bit integer indicating the lease lifetime, in seconds, desired by the requestor, represented in network (big-endian) byte order. In Update Responses, this field contains the actual lease granted by the server. The lease granted by the server may be less than, greater than, or equal to the value requested by the requestor.</t> <t>There are two variants of the EDNS(0) UPDATE-LEASEoption,option: the basic (4-byte) variant and the extended (8-byte) variant.</t> <t>In the basic (4-byte) variant, the LEASE indicated in the Update Lease option applies to all resource records in the Update section.</t> <t>In the extended (8-byte) variant, the Update Lease communicates two lease lifetimes. The LEASE indicated in the Update Lease option applies to all resource records in the Update section*except*<em>except</em> for KEY records. The KEY-LEASE indicated in the Update Lease option applies to KEY records in the Update section.</t> <t>Thereason theKEY record can be given a special lease timeis thatbecause this record is used in the DNS-SD Service Registration Protocol <xreftarget="I-D.ietf-dnssd-srp"/>target="RFC9665"/> to reserve a name (or names) when the service is not present.</t> <t>In the case of a KEY record and some other record, obviously the KEY LEASE applies to the key, and the LEASE applies to the other record. If more than one record that is not a KEY record is added by the update, the LEASE (not the KEY LEASE) is applied to all such records. Records that are removed are permanently removed.</t> <section anchor="update-refresh"> <name>Types of DNS Update Requestmessages</name>Messages</name> <t>This document describes two types of updates: Registrations and Refreshes. A Registration is a DNS Update Request that is intended to add information not already present on the DNS server. A Refresh is intended simply to renew the lease on a previous Registration without changing anything. Both messages are DNS Update messages, so the term "DNS Update message" is to specify behavior that is the same for both types of DNS Updatemessage.</t>messages.</t> <t>In somecasescases, it may be necessary to add new information without removing old information. For the purpose of this document, such messages arereferred to asRegistrations, although ineffecteffect, they may also refresh whatever information is unchanged from a previous registration.</t> </section> <section anchor="requestor"> <name>Requestor Behavior</name> <t>DNS Update requestorsMUST<bcp14>MUST</bcp14> send an Update Lease option with any DNS Update that is not intended to be present indefinitely. The Update Lease optionSHOULD<bcp14>SHOULD</bcp14> specify a time interval that is no shorter than 1800 seconds (30 minutes). RequestorsMAY<bcp14>MAY</bcp14> specify a shorter lease if they anticipate that the records being updated will changesoonerin less than 30 minutes. Requestors that expect the updated records to be relatively staticSHOULD<bcp14>SHOULD</bcp14> request appropriately longer leases.</t> <t>If the DNS response received by the requestor does not include an Update Lease option, this is an indication that the DNS server does not support the Update Lease option.The requestor SHOULD inIn thiscasecase, the requestor <bcp14>SHOULD</bcp14> continue sending Refresh messages (see below) as if the server had returned an identical update lease option in its response.</t> <t>If the DNS response does include an Update Lease option, the requestorMUST<bcp14>MUST</bcp14> use theinterval(s)interval or intervals returned in this option when determining when to send Refresh messages. This is true both if theinterval(s)interval or intervals returned by the server are shorter and if they are longer.</t> <t>When sending a Registration, the requestorMUST<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 onstartup:startup; since Refreshes include a random factor as well, any synchronization that occurs after such an event should quickly randomize.</t> <t>Note: therequirement for 10ms10 ms granularity is a scheduling requirement intended to result in an even spread ofrequests,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> <t>Note: thereason for the 3000ms (three second)use of a 3000 ms (3-second) random interval as opposed to some other random interval is to allow for enough time to meaningfully spread the load when many devices renew at once, without delaying so long that the delay in discovery of devices becomes obvious to an end user. A 3-second random delay means that if thereareare, forexampleexample, 100 devices, and the random number generator spread is even, we would have one renewal every30ms.30 ms. In practice, on relatively constrained devices acting asSRPService Registration Protocol (SRP) servers, we are seeing the processing time for an SRP registration taking on the order of7ms,7 ms, so this seems reasonable.</t> </section> <section> <name>Server Behavior</name><t>DNS<!--[rfced] Might the following update be less redundant than the original? Original: DNS Servers implementing the Update Lease option MUST include an Update Lease option in response to any successful DNS Update (RCODE=0) that includes an Update Lease option. Perhaps: DNS servers MUST include an Update Lease option in response to any successful DNS Update (RCODE=0) that also includes one. --> <t>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. ServersMAY<bcp14>MAY</bcp14> return a different leaseinterval(s)interval or intervals than specified by the requestor, granting relatively longer or shorter leases to reduce network traffic due toRefreshes,Refreshes or to reduce stale data, respectively.</t> <t>Note that both the 4-byte and 8-byte variant are valid on both clients and servers, but clients and servers may exist that do not support the newer 8-byte variant. Therefore, clients and servers that do support this variant must account for the possibility that the server with which they are communicating does not.</t> <t>A client that receives a 4-byte variant from a server when it sent an 8-byte variantMUST<bcp14>MUST</bcp14> treat the 4-byte variant as specifying both the lease time and the key lease time. A server that supports the 8-byte variantMUST<bcp14>MUST</bcp14> treat the 4-byte variant as specifying both the lease time and the key lease time. When a server receives a 4-byte variant, itMUST<bcp14>MUST</bcp14> respond with a 4-byte variant. In thiscasecase, the key and the other records expire at the same time.</t> </section> </section> <section anchor="refresh"> <name>Refresh Messages</name> <t>A Refresh message is a DNS Update message that is sent to the server after an initial DNS Update has beensent,sent in order to prevent the update's records from being garbage collected.</t> <section> <name>Refresh Message Format</name> <t>Refresh messages are formatted like Dynamic Update Leases Requests and Responses (see <xreftarget="update"/> "Update Message Format").target="update" format="default"/>). The Refresh message is constructed with the assumption that the result of the previous Registration or Refresh is still in effect.The Refresh message will, inIn the case that the records added in a previous update were for some reason garbage collected, the Refresh message will result in those records being added again.</t> <t>The Refresh messageSHOULD NOT<bcp14>SHOULD NOT</bcp14> include any update prerequisites that would fail if the requestor's previous Registration or Refresh is still in effect. It alsoSHOULD NOT<bcp14>SHOULD NOT</bcp14> include prerequisites that would fail if the records affected by the previous Registration or Refresh are no longerpresent--thatpresent; that is, the Refresh should also work as a Registration. There may be cases where this is notpossible,possible; in whichcasecase, the response from the server can be used to determine how to proceed when the Refresh fails.</t> <t>An update message that changes the server state resulting from a previous Refresh or Registration is a Registration, not a Refresh.</t> <t>The Update Lease option in a Refresh message contains the desired new lease for Requests, and the actual granted lease for Responses. The LEASE interval indicated in the Update Lease option applies to all resource records in the Update section of the Refresh request, except that if a KEY-LEASE interval is included as well, that interval applies to any KEY records included in the Update section.</t> </section> <section> <name>Requestor Behavior</name> <t>A requestor that intendsthatfor its records from a previousupdate, whether aRegistration ora Refresh,Refresh to remainactive, MUSTactive <bcp14>MUST</bcp14> send a Refresh message before the leaseelapses, or elseelapses; otherwise, the records will be removed by the server.</t><t>In<!--[rfced] May we update this text as follows to reduce redundancy? Original: In order to prevent records expiring, requestors MUST refresh resource records before they expire. Perhaps: In order to prevent records expiring, requestors MUST refresh them. --> <t>In order to prevent records expiring, requestors <bcp14>MUST</bcp14> refresh resource records before they expire. At the time of registration, the client computes an interval that is 80% of the lease time plus a random offset between00% and 5% of the lease time. The random offset is to prevent refreshes from being synchronized. When this interval has expired, the clientMUST<bcp14>MUST</bcp14> refresh the message if the data in the initial Registration should continue to be advertised.</t> <t>For Refresh messages, the server is expected to return an Update Lease option, if supported, just as with the initial Registration. As with the Registration, the requestorMUST<bcp14>MUST</bcp14> use theinterval(s)intervals specified by the server when determining when to send the next Refresh message.</t> <t>When sending Refresh messages, the requestorMUST<bcp14>MUST</bcp14> include an Update Lease option, as it did for the initial Registration. The Update Lease optionMAY<bcp14>MAY</bcp14> either specify the same intervals as in the initialRegistration,Registration orMAYuse the values returned by the server in the previous Update Response, whether it was a response to a Registration or a Refresh. As with responses to Registrations, the requestorMUST<bcp14>MUST</bcp14> use the interval or intervals returned by the server in the response when determining when to send the next Refresh message.</t> <section> <name>Coalescing Refresh Messages</name> <t>If the requestor has performed multiple successful Registrations with a single server, the requestorMAY<bcp14>MAY</bcp14> include Refreshes for all such Registrations to that server in a single message. This effectively places all records for a requestor on the same expiration schedule, reducing network traffic due to Refreshes.</t> <t>In doing so, the requestor includes in the Refresh message all existing updates to the server, including those not yet close to expiration, so long as at least one resource record in the message has elapsed at least 75% of its original lease. If the requestor uses UDP, the requestorMUST NOT<bcp14>MUST NOT</bcp14> coalesce Refresh messages if doing so would cause truncation of the message; in this case, the requestor should either send multiple messages orshoulduse TCP to send the entire update at once.</t> <t>RequestorsSHOULD NOT<bcp14>SHOULD NOT</bcp14> sendaRefresh messages when all of the records in the Refresh have more than 50% of their lease interval remaining before expiry. However, there may be cases where the requestor needs to send an early Refresh, and itMAY<bcp14>MAY</bcp14> do so. For example, a power-constrained (sleepy) device may need to send an update 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 the lease interval registered with the server is no longer appropriate and the Requestor wishes to negotiate a different lease interval. However, in this case, if the server does not honor the requested interval in its response, the requestorMUST NOT<bcp14>MUST NOT</bcp14> retry this negotiation.</t> </section> </section> <section> <name>Server Behavior</name> <t>Upon receiving a valid Refresh Request, the serverMUST<bcp14>MUST</bcp14> send an acknowledgment. This acknowledgment is identical to the Update Response format described in <xref target="update"/>"Update Message Format",and contains the new lease of the resource records being Refreshed. The serverMUST NOT<bcp14>MUST NOT</bcp14> increment the serial number of a zone as the result of a Refresh.</t> <t>However, the server's state may not match what the client expects. In this case, a Refresh may actually appear to be a Registration, from the server's perspective. If the Refresh changes the contents of the zone, the serverMUST<bcp14>MUST</bcp14> update the zone serial number.</t> </section> </section> <section> <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. <xref target="RFC1035" section="4.2.1" sectionFormat="of"/> provides some guidance on this topic, as does <xref target="RFC1536" section="1" sectionFormat="of"/>. <xref target="RFC8085" section="3.1.3" sectionFormat="of"/> also provides useful guidance that is particularly relevant to DNS.</t> </section> <section> <name>Garbage Collection</name> <t>If the Update Lease of a resource record elapses without being refreshed, the serverMUST NOT<bcp14>MUST NOT</bcp14> return the expired record in answers to queries. The serverMAY<bcp14>MAY</bcp14> delete the record from its database. The leaseinterval(s)interval or intervals returned by the server to the requestor are used in determining when the lease on a resource record has expired.</t> <t>For all resource records other than a KEY record included in a DNS Update request, the Update Lease is the LEASE value in the Update Lease option. For KEY records, if the optional KEY-LEASE value was included, this interval is used rather than the interval specified in the LEASE. If the KEY-LEASE was not specified, the interval specified in the LEASE is used. </t> </section><section title="Security Considerations"><section> <name>Security Considerations</name> <t><xref target="RFC2136" section="8" sectionFormat="of"/> 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, a too-long lease time is not much different than no lease time: the records associated with this lease time will effectively never be cleaned up. Servers implementing the 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. ServersMAY<bcp14>MAY</bcp14> provide a way for the operator to change this upper limit. Default values for these limits of 24 hours and 7 days, respectively, areRECOMMENDED.</t><bcp14>RECOMMENDED</bcp14>.</t> <t>The second issue is that a too-short lease can result in increased server load as requestors rapidly renew the lease. A delay in renewing could result in the data being removed prematurely. Servers implementing Update LeaseMUST<bcp14>MUST</bcp14> have a default minimum lease interval that avoids this issue. <!-- [rfced] We suggest the following update as BCP 14 uses "RECOMMENDED" (with the -ed ending). Please let us know any objections. Current: We RECOMMEND a minimum of 30 seconds for both the LEASE and KEY-LEASE intervals. Perhaps: A minimum of 30 seconds for both the LEASE and KEY-LEASE intervals is RECOMMENDED. --> We RECOMMEND a minimum of 30 seconds for both the LEASE and KEY-LEASE intervals. However, in most cases, much longer lease times (for example, an hour) areRECOMMENDED.</t><bcp14>RECOMMENDED</bcp14>.</t> <t>There may be some cost associated with renewing leases. A malicious (or buggy) client could renew at a high rate in order to overload the server more than it would be overloaded by query traffic. This risk is present for a regular DNS update as well. The serverMUST<bcp14>MUST</bcp14> enforce a minimum interval between updates. After a Refresh or Registration has been successfully processed and acknowledged, another Update of either type from the client during that intervalMUST<bcp14>MUST</bcp14> be silently ignored by the server.</t> <t>Some authentication strategy should be used when accepting DNS updates.SharedA 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 <xreftarget="I-D.ietf-dnssd-srp"/>,target="RFC9665"/>, which uses"first come, first-served naming""First Come, First Served Naming" rather than an explicit trust establishmentprocess,process to confer update permission to a set of records.</t> </section> <section> <name>IANA Considerations</name><t>The EDNS(0) OPTION CODE 2<t>IANA hasalready been assigned for this DNS extension. This document appears inupdated theDNS"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 registryasfollows:</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 2Name: 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.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="EDNS0Codes" target="https://www.iana.org/assignments/dns-parameters"> <front> <title>DNS EDNS0 Option Codes (OPT)</title> <author> <organization>IANA</organization> </author> </front> </reference> </references> </references> <section numbered="false"> <name>Acknowledgments</name> <t>Thanks toMarc 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 toRoger Pantos and Chris Sharp<contact fullname="Roger Pantos"/> and <contact fullname="Chris Sharp"/> for their contributions. Thanks toChris Box, Esko Dijk, Jonathan Hui, Peter<contact fullname="Chris Box"/>, <contact fullname="Esko Dijk"/>, <contact fullname="Jonathan Hui"/>, <contact fullname="Peter vanDijk, Abtin Keshvarzian, Nathan Dyck, Steve Hanna, Gabriel Montenegro, Kangping Dong, and Tim WicinskiDijk"/>, <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 toDavid 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</back> <!--[rfced] We had the following questions related tokeepterminology used throughout theAuthors' Addresses heading from being split fromdocument: We see thelistfollowing similar terms. Please let us know if/how they may be made uniform. (4-byte) variant vs. 4-byte variant (8-byte) variant vs. 8-byte variant --> <!--<displayreference target="I-D.sctl-service-registration" to="RegProt"/>[rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). Specifically, we're referring to the instances of "Note:" in Section 4.2 and of "Note that" in Section 4.3. --> <!--<displayreference target="I-D.ietf-dnssd-hybrid" to="I-D.ietf-dnssd-hybrid"/> appears to[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Note that our script did notworkflag any words inxml2rfc 2.6.2particular, but this should still be reviewed as a best practice. --><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>