<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> version='1.0' encoding='UTF-8'?>

<!-- generated pre-edited by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.2.4) ST 10/01/24 -->
<!-- formatted by ST 11/08/24 -->
<!-- reference review by TH 11/25/24 -->

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-dnsop-avoid-fragmentation-20" number="9715" category="info" consensus="true" submissionType="IETF" tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" obsoletes="" updates="" version="3" xml:lang="en">

<!--[rfced] We have updated the short title that spans the header of
the PDF file from "avoid-fragmentation" to "Avoid IP
Fragmentation". Please review and let us know if any further
changes are desired.

Original:
  avoid-fragmentation

Current:
   Avoid IP Fragmentation
-->

  <front>
    <title abbrev="avoid-fragmentation">IP abbrev="Avoid IP Fragmentation">IP Fragmentation Avoidance in DNS over UDP</title>
    <seriesInfo name="RFC" value="9715"/>
    <author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara">
      <organization abbrev="JPRS">Japan Registry Services Co., Ltd.</organization>
      <address>
        <postal>
          <street>Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda</street>
	  <region>Chiyoda-ku, Tokyo</region>
          <code>101-0065</code>
          <country>Japan</country>
        </postal>
        <phone>+81 3 5215 8451</phone>
        <email>fujiwara@jprs.co.jp</email>
      </address>
    </author>
    <author initials="P." surname="Vixie" fullname="Paul Vixie">
      <organization>AWS Security</organization>
      <address>
        <postal>
          <street>11400 La Honda Road</street>
          <city>Woodside, CA</city>
          <city>Woodside</city>
	  <region>CA</region>
          <code>94062</code>
          <country>United States of America</country>
        </postal>
        <phone>+1 650 393 3994</phone>
        <email>paul@redbarn.org</email>
      </address>
    </author>
    <date year="2024" month="September" day="26"/>

    <area>operations</area>

    <keyword>Internet-Draft</keyword> year="2025" month="January"/>
    <area>OPS</area>
    <workgroup>dnsop</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

    <abstract>

<?line 129?>
<t>The widely
deployed EDNS0 Extension Mechanisms for DNS (EDNS0) feature in the DNS enables a DNS receiver to indicate
its received UDP message size capacity, which supports the sending of
large UDP responses by a DNS server.
Large DNS/UDP messages are more likely to be fragmented fragmented,
and IP fragmentation has exposed weaknesses in application protocols.
It is possible to avoid IP fragmentation in DNS by limiting the response
size where possible, possible and signaling the need to upgrade from UDP to TCP
transport where necessary.
This document describes techniques to avoid IP fragmentation in DNS.</t>
    </abstract>
  </front>
  <middle>
    <?line 142?>

<section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>
      <t>This document was originally intended to be a BCP, Best Current Practice, but due to
operating system and socket option limitations, some of the
recommendations have not yet gained real-world experience and
therefore the experience;
therefore, this document is published as Informational.
It is hoped and expected that, as operating systems and implementations evolve,
we will gain more experience with the recommendations, recommendations and plan to will publish an
updated document as a Best Current Practice.</t> Practice in the future.</t>
      <t>DNS has an EDNS0 mechanism <xref target="RFC6891"/> mechanism. target="RFC6891"/>.
The widely deployed EDNS0 feature in the DNS enables a DNS receiver to indicate
its received UDP message size capacity capacity, which supports the sending of
large UDP responses by a DNS server.
DNS over UDP invites IP fragmentation when a packet is larger than the
MTU
Maximum Transmission Unit (MTU) of some network in the packet's path.</t>
      <t>Fragmented DNS UDP responses have systemic weaknesses, which expose
the requestor to DNS cache poisoning from off-path attackers.
(See attackers (see <xref target="ProblemOfFragmentation"/> for references and details.)</t> details).</t>
      <t><xref target="RFC8900"/> states that IP fragmentation
introduces fragility to Internet communication.
The transport of DNS messages
over UDP should take account of the observations stated in that document.</t>
      <t>TCP avoids fragmentation by segmenting data into packets that are smaller
      than or equal to the Maximum Segment Size (MSS).

<!--[rfced] How may we make these sentences clearer? Specifically,
what does "other end" refer to in "keep it within the other end's
MSS" - is it the other end of the segment? Also, does "as to how
much queued data will fit" mean "depending on how much queued
data will fit"? Please advise.

Original:
   For each transmitted segment, the size of the IP and TCP
   headers is known, and the IP packet size can be chosen to
   keep it within the estimated MTU and the other end's MSS.
   This takes advantage of the elasticity of TCP's packetizing
   process as to how much queued data will fit into the next
   segment.

Perhaps:
   For each transmitted segment, the size of the IP and TCP
   headers is known, and the IP packet size can be chosen to
   keep it within the estimated MTU and the MSS of the other
   end of the segment.  This takes advantage of the elasticity
   of the TCP's packetizing process, depending on how much
   queued data will fit into the next segment.
-->

For each transmitted segment, the size of the IP and TCP headers is known,
and the IP packet size can be chosen to keep it within the estimated MTU and the other end's MSS. This takes advantage of the elasticity of TCP's
packetizing process as to how much queued data will fit into the next
segment. In contrast, DNS over UDP has little datagram size elasticity and
lacks insight into IP header and option size, so we must make more
conservative estimates about available UDP payload space.</t>
      <t><xref target="RFC7766"/> states that all general-purpose DNS
      implementations MUST <bcp14>MUST</bcp14> support both UDP and TCP transport.</t>

      <t>DNS transaction security <xref target="RFC8945"/> <xref target="RFC2931"/> does protect
against the security risks of fragmentation, including protecting and it protects
delegation responses. But <xref target="RFC8945"/> has limited applicability due
to key distribution requirements requirements, and there is little if any deployment
of <xref target="RFC2931"/>.</t>
      <t>This document describes various techniques to avoid IP fragmentation
of UDP packets in DNS.
This document is primarily applicable to DNS use on the global Internet.</t>
      <t>In contrast, a path MTU that deviates from the
recommended value might be obtained through static configuration, server
routing hints, or a future discovery protocol.  However, addressing
this falls outside the scope of this document and may be the subject
of future specifications.</t>
    </section>
    <section anchor="terminology"><name>Terminology</name>

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

<t>"Requestor" here.
        </t>
<!-- [rfced] FYI: In Section 2, we placed the definitions that are
direct quotes within the <blockquote> element, and we updated the
text slightly to exactly match the quoted text in RFCs 6891 and 8201.
Please review and let us know of any concerns.

Original:
   "Requestor" refers to the side that sends a request. "Responder"
   refers to an authoritative server, recursive resolver or other DNS
   component that responds to questions. (Quoted from EDNS0 <xref target="RFC6891"/>)</t>

<t>"Path [RFC6891])

   "Path MTU" is the minimum link MTU of all the links in a path between
   a source node and a destination node. (Quoted from [RFC8201])

Current:
   The definitions of "requestor" and "responder" are per [RFC6891]:

       "Requestor" refers to the side that sends a request. "Responder"
       refers to an authoritative, recursive resolver or other DNS
       component that responds to questions.

   The definition of "path MTU" is per [RFC8201]:

       path MTU [is] the minimum link MTU of all the links in a path
       between a source node and a destination node.
-->

<t>The definitions of "requestor" and "responder" are per <xref target="RFC6891"/>:</t>

<blockquote>
  "Requestor" refers to the side that sends a request.  "Responder"
refers to an authoritative, recursive resolver or other DNS component
that responds to questions.</blockquote>

<t>The definition of "path MTU" is per <xref target="RFC8201"/>)</t> target="RFC8201"/>:</t>
      <blockquote>path MTU [is] the minimum link MTU of all the links in a path
      between a source node and a destination node.</blockquote>

      <t>In this document, the term "Path MTU discovery" Discovery" includes
both Classical Path MTU discovery Discovery <xref target="RFC1191"/>, target="RFC1191"/> <xref target="RFC8201"/>, target="RFC8201"/> and
Packetization Layer Path MTU discovery Discovery <xref target="RFC8899"/>.</t>
      <t>Many of the specialized terms used in this document are defined in
DNS Terminology
"DNS Terminology" <xref target="RFC8499"/>.</t> target="RFC9499"/>.</t>
    </section>
    <section anchor="recommendation"><name>How anchor="recommendation">
      <name>How to avoid Avoid IP fragmentation Fragmentation in DNS</name>
      <t>These recommendations are intended
for nodes with global IP addresses on the Internet.
Private networks or local networks are out of the scope of this document.</t>
      <t>The methods to avoid IP fragmentation in DNS are described below:</t>
      <section anchor="RecommendationsResponders"><name>Proposed anchor="RecommendationsResponders">
        <name>Proposed Recommendations for UDP responders</name>

<t>R1. UDP Responders</name>
	<dl spacing="normal" newline="false" indent="7">
          <dt>R1.</dt><dd>UDP responders should not use IPv6 fragmentation
          <xref target="RFC8200"/>.</t>

<t>R2. UDP target="RFC8200"/>.</dd>
          <dt>R2.</dt><dd><t>UDP responders should configure their systems to
          prevent fragmentation of UDP packets when sending replies, provided
          it can be done safely. The mechanisms to achieve this vary across
          different operating systems.</t>

          <t>For BSD-like operating systems, the IP "Don't Don't Fragment flag (DF) bit"
          bit <xref target="RFC0791"></xref> target="RFC0791"/> can be used to prevent
          fragmentation. In contrast, Linux systems do not expose a direct API
          for this purpose and require the use of Path MTU socket options
          (IP_MTU_DISCOVER) to manage fragmentation settings. However, it is
          important to note that enabling IPv4 Path MTU Discovery for UDP in
          current Linux versions is considered harmful and dangerous. For more
          details, refer to see <xref target="impl"/>.</t>

<t>R3. UDP target="impl"/>.</t></dd>
          <dt>R3.</dt><dd>UDP responders should compose response packets that
          fit in the minimum of the offered requestor's maximum UDP payload
          size <xref target="RFC6891"/>, the interface MTU, the network MTU
          value configured by the knowledge of the network operators, and the RECOMMENDED
          <bcp14>RECOMMENDED</bcp14> maximum DNS/UDP payload size 1400.
  (See <xref target="details"/> for For more information.)</t>

<t>R4. If details, see
          <xref target="details"/>.</dd>
          <dt>R4.</dt><dd>If the UDP responder detects an immediate error
          indicating that the UDP packet exceeds the path MTU size, the UDP
          responder may recreate response packets that fit in the path MTU size,
          size or with the TC bit set.</t> set.</dd>
	</dl>
        <t>The cause and effect of the TC bit are unchanged <xref target="RFC1035"/>.</t>
      </section>
      <section anchor="RecommendationsRequestors"><name>Proposed anchor="RecommendationsRequestors">
        <name>Proposed Recommendations for UDP requestors</name>

<t>R5. UDP Requestors</name>
	<dl spacing="normal" newline="false" indent="7">
          <dt>R5.</dt><dd>UDP requestors should limit the requestor's maximum
          UDP payload size to fit in the minimum of the interface MTU, the
          network MTU value configured by the network operators, and the RECOMMENDED
          <bcp14>RECOMMENDED</bcp14> maximum DNS/UDP payload size 1400.  A
          smaller limit may be allowed.
(See <xref target="details"/> for For more information.)</t>

<t>R6. details, see <xref target="details"/>.</dd>

<!--[rfced] Section 3.2. We find the use of "should/may" confusing.
Is using only "should" or "may" acceptable?  Please advise.

Original:
   R6.    UDP requestors should/may drop fragmented DNS/UDP responses
          without IP reassembly to avoid cache poisoning attacks (at
          firewall function).</t>

<t>R7. DNS function).

Perhaps:
   R6.    UDP requestors may drop fragmented DNS/UDP responses without
          IP reassembly to avoid cache poisoning attacks (at the firewall
          function).
-->

          <dt>R6.</dt><dd>UDP requestors should/may drop fragmented DNS/UDP
          responses without IP reassembly to avoid cache poisoning attacks (at
          the firewall function).</dd>
          <dt>R7.</dt><dd>DNS responses may be dropped by IP fragmentation.
  Requestors are
          It is recommended to that requestors eventually try alternative transport protocols eventually.</t> protocols.</dd>
	</dl>
      </section>
    </section>
    <section anchor="RecommendationOperators"><name>Proposed anchor="RecommendationOperators">
      <name>Proposed Recommendations for DNS operators</name> Operators</name>
      <t>Large DNS responses are typically the result of zone configuration.
      People who publish information in the DNS should seek configurations
      resulting in small responses.  For example,</t>

<t>R8. Use example:</t>
      <dl spacing="normal" newline="false" indent="7">
	<dt>R8.</dt><dd>Use a smaller number of name servers.</t>

<t>R9. Use servers.</dd>
	<dt>R9.</dt><dd>Use a smaller number of A/AAAA RRs for a domain name.</t>

<t>R10. Use name.</dd>
	<dt>R10.</dt><dd>Use minimal-responses configuration: Some
	implementations have a 'minimal responses' configuration option that
	causes DNS servers to make response packets smaller, smaller by containing only
	mandatory and required data (<xref target="minimal-responses"/>).</t>

<t>R11. Use target="minimal-responses"/>).</dd>
	<dt>R11.</dt><dd>Use a smaller signature / public key size algorithm
	for DNSSEC.  Notably, the signature sizes of ECDSA and EdDSA the Elliptic Curve Digital Signature Algorithm (ECDSA)  and Edwards-curve Digital Signature Algorithm (EdDSA) are
	smaller than those of equivalent cryptographic strength using RSA.</t> RSA.</dd>
      </dl>
      <t>It is difficult to determine a specific upper limit for R8, R9, and
R11, but it is sufficient if all responses from the DNS servers are
below the size of R3 and R5.</t>
    </section>
    <section anchor="protocol"><name>Protocol compliance considerations</name> anchor="protocol">
      <name>Protocol Compliance Considerations</name>
      <t>Some authoritative servers deviate from the DNS standard as follows:</t>

<t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>Some authoritative servers ignore the EDNS0 requestor's maximum UDP payload size and return large UDP responses. responses <xref target="Fujiwara2018"></xref></t> target="Fujiwara2018"/>.</t>
        </li>
        <li>
          <t>Some authoritative servers do not support TCP transport.</t>
</list></t>
        </li>
      </ul>
      <t>Such non-compliant behavior cannot become implementation or configuration
constraints for the rest of the DNS. If failure is the result, then that
failure must be localized to the non-compliant servers.</t>
    </section>
    <section anchor="iana"><name>IANA anchor="iana">
      <name>IANA Considerations</name>
      <t>This document requests has no IANA actions.</t>
    </section>
    <section anchor="securitycons"><name>Security anchor="securitycons">
      <name>Security Considerations</name>
      <section anchor="on-path-fragmentation-on-ipv4"><name>On-path fragmentation anchor="on-path-fragmentation-on-ipv4">
        <name>On-Path Fragmentation on IPv4</name>
        <t>If the Don't Fragment (DF) bit is not set,
on-path fragmentation may happen on IPv4,
and it can lead to vulnerabilities, vulnerabilities as shown in <xref target="ProblemOfFragmentation"/>.
To avoid this, recommendation R6 needs to be used
to discard the fragmented responses and retry by using TCP.</t>
      </section>
      <section anchor="small-mtu-network"><name>Small anchor="small-mtu-network">
        <name>Small MTU network</name> Network</name>
        <t>When avoiding fragmentation,
a DNS/UDP requestor behind a small MTU network may experience
UDP timeouts, which would reduce performance
and which may lead to TCP fallback.
This would indicate prior reliance upon IP fragmentation,
which is considered to be harmful
to both the performance and stability of applications, endpoints, and gateways.
Avoiding IP fragmentation will improve operating conditions overall,
and the performance of DNS/TCP has increased and will continue to increase.</t>
        <t>If a UDP response packet is dropped in transit,
up to and including the network stack of the initiator,
it increases the attack window for poisoning the requestor's cache.</t>
      </section>
      <section anchor="ProblemOfFragmentation"><name>Weaknesses anchor="ProblemOfFragmentation">
        <name>Weaknesses of IP fragmentation</name> Fragmentation</name>
        <t>"Fragmentation Considered Poisonous" <xref target="Herzberg2013"></xref> noted target="Herzberg2013"/> notes effective
off-path DNS cache poisoning attack vectors using IP fragmentation.
"IP fragmentation attack on DNS" <xref target="Hlavacek2013"></xref> target="Hlavacek2013"/> and "Domain Validation++
For MitM-Resilient PKI" <xref target="Brandt2018"></xref> noted target="Brandt2018"/> note that off-path attackers
can intervene in the path Path MTU discovery Discovery <xref target="RFC1191"/>
to cause authoritative servers to produce fragmented responses.
<xref target="RFC7739"/> stated states the
	security implications of predictable fragment identification values.</t>

<t>In

<!-- [rfced] For clarity, may we update the following sentence as
shown below since some of the text is a direct quote from RFC 8085?

Current:
   In Section 3.2 (Message Side Guidelines) of UDP Usage Guidelines <xref target="RFC8085"/> [RFC8085] we
   are told that an application SHOULD NOT send UDP datagrams that result in IP
   packets that exceed the Maximum Transmission Unit (MTU) along the path to the
   destination.

Perhaps:
   Section 3.2 of [RFC8085] states that "an application SHOULD NOT send UDP
   datagrams that result in IP packets that exceed the Maximum Transmission Unit
   (MTU) along the path to the destination".
-->
        <t>In Section <xref section="3.2" sectionFormat="bare" target="RFC8085"/> ("Message Size Guidelines") of "UDP Usage Guidelines" <xref target="RFC8085"/>,
we are told that an application <bcp14>SHOULD NOT</bcp14> send UDP datagrams
that result in IP packets that exceed the MTU
along the path to the destination.</t>
        <t>A DNS message receiver cannot trust fragmented UDP datagrams primarily due to
the small amount of entropy provided by UDP port numbers and DNS message
identifiers, each of which being is only 16 bits in size, and both are likely
being
to be in the first fragment of a packet if fragmentation occurs.
By comparison, the TCP protocol stack controls packet size and avoids IP fragmentation under ICMP NEEDFRAG attacks.
In TCP, fragmentation should be avoided for performance reasons, whereas for
UDP, fragmentation should be avoided for resiliency and authenticity reasons.</t>
      </section>
      <section anchor="dns-security-protections"><name>DNS anchor="dns-security-protections">
        <name>DNS Security Protections</name>
        <t>DNSSEC is a countermeasure against cache poisoning attacks that use
IP fragmentation.
However, DNS delegation responses are not signed with DNSSEC,
and DNSSEC does not have a mechanism to get the correct response if
an incorrect delegation is injected. This is a denial-of-service
vulnerability that can yield failed name resolutions.
If cache poisoning attacks can be avoided,
DNSSEC validation failures will be avoided.</t>
      </section>
      <section anchor="possible-actions-for-resolver-operators"><name>Possible actions anchor="possible-actions-for-resolver-operators">
        <name>Possible Actions for resolver operators</name> Resolver Operators</name>
        <t>Because this document is published as an "Informational" document Informational
rather than a "Best Best Current Practice," Practice,
this section presents steps that resolver operators can take
to avoid vulnerabilities related to IP fragmentation.</t>
        <t>To avoid vulnerabilities related to IP fragmentation,
	implement R5 and R6.</t>

        <t>Specifically, configure the firewall functions protecting the full-service resolver
to discard incoming DNS response packets
with a non-zero Fragment offset Offset (FO) or a More Fragments (MF) bit of 1 on IPv4,
and discard packets with IPv6 Fragment Headers.
(If the resolver's IP address is not dedicated to the DNS resolver
and uses UDP communication that relies on IP Fragmentation for purposes
other than DNS, discard only the first fragment that contains the UDP header
from port 53.)</t>
        <t>The most recent resolver software is believed to implement R7.</t>
        <t>Even if R7 is not implemented, it will only result in a name resolution error,
preventing attacks from leading to malicious sites.</t>
      </section>
    </section>
<section anchor="acknowledgments"><name>Acknowledgments</name>

<t>The author would like to specifically thank
Paul Wouters,
Mukund Sivaraman,
Tony Finch,
Hugo Salgado,
Peter van Dijk,
Brian Dickson,
Puneet Sood,
Jim Reid,
Petr Spacek,
Andrew McConachie,
Joe Abley,
Daisuke Higashi,
Joe Touch,
Wouter Wijngaards,
Vladimir Cunat,
Benno Overeinder
and
Štěpán Němec
for extensive review and comments.</t>

</section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references title='Normative References' anchor="sec-normative-references">

<reference anchor="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>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>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="RFC7766">
  <front>
    <title>DNS Transport over TCP - Implementation Requirements</title>
    <author fullname="J. Dickinson" initials="J." surname="Dickinson"/>
    <author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
    <author fullname="R. Bellis" initials="R." surname="Bellis"/>
    <author fullname="A. Mankin" initials="A." surname="Mankin"/>
    <author fullname="D. Wessels" initials="D." surname="Wessels"/>
    <date month="March" year="2016"/>
    <abstract>
      <t>This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7766"/>
  <seriesInfo name="DOI" value="10.17487/RFC7766"/>
</reference>

<reference anchor="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>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>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>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="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>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="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>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="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>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>

<reference anchor="RFC8201">
  <front>
    <title>Path MTU Discovery for IP version 6</title>
    <author fullname="J. McCann" initials="J." surname="McCann"/>
    <author fullname="S. Deering" initials="S." surname="Deering"/>
    <author fullname="J. Mogul" initials="J." surname="Mogul"/>
    <author fullname="R. Hinden" initials="R." role="editor" surname="Hinden"/>
    <date month="July" year="2017"/>
    <abstract>
      <t>This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="87"/>
  <seriesInfo name="RFC" value="8201"/>
  <seriesInfo name="DOI" value="10.17487/RFC8201"/>
</reference>

<reference anchor="RFC1191">
  <front>
    <title>Path MTU discovery</title>
    <author fullname="J. Mogul" initials="J." surname="Mogul"/>
    <author fullname="S. Deering" initials="S." surname="Deering"/>
    <date month="November" year="1990"/>
    <abstract>
      <t>This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed,
        <name>Normative References</name>
        <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.7766.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8945.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.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8201.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1191.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8899.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <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.7739.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8085.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

<!-- [rfced] Informative Reference URLs

a) We found the following URL for [Brandt2018]:
https://dl.acm.org/doi/10.1145/3243734.3243790.
May we update this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="1191"/>
  <seriesInfo name="DOI" value="10.17487/RFC1191"/>
</reference>

<reference anchor="RFC8899">
  <front>
    <title>Packetization Layer Path MTU Discovery for Datagram Transports</title>
    <author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
    <author fullname="T. Jones" initials="T." surname="Jones"/>
    <author fullname="M. Tüxen" initials="M." surname="Tüxen"/>
    <author fullname="I. Rüngeler" initials="I." surname="Rüngeler"/>
    <author fullname="T. Völker" initials="T." surname="Völker"/>
    <date month="September" year="2020"/>
    <abstract>
      <t>This document specifies Datagram Packetization Layer Path MTU Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path reference to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP.</t>
      <t>The document provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports.</t>
      <t>This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8899"/>
  <seriesInfo name="DOI" value="10.17487/RFC8899"/>
</reference>

<reference anchor="RFC8499">
  <front>
    <title>DNS Terminology</title>
    <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
    <author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
    <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
    <date month="January" year="2019"/>
    <abstract>
      <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t>
      <t>This document obsoletes RFC 7719 this URL?

Original:
 [Brandt2018]
   Brandt, M., Dai, T., Klein, A., Shulman, H., and updates RFC 2308.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8499"/>
  <seriesInfo name="DOI" value="10.17487/RFC8499"/>
</reference>

<reference anchor="RFC8200">
  <front>
    <title>Internet Protocol, Version 6 (IPv6) Specification</title>
    <author fullname="S. Deering" initials="S." surname="Deering"/>
    <author fullname="R. Hinden" initials="R." surname="Hinden"/>
    <date month="July" year="2017"/>
    <abstract>
      <t>This document specifies version 6 M. Waidner, "Domain
   Validation++ For MitM-Resilient PKI", Proceedings of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="86"/>
  <seriesInfo name="RFC" value="8200"/>
  <seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>

<reference anchor="RFC1035">
  <front>
    <title>Domain names - implementation 2018 ACM
   SIGSAC Conference on Computer and specification</title>
    <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/>
    <date month="November" year="1987"/>
    <abstract>
      <t>This RFC is the revised specification of the protocol Communications Security , 2018.

Perhaps:
 [Brandt2018]
    Brandt, M., Dai, T., Klein, A., Shulman, H., 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="RFC7739">
  <front>
    <title>Security Implications M.
    Waidner, "Domain Validation++ For MitM-Resilient PKI",
    Proceedings of Predictable Fragment Identification Values</title>
    <author fullname="F. Gont" initials="F." surname="Gont"/>
    <date month="February" year="2016"/>
    <abstract>
      <t>IPv6 specifies the Fragment Header, which is employed for the fragmentation and reassembly mechanisms. The Fragment Header contains an "Identification" field that, together with the IPv6 Source Address 2018 ACM SIGSAC Conference on Computer
    and the IPv6 Destination Address of a packet, identifies fragments that correspond Communications Security, pp. 2060-2076,
    DOI 10.1145/3243734.3243790, October 2018,
    <https://dl.acm.org/doi/10.1145/3243734.3243790>.

b) We found the following URL for [Herzberg2013]:
https://ieeexplore.ieee.org/document/6682711.
May we update this reference to the same original datagram, such that they can be reassembled together by the receiving host. The only requirement for setting the Identification field is that the corresponding value must be different than that employed for any other fragmented datagram sent recently with the same Source Address and Destination Address. Some implementations use a simple global counter for setting the Identification field, thus leading to predictable Identification values. This document analyzes the security implications of predictable Identification values, and provides implementation guidance for setting the Identification field of the Fragment Header, such that the aforementioned security implications are mitigated.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7739"/>
  <seriesInfo name="DOI" value="10.17487/RFC7739"/>
</reference>

<reference anchor="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>The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines this URL?

Original:
 [Herzberg2013]
    Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous",
    IEEE Conference on the use of UDP for the designers of applications, tunnels, Communications and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance Network Security , 2013.

Perhaps:
 [Herzberg2013]
    Herzberg, A. and H. Shulman, "Fragmentation Considered
    Poisonous, or: One-domain-to-rule-them-all.org", IEEE
    Conference 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>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 Communications and Network Security (CNS),
    DOI 10.1109/CNS.2013.6682711, 2013,
    <https://ieeexplore.ieee.org/document/6682711>.

c) We found the following URL for [Fujiwara2018]:
https://indico.dns-oarc.net/event/31/contributions/692/
attachments/660/1115/fujiwara-5.pdf. May we update this
reference 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>Some guidance is also applicable this URL?

Original:
 [Fujiwara2018]
    Fujiwara, K., "Measures against cache poisoning attacks
    using IP fragmentation in DNS", OARC 30 Workshop , 2019.

Perhaps:
 [Fujiwara2018]
    Fujiwara, K., "Measures against DNS cache poisoning attacks
    using IP fragmentation", OARC 30 Workshop, 2019,
    <https://indico.dns-oarc.net/event/31/contributions/692/
    attachments/660/1115/fujiwara-5.pdf>.

d) We found the following URL for [Huston2021]:
https://indico.dns-oarc.net/event/37/contributions/806/
attachments/782/1366/2021-02-04-dns-flag.pdf. May we add
this URL 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>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>

    </references>

    <references title='Informative References' anchor="sec-informative-references"> reference?

Original:
 [Huston2021]
    Huston, G. and J. Damas, "Measuring DNS Flag Day 2020",
    OARC 34 Workshop , February 2021.

Perhaps:
 [Huston2021]
    Huston, G. and J. Damas, "Measuring DNS Flag Day 2020",
    OARC 34 Workshop, February 2021, <https://indico.dns-oarc.net/
    event/37/contributions/806/attachments/782/1366/2021-02-04-dns-flag.pdf>
 -->
        <reference anchor="Brandt2018" > anchor="Brandt2018">
          <front>
            <title>Domain Validation++ For MitM-Resilient PKI</title>
            <author initials="M." surname="Brandt" fullname="Markus Brandt">
              <organization>Fraunhofer Institute for Secure Information Technology SIT, Darmstadt, Germany</organization>
            </author>
            <author initials="T." surname="Dai" fullname="Tianxiang Dai">
              <organization>Fraunhofer Institute for Secure Information Technology SIT, Darmstadt, Germany</organization>
            </author>
            <author initials="A." surname="Klein" fullname="Amit Klein">
              <organization>Fraunhofer Institute for Secure Information Technology SIT, Darmstadt, Germany</organization>
            </author>
            <author initials="H." surname="Shulman" fullname="Haya Shulman">
              <organization>Fraunhofer Institute for Secure Information Technology SIT, Darmstadt, Germany</organization>
            </author>
            <author initials="M." surname="Waidner" fullname="Michael Waidner">
              <organization>Fraunhofer Institute for Secure Information Technology SIT, Darmstadt, Germany</organization>
            </author>
            <date month="October" year="2018"/>
          </front>
  <seriesInfo name="Proceedings
          <refcontent>Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security" value=""/> Security, pp. 2060-2076</refcontent>
	  <seriesInfo name="DOI" value="10.1145/3243734.3243790"/>
        </reference>

        <reference anchor="Herzberg2013" > anchor="Herzberg2013">
          <front>
            <title>Fragmentation Considered Poisonous</title> Poisonous, or: One-domain-to-rule-them-all.org</title>
            <author initials="A." surname="Herzberg" fullname="Amir Herzberg">
      <organization></organization>
              <organization/>
            </author>
            <author initials="H." surname="Shulman" fullname="Haya Shulman">
      <organization></organization>
              <organization/>
            </author>
            <date year="2013"/>
          </front>
  <seriesInfo name="IEEE
          <refcontent>IEEE Conference on Communications and Network Security" value=""/> Security (CNS)</refcontent>
	  <seriesInfo name="DOI" value="10.1109/CNS.2013.6682711"/>
        </reference>

        <reference anchor="Hlavacek2013" target="https://ripe67.ripe.net/presentations/240-ipfragattack.pdf">
          <front>
            <title>IP fragmentation attack on DNS</title>
            <author initials="T." surname="Hlavacek" fullname="Tomas Hlavacek">
              <organization>cz.nic</organization>
            </author>
            <date year="2013"/>
          </front>
  <seriesInfo name="RIPE
	  <refcontent>RIPE 67 Meeting" value=""/> Meeting</refcontent>
        </reference>

        <reference anchor="Fujiwara2018" > anchor="Fujiwara2018">
          <front>
            <title>Measures against DNS cache poisoning attacks using IP fragmentation in DNS</title> fragmentation</title>
            <author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara">
              <organization>JPRS</organization>
            </author>
            <date year="2019"/>
          </front>
  <seriesInfo name="OARC
          <refcontent>OARC 30 Workshop" value=""/> Workshop</refcontent>
        </reference>

        <reference anchor="DNSFlagDay2020" target="https://dnsflagday.net/2020/">
          <front>
            <title>DNS flag day 2020</title>
    <author >
      <organization></organization>
            <author>
              <organization/>
            </author>
    <date year="n.d."/>
            <date></date>
          </front>
        </reference>

        <reference anchor="Huston2021" > anchor="Huston2021">
          <front>
            <title>Measuring DNS Flag Day 2020</title>
            <author initials="G." surname="Huston" fullname="Geoff Huston">
              <organization>APNIC Labs</organization>
            </author>
            <author initials="J." surname="Damas" fullname="Joao Damas">
              <organization>APNIC Labs</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
  <seriesInfo name="OARC
          <refcontent>OARC 34 Workshop" value=""/>
</reference>

<reference anchor="RFC8900">
  <front>
    <title>IP Fragmentation Considered Fragile</title>
    <author fullname="R. Bonica" initials="R." surname="Bonica"/>
    <author fullname="F. Baker" initials="F." surname="Baker"/>
    <author fullname="G. Huston" initials="G." surname="Huston"/>
    <author fullname="R. Hinden" initials="R." surname="Hinden"/>
    <author fullname="O. Troan" initials="O." surname="Troan"/>
    <author fullname="F. Gont" initials="F." surname="Gont"/>
    <date month="September" year="2020"/>
    <abstract>
      <t>This document describes IP fragmentation and explains how it introduces fragility to Internet communication.</t>
      <t>This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="230"/>
  <seriesInfo name="RFC" value="8900"/>
  <seriesInfo name="DOI" value="10.17487/RFC8900"/>
</reference>

<reference anchor="RFC0791">
  <front>
    <title>Internet Protocol</title>
    <author fullname="J. Postel" initials="J." surname="Postel"/>
    <date month="September" year="1981"/>
  </front>
  <seriesInfo name="STD" value="5"/>
  <seriesInfo name="RFC" value="791"/>
  <seriesInfo name="DOI" value="10.17487/RFC0791"/>
</reference>

<reference anchor="RFC4035">
  <front>
    <title>Protocol Modifications for the DNS Security Extensions</title>
    <author fullname="R. Arends" initials="R." surname="Arends"/>
    <author fullname="R. Austein" initials="R." surname="Austein"/>
    <author fullname="M. Larson" initials="M." surname="Larson"/>
    <author fullname="D. Massey" initials="D." surname="Massey"/>
    <author fullname="S. Rose" initials="S." surname="Rose"/>
    <date month="March" year="2005"/>
    <abstract>
      <t>This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications.</t>
      <t>This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="4035"/>
  <seriesInfo name="DOI" value="10.17487/RFC4035"/>
</reference>

<reference anchor="RFC9471">
  <front>
    <title>DNS Glue Requirements in Referral Responses</title>
    <author fullname="M. Andrews" initials="M." surname="Andrews"/>
    <author fullname="S. Huque" initials="S." surname="Huque"/>
    <author fullname="P. Wouters" initials="P." surname="Wouters"/>
    <author fullname="D. Wessels" initials="D." surname="Wessels"/>
    <date month="September" year="2023"/>
    <abstract>
      <t>The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone. Authoritative servers are expected to return all available glue records for in-domain name servers in a referral response. If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server must set the TC (Truncated) flag to inform the client that the response is incomplete and that the client should use another transport to retrieve the full response. This document updates RFC 1034 to clarify correct server behavior.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9471"/>
  <seriesInfo name="DOI" value="10.17487/RFC9471"/>
</reference>

<reference anchor="RFC2308">
  <front>
    <title>Negative Caching of DNS Queries (DNS NCACHE)</title>
    <author fullname="M. Andrews" initials="M." surname="Andrews"/>
    <date month="March" year="1998"/>
    <abstract>
      <t>RFC1034 provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="2308"/>
  <seriesInfo name="DOI" value="10.17487/RFC2308"/>
</reference>

<reference anchor="RFC2782">
  <front>
    <title>A DNS RR for specifying the location of services (DNS SRV)</title>
    <author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/>
    <author fullname="P. Vixie" initials="P." surname="Vixie"/>
    <author fullname="L. Esibov" initials="L." surname="Esibov"/>
    <date month="February" year="2000"/>
    <abstract>
      <t>This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="2782"/>
  <seriesInfo name="DOI" value="10.17487/RFC2782"/>
</reference>

<reference anchor="RFC9460">
  <front>
    <title>Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)</title>
    <author fullname="B. Schwartz" initials="B." surname="Schwartz"/>
    <author fullname="M. Bishop" initials="M." surname="Bishop"/>
    <author fullname="E. Nygren" initials="E." surname="Nygren"/>
    <date month="November" year="2023"/>
    <abstract>
      <t>This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9460"/>
  <seriesInfo name="DOI" value="10.17487/RFC9460"/>
</reference>

<reference anchor="RFC5155">
  <front>
    <title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title>
    <author fullname="B. Laurie" initials="B." surname="Laurie"/>
    <author fullname="G. Sisson" initials="G." surname="Sisson"/>
    <author fullname="R. Arends" initials="R." surname="Arends"/>
    <author fullname="D. Blacka" initials="D." surname="Blacka"/>
    <date month="March" year="2008"/>
    <abstract>
      <t>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="5155"/>
  <seriesInfo name="DOI" value="10.17487/RFC5155"/> Workshop</refcontent>
        </reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8900.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9471.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2671.xml"/>

      </references>
    </references>

<?line 442?>

<section anchor="details"><name>Details anchor="details">
      <name>Details of requestor's maximum Requestor's Maximum UDP payload size discussions</name> Payload Size Discussions</name>
      <t>There are many discussions for about default path MTU size and a requestor's maximum UDP payload size.</t>

<t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>The minimum MTU for an IPv6 interface is 1280 octets
(see Section 5 of <xref section="5" sectionFormat="of" target="RFC8200"/>).
So, we can use it can be used as the default path MTU value for IPv6.
The corresponding minimum MTU for an IPv4 interface is 68 (60 + 8)
<xref target="RFC0791"/>.</t>
  <t><xref target="RFC4035"/>
        </li>
        <li>
<!--[rfced] FYI: To match the quoted text in Section 3 of RFC 4035, we
updated the text below to include a reference to RFC 2671, and we
listed RFC 2671 as an informative reference.

Original:
   [RFC4035] defines that "A security-aware name server MUST support
   the EDNS0 message size extension, MUST support a message
   size of at least 1220 octets".

Current:
   [RFC4035] states that "A security-aware name server MUST support
   the EDNS0 ([RFC2671]) message size extension, [and it] MUST
   support a message size of at least 1220 octets".
-->

          <t><xref target="RFC4035"/> states that "A security-aware name server <bcp14>MUST</bcp14> support the EDNS0 (<xref target="RFC2671"/>) message size extension, [and it] <bcp14>MUST</bcp14> support a message size of at least 1220 octets". Then, the smallest number of
the maximum DNS/UDP payload size is 1220.</t>
        </li>
        <li>
          <t>In order to avoid IP fragmentation,
<xref target="DNSFlagDay2020"></xref> proposed target="DNSFlagDay2020"/> proposes that the UDP requestors set the requestor's
payload size to 1232, 1232 and the UDP responders compose UDP responses so they fit
in 1232 octets.
The size 1232 is based on an MTU of 1280, which is required
by the IPv6 specification <xref target="RFC8200"/>,
minus 48 octets for the IPv6 and UDP headers.</t>
        </li>
        <li>
          <t>Most of the Internet and Internet, especially the inner core core, has an MTU of at least
1500 octets.
Maximum DNS/UDP payload size for IPv6 on an MTU 1500 ethernet Ethernet is
1452 (1500 minus 40 (IPv6 header size) minus 8 (UDP header size)).
To allow for possible IP options and distant tunnel overhead,
the recommendation of default maximum DNS/UDP payload size is 1400.</t>
        </li>
        <li>
          <t><xref target="Huston2021"></xref> analyzed target="Huston2021"/> analyzes the result of <xref target="DNSFlagDay2020"></xref> target="DNSFlagDay2020"/> and reported reports that
their measurements suggest that in the interior of the Internet
between recursive resolvers and authoritative servers servers, the prevailing MTU is 1500
and there is no measurable signal of use of smaller MTUs
in this part of the Internet, and proposed Internet. They propose that
their measurements suggest setting the EDNS0 requestor's UDP payload size to
1472 octets for IPv4, IPv4 and 1452 octets for IPv6.</t>
</list></t>
        </li>
      </ul>
      <t>As a result of these discussions,
this document decided to recommend recommends a value of 1400,
with smaller values also allowed.</t>
    </section>
    <section anchor="minimal-responses"><name>Minimal-responses</name> anchor="minimal-responses">
      <name>Minimal Responses</name>
      <t>Some implementations have a "minimal responses" configuration setting/option that causes
a DNS server to make response packets smaller, containing only mandatory and
      required data.</t>

      <t>Under the minimal-responses configuration,
a DNS server composes responses containing only necessary RRs. Resource Records (RRs).
For delegations, see <xref target="RFC9471"/>.
In case of a non-existent domain name or non-existent type,
the authority section will contain an SOA record record, and the answer section is empty.
(defined in Section 2 of empty
(see <xref section="2" sectionFormat="of" target="RFC2308"/>).</t>
      <t>Some resource records (MX, SRV, SVCB, and HTTPS) require
additional A, AAAA, and SVCB Service Binding (SVCB) records
in the Additional Section section
defined in <xref target="RFC1035"/>, <xref target="RFC2782"/> target="RFC2782"/>, and <xref target="RFC9460"/>.</t>
      <t>In addition, if the zone is DNSSEC signed and a query has the DNSSEC OK bit,
signatures are added in the answer section,
or the corresponding DS RRSet and signatures are added in the authority section.
Details are defined in <xref target="RFC4035"/> and <xref target="RFC5155"/>.</t>
    </section>
    <section anchor="impl"><name>Known anchor="impl">
      <name>Known Implementations</name>

<t>This

<!--[rfced] Regarding Appendix C ("Known Implementations"), is it your
intention that this section remain in the RFC? The reason we ask
is because RFC 7942 recommends removing it but also states that
it is not mandatory to remove it.
-->

<!--[rfced] Since this document is "Informational", is it correct to
state that this specification defines "best practices", or does
this text need an update to avoid any confusion?

Original:
   This section records the status of known implementations of these
   best practices defined by this specification at the time of
   publication, and any deviation from the specification.
-->

      <t>This section records the status of known implementations of the best
practices defined by this specification at the time of publication and any
deviation from the specification.</t>
      <t>Please note that the listing of any individual implementation here does not
imply endorsement by the IETF. Furthermore, no effort has been spent made to
verify the information presented here that was supplied by IETF contributors.</t> contributors and presented here.</t>
<section anchor="bind-9"><name>BIND anchor="bind-9">

<!-- [rfced] Appendix C.1

a) We notice inconsistencies with the recommendation numbers, for example,
"recommendation R6", "recommendation 2", and "R5". May we use "R#" for
consistency below and throughout the document? Please let us know your
preference.

b) We find "the first recommendation of Section 3.2" and "recommendation 2
of Section 3.2" (which should be "R6") confusing. For clarity, may we add
section numbers for the recommendation numbers that do not have them and
update the text as shown below?

c) Please confirm if "recommendation 3" in the last entry is referring
to R7 of Section 3.2.

Original:
   BIND 9 does not implement the recommendations 1 and 2 in Section 3.1

   For recommendation 3, BIND 9 will honor the requestor's size up to
   the configured limit (max-udp-size)...

   In the case of recommendation 4, and the send fails with EMSGSIZE,
   BIND 9 set the TC bit and try to send a minimal answer again.

   In the first recommendation of Section 3.2, BIND 9 uses the
   edns-buf-size option, with the default of 1232.

   BIND 9 does implement recommendation 2 of Section 3.2.

   For recommendation 3, after two UDP timeouts, BIND 9 will fall back
   to TCP.

Perhaps:
   BIND 9 does not implement R1 and R2 in Section 3.1.

   For R3 (Section 3.1), BIND 9 will honor the requestor's size up to
   the configured limit (max-udp-size)...

   In the case of R4 (Section 3.1) and the send fails with EMSGSIZE,
   BIND 9 sets the TC bit and tries to send a minimal answer again.

   For R5 (Section 3.2), BIND 9 uses the edns-buf-size
   option, with the default of 1232.

   BIND 9 does implement R6 (Section 3.2).

   For R7 (Section 3.2), after two UDP timeouts, BIND 9 will fall back
   to TCP.

c) How may we update this sentence for clarity? Does BIND 9 cause
IP_DONTFRAG to be disabled? If so, may we add "When" as shown
below?

Original:
   BIND 9 on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG is
   disabled.

Perhaps:
   When BIND 9 is on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG
   is disabled.
-->
        <name>BIND 9</name>
        <t>BIND 9 does not implement the recommendations 1 and 2 in <xref target="RecommendationsResponders"/>.</t>
        <t>BIND 9 on Linux sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with a fallback to
	IP_PMTUDISC_DONT.</t>

        <t>BIND 9 on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG is disabled.</t>
        <t>Accepting PATH Path MTU Discovery for UDP is considered harmful and dangerous.
BIND 9's settings avoid attacks to path Path MTU discovery.</t> Discovery.</t>
        <t>For recommendation 3, BIND 9 will honor the requestor's size up to the
configured limit (<spanx style="verb">max-udp-size</spanx>). (<tt>max-udp-size</tt>). The UDP response packet is bound to be
between 512 and 4096 bytes, with the default set to 1232. BIND 9 supports the
requestor's size up to the configured limit (<spanx style="verb">max-udp-size</spanx>).</t> (<tt>max-udp-size</tt>).</t>
        <t>In the case of recommendation 4, 4 and the send fails with EMSGSIZE, BIND 9
set
sets the TC bit and try tries to send a minimal answer again.</t>
        <t>In the first recommendation of <xref target="RecommendationsRequestors"/>, BIND 9 uses the <spanx style="verb">edns-buf-size</spanx> <tt>edns-buf-size</tt>
option, with the default of 1232.</t>
<t>BIND 9 does implement recommendation 2 of <xref target="RecommendationsRequestors"/>.</t> (<xref target="RecommendationsRequestors"/>).</t>

        <t>For recommendation 3, after two UDP timeouts, BIND 9 will fall back to TCP.</t>
      </section>
      <section anchor="knot-dns-and-knot-resolver"><name>Knot anchor="knot-dns-and-knot-resolver">
        <name>Knot DNS and Knot Resolver</name>
        <t>Both Knot servers set IP_PMTUDISC_OMIT to avoid path MTU spoofing. The UDP size limit is 1232 by default.</t>
        <t>Fragments are ignored if they arrive over an XDP interface.</t>
        <t>TCP is attempted after repeated UDP timeouts.</t>
        <t>Minimal responses are returned and are currently not configurable.</t>
        <t>Smaller signatures are used, with ecdsap256sha256 as the default.</t>
      </section>
      <section anchor="powerdns-authoritative-server-powerdns-recursor-powerdns-dnsdist"><name>PowerDNS anchor="powerdns-authoritative-server-powerdns-recursor-powerdns-dnsdist">
        <name>PowerDNS Authoritative Server, PowerDNS Recursor, and PowerDNS dnsdist</name>

<t><list style="symbols">

<!--[rfced] May we make the first three bulleted items into complete
sentences for clarity? Also, is "Spoofing nearmisses" a specific
term, or may we add a space to "nearmisses" per its dictionary
spelling? And does this quoted term need a reference for
background, or will readers be familiar with it?

Original:
   *  IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT

   *  default EDNS buffer size of 1232, no probing for smaller sizes

   *  no handling of EMSGSIZE

   *  Recursor: UDP timeouts do not cause a switch to TCP.  "Spoofing
      nearmisses" do.

Perhaps:
   *  Use IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT

   *  The default EDNS buffer size is 1232; no probing for smaller sizes.

   *  There is no handling of EMSGSIZE.

   *  Recursor: UDP timeouts do not cause a switch to TCP; "Spoofing
      near misses" do.
-->

        <ul spacing="normal">
          <li>
            <t>IP_PMTUDISC_OMIT with a fallback to IP_PMTUDISC_DONT</t>
          </li>
          <li>
            <t>default EDNS buffer size of 1232, 1232; no probing for smaller sizes</t>
          </li>
          <li>
            <t>no handling of EMSGSIZE</t>
          </li>
          <li>
            <t>Recursor: UDP timeouts do not cause a switch to TCP. TCP; "Spoofing nearmisses" do.</t>
</list></t>
          </li>
        </ul>
      </section>
      <section anchor="powerdns-authoritative-server"><name>PowerDNS anchor="powerdns-authoritative-server">
        <name>PowerDNS Authoritative Server</name>

<t><list style="symbols">
  <t>the
        <ul spacing="normal">
          <li>
            <t>The default DNSSEC algorithm is 13</t>
  <t>responses 13.</t>
          </li>
          <li>
            <t>Responses are minimal, minimal; this is not configurable</t>
</list></t> configurable.</t>
          </li>
        </ul>
      </section>
      <section anchor="unbound"><name>Unbound</name> anchor="unbound">
        <name>Unbound</name>
        <t>Unbound sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with fallback to
IP_PMTUDISC_DONT. It also disables IP_DONTFRAG on systems that have
it, but not on Apple systems. On systems that support it it, Unbound sets
IPV6_USE_MIN_MTU, with a fallback to IPV6_MTU at 1280, with a fallback
to IPV6_USER_MTU. It also sets IPV6_MTU_DISCOVER to IPV6_PMTUDISC_OMIT IPV6_PMTUDISC_OMIT,
with a fallback to IPV6_PMTUDISC_DONT.</t>
        <t>Unbound requests a UDP size of 1232 from peers, by default. The requestors requestor's
	size is limited to a max of 1232.</t>

<!--[rfced] Please clarify what "if that is smaller" means as the
text states that Unbound requests size 1232 and then it retries
with a smaller size of 1232 for IPv6, which is confusing. Is the
intended meaning perhaps that Unbound retries with a smaller size
"if applicable"?  Also, please clarify the intended meaning of
"anything" in "This does not do anything".

Additionally, should a citation be included for "flag day", either
[DNSFlagDay2020] or [Huston2021], for easy reference?

Note that the preceding sentence is included for context.

Original:
   Unbound requests UDP size 1232 from peers, by default.  The
   requestors size is limited to a max of 1232.

   After some timeouts, Unbound retries with a smaller size, if that is
   smaller, at size 1232 for IPv6 and 1472 for IPv4.  This does not do
   anything since the flag day change to 1232.

Perhaps:
   Unbound requests a UDP size of 1232 from peers, by default.  The
   requestor's size is limited to a max of 1232.

   After some timeouts, Unbound retries with a smaller size, if applicable,
   or at size 1232 for IPv6 and 1472 for IPv4.  This does not cause any
   negative effects due to the "flag day" [DNSFlagDay2020] change to 1232.
-->

        <t>After some timeouts, Unbound retries with a smaller size, if that is
smaller, at size 1232 for IPv6 and 1472 for IPv4. This does not do
	anything since the flag day change to 1232.</t>

<!--[rfced] May we update this sentence as follows for clarity?

Original:
   Unbound has minimal responses as an option, default on.

Perhaps:
   Unbound has the 'minimal responses' configuration option; set
   default on.
-->

        <t>Unbound has minimal responses as an option, default on.</t>
      </section>
        <section anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t>The authors would like to specifically thank <contact fullname="Paul
      Wouters"/>, <contact fullname="Mukund Sivaraman"/>, <contact
      fullname="Tony Finch"/>, <contact fullname="Hugo Salgado"/>, <contact
      fullname="Peter van Dijk"/>, <contact fullname="Brian Dickson"/>,
      <contact fullname="Puneet Sood"/>, <contact fullname="Jim Reid"/>,
      <contact fullname="Petr Spacek"/>, <contact fullname="Andrew
      McConachie"/>, <contact fullname="Joe Abley"/>, <contact
      fullname="Daisuke Higashi"/>, <contact fullname="Joe Touch"/>, <contact
      fullname="Wouter Wijngaards"/>, <contact fullname="Vladimir Cunat"/>,
      <contact fullname="Benno Overeinder"/>, and <contact fullname="Štěpán
      Němec"/> for their extensive reviews and comments.</t>
    </section>
    </section>
  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA8Vc63IbR3b+30/RoX5YKgMQwJtIVqWyEC8WLVHkApS9ictl
DzANYMzBDHZ6hhTE8pPsn+RZsnmvfOec7rkBlLSbZKMqW+Rcuk+f63cuo263
q/Ioj82JvrzRF1kwX5okD/IoTfTwPo3CIJkaHSX67P1Yp/cm0x/OblQwmWTm
/kQH9ER3Vn9Lhek0CZZYL8yCWd6NTD7rholNV90tT3d3+0rZPEjCX4I4TfBW
nhVGqWiV8Y823+33j/u7KshMcKLTlcn4PavuHkBxkpssMXn3jLZS0yA/Aamz
VE3xhElsYd16NsfrS7xwfnuh1Co6UVrn6fREr42VH0Ozyhcneh+/2TTD4zPr
79r1svpVBUW+SDNaoIv/NPbDnbc9fVH8Fj0EWcAXhQFvg09FkmZR816azU/0
98EqSPTIzCOQttZjk91HU2P1adrr6Hd52ONHPZu/vxmN+QKdw+CQp4tonYaB
vogym+vXcTjv6fMAPw72Ljp6r3vUHej3kV1E3bdgreybYbM0Kd/t3hUdfZve
rVO+O01DUDzoD7r9/uGBu1QkIM4Ry5dWC5bRt0cDvacPdgcH+mj/YMC3zDKI
4hM9c0f9w2+rzPamae+3FbFKV7y66ekfoo+RqTHqJiji2kXm0PDHMdgyLbIo
X9eZ0eDDYLDf7+t3gX6T4ph6lAahkI6XTvSPaRraKDQdfTqsHfJ4v3+42zzh
hyTKTajHUEoIIZ3p4dJk0TRoHHqgDw/6eu94D/8d79cPvQL9f8hMOAmypAfq
lYLYl1DUe3MCXYZGlr9p/TqDSKDWg6MT4Yozv52zFKsl+ocghtWRkn/7rb5I
M30V5VfdkbFRHMFs9M3byx1hSKmJ9Kfr/nZcvuq5jcrLwuqrILsrbPsecxzG
XySLdAYbv0wsqCpyo0G6iMHgojsHXMOtmS6SNE7n0N3L244+C7IlzDjMO/o7
g4eStdpO120Pz0Ytom6jIPmI/+aNe/84ooY9/TY2UdIia7iM8taNfxxNb3p6
vCjiZdCm6k2wDjZu/ePogmL9GERhYrK2ZkXTRWDijbv/F6TRurAR7Ep2JC4B
BgsbwTrwJ1k6NSaMkjkbc74w/Jwenl5hye/Gw1M42gTEGApu2PI0Xa5AUaZh
FfTLskhg/RxoKieEbd6Y7NPEZHOstnfSMN5m5MTq5HjgEvRNGtk0SQv7FUYL
PfQ7bKpi1r73dytMnVWX5+fnm8yon59Y8t7kD2l213TIpQD2mDVxcB9MzV2N
NUE2Jye9yPOVPXn5MotW5vBVj/7qIWi/XGXGeo7Zl7v7/W60InAQ5Hkwveut
wlmDw4AnDeig5TmiGNjkK7gL1+OJbPsfeF67eZM1d/qpB160D9xm4+jy5lwf
vtJXCEtQO2KID/rs6esnuTKBhc6Ds3P4ewTtaTCFhq5YUfCyO5jVhaXfNs4t
YOzL522Dkuq824FJeeQKbtROeD0cneq9PoJqdmcX6arJkWM6Mai6iIP5WbDe
7e/2G2cm9DjDPbyx1nR3q4YAJtJDeIYVhJ57yboFHJgm+HWwhZHEI1qetoav
qC3/We5813PLtnjznUlns/YtQSQ37y9PATYmdvuK31NogyK1Fvw+DdLWjW3L
bfJ6fxuvL8ykp/c7dMiBUt1uF7gIaCiY5krdQose4HbitQKcjdM13M85WNPX
MxPk5GahOuQMiV0mCSYxKSH/lpmpiQjd5ykeCsn4jYpy62+EBPv10lgbzI22
0ScDrV0FhLM6+mEB169tsVoBOVveAYZN7hfeV8UkZH4dOr8iYG71ZO32xamx
a0+944dw5WVtHxAHmpcp/hdHdzgWUTcxpTmYUJFz2jCQBYzZfFylFmQ/mOAu
wXJYDIcPVqvYOTa9ylLg/jS2PXWZ68jCAK2NwBPahVOVp0yPyI8jgAM6IZ3W
H0wxYx4W8KXlah12oDaaJ8B17vkEwYl2KVbzLAjpQOmSOYRrt6c3CvJMLDHT
rZVACOBItu5BxqAUKVZBROnQ2GkWTXC4nIJm9OeCfvwC+T3Rm2UUhjFSLSRR
WRoWU37i8VlU+/V39c/0R7V2fQB/4T3mEY4EoeANSFtOBOkE+vXpTUdPCpBX
EDOVy9pweLu2uVkKR9LpncmR0fG+zE6JBB3cWhoXtxX0D+EI67totAjuwY80
RzKWa/Kf2Be5XdxFfIpDEjvZEUUybKJyYt+MFIjYXh6AhF1MYiRIeBuHqaGP
IPbqALuju4ksOqX8IF8EACF0+taJJEpGy1VsSm5DB+/T+N501AOZZRwzuaLO
NTIfonzhlKhxUtGbVYw0EXx15OKaKlbkCcLqNAEZ8WuDQHJaZBmnCOQPkE9C
0qSuZA9YRlzB4+M/jS5OD4+OB7//DkMDZksiu+z9PzmP/w3fUa9MYP/7iHK4
Dd2HJcH+kaqx2kG+vHZGMuVzqavbD6R0rHyJwzvuyPLSN9CaIF+AqRelA2JC
mvSxhopaRNOa//F+UjyTEpGTweYpc45WaiMBdgyIR13a2OECg7xaPR8bA1EC
6EIOy+tZA35CsAStofkC6kQ7Q5MjWbW9F0o9Pv4LdODouN/Ho1aSXtLtDa4p
7w3wAN1ACpqzF/aVFz2tg0XRosp7gZ10Ku/OVSklBLUC1poHd7DTKafhHqin
E5KrsyCmLRQxgDyv8hAB3KR4OduSM9TDGv6dGAhTCchBpU6G7pwUV+wS3gt5
CisA2AVZBDGdjai4Cj5Gy2IJwMtL6TEp7fOr8fhFT1FObiAoOSj8FpHo9uyI
BtPT7jxgKXGf6F0YOPvMkvLdJelD0uHw5R5yiumsIyFPOl1AUdj874xZaSSj
5CycTkJvoiVzhxTXL5SSx4N5hlBWUOviBfEZShDeB+DSvCTNxAEWYTPEFVD4
jVVCRvSJmLeiNMpacjCgYZE+6GWBY0NnC/I/xFr2azNQxjyW2PYxV44bPegJ
NAQ6hI06jRIiOyVoE4Acr4RAuJTD16giFx4zFAbAiuYLt82lZyUf20UQepdC
BywOZMIZLkm5yNtKNZB16r7iG441SRGjgPmjmLwZU7UK1nEaQJzgA7lP8Zav
Xh0etiwlIH9ukOci9KyKjEyaUXk7Blx9GN9696YnEA9v4zWiNBXnqfn3QEKx
dbmW89hHx/sHoEF+2T3eI/cdpiCHcAzCk/LZhLhQ924W2TvOgRtG0gEfp3ER
OiHT65S0wPmbuVhR6c56+jWY1CBBJLfkipkDVBNxDIj3irUVP1JhMwIIkNX+
XEQZs8V6VaWAUmpANMNlvMSBhx5TILl+1F4bg1TI5z7IIqTXX4WAaFkRszgD
D4iaaxM8yKAkWQR0408ouJCEVFhOk4nP8zidwGl4b9gjNFVT+IADBhuo+C9z
H7EKsV9vwBvw8j6IgZeWrOcTcoS5wJt8kaXFfMHqh4iC5WfRvMicJCUKKjzC
Dg/uIUeogYsK9KzguA1RTMns1iXk7SGlSh8MroHGMISwKdOEJ8TJZ9BsaEyR
UwFDlGkKuCM+o84lkuMS6dbEPVVMfiM1JF2TfS1QUzTzdQSSoMmWkavsPD7L
q98czvRY07AGIQDDue+QAe105G/9/pp/Hp3/8cPl6PyMfh6/Gb57V/4gTyj8
cv3hnbtPP1Vvnl5fXZ2/P5OXcVW3Ll0N/3WHsZfaub65vbx+P3y3IwGocfjM
OLhL6DdbZSYXKOn1koOWAhIe7HtFHgyOSwM+Grzaxy8ESgTopUm8dr+Cm6x2
Jsg4Z4ljBbgEeBxbBp8Ing9IcmBB4OnOyGOIHQn41ocwJz+oHQEqwmoObkD6
eIvsGy50R1VvIepIysxQnFAM61aHcFyRWboCVSFMm5GCSaxh2JIusRqZLe8n
ziPkNXlHlr9+/sciJS6x8m+CUeCSnRtnLjtkg3QIaAjHYaROd9ohNHK9dI+u
SVbHZqYmAG2GQZ5Ni2xKaULIaQCuhERFIr6NLreocULZ7Qsdly1xS1QnhdUl
iZVZ7ThvCoDDDv4UAcxC7WO9+awW6AVVwE6dxr6idDcu/gqp74I1WLx1GX7x
6PiYfeMVeU8X1dnskGt+ItcBkqmO5DFUW4VDM2MXEyUcfhoGKjvsux3gL76c
Fz8+ayYxbbu2G1kOU+ETSEWolaRjJSvy3vXGOynqzYjjrTzuTRYhspeQnTJT
HafE/fIK7UGh3jNoqz/riedZGhhA+OUk2rHPG/vExOnDiQI1qdQdRq1z0tGq
PIFh4OOz1kOlUdrfKUP/0h+lRoNee1GHrClDpjh1eXN/2KK/1Lk+C3a0+9Qa
PtCwf4+yMtUlMJ0heCTSP2qu3gqwnHX5hC5DeI8oEUIcuo8o5EW5w7pS4YIP
0TaYIQftaRGGS09FHtNFhG1FbIj6cJLTLAU+DaMZZzpCz0Zu3uNqLPj/enzW
pULS5iMdj8J3ztLkm7zsg0vN8vnZxQs9iXKqMf8E3vVfHQ9+9iCdjatiSZMd
LQD8LkqKj9xRFk6GKQtKMkLyUgBJ01wPby5ZX/igHlySH3M4ipGDFhwyq7xD
o6Ji9fPLm19w+Zezy/Hp9Q/noxdE5TJIkACottSsyYkdcNIlLogYBwHOAp0i
baCXQauLKJz/E2TQpGH7FQ1npYfyCg9zmbqyBB9f465lAiMqfE6rTskiyJaz
IpZkNUiQnAPW9VhyXDRxCWxH4hwR9PhIcJvUGHKHKu89rcpLZqKHtc1sUPKX
RrxJqffACRWrVlil6kisli45bCQMlLrUw1nHLcD4YIZsgvjjL/r6ArFMYF9p
bCFlsPQMpYixCat0zb8k2ptm4ASW85lfDcaUBPp6aoNIapkTw1wJwXHV1QyY
0VFVDqNqwWgfaiwkNLhLAoG6cm0pghsLCdtqk2Vp5stAoiLMZP+6y3PNR+rQ
WVde8RpMOZxjUXMrApqwjczQFl+U4saCoKiss92eki2TyrNjID8zDQpnYQbi
npaRwj1Krr5IyBXNIR4R8qC/d8D+8ys8vtOcrR7f3/taj3/Qay/qVJwzMt2o
Kn1GVSlN2672W3T2azV2U0HV36mdQ1+dccdyeQYuwT2FZfnrK3T38Al+vaQl
Q8iu1k0oKaqKeaQ1BB0u6SJgnVlO4jVPDDl48FTv7jlrZGYeCK3OoD1E0QuK
t696rmjq93CHI2JWwsw25iBzrVSF9FFpXU8dCfJTPIwJFQl2r6pwZaNDc4Qq
qGj/JcXlUo0X44beXvs7NYAnIK/s49TOx7nSekWIOF77fkkRs5V9opDfyGiB
6Ey6iqmNUpW9a1Ktl6Gd6ltj7pqLWLcFSQTPszLVahpSwvsYUK2mA5EcQUk4
AHutS4rlhJKcGffwXB5EQGJ0/PSjw5dD/NGjkbAQ4VwGemgJenXQl3fZ2IK4
W3GoQTv1K8dUhG6XkriwHOhv3PvVeb5pLuArYuwV2bVZac76cwgQuNviSN2h
OoxZQDuX4SkzXdIYGSS+dhHHIRFXBXz++LhxKCRSfOhBm2HcCuMCwUuR75TT
fbb+IJ5T9rlYeiUcn5/21Ps0B9xY+9qqf53e4NrW+enZeMhknYf4SdWqu768
nwpWIqrhvQiMTLP1Kk/nWbBagAIaKEvmiBDScx+Nh1TLYQhE6DKakr6CbRTy
KEfiA7n6hi5gt95TEd2jo44eHUs+BwZIL0zwlC1oMZ7jiiSTrbTAF4UaoiJb
5+SiUVge7fFxEQ3Yjtm8GeTEEc9relTlNOfxmfcBDYNVivVsW85vfa2qRRVN
agYZVzpmKXlji6Snqz+zDsTl+2+S838VkhIdg5gTvaUH1NM/1acrfv4CCQ5m
+ypsu/A6pqJ2kiZdz0Aqv8HYIogSIJ9enZD7a1skoYqG4XGhGStTCc4BeLax
Ek9QrZGg1AxRq5ACaOUOWb3FapV/gAvZiA2c0EpG76rsDXIr/3Q5fD8sp49K
6eOhoOWqvQo8nri7zRKoE5LFRprXlKI0beFngDa38VVn3zbG2v4SceZ3pa4T
6WS1csaEswhVwzkOb7ayMZ+IEeNYoibvqHTrmhRUF1REK5cXMBKbgJl4X8RU
vOfCNeekZWEtSj7TWOupWx/5KTvrtOoZenTIzX3rioOUHBLUosINmQ2dqYY3
ajFS9B0xHOEfCkp85qBFeMvhqjp/fuRuJtEhbcJ6cV8FNSDjG4zQ6IgrYba9
LLOqakgrnkOIloZKwL5n+cBxFv6+gHPBkxyN6WGiWx6hVTxzycKojjyhOS7R
LFnBd4epvs4dSuevihULqX0QWTmy9SxRGOtyReIt19wY9Vd0yYRB7vsSVDSs
Jj9wKsgLkI0r5fTkHCQ9BGto99CzdLN/TJ0uOIAM6W2tgADKwkgMgPJeHLoC
vXWCpBX6ktuAAVUtKZexbsCA16aQiwTZSBddbvfYEoKG96u1sD1kJEhEDi2C
ORQrKeWGtR5PHZxbGZqbueQUtFNc7yhOBmRX8UpuvO4BMkP0IXdWodx2msEo
GMT+WE3bYIcNHj4+e8Ku6qr9NaOU+qf6JObPXJnwyRs8vypb5tua6u5g93iW
wO32Kbue+tLAIWiojTz+zCzfNsOtnpjh1j9Vk+D+BAzZNvv9impNnJQBwJuN
LLddFpbqMtmGS2y3RkWuWXFvf6tL6pW9z71j3/tktVZlc5HCYTkmCnmvIKRo
mnOvzC+pITvotW8DSe5opVE2NtLp3Ovt6udXbjxkTG2L7wqaRAHMsi98RfED
361u+Dpm/wh5OI3YSEsmdkwMmsNeVReIq5G8om8727JrQSAvSqpuvKssSK2i
MRdwK61/S5Us/noAB7j98ELRRyzzSjouWte6Dzj5sD4UUQ3POKjBH73UJdIg
tdaYdMNVDAvZpwdLP0dhaGpjta7qrAgqDLEI/kjCIiGnRojygjJUWOL5Bqwk
HnhiykRgcEgBmNsu0nGnZdgFy4iekmedis74+5RSF8gPl+5r1kYBU2oy9dTr
NSNZHNKm0g3jeOIRrHNgXFSlnLY+N8G9HhkK2TDegutIl6dXN/r9+fnZxWj4
nU/We6SMtzS01qqKSnpJhQdalJpF5AVrXp3cJQcUntNjUJxRAP26lTLnD6Zr
obwgAOhGH9zKbi6gxFw3rltPX0BVLlMSJYoIgXzTghxFhoy/OGPMCg4noTYd
YFkKJgq2zQawyTEOA8inWctIPC5okSDo6OIxBXrOZbBlWZ/sY26kajVNMy5+
l2Eumin2ev5GjQIqTCe/8UweNQoiK0eHAkdIQdNZ18r3VKqO8tY+IU70OjKQ
BoFsUM0ZPvc1CwdxEXKfYpcr+jspdjzn70t/77G9laBePUuZmh8wdWDaK4Hr
qPqiSj0YvjbiwvONAYX6/CKI2mnMMO6UzyqsufB5cKB3ts4Jdnak92+dQ3aT
+TR/ZVZORzbpZGbQaJEqq2EtVE0AT8JGuiXAVlD6b3itU03YIP2VLPiQ0LIf
NoipUNBoXW3W4Wxt6kWeKOLYK0150jpwJzVc+knzdtlEseIHnJR9MllaJSwI
5ZZaMlQNuqI02N+xiBcul4FTHDRzFL9p2USj5bmTVy78RkbJeuq5y5Q80d/Y
Wr/U50mhEdhdpo/uFHJM2pKKRBwiGvN8XvLUtRMSW1+Isj+UBpVVaaVoWL9T
HoPjxpZoIOYohSZb1vxlsktx2YHj1cEeFXK5HZjanONlUlNHm87yh0CS6QlR
ei/HrKnJK+jHOZATxZzRK8+U8gHYsczWQUOY1goJBG3vIO2NjnLdvrprYIop
A2Klogob0AdPJlmaSKXAP/U9HVaBarjaQzSXJXGPEivYmk4zX++04k8lf0zp
YyXq/1wVdwhsAE33AeBBAPO4TZO1voC+LjrqTTFP9TiI50GYdtQN1a7gqiCe
6Le7jnqdRfwziCe7uimQueZ6nKbwa99HSz0yUchvZXpM43B4ZZhArx701RSo
nNuxeDI1egintoYzDCJbgPQ30Tywi0ju3aYFkSIk6x+j35J5AK2wHfVDDF7R
d02nBbAR6DEAQPoaQgWECEUx1X/9e/7Xv6z+8z8S/f6vf0Hg4BkB8zE3iZtH
uY9AEKmw5OG5dePtlHsiMkqHgIzsq+pOpLOFta6g4fsLqhRUJjhzydNqtWcp
7odmFpDeNLpPZbX0S1sT2dL0dr0YWoHryInYftWUgQIPdo/6QEw5eR+tn1tj
SjR9oMvZOWnyv+hxRblDk5HksimeRDw2Lti0RbV0d2hn2rbnW2QUhbkbR+q9
ncb9Jo2HR/r5YV9/q49eYBEZfKHWObfNuu7CPvfR3CCKCzU7w3KAsRuwbdeq
8I2JStcrlMJiY8DcqQghyMYIZlDiXV1WU7El7Ja+nt7d9Vzd4QkEhz+lmGzz
qtjvNv5sK4vFtNvnw15StTCUrvX2uRJqU/7U/ILqZwpT0qNptFDrzSyz0fPD
Og0ysONgd2+3U3aKWy1y3xtvNr5sKnNos4iYDFdIazjeeJ2Qhh1dJ9/L1QzK
khM/qEVK6itIkS17BnjbNQxZrxtjgg3FJZZA0+BB94/c1mVZlV8NXCa38NEQ
nL5Kq3prOaXOrV03GOWCUZQklHRRUHbfR/jxMq8N2H1w0O/XDn31OXF7iyEe
0FL8rqGYmHC1hpbbP0Cmyzfcufo0poF33DwzLfTC3YP1VGeTO2zJhJqo8u5K
Mg5SQp384IeDEDK1UeCYMZemaCHfXG9VLXFq7wa+qNHcnwWff6o+yqPaRxCv
P7kcuerubeizOEMyRKfTQg9igMtXBBvZYj431iEEl0qya6GiYUu2pE1u8G9z
TNGWidVG/cNxggI5fDw5NRIanRDiqeYqBFggLgmBXNuQj7mIEDeC45tNWMGK
tcjoTpBtqKL7rKdu15/ngRvNeaKBsiGiPGU9e7VbNxiGlrwxa2DzDqHnoYyH
ernVIltH5a2562nkOs6lEuFdCRpk89CPjgBizxUp+UBpbVp18NXVRhf08dlm
E1E1OlVPdER3NjqiO62OqGPiyy2d0fq3RP+Txih3+xptURzyAxcdygmLp5u+
nSYdzidb3Xi8sXH5TSA1nKWjXWXI9BEdT0hQiD3ef8Uxl0bRAlFYyVXMR3gJ
FmrVqNY8glm7l69XBkAzX1R1xHWZKJaFa3odLnR8PWS1yMIy2gSJfSD/5d6A
LpnlKl8jc6mGT0vssivYhaje3esfSQ+ZRU8WzUO9sjzlT3/q6PHoB/zvh9PX
Hf3m9vZm/MIHGYUMKJJcWA87mhrzYgD0sF9DOdcyrJ51hKgabW5il3FKxxP3
6mgXqIUW9Dw+lHFKMNlv3aF8g9bnIQcc3BULXLVEBpNhytmaI5DLy+iJ67eU
GXZU2euWUgsW9oO8bb52lIuLTZx2NoZ2jF0A/OxqbdH2SujcnBNuwraKAQeD
A5mHektfNunLlqU+PuNJvVoP0n3Q4fXCi5XhFt4qGLPzZ1IbZi8uFZo8gRtE
KiZFDFtSyeiC1m4gCwegqLXFxWoePXAfUbAsEvrykZrenNn6tndjESriEDgw
tVlIGUW3uXyyyN+xUJvrPgrpe7JWy5gDiq+HcSljTc0oQDnJVT0wOr+9oK/3
M4pANNfUoRBkZjOCsKQsE4p3II0HMxVcRjTzsKaalHFlHBqtNJmjlr7dJSyM
RFlGjbCTFFPpY52UQdTry/dn+liVNSj+tariVZn1JpRA+GRm7oqqPD3g/Hu5
D+ElmQy15GlbU6tSA/rlBtfo0i/XV5e32tVbfIuRWFB/5uz6/W1jeT9v6wop
/AAXgJ9b6v2DJReZMa/HZy86jds8/WEp5oecvk/NisV8M7x989S4a6NZuX2k
1VH2jS3nbl1OUBZl0y3NHfrulOuFDei219HunOyLF2lSzh1UKIGRgTQGqYFT
m9yToZXnvwL2dYtw1aUnf30h09dPNB0nKVUcuA1bfnJxMNjlM+73jw+hVTl/
7eoHLj205FxFkpGeJ7r+4a96mmT9ZZLdVxumjHEtRu1XCRB3gGbs3JjI86vx
d+PLfzv3rFQ+q/Lzn/Rext+9WoE7HnA4J8xF9ooCqXNtYuwt9lCOf/5eyrHw
DdhfTZjY7qSYyRGVgJctjOVUC0xtmmplpi1Kdr9Iy5OqFsyoiJM/pLo5JVBX
QbJK7czSjTK8JbfBH02Ae/zLyBcfnYuhBtJbGemQ7iSJYMPuy+S5KrGs0hRO
f97jsQVWGtEPTr6RmU7Wnk2177bdZyc8mRS6KA0Al2WUH/AXqsAyf+LhdVfP
cF8cU5shzwnAUABnZiCdMYHv03mOVPi21S2RmSYf/XHBzcYToEvzChPC5fgR
kPrInCxCUyVODcw0tMFq9+DQLgL8v1XU4Z4DFJRYP2wkQWP3ZVd5e8S5U1q/
BO2jNNKJqPuEG645Yd12wnjJ6+g5/7sZBU3Tl3UXKUsk3Iee8BwLlK4aE/wE
dN6l2wswK3bh1dsq7niSTxqs99NervWtLaicLrwu6p2x0xgAaDjnyHK2EKZf
YlXJhbrhObhWTS2S1u3hoabQnbfoCCpx5ee6qClRYLfqdnG//Y0B8bPhUF/m
koG5gGYbga4WIxklUGKlgEB5cpGopX8NckVTuf6bGn3desUX2GB7dfJByQ+H
v3wYn/9ydfmeDtLZEr01P8Tfsee+atR8SPmHsNKInqwO5JgkC7TYhIsNRqmn
9m5jB3+Ecg6udC/sVaQ7YbgGX/MwHDar6pzyRRP/tTT5L6qw1Dz2kJ0I/6MT
lTutds/pHwXyzKibhksuAq4sldlpkNeJ9AUpSfxflVf2XdO0RHRhqgBb6Z8W
mON9amxzGPP/XpN8+VDG7oo7hEQ3cm/XkPTRqgxSCJD/DUD52a9tVAAA [rfced] In the html and pdf outputs, the text enclosed in <tt> is output in
fixed-width font. In the txt output, there are no changes to the font,
and the quotation marks have been removed.

Please review carefully and let us know if the output is acceptable or if any
updates are needed.
-->

<!-- [rfced] Terminology

a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.

  Don't Fragment flag (DF) bit vs. Don't Fragment (DF) bit
   [Note: Should this be "Don't Fragment (DF) flag bit"
   per RFC 0791?]

  More Fragments (MF) bit
   [Note: Should this be "More Fragments (MF) flag bit"
   for consistency?]

b) We made the following updates for consistency. Please let us know of
any objections.

  Additional Section -> Additional section (per RFCs 1035 and 9460)
    [Note: RFC 2782 uses "Additional Data section"; please let
    us know if the current text is okay or if it should include
    "data".]

  Path MTU discovery -> Path MTU Discovery (per RFC 8201)
  Path MTU -> path MTU (per RFC 8201)
-->

<!-- [rfced] Abbreviations

a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.

  Elliptic Curve Digital Signature Algorithm (ECDSA)
  Edwards-curve Digital Signature Algorithm (EdDSA)
  Service Binding (SVCB)
  Resource Record (RR)

b) We notice that this document as well as RFCs 8900 and 9471 use
"EDNS0" but RFC 6891 uses "EDNS(0)". Please let us know if using
"EDNS0" is preferred or if you would like to use "EDNS(0)".

Current:
   Extension Mechanisms for DNS (EDNS0)

Perhaps:
   Extension Mechanisms for DNS (EDNS(0))

c) We do not see "XDP" used in any other RFCs. Does "XDP" stand for something
(i.e., can it be expanded)?

Current:
   Fragments are ignored if they arrive over an XDP interface.
-->

<!-- [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.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->

</rfc>