rfc9715xml2.original.xml   rfc9715.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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) -->
<!DOCTYPE rfc [ <!-- pre-edited by ST 10/01/24 -->
<!-- formatted by ST 11/08/24 -->
<!-- reference review by TH 11/25/24 -->
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-ietf-dnsop-avoid-fragmentation-20" categor <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
y="info" consensus="true" submissionType="IETF" tocDepth="4" tocInclude="true" s -ietf-dnsop-avoid-fragmentation-20" number="9715" category="info" consensus="tru
ortRefs="true" symRefs="true"> e" submissionType="IETF" tocDepth="4" tocInclude="true" sortRefs="true" symRefs=
<front> "true" obsoletes="" updates="" version="3" xml:lang="en">
<title abbrev="avoid-fragmentation">IP Fragmentation Avoidance in DNS over U
DP</title> <!--[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 IP Fragmentation">IP Fragmentation Avoidance in DNS ove
r UDP</title>
<seriesInfo name="RFC" value="9715"/>
<author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara"> <author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara">
<organization abbrev="JPRS">Japan Registry Services Co., Ltd.</organizatio n> <organization abbrev="JPRS">Japan Registry Services Co., Ltd.</organizatio n>
<address> <address>
<postal> <postal>
<street>Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda</street> <street>Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda</street>
<region>Chiyoda-ku, Tokyo</region> <region>Chiyoda-ku, Tokyo</region>
<code>101-0065</code> <code>101-0065</code>
<country>Japan</country> <country>Japan</country>
</postal> </postal>
<phone>+81 3 5215 8451</phone> <phone>+81 3 5215 8451</phone>
<email>fujiwara@jprs.co.jp</email> <email>fujiwara@jprs.co.jp</email>
</address> </address>
</author> </author>
<author initials="P." surname="Vixie" fullname="Paul Vixie"> <author initials="P." surname="Vixie" fullname="Paul Vixie">
<organization>AWS Security</organization> <organization>AWS Security</organization>
<address> <address>
<postal> <postal>
<street>11400 La Honda Road</street> <street>11400 La Honda Road</street>
<city>Woodside, CA</city> <city>Woodside</city>
<region>CA</region>
<code>94062</code> <code>94062</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<phone>+1 650 393 3994</phone> <phone>+1 650 393 3994</phone>
<email>paul@redbarn.org</email> <email>paul@redbarn.org</email>
</address> </address>
</author> </author>
<date year="2025" month="January"/>
<area>OPS</area>
<workgroup>dnsop</workgroup>
<date year="2024" month="September" day="26"/> <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<area>operations</area>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<?line 129?>
<t>The widely <t>The widely
deployed EDNS0 feature in the DNS enables a DNS receiver to indicate deployed Extension Mechanisms for DNS (EDNS0) feature in the DNS enables a DNS r eceiver to indicate
its received UDP message size capacity, which supports the sending of its received UDP message size capacity, which supports the sending of
large UDP responses by a DNS server. large UDP responses by a DNS server.
Large DNS/UDP messages are more likely to be fragmented Large DNS/UDP messages are more likely to be fragmented,
and IP fragmentation has exposed weaknesses in application protocols. and IP fragmentation has exposed weaknesses in application protocols.
It is possible to avoid IP fragmentation in DNS by limiting the response It is possible to avoid IP fragmentation in DNS by limiting the response
size where possible, and signaling the need to upgrade from UDP to TCP size where possible and signaling the need to upgrade from UDP to TCP
transport where necessary. transport where necessary.
This document describes techniques to avoid IP fragmentation in DNS.</t> This document describes techniques to avoid IP fragmentation in DNS.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 142?>
<?line 142?> <section anchor="introduction">
<name>Introduction</name>
<section anchor="introduction"><name>Introduction</name> <t>This document was originally intended to be a Best Current Practice, bu
t due to
<t>This document was originally intended to be a BCP, but due to
operating system and socket option limitations, some of the operating system and socket option limitations, some of the
recommendations have not yet gained real-world experience and recommendations have not yet gained real-world experience;
therefore the document is published as Informational. therefore, this document is Informational.
It is hoped and expected that, as operating systems and implementations evolve, It is expected that, as operating systems and implementations evolve,
we will gain more experience with the recommendations, and plan to publish an we will gain more experience with the recommendations and will publish an
updated document as a Best Current Practice.</t> updated document as a Best Current Practice in the future.</t>
<t>DNS has an EDNS0 mechanism <xref target="RFC6891"/>.
<t>DNS has an EDNS0 <xref target="RFC6891"/> mechanism. The widely deployed EDNS0 feature in the DNS enables a DNS receiver to indicate
The widely its received UDP message size capacity, which supports the sending of
deployed 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 UDP responses by a DNS server.
DNS over UDP invites IP fragmentation when a packet is larger than the DNS over UDP invites IP fragmentation when a packet is larger than the
MTU of some network in the packet's path.</t> Maximum Transmission Unit (MTU) of some network in the packet's path.</t>
<t>Fragmented DNS UDP responses have systemic weaknesses, which expose
<t>Fragmented DNS UDP responses have systemic weaknesses, which expose the requestor to DNS cache poisoning from off-path attackers (see <xref target="
the requestor to DNS cache poisoning from off-path attackers. ProblemOfFragmentation"/> for references and details).</t>
(See <xref target="ProblemOfFragmentation"/> for references and details.)</t> <t><xref target="RFC8900"/> states that IP fragmentation
<t><xref target="RFC8900"/> states that IP fragmentation
introduces fragility to Internet communication. introduces fragility to Internet communication.
The transport of DNS messages The transport of DNS messages
over UDP should take account of the observations stated in that document.</t> over UDP should take account of the observations stated in that document.</t>
<t>TCP avoids fragmentation by segmenting data into packets that are small
er
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.
-->
<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, 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 and the IP packet size can be chosen to keep it within the estimated MTU and the
other end's MSS. other end's MSS. This takes advantage of the elasticity of TCP's
This takes advantage of the elasticity of TCP's
packetizing process as to how much queued data will fit into the next 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 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 lacks insight into IP header and option size, so we must make more
conservative estimates about available UDP payload space.</t> conservative estimates about available UDP payload space.</t>
<t><xref target="RFC7766"/> states that all general-purpose DNS
implementations <bcp14>MUST</bcp14> support both UDP and TCP transport.</t
>
<t><xref target="RFC7766"/> states that all general-purpose DNS <t>DNS transaction security <xref target="RFC8945"/> <xref target="RFC2931
implementations MUST support both UDP and TCP transport.</t> "/> does protect
against the security risks of fragmentation, and it protects
<t>DNS transaction security <xref target="RFC8945"/> <xref target="RFC2931"/> do
es protect
against the security risks of fragmentation, including protecting
delegation responses. But <xref target="RFC8945"/> has limited applicability due delegation responses. But <xref target="RFC8945"/> has limited applicability due
to key distribution requirements and there is little if any deployment to key distribution requirements, and there is little if any deployment
of <xref target="RFC2931"/>.</t> of <xref target="RFC2931"/>.</t>
<t>This document describes various techniques to avoid IP fragmentation
<t>This document describes various techniques to avoid IP fragmentation
of UDP packets in DNS. of UDP packets in DNS.
This document is primarily applicable to DNS use on the global Internet.</t> This document is primarily applicable to DNS use on the global Internet.</t>
<t>In contrast, a path MTU that deviates from the
<t>In contrast, a path MTU that deviates from the
recommended value might be obtained through static configuration, server recommended value might be obtained through static configuration, server
routing hints, or a future discovery protocol. However, addressing routing hints, or a future discovery protocol. However, addressing
this falls outside the scope of this document and may be the subject this falls outside the scope of this document and may be the subject
of future specifications.</t> of future specifications.</t>
</section>
<section anchor="terminology">
<name>Terminology</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown 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.
</section> Original:
<section anchor="terminology"><name>Terminology</name> "Requestor" refers to the side that sends a request. "Responder"
refers to an authoritative server, recursive resolver or other DNS
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", component that responds to questions. (Quoted from EDNS0 [RFC6891])
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the
y appear in all
capitals, as shown here.</t>
<t>"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 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>
<t>In this document, the term "Path MTU discovery" includes
both Classical Path MTU discovery <xref target="RFC1191"/>, <xref target="RFC820
1"/>, and
Packetization Layer Path MTU discovery <xref target="RFC8899"/>.</t>
<t>Many of the specialized terms used in this document are defined in
DNS Terminology <xref target="RFC8499"/>.</t>
</section>
<section anchor="recommendation"><name>How to avoid IP fragmentation in DNS</nam
e>
<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 Recommendations for U
DP responders</name>
<t>R1. UDP responders should not use IPv6 fragmentation <xref target="RFC8200"/>
.</t>
<t>R2. 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 Fragment flag (DF) bit"
<xref target="RFC0791"></xref> can be used to prevent fragmentation. In contra
st, 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 <xref target="imp
l"/>.</t>
<t>R3. UDP responders should compose response packets that fit in the minimum of "Path MTU" is the minimum link MTU of all the links in a path between
the offered requestor's maximum UDP payload size <xref target="RFC6891"/>, a source node and a destination node. (Quoted from [RFC8201])
the interface MTU,
the network MTU value configured by the knowledge of the network operators,
and the RECOMMENDED maximum DNS/UDP payload size 1400.
(See <xref target="details"/> for more information.)</t>
<t>R4. If the UDP responder detects an immediate error indicating Current:
that the UDP packet exceeds the path MTU size, The definitions of "requestor" and "responder" are per [RFC6891]:
the UDP responder may recreate response packets that fit in the path MTU size,
or with the TC bit set.</t>
<t>The cause and effect of the TC bit are unchanged <xref target="RFC1035"/>.</t "Requestor" refers to the side that sends a request. "Responder"
> refers to an authoritative, recursive resolver or other DNS
component that responds to questions.
</section> The definition of "path MTU" is per [RFC8201]:
<section anchor="RecommendationsRequestors"><name>Proposed Recommendations for U
DP requestors</name>
<t>R5. UDP requestors should limit the requestor's maximum UDP payload size path MTU [is] the minimum link MTU of all the links in a path
to fit in the minimum of between a source node and a destination node.
the interface MTU, -->
the network MTU value configured by the network operators,
and the RECOMMENDED maximum DNS/UDP payload size 1400.
A smaller limit may be allowed.
(See <xref target="details"/> for more information.)</t>
<t>R6. UDP requestors should/may drop fragmented DNS/UDP responses without IP re <t>The definitions of "requestor" and "responder" are per <xref target="RFC6891"
assembly />:</t>
to avoid cache poisoning attacks (at firewall function).</t>
<t>R7. DNS responses may be dropped by IP fragmentation. <blockquote>
Requestors are "Requestor" refers to the side that sends a request. "Responder"
recommended to try alternative transport protocols eventually.</t> refers to an authoritative, recursive resolver or other DNS component
that responds to questions.</blockquote>
</section> <t>The definition of "path MTU" is per <xref target="RFC8201"/>:</t>
</section> <blockquote>path MTU [is] the minimum link MTU of all the links in a path
<section anchor="RecommendationOperators"><name>Proposed Recommendations for DNS between a source node and a destination node.</blockquote>
operators</name>
<t>Large DNS responses are typically the result of zone configuration. <t>In this document, the term "Path MTU Discovery" includes
People who publish information in the DNS should seek configurations resulting i both Classical Path MTU Discovery <xref target="RFC1191"/> <xref target="RFC8201
n small responses. "/> and
For example,</t> Packetization Layer Path MTU Discovery <xref target="RFC8899"/>.</t>
<t>Many of the specialized terms used in this document are defined in
"DNS Terminology" <xref target="RFC9499"/>.</t>
</section>
<section anchor="recommendation">
<name>How to Avoid IP 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 Recommendations for UDP Responders</name>
<dl spacing="normal" newline="false" indent="7">
<dt>R1.</dt><dd>UDP responders should not use IPv6 fragmentation
<xref 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>R8. Use a smaller number of name servers.</t> <t>For BSD-like operating systems, the IP Don't Fragment flag (DF)
bit <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, see <xref 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
<bcp14>RECOMMENDED</bcp14> maximum DNS/UDP payload size 1400. For more
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 or with the TC bit set.</dd>
</dl>
<t>The cause and effect of the TC bit are unchanged <xref target="RFC103
5"/>.</t>
</section>
<section anchor="RecommendationsRequestors">
<name>Proposed Recommendations for 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
<bcp14>RECOMMENDED</bcp14> maximum DNS/UDP payload size 1400. A
smaller limit may be allowed. For more details, see <xref target="deta
ils"/>.</dd>
<t>R9. Use a smaller number of A/AAAA RRs for a domain name.</t> <!--[rfced] Section 3.2. We find the use of "should/may" confusing.
Is using only "should" or "may" acceptable? Please advise.
<t>R10. Use minimal-responses configuration: Original:
Some implementations have a 'minimal responses' configuration option that caus R6. UDP requestors should/may drop fragmented DNS/UDP responses
es without IP reassembly to avoid cache poisoning attacks (at
DNS servers to make response packets smaller, containing only mandatory firewall function).
and required data (<xref target="minimal-responses"/>).</t>
<t>R11. Use a smaller signature / public key size algorithm for DNSSEC. Perhaps:
Notably, the signature sizes of ECDSA and EdDSA R6. UDP requestors may drop fragmented DNS/UDP responses without
are smaller than those of equivalent cryptographic strength using RSA.</t> IP reassembly to avoid cache poisoning attacks (at the firewall
function).
-->
<t>It is difficult to determine a specific upper limit for R8, R9, and <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.
It is recommended that requestors eventually try alternative transport
protocols.</dd>
</dl>
</section>
</section>
<section anchor="RecommendationOperators">
<name>Proposed Recommendations for DNS 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>
<dl spacing="normal" newline="false" indent="7">
<dt>R8.</dt><dd>Use a smaller number of name servers.</dd>
<dt>R9.</dt><dd>Use a smaller number of A/AAAA RRs for a domain 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 by containing only
mandatory and required data (<xref target="minimal-responses"/>).</dd>
<dt>R11.</dt><dd>Use a smaller signature / public key size algorithm
for DNSSEC. Notably, the signature sizes of the Elliptic Curve Digital S
ignature Algorithm (ECDSA) and Edwards-curve Digital Signature Algorithm (EdDSA
) are
smaller than those of equivalent cryptographic strength using 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 R11, but it is sufficient if all responses from the DNS servers are
below the size of R3 and R5.</t> below the size of R3 and R5.</t>
</section>
</section> <section anchor="protocol">
<section anchor="protocol"><name>Protocol compliance considerations</name> <name>Protocol Compliance Considerations</name>
<t>Some authoritative servers deviate from the DNS standard as follows:</t
<t>Some authoritative servers deviate from the DNS standard as follows:</t> >
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Some authoritative servers ignore the EDNS0 requestor's maximum UDP payload <t>Some authoritative servers ignore the EDNS0 requestor's maximum UDP
size and return large UDP responses. <xref target="Fujiwara2018"></xref></t> payload size and return large UDP responses <xref target="Fujiwara2018"/>.</t>
<t>Some authoritative servers do not support TCP transport.</t> </li>
</list></t> <li>
<t>Some authoritative servers do not support TCP transport.</t>
<t>Such non-compliant behavior cannot become implementation or configuration </li>
</ul>
<t>Such non-compliant behavior cannot become implementation or configurati
on
constraints for the rest of the DNS. If failure is the result, then that constraints for the rest of the DNS. If failure is the result, then that
failure must be localized to the non-compliant servers.</t> failure must be localized to the non-compliant servers.</t>
</section>
</section> <section anchor="iana">
<section anchor="iana"><name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document requests no IANA actions.</t> <t>This document has no IANA actions.</t>
</section>
</section> <section anchor="securitycons">
<section anchor="securitycons"><name>Security Considerations</name> <name>Security Considerations</name>
<section anchor="on-path-fragmentation-on-ipv4">
<section anchor="on-path-fragmentation-on-ipv4"><name>On-path fragmentation on I <name>On-Path Fragmentation on IPv4</name>
Pv4</name> <t>If the Don't Fragment (DF) bit is not set,
<t>If the Don't Fragment (DF) bit is not set,
on-path fragmentation may happen on IPv4, on-path fragmentation may happen on IPv4,
and lead to vulnerabilities, as shown in <xref target="ProblemOfFragmentation"/> . and it can lead to vulnerabilities as shown in <xref target="ProblemOfFragmentat ion"/>.
To avoid this, recommendation R6 needs to be used To avoid this, recommendation R6 needs to be used
to discard the fragmented responses and retry by TCP.</t> to discard the fragmented responses and retry using TCP.</t>
</section>
</section> <section anchor="small-mtu-network">
<section anchor="small-mtu-network"><name>Small MTU network</name> <name>Small MTU Network</name>
<t>When avoiding fragmentation,
<t>When avoiding fragmentation,
a DNS/UDP requestor behind a small MTU network may experience a DNS/UDP requestor behind a small MTU network may experience
UDP timeouts, which would reduce performance UDP timeouts, which would reduce performance
and which may lead to TCP fallback. and may lead to TCP fallback.
This would indicate prior reliance upon IP fragmentation, This would indicate prior reliance upon IP fragmentation,
which is considered to be harmful which is considered to be harmful
to both the performance and stability of applications, endpoints, and gateways. to both the performance and stability of applications, endpoints, and gateways.
Avoiding IP fragmentation will improve operating conditions overall, Avoiding IP fragmentation will improve operating conditions overall,
and the performance of DNS/TCP has increased and will continue to increase.</t> and the performance of DNS/TCP has increased and will continue to increase.</t>
<t>If a UDP response packet is dropped in transit,
<t>If a UDP response packet is dropped in transit,
up to and including the network stack of the initiator, up to and including the network stack of the initiator,
it increases the attack window for poisoning the requestor's cache.</t> it increases the attack window for poisoning the requestor's cache.</t>
</section>
</section> <section anchor="ProblemOfFragmentation">
<section anchor="ProblemOfFragmentation"><name>Weaknesses of IP fragmentation</n <name>Weaknesses of IP Fragmentation</name>
ame> <t>"Fragmentation Considered Poisonous" <xref target="Herzberg2013"/> no
tes effective
<t>"Fragmentation Considered Poisonous" <xref target="Herzberg2013"></xref> note
d effective
off-path DNS cache poisoning attack vectors using IP fragmentation. off-path DNS cache poisoning attack vectors using IP fragmentation.
"IP fragmentation attack on DNS" <xref target="Hlavacek2013"></xref> and "Domain "IP fragmentation attack on DNS" <xref target="Hlavacek2013"/> and "Domain Valid
Validation++ ation++
For MitM-Resilient PKI" <xref target="Brandt2018"></xref> noted that off-path at For MitM-Resilient PKI" <xref target="Brandt2018"/> note that off-path attackers
tackers can intervene in the Path MTU Discovery <xref target="RFC1191"/>
can intervene in the path MTU discovery <xref target="RFC1191"/>
to cause authoritative servers to produce fragmented responses. to cause authoritative servers to produce fragmented responses.
<xref target="RFC7739"/> stated the <xref target="RFC7739"/> states the
security implications of predictable fragment identification values.</t> security implications of predictable fragment identification values.</t>
<t>In Section 3.2 (Message Side Guidelines) of UDP Usage Guidelines <xref target <!-- [rfced] For clarity, may we update the following sentence as
="RFC8085"/> shown below since some of the text is a direct quote from RFC 8085?
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.</t>
<t>A DNS message receiver cannot trust fragmented UDP datagrams primarily due to Current:
In Section 3.2 (Message Side Guidelines) of UDP Usage Guidelines [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 primaril
y due to
the small amount of entropy provided by UDP port numbers and DNS message the small amount of entropy provided by UDP port numbers and DNS message
identifiers, each of which being only 16 bits in size, and both likely identifiers, each of which is only 16 bits in size, and both are likely
being in the first fragment of a packet if fragmentation occurs. to be in the first fragment of a packet if fragmentation occurs.
By comparison, the TCP protocol stack controls packet size and avoids IP fragmen tation under ICMP NEEDFRAG attacks. By comparison, the TCP protocol stack controls packet size and avoids IP fragmen tation under ICMP NEEDFRAG attacks.
In TCP, fragmentation should be avoided for performance reasons, whereas for In TCP, fragmentation should be avoided for performance reasons, whereas for
UDP, fragmentation should be avoided for resiliency and authenticity reasons.</t > UDP, fragmentation should be avoided for resiliency and authenticity reasons.</t >
</section>
</section> <section anchor="dns-security-protections">
<section anchor="dns-security-protections"><name>DNS Security Protections</name> <name>DNS Security Protections</name>
<t>DNSSEC is a countermeasure against cache poisoning attacks that use
<t>DNSSEC is a countermeasure against cache poisoning attacks that use
IP fragmentation. IP fragmentation.
However, DNS delegation responses are not signed with DNSSEC, However, DNS delegation responses are not signed with DNSSEC,
and DNSSEC does not have a mechanism to get the correct response if and DNSSEC does not have a mechanism to get the correct response if
an incorrect delegation is injected. This is a denial-of-service an incorrect delegation is injected. This is a denial-of-service
vulnerability that can yield failed name resolutions. vulnerability that can yield failed name resolutions.
If cache poisoning attacks can be avoided, If cache poisoning attacks can be avoided,
DNSSEC validation failures will be avoided.</t> DNSSEC validation failures will be avoided.</t>
</section>
</section> <section anchor="possible-actions-for-resolver-operators">
<section anchor="possible-actions-for-resolver-operators"><name>Possible actions <name>Possible Actions for Resolver Operators</name>
for resolver operators</name> <t>Because this document is published as Informational
rather than a Best Current Practice,
<t>Because this document is published as an "Informational" document
rather than a "Best Current Practice,"
this section presents steps that resolver operators can take this section presents steps that resolver operators can take
to avoid vulnerabilities related to IP fragmentation.</t> to avoid vulnerabilities related to IP fragmentation.</t>
<t>To avoid vulnerabilities related to IP fragmentation,
implement R5 and R6.</t>
<t>To avoid vulnerabilities related to IP fragmentation, <t>Specifically, configure the firewall functions protecting the full-se
implement R5 and R6.</t> rvice resolver
<t>Specifically, configure the firewall functions protecting the full-service re
solver
to discard incoming DNS response packets to discard incoming DNS response packets
with a non-zero Fragment offset or a More Fragments (MF) bit of 1 on IPv4, with a non-zero Fragment Offset (FO) or a More Fragments (MF) bit of 1 on IPv4,
and discard packets with IPv6 Fragment Headers. and discard packets with IPv6 Fragment Headers.
(If the resolver's IP address is not dedicated to the DNS resolver (If the resolver's IP address is not dedicated to the DNS resolver
and uses UDP communication that relies on IP Fragmentation for purposes and uses UDP communication that relies on IP Fragmentation for purposes
other than DNS, discard only the first fragment that contains the UDP header other than DNS, discard only the first fragment that contains the UDP header
from port 53.)</t> from port 53.)</t>
<t>The most recent resolver software is believed to implement R7.</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 resoluti
on error,
<t>Even if R7 is not implemented, it will only result in a name resolution error
,
preventing attacks from leading to malicious sites.</t> preventing attacks from leading to malicious sites.</t>
</section>
</section> </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> </middle>
<back> <back>
<references>
<name>References</name>
<references anchor="sec-normative-references">
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
891.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
766.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
945.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
931.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
201.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
191.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
899.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
499.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
200.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
035.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
739.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
085.xml"/>
</references>
<references anchor="sec-informative-references">
<name>Informative References</name>
<references title='Normative References' anchor="sec-normative-references"> <!-- [rfced] Informative Reference URLs
<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 field
s whose range has been or soon will be exhausted and does not allow requestors t
o advertise their capabilities to responders. This document describes backward-c
ompatible mechanisms for allowing the protocol to grow.</t>
<t>This document updates the Extension Mechanisms for DNS (EDNS(0)) specif
ication (and obsoletes RFC 2671) based on feedback from deployment experience in
several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Doma
in Name System") and adds considerations on the use of extended labels in the DN
S.</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 transpo
rt 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 dynami
c updates to a DNS zone as coming from an approved client or to authenticate res
ponses 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 Requ
est and Transaction signature resource records ( SIG(0)s ) that implementation e
xperience 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 docu
ment defines these words as they should be interpreted in IETF documents. This d
ocument 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 specif
ications. This document aims to reduce the ambiguity by clarifying that only UPP
ERCASE 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 ver
sion 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"> a) We found the following URL for [Brandt2018]:
<front> https://dl.acm.org/doi/10.1145/3243734.3243790.
<title>Path MTU discovery</title> May we update this reference to use this URL?
<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 cha
nge 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 discove
r 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"> Original:
<front> [Brandt2018]
<title>Packetization Layer Path MTU Discovery for Datagram Transports</title Brandt, M., Dai, T., Klein, A., Shulman, H., and M. Waidner, "Domain
> Validation++ For MitM-Resilient PKI", Proceedings of the 2018 ACM
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/> SIGSAC Conference on Computer and Communications Security , 2018.
<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 datagr
am. This can be used to detect and reduce the message size when a sender encount
ers a packet black hole. It can also probe a network path to discover whether th
e maximum packet size can be increased. This provides functionality for datagram
transports that is equivalent to the PLPMTUD specification for TCP, specified i
n 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 P
MTUD 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"> Perhaps:
<front> [Brandt2018]
<title>DNS Terminology</title> Brandt, M., Dai, T., Klein, A., Shulman, H., and M.
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> Waidner, "Domain Validation++ For MitM-Resilient PKI",
<author fullname="A. Sullivan" initials="A." surname="Sullivan"/> Proceedings of the 2018 ACM SIGSAC Conference on Computer
<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/> and Communications Security, pp. 2060-2076,
<date month="January" year="2019"/> DOI 10.1145/3243734.3243790, October 2018,
<abstract> <https://dl.acm.org/doi/10.1145/3243734.3243790>.
<t>The Domain Name System (DNS) is defined in literally dozens of differen
t RFCs. The terminology used by implementers and developers of DNS protocols, an
d by operators of DNS systems, has sometimes changed in the decades since the DN
S was first defined. This document gives current definitions for many of the ter
ms 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"> b) We found the following URL for [Herzberg2013]:
<front> https://ieeexplore.ieee.org/document/6682711.
<title>Internet Protocol, Version 6 (IPv6) Specification</title> May we update this reference to use this URL?
<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 o
bsoletes 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"> Original:
<front> [Herzberg2013]
<title>Domain names - implementation and specification</title> Herzberg, A. and H. Shulman, "Fragmentation Considered Poisonous",
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> IEEE Conference on Communications and Network Security , 2013.
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised specification of the protocol and format used i
n 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"> Perhaps:
<front> [Herzberg2013]
<title>Security Implications of Predictable Fragment Identification Values</ Herzberg, A. and H. Shulman, "Fragmentation Considered
title> Poisonous, or: One-domain-to-rule-them-all.org", IEEE
<author fullname="F. Gont" initials="F." surname="Gont"/> Conference on Communications and Network Security (CNS),
<date month="February" year="2016"/> DOI 10.1109/CNS.2013.6682711, 2013,
<abstract> <https://ieeexplore.ieee.org/document/6682711>.
<t>IPv6 specifies the Fragment Header, which is employed for the fragmenta
tion and reassembly mechanisms. The Fragment Header contains an "Identification"
field that, together with the IPv6 Source Address and the IPv6 Destination Addr
ess of a packet, identifies fragments that correspond to the same original datag
ram, 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 rec
ently 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 implic
ations of predictable Identification values, and provides implementation guidanc
e for setting the Identification field of the Fragment Header, such that the afo
rementioned security implications are mitigated.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7739"/>
<seriesInfo name="DOI" value="10.17487/RFC7739"/>
</reference>
<reference anchor="RFC8085"> c) We found the following URL for [Fujiwara2018]:
<front> https://indico.dns-oarc.net/event/31/contributions/692/
<title>UDP Usage Guidelines</title> attachments/660/1115/fujiwara-5.pdf. May we update this
<author fullname="L. Eggert" initials="L." surname="Eggert"/> reference to use this URL?
<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 tra
nsport that has no inherent congestion control mechanisms. This document provide
s guidelines on the use of UDP for the designers of applications, tunnels, and o
ther 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 No
tification (ECN), Differentiated Services Code Points (DSCPs), and ports.</t>
<t>Because congestion control is critical to the stable operation of the I
nternet, 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 implemen
t 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 the
se 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> Original:
[Fujiwara2018]
Fujiwara, K., "Measures against cache poisoning attacks
using IP fragmentation in DNS", OARC 30 Workshop , 2019.
<references title='Informative References' anchor="sec-informative-reference Perhaps:
s"> [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>.
<reference anchor="Brandt2018" > d) We found the following URL for [Huston2021]:
<front> https://indico.dns-oarc.net/event/37/contributions/806/
<title>Domain Validation++ For MitM-Resilient PKI</title> attachments/782/1366/2021-02-04-dns-flag.pdf. May we add
<author initials="M." surname="Brandt" fullname="Markus Brandt"> this URL to the reference?
<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 year="2018"/>
</front>
<seriesInfo name="Proceedings of the 2018 ACM SIGSAC Conference on Computer an
d Communications Security" value=""/>
</reference>
<reference anchor="Herzberg2013" >
<front>
<title>Fragmentation Considered Poisonous</title>
<author initials="A." surname="Herzberg" fullname="Amir Herzberg">
<organization></organization>
</author>
<author initials="H." surname="Shulman" fullname="Haya Shulman">
<organization></organization>
</author>
<date year="2013"/>
</front>
<seriesInfo name="IEEE Conference on Communications and Network Security" valu
e=""/>
</reference>
<reference anchor="Hlavacek2013" target="https://ripe67.ripe.net/presentations/2
40-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 67 Meeting" value=""/>
</reference>
<reference anchor="Fujiwara2018" >
<front>
<title>Measures against cache poisoning attacks using IP fragmentation in DN
S</title>
<author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara">
<organization>JPRS</organization>
</author>
<date year="2019"/>
</front>
<seriesInfo name="OARC 30 Workshop" value=""/>
</reference>
<reference anchor="DNSFlagDay2020" target="https://dnsflagday.net/2020/">
<front>
<title>DNS flag day 2020</title>
<author >
<organization></organization>
</author>
<date year="n.d."/>
</front>
</reference>
<reference 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 34 Workshop" value=""/>
</reference>
<reference anchor="RFC8900"> Original:
<front> [Huston2021]
<title>IP Fragmentation Considered Fragile</title> Huston, G. and J. Damas, "Measuring DNS Flag Day 2020",
<author fullname="R. Bonica" initials="R." surname="Bonica"/> OARC 34 Workshop , February 2021.
<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 provid
es 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"> Perhaps:
<front> [Huston2021]
<title>Internet Protocol</title> Huston, G. and J. Damas, "Measuring DNS Flag Day 2020",
<author fullname="J. Postel" initials="J." surname="Postel"/> OARC 34 Workshop, February 2021, <https://indico.dns-oarc.net/
<date month="September" year="1981"/> event/37/contributions/806/attachments/782/1366/2021-02-04-dns-flag.pdf>
</front> -->
<seriesInfo name="STD" value="5"/> <reference anchor="Brandt2018">
<seriesInfo name="RFC" value="791"/> <front>
<seriesInfo name="DOI" value="10.17487/RFC0791"/> <title>Domain Validation++ For MitM-Resilient PKI</title>
</reference> <author initials="M." surname="Brandt" fullname="Markus Brandt">
<organization>Fraunhofer Institute for Secure Information Technolo
gy SIT, Darmstadt, Germany</organization>
</author>
<author initials="T." surname="Dai" fullname="Tianxiang Dai">
<organization>Fraunhofer Institute for Secure Information Technolo
gy SIT, Darmstadt, Germany</organization>
</author>
<author initials="A." surname="Klein" fullname="Amit Klein">
<organization>Fraunhofer Institute for Secure Information Technolo
gy SIT, Darmstadt, Germany</organization>
</author>
<author initials="H." surname="Shulman" fullname="Haya Shulman">
<organization>Fraunhofer Institute for Secure Information Technolo
gy SIT, Darmstadt, Germany</organization>
</author>
<author initials="M." surname="Waidner" fullname="Michael Waidner">
<organization>Fraunhofer Institute for Secure Information Technolo
gy SIT, Darmstadt, Germany</organization>
</author>
<date month="October" year="2018"/>
</front>
<refcontent>Proceedings of the 2018 ACM SIGSAC Conference on Computer
and Communications Security, pp. 2060-2076</refcontent>
<seriesInfo name="DOI" value="10.1145/3243734.3243790"/>
</reference>
<reference anchor="RFC4035"> <reference anchor="Herzberg2013">
<front> <front>
<title>Protocol Modifications for the DNS Security Extensions</title> <title>Fragmentation Considered Poisonous, or: One-domain-to-rule-th
<author fullname="R. Arends" initials="R." surname="Arends"/> em-all.org</title>
<author fullname="R. Austein" initials="R." surname="Austein"/> <author initials="A." surname="Herzberg" fullname="Amir Herzberg">
<author fullname="M. Larson" initials="M." surname="Larson"/> <organization/>
<author fullname="D. Massey" initials="D." surname="Massey"/> </author>
<author fullname="S. Rose" initials="S." surname="Rose"/> <author initials="H." surname="Shulman" fullname="Haya Shulman">
<date month="March" year="2005"/> <organization/>
<abstract> </author>
<t>This document is part of a family of documents that describe the DNS Se <date year="2013"/>
curity Extensions (DNSSEC). The DNS Security Extensions are a collection of new </front>
resource records and protocol modifications that add data origin authentication <refcontent>IEEE Conference on Communications and Network Security (CN
and data integrity to the DNS. This document describes the DNSSEC protocol modif S)</refcontent>
ications. This document defines the concept of a signed zone, along with the req <seriesInfo name="DOI" value="10.1109/CNS.2013.6682711"/>
uirements for serving and resolving by using DNSSEC. These techniques allow a se </reference>
curity-aware resolver to authenticate both DNS resource records and authoritativ
e DNS error indications.</t>
<t>This document obsoletes RFC 2535 and incorporates changes from all upda
tes to RFC 2535. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4035"/>
<seriesInfo name="DOI" value="10.17487/RFC4035"/>
</reference>
<reference anchor="RFC9471"> <reference anchor="Hlavacek2013" target="https://ripe67.ripe.net/present
<front> ations/240-ipfragattack.pdf">
<title>DNS Glue Requirements in Referral Responses</title> <front>
<author fullname="M. Andrews" initials="M." surname="Andrews"/> <title>IP fragmentation attack on DNS</title>
<author fullname="S. Huque" initials="S." surname="Huque"/> <author initials="T." surname="Hlavacek" fullname="Tomas Hlavacek">
<author fullname="P. Wouters" initials="P." surname="Wouters"/> <organization>cz.nic</organization>
<author fullname="D. Wessels" initials="D." surname="Wessels"/> </author>
<date month="September" year="2023"/> <date year="2013"/>
<abstract> </front>
<t>The DNS uses glue records to allow iterative clients to find the addres <refcontent>RIPE 67 Meeting</refcontent>
ses of name servers that are contained within a delegated zone. Authoritative se </reference>
rvers are expected to return all available glue records for in-domain name serve
rs 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 (Truncat
ed) flag to inform the client that the response is incomplete and that the clien
t should use another transport to retrieve the full response. This document upda
tes 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"> <reference anchor="Fujiwara2018">
<front> <front>
<title>Negative Caching of DNS Queries (DNS NCACHE)</title> <title>Measures against DNS cache poisoning attacks using IP fragmen
<author fullname="M. Andrews" initials="M." surname="Andrews"/> tation</title>
<date month="March" year="1998"/> <author initials="K." surname="Fujiwara" fullname="Kazunori Fujiwara
<abstract> ">
<t>RFC1034 provided a description of how to cache negative responses. It h <organization>JPRS</organization>
owever had a fundamental flaw in that it did not allow a name server to hand out </author>
those cached responses to other resolvers, thereby greatly reducing the effect <date year="2019"/>
of the caching. This document addresses issues raise in the light of experience </front>
and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]</t> <refcontent>OARC 30 Workshop</refcontent>
</abstract> </reference>
</front>
<seriesInfo name="RFC" value="2308"/>
<seriesInfo name="DOI" value="10.17487/RFC2308"/>
</reference>
<reference anchor="RFC2782"> <reference anchor="DNSFlagDay2020" target="https://dnsflagday.net/2020/"
<front> >
<title>A DNS RR for specifying the location of services (DNS SRV)</title> <front>
<author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen"/> <title>DNS flag day 2020</title>
<author fullname="P. Vixie" initials="P." surname="Vixie"/> <author>
<author fullname="L. Esibov" initials="L." surname="Esibov"/> <organization/>
<date month="February" year="2000"/> </author>
<abstract> <date></date>
<t>This document describes a DNS RR which specifies the location of the se </front>
rver(s) for a specific protocol and domain. [STANDARDS-TRACK]</t> </reference>
</abstract>
</front>
<seriesInfo name="RFC" value="2782"/>
<seriesInfo name="DOI" value="10.17487/RFC2782"/>
</reference>
<reference anchor="RFC9460"> <reference anchor="Huston2021">
<front> <front>
<title>Service Binding and Parameter Specification via the DNS (SVCB and HTT <title>Measuring DNS Flag Day 2020</title>
PS Resource Records)</title> <author initials="G." surname="Huston" fullname="Geoff Huston">
<author fullname="B. Schwartz" initials="B." surname="Schwartz"/> <organization>APNIC Labs</organization>
<author fullname="M. Bishop" initials="M." surname="Bishop"/> </author>
<author fullname="E. Nygren" initials="E." surname="Nygren"/> <author initials="J." surname="Damas" fullname="Joao Damas">
<date month="November" year="2023"/> <organization>APNIC Labs</organization>
<abstract> </author>
<t>This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS <date year="2021" month="February"/>
resource record (RR) types to facilitate the lookup of information needed to mak </front>
e connections to network services, such as for HTTP origins. SVCB records allow <refcontent>OARC 34 Workshop</refcontent>
a service to be provided from multiple alternative endpoints, each with associat </reference>
ed 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 p
roviding more information to the client before it attempts to establish a connec
tion, 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"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 900.xml"/>
<title>DNS Security (DNSSEC) Hashed Authenticated Denial of Existence</title <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
> 791.xml"/>
<author fullname="B. Laurie" initials="B." surname="Laurie"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="G. Sisson" initials="G." surname="Sisson"/> 035.xml"/>
<author fullname="R. Arends" initials="R." surname="Arends"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<author fullname="D. Blacka" initials="D." surname="Blacka"/> 471.xml"/>
<date month="March" year="2008"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<abstract> 308.xml"/>
<t>The Domain Name System Security (DNSSEC) Extensions introduced the NSEC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
resource record (RR) for authenticated denial of existence. This document intro 782.xml"/>
duces an alternative resource record, NSEC3, which similarly provides authentica <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
ted denial of existence. However, it also provides measures against zone enumera 460.xml"/>
tion and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
]</t> 155.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.26
</front> 71.xml"/>
<seriesInfo name="RFC" value="5155"/>
<seriesInfo name="DOI" value="10.17487/RFC5155"/>
</reference>
</references>
</references> </references>
<?line 442?> <section anchor="details">
<name>Details of Requestor's Maximum UDP Payload Size Discussions</name>
<t>There are many discussions about default path MTU size and a requestor'
s maximum UDP payload size.</t>
<ul spacing="normal">
<li>
<t>The minimum MTU for an IPv6 interface is 1280 octets
(see <xref section="5" sectionFormat="of" target="RFC8200"/>).
So, 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>
<!--[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.
<section anchor="details"><name>Details of requestor's maximum UDP payload size Original:
discussions</name> [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".
<t>There are many discussions for Current:
default path MTU size and requestor's maximum UDP payload size.</t> [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><list style="symbols"> <t><xref target="RFC4035"/> states that "A security-aware name server
<t>The minimum MTU for an IPv6 interface is 1280 octets <bcp14>MUST</bcp14> support the EDNS0 (<xref target="RFC2671"/>) message size ex
(see Section 5 of <xref target="RFC8200"/>). tension, [and it] <bcp14>MUST</bcp14> support a message size of at least 1220 oc
So, we can use it as the default path MTU value for IPv6. tets". Then, the smallest number of
The corresponding minimum MTU for an IPv4 interface is 68 (60 + 8)
<xref target="RFC0791"/>.</t>
<t><xref target="RFC4035"/> defines that "A security-aware name server MUST su
pport
the EDNS0 message size extension, MUST support a message
size of at least 1220 octets". Then, the smallest number of
the maximum DNS/UDP payload size is 1220.</t> the maximum DNS/UDP payload size is 1220.</t>
<t>In order to avoid IP fragmentation, </li>
<xref target="DNSFlagDay2020"></xref> proposed that the UDP requestors set the r <li>
equestor's <t>In order to avoid IP fragmentation,
payload size to 1232, and the UDP responders compose UDP responses so they fit <xref target="DNSFlagDay2020"/> proposes that UDP requestors set the requestor's
payload size to 1232 and UDP responders compose UDP responses so they fit
in 1232 octets. in 1232 octets.
The size 1232 is based on an MTU of 1280, which is required The size 1232 is based on an MTU of 1280, which is required
by the IPv6 specification <xref target="RFC8200"/>, by the IPv6 specification <xref target="RFC8200"/>,
minus 48 octets for the IPv6 and UDP headers.</t> minus 48 octets for the IPv6 and UDP headers.</t>
<t>Most of the Internet and especially the inner core has an MTU of at least </li>
<li>
<t>Most of the Internet, especially the inner core, has an MTU of at l
east
1500 octets. 1500 octets.
Maximum DNS/UDP payload size for IPv6 on MTU 1500 ethernet is Maximum DNS/UDP payload size for IPv6 on an MTU 1500 Ethernet is
1452 (1500 minus 40 (IPv6 header size) minus 8 (UDP header size)). 1452 (1500 minus 40 (IPv6 header size) minus 8 (UDP header size)).
To allow for possible IP options and distant tunnel overhead, To allow for possible IP options and distant tunnel overhead,
the recommendation of default maximum DNS/UDP payload size is 1400.</t> the recommendation of default maximum DNS/UDP payload size is 1400.</t>
<t><xref target="Huston2021"></xref> analyzed the result of <xref target="DNSF </li>
lagDay2020"></xref> and reported that <li>
<t><xref target="Huston2021"/> analyzes the result of <xref target="DN
SFlagDay2020"/> and reports that
their measurements suggest that in the interior of the Internet their measurements suggest that in the interior of the Internet
between recursive resolvers and authoritative servers between recursive resolvers and authoritative servers, the prevailing MTU is 150
the prevailing MTU is 1500 0
and there is no measurable signal of use of smaller MTUs and there is no measurable signal of use of smaller MTUs
in this part of the Internet, and proposed that in this part of the Internet. They propose that
their measurements suggest setting the EDNS0 requestor's UDP payload size to their measurements suggest setting the EDNS0 requestor's UDP payload size to
1472 octets for IPv4, and 1452 octets for IPv6.</t> 1472 octets for IPv4 and 1452 octets for IPv6.</t>
</list></t> </li>
</ul>
<t>As a result of discussions, <t>As a result of these discussions,
this document decided to recommend a value of 1400, this document recommends a value of 1400,
with smaller values also allowed.</t> with smaller values also allowed.</t>
</section>
</section> <section anchor="minimal-responses">
<section anchor="minimal-responses"><name>Minimal-responses</name> <name>Minimal Responses</name>
<t>Some implementations have a "minimal responses" configuration setting/o
<t>Some implementations have a "minimal responses" configuration setting/option ption that causes
that causes
a DNS server to make response packets smaller, containing only mandatory and a DNS server to make response packets smaller, containing only mandatory and
required data.</t> required data.</t>
<t>Under the minimal-responses configuration, <t>Under the minimal-responses configuration,
a DNS server composes responses containing only necessary RRs. a DNS server composes responses containing only necessary Resource Records (RRs)
.
For delegations, see <xref target="RFC9471"/>. For delegations, see <xref target="RFC9471"/>.
In case of a non-existent domain name or non-existent type, In case of a non-existent domain name or non-existent type,
the authority section will contain an SOA record and the answer section is empty the authority section will contain an SOA record, and the answer section is empt
. y
(defined in Section 2 of <xref target="RFC2308"/>).</t> (see <xref section="2" sectionFormat="of" target="RFC2308"/>).</t>
<t>Some resource records (MX, SRV, SVCB, and HTTPS) require
<t>Some resource records (MX, SRV, SVCB, HTTPS) require additional A, AAAA, and Service Binding (SVCB) records
additional A, AAAA, and SVCB records in the Additional section
in the Additional Section defined in <xref target="RFC1035"/>, <xref target="RFC2782"/>, and <xref target=
defined in <xref target="RFC1035"/>, <xref target="RFC2782"/> and <xref target=" "RFC9460"/>.</t>
RFC9460"/>.</t> <t>In addition, if the zone is DNSSEC signed and a query has the DNSSEC OK
bit,
<t>In addition, if the zone is DNSSEC signed and a query has the DNSSEC OK bit,
signatures are added in the answer section, signatures are added in the answer section,
or the corresponding DS RRSet and signatures are added in the authority 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 > Details are defined in <xref target="RFC4035"/> and <xref target="RFC5155"/>.</t >
</section>
<section anchor="impl">
<name>Known Implementations</name>
</section> <!--[rfced] Regarding Appendix C ("Known Implementations"), is it your
<section anchor="impl"><name>Known Implementations</name> 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.
-->
<t>This section records the status of known implementations of these best <!--[rfced] Since this document is "Informational", is it correct to
practices defined by this specification at the time of publication, and any 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> 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 made to
verify the information that was supplied by IETF contributors and presented here
.</t>
<section anchor="bind-9">
<t>Please note that the listing of any individual implementation here does not <!-- [rfced] Appendix C.1
imply endorsement by the IETF. Furthermore, no effort has been spent to
verify the information presented here that was supplied by IETF contributors.</t
>
<section anchor="bind-9"><name>BIND 9</name> 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.
<t>BIND 9 does not implement the recommendations 1 and 2 in <xref target="Recomm b) We find "the first recommendation of Section 3.2" and "recommendation 2
endationsResponders"/>.</t> 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?
<t>BIND 9 on Linux sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with a fallback to c) Please confirm if "recommendation 3" in the last entry is referring
IP_PMTUDISC_DONT.</t> to R7 of Section 3.2.
<t>BIND 9 on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG is disabled Original:
.</t> BIND 9 does not implement the recommendations 1 and 2 in Section 3.1
<t>Accepting PATH MTU Discovery for UDP is considered harmful and dangerous. For recommendation 3, BIND 9 will honor the requestor's size up to
BIND 9's settings avoid attacks to path MTU discovery.</t> the configured limit (max-udp-size)...
<t>For recommendation 3, BIND 9 will honor the requestor's size up to the In the case of recommendation 4, and the send fails with EMSGSIZE,
configured limit (<spanx style="verb">max-udp-size</spanx>). The UDP response pa BIND 9 set the TC bit and try to send a minimal answer again.
cket 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</s
panx>).</t>
<t>In the case of recommendation 4, and the send fails with EMSGSIZE, BIND 9 In the first recommendation of Section 3.2, BIND 9 uses the
set the TC bit and try to send a minimal answer again.</t> edns-buf-size option, with the default of 1232.
<t>In the first recommendation of <xref target="RecommendationsRequestors"/>, BI BIND 9 does implement recommendation 2 of Section 3.2.
ND 9 uses the <spanx style="verb">edns-buf-size</spanx>
option, with the default of 1232.</t>
<t>BIND 9 does implement recommendation 2 of <xref target="RecommendationsReques For recommendation 3, after two UDP timeouts, BIND 9 will fall back
tors"/>.</t> to TCP.
<t>For recommendation 3, after two UDP timeouts, BIND 9 will fall back to TCP.</ Perhaps:
t> BIND 9 does not implement R1 and R2 in Section 3.1.
</section> For R3 (Section 3.1), BIND 9 will honor the requestor's size up to
<section anchor="knot-dns-and-knot-resolver"><name>Knot DNS and Knot Resolver</n the configured limit (max-udp-size)...
ame>
<t>Both Knot servers set IP_PMTUDISC_OMIT to avoid path MTU spoofing. In the case of R4 (Section 3.1) and the send fails with EMSGSIZE,
UDP size limit is 1232 by default.</t> BIND 9 sets the TC bit and tries to send a minimal answer again.
<t>Fragments are ignored if they arrive over an XDP interface.</t> For R5 (Section 3.2), BIND 9 uses the edns-buf-size
option, with the default of 1232.
<t>TCP is attempted after repeated UDP timeouts.</t> BIND 9 does implement R6 (Section 3.2).
<t>Minimal responses are returned and are currently not configurable.</t> For R7 (Section 3.2), after two UDP timeouts, BIND 9 will fall back
to TCP.
<t>Smaller signatures are used, with ecdsap256sha256 as the default.</t> 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?
</section> Original:
<section anchor="powerdns-authoritative-server-powerdns-recursor-powerdns-dnsdis BIND 9 on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG is
t"><name>PowerDNS Authoritative Server, PowerDNS Recursor, PowerDNS dnsdist</nam disabled.
e>
<t><list style="symbols"> Perhaps:
<t>IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT</t> When BIND 9 is on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG
<t>default EDNS buffer size of 1232, no probing for smaller sizes</t> is disabled.
<t>no handling of EMSGSIZE</t> -->
<t>Recursor: UDP timeouts do not cause a switch to TCP. "Spoofing nearmisses" <name>BIND 9</name>
do.</t> <t>BIND 9 does not implement recommendations 1 and 2 in <xref target="Re
</list></t> commendationsResponders"/>.</t>
<t>BIND 9 on Linux sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with a fallb
ack to
IP_PMTUDISC_DONT.</t>
</section> <t>BIND 9 on systems with IP_DONTFRAG (such as FreeBSD), IP_DONTFRAG is
<section anchor="powerdns-authoritative-server"><name>PowerDNS Authoritative Ser disabled.</t>
ver</name> <t>Accepting Path MTU Discovery for UDP is considered harmful and danger
ous.
BIND 9's settings avoid attacks to Path MTU Discovery.</t>
<t>For recommendation 3, BIND 9 will honor the requestor's size up to th
e
configured limit (<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 (<tt>max-udp-size</tt>).</t>
<t>In the case of recommendation 4 and the send fails with EMSGSIZE, BIN
D 9
sets the TC bit and tries to send a minimal answer again.</t>
<t>In the first recommendation of <xref target="RecommendationsRequestor
s"/>, BIND 9 uses the <tt>edns-buf-size</tt>
option, with the default of 1232.</t>
<t>BIND 9 does implement recommendation 2 (<xref target="RecommendationsRequesto
rs"/>).</t>
<t><list style="symbols"> <t>For recommendation 3, after two UDP timeouts, BIND 9 will fall back t
<t>the default DNSSEC algorithm is 13</t> o TCP.</t>
<t>responses are minimal, this is not configurable</t> </section>
</list></t> <section 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. Th
e 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 Authoritative Server, PowerDNS Recursor, and PowerDNS dns
dist</name>
</section> <!--[rfced] May we make the first three bulleted items into complete
<section anchor="unbound"><name>Unbound</name> 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?
<t>Unbound sets IP_MTU_DISCOVER to IP_PMTUDISC_OMIT with fallback to 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; 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; "Spoofing ne
armisses" do.</t>
</li>
</ul>
</section>
<section anchor="powerdns-authoritative-server">
<name>PowerDNS Authoritative Server</name>
<ul spacing="normal">
<li>
<t>The default DNSSEC algorithm is 13.</t>
</li>
<li>
<t>Responses are minimal; this is not configurable.</t>
</li>
</ul>
</section>
<section 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 IP_PMTUDISC_DONT. It also disables IP_DONTFRAG on systems that have
it, but not on Apple systems. On systems that support it Unbound sets it, but not on Apple systems. On systems that support it, Unbound sets
IPV6_USE_MIN_MTU, with a fallback to IPV6_MTU at 1280, with a fallback 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 to IPV6_USER_MTU. It also sets IPV6_MTU_DISCOVER to IPV6_PMTUDISC_OMIT,
with a fallback to IPV6_PMTUDISC_DONT.</t> with a fallback to IPV6_PMTUDISC_DONT.</t>
<t>Unbound requests a UDP size of 1232 from peers, by default. The reque
stor's
size is limited to a max of 1232.</t>
<t>Unbound requests UDP size 1232 from peers, by default. The requestors <!--[rfced] Please clarify what "if that is smaller" means as the
size is limited to a max of 1232.</t> 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".
<t>After some timeouts, Unbound retries with a smaller size, if that is 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 smaller, at size 1232 for IPv6 and 1472 for IPv4. This does not do
anything since the flag day change to 1232.</t> anything since the flag day change to 1232.</t>
<t>Unbound has minimal responses as an option, default on.</t> <!--[rfced] May we update this sentence as follows for clarity?
</section> Original:
</section> 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> </back>
<!-- ##markdown-source: <!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is output in
H4sIAAAAAAAAA8Vc63IbR3b+30/RoX5YKgMQwJtIVqWyEC8WLVHkApS9ictl fixed-width font. In the txt output, there are no changes to the font,
DzANYMzBDHZ6hhTE8pPsn+RZsnmvfOec7rkBlLSbZKMqW+Rcuk+f63cuo263 and the quotation marks have been removed.
q/Ioj82JvrzRF1kwX5okD/IoTfTwPo3CIJkaHSX67P1Yp/cm0x/OblQwmWTm
/kQH9ER3Vn9Lhek0CZZYL8yCWd6NTD7rholNV90tT3d3+0rZPEjCX4I4TfBW Please review carefully and let us know if the output is acceptable or if any
nhVGqWiV8Y823+33j/u7KshMcKLTlcn4PavuHkBxkpssMXn3jLZS0yA/Aamz updates are needed.
VE3xhElsYd16NsfrS7xwfnuh1Co6UVrn6fREr42VH0Ozyhcneh+/2TTD4zPr -->
79r1svpVBUW+SDNaoIv/NPbDnbc9fVH8Fj0EWcAXhQFvg09FkmZR816azU/0
98EqSPTIzCOQttZjk91HU2P1adrr6Hd52ONHPZu/vxmN+QKdw+CQp4tonYaB <!-- [rfced] Terminology
vogym+vXcTjv6fMAPw72Ljp6r3vUHej3kV1E3bdgreybYbM0Kd/t3hUdfZve
rVO+O01DUDzoD7r9/uGBu1QkIM4Ry5dWC5bRt0cDvacPdgcH+mj/YMC3zDKI a) Throughout the text, the following terminology appears to be used
4hM9c0f9w2+rzPamae+3FbFKV7y66ekfoo+RqTHqJiji2kXm0PDHMdgyLbIo inconsistently. Please review these occurrences and let us know if/how they
X9eZ0eDDYLDf7+t3gX6T4ph6lAahkI6XTvSPaRraKDQdfTqsHfJ4v3+42zzh may be made consistent.
hyTKTajHUEoIIZ3p4dJk0TRoHHqgDw/6eu94D/8d79cPvQL9f8hMOAmypAfq
lYLYl1DUe3MCXYZGlr9p/TqDSKDWg6MT4Yozv52zFKsl+ocghtWRkn/7rb5I Don't Fragment flag (DF) bit vs. Don't Fragment (DF) bit
M30V5VfdkbFRHMFs9M3byx1hSKmJ9Kfr/nZcvuq5jcrLwuqrILsrbPsecxzG [Note: Should this be "Don't Fragment (DF) flag bit"
XySLdAYbv0wsqCpyo0G6iMHgojsHXMOtmS6SNE7n0N3L244+C7IlzDjMO/o7 per RFC 0791?]
g4eStdpO120Pz0Ytom6jIPmI/+aNe/84ooY9/TY2UdIia7iM8taNfxxNb3p6
vCjiZdCm6k2wDjZu/ePogmL9GERhYrK2ZkXTRWDijbv/F6TRurAR7Ep2JC4B More Fragments (MF) bit
BgsbwTrwJ1k6NSaMkjkbc74w/Jwenl5hye/Gw1M42gTEGApu2PI0Xa5AUaZh [Note: Should this be "More Fragments (MF) flag bit"
FfTLskhg/RxoKieEbd6Y7NPEZHOstnfSMN5m5MTq5HjgEvRNGtk0SQv7FUYL for consistency?]
PfQ7bKpi1r73dytMnVWX5+fnm8yon59Y8t7kD2l213TIpQD2mDVxcB9MzV2N
NUE2Jye9yPOVPXn5MotW5vBVj/7qIWi/XGXGeo7Zl7v7/W60InAQ5Hkwveut b) We made the following updates for consistency. Please let us know of
wlmDw4AnDeig5TmiGNjkK7gL1+OJbPsfeF67eZM1d/qpB160D9xm4+jy5lwf any objections.
vtJXCEtQO2KID/rs6esnuTKBhc6Ds3P4ewTtaTCFhq5YUfCyO5jVhaXfNs4t
YOzL522Dkuq824FJeeQKbtROeD0cneq9PoJqdmcX6arJkWM6Mai6iIP5WbDe Additional Section -> Additional section (per RFCs 1035 and 9460)
7e/2G2cm9DjDPbyx1nR3q4YAJtJDeIYVhJ57yboFHJgm+HWwhZHEI1qetoav [Note: RFC 2782 uses "Additional Data section"; please let
qC3/We5813PLtnjznUlns/YtQSQ37y9PATYmdvuK31NogyK1Fvw+DdLWjW3L us know if the current text is okay or if it should include
bfJ6fxuvL8ykp/c7dMiBUt1uF7gIaCiY5krdQose4HbitQKcjdM13M85WNPX "data".]
MxPk5GahOuQMiV0mCSYxKSH/lpmpiQjd5ykeCsn4jYpy62+EBPv10lgbzI22
0ScDrV0FhLM6+mEB169tsVoBOVveAYZN7hfeV8UkZH4dOr8iYG71ZO32xamx Path MTU discovery -> Path MTU Discovery (per RFC 8201)
a0+944dw5WVtHxAHmpcp/hdHdzgWUTcxpTmYUJFz2jCQBYzZfFylFmQ/mOAu Path MTU -> path MTU (per RFC 8201)
wXJYDIcPVqvYOTa9ylLg/jS2PXWZ68jCAK2NwBPahVOVp0yPyI8jgAM6IZ3W -->
H0wxYx4W8KXlah12oDaaJ8B17vkEwYl2KVbzLAjpQOmSOYRrt6c3CvJMLDHT
rZVACOBItu5BxqAUKVZBROnQ2GkWTXC4nIJm9OeCfvwC+T3Rm2UUhjFSLSRR <!-- [rfced] Abbreviations
WRoWU37i8VlU+/V39c/0R7V2fQB/4T3mEY4EoeANSFtOBOkE+vXpTUdPCpBX
EDOVy9pweLu2uVkKR9LpncmR0fG+zE6JBB3cWhoXtxX0D+EI67totAjuwY80 a) FYI - We have added expansions for the following abbreviations
RzKWa/Kf2Be5XdxFfIpDEjvZEUUybKJyYt+MFIjYXh6AhF1MYiRIeBuHqaGP per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
IPbqALuju4ksOqX8IF8EACF0+taJJEpGy1VsSm5DB+/T+N501AOZZRwzuaLO expansion in the document carefully to ensure correctness.
NTIfonzhlKhxUtGbVYw0EXx15OKaKlbkCcLqNAEZ8WuDQHJaZBmnCOQPkE9C
0qSuZA9YRlzB4+M/jS5OD4+OB7//DkMDZksiu+z9PzmP/w3fUa9MYP/7iHK4 Elliptic Curve Digital Signature Algorithm (ECDSA)
Dd2HJcH+kaqx2kG+vHZGMuVzqavbD6R0rHyJwzvuyPLSN9CaIF+AqRelA2JC Edwards-curve Digital Signature Algorithm (EdDSA)
mvSxhopaRNOa//F+UjyTEpGTweYpc45WaiMBdgyIR13a2OECg7xaPR8bA1EC Service Binding (SVCB)
6EIOy+tZA35CsAStofkC6kQ7Q5MjWbW9F0o9Pv4LdODouN/Ho1aSXtLtDa4p Resource Record (RR)
7w3wAN1ACpqzF/aVFz2tg0XRosp7gZ10Ku/OVSklBLUC1poHd7DTKafhHqin
E5KrsyCmLRQxgDyv8hAB3KR4OduSM9TDGv6dGAhTCchBpU6G7pwUV+wS3gt5 b) We notice that this document as well as RFCs 8900 and 9471 use
CisA2AVZBDGdjai4Cj5Gy2IJwMtL6TEp7fOr8fhFT1FObiAoOSj8FpHo9uyI "EDNS0" but RFC 6891 uses "EDNS(0)". Please let us know if using
BtPT7jxgKXGf6F0YOPvMkvLdJelD0uHw5R5yiumsIyFPOl1AUdj874xZaSSj "EDNS0" is preferred or if you would like to use "EDNS(0)".
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
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> </rfc>
 End of changes. 138 change blocks. 
1118 lines changed or deleted 883 lines changed or added

This html diff was produced by rfcdiff 1.48.