<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.17 (Ruby 3.2.4) --> version='1.0' encoding='UTF-8'?>

<!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">

  <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 13F</street>
	  <street>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>

    <abstract>

<?line 129?>
<t>The widely
deployed EDNS0 Extension Mechanisms for DNS (EDNS(0)) 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 EDNS(0) mechanism <xref target="RFC6891"/> mechanism. target="RFC6891"/>.
The widely deployed EDNS0 EDNS(0) 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). 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 the TCP's
packetizing process as to process, depending on 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>

<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 server, authoritative, recursive resolver or other DNS component
that responds to questions. (Quoted from EDNS0 <xref target="RFC6891"/>)</t>

<t>"Path questions.</blockquote>

<t>The definition of "path MTU" is per <xref 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. (Quoted from <xref target="RFC8201"/>)</t> 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" flag
          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. UDP details, see <xref target="details"/>.</dd>

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

<t>R7. DNS 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 EDNS(0) 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) flag 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 Section 3.2 (Message Side Guidelines) of UDP Usage Guidelines <xref

        <t><xref section="3.2" sectionFormat="of" target="RFC8085"/>
we are told states that an
"an application SHOULD NOT <bcp14>SHOULD NOT</bcp14> send UDP datagrams
that result in IP packets that exceed the Maximum Transmission Unit (MTU)
along the path to the destination.</t> 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) flag 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, 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 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 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 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 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 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 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 and the IPv6 Destination Address of a packet, identifies fragments that correspond 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 on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t>
      <t>Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP.</t>
      <t>Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control.</t>
      <t>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>
        <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 title='Informative References' anchor="sec-informative-references">
        <name>Informative References</name>

        <reference anchor="Brandt2018" > target="https://dl.acm.org/doi/10.1145/3243734.3243790">
          <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" > target="https://ieeexplore.ieee.org/document/6682711">
          <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" > target="https://indico.dns-oarc.net/event/31/contributions/692/attachments/660/1115/fujiwara-5.pdf">
          <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" > target="https://indico.dns-oarc.net/event/37/contributions/806/attachments/782/1366/2021-02-04-dns-flag.pdf">
          <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>
        </li>
        <li>

          <t><xref target="RFC4035"/> defines states that "A security-aware name server MUST <bcp14>MUST</bcp14> support the EDNS0 (<xref target="RFC2671"/>) message size extension, MUST [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 EDNS(0) 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 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> proposed recommendations described in <xref target="recommendation"/>.</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">

        <name>BIND 9</name>
        <t>BIND 9 does not implement the recommendations 1 R1 and 2 in <xref target="RecommendationsResponders"/>.</t> R2. <!--<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

        <t>When BIND 9 is 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, R3, 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, R4 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"/>,
        <t>For R5, 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>
        <t>For recommendation 3, R7, 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 a Linux 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">
  <t>IP_PMTUDISC_OMIT

        <ul spacing="normal">
          <li>
            <t>Use IP_PMTUDISC_OMIT with a fallback to IP_PMTUDISC_DONT</t>
  <t>default IP_PMTUDISC_DONT.</t>
          </li>
          <li>
            <t>The default EDNS buffer size of 1232, 1232; no probing for smaller sizes</t>
  <t>no sizes.</t>
          </li>
          <li>
            <t>There is no handling of EMSGSIZE</t> EMSGSIZE.</t>
          </li>
          <li>
            <t>Recursor: UDP timeouts do not cause a switch to TCP. "Spoofing nearmisses" do.</t>
</list></t> TCP, but "spoofing near misses" may.</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>

        <t>After some timeouts, Unbound retries with a smaller size, if that is
smaller, applicable, or at
size 1232 for IPv6 and 1472 for IPv4. This does not do
anything since cause any negative effects due to
	the flag day "flag day" <xref target="DNSFlagDay2020"/> change to 1232.</t>

        <t>Unbound has minimal responses as an option, the "minimal responses" configuration option; set 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

-->
</rfc>