rfc9567xml2.original.xml   rfc9567.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.6.17 (Ruby 2.
6.10) -->
<!DOCTYPE rfc [ <!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 comments="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-dnsop-dns-error-reporting-08" number="9567" obsoletes="" updates="" xml:la ng="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<rfc ipr="trust200902" docName="draft-ietf-dnsop-dns-error-reporting-08" categor y="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
<front> <front>
<title abbrev="DNS-ER">DNS Error Reporting</title> <title abbrev="DNS Error Reporting">DNS Error Reporting</title>
<seriesInfo name="RFC" value="9567"/>
<author initials="R." surname="Arends" fullname="Roy Arends"> <author initials="R." surname="Arends" fullname="Roy Arends">
<organization>ICANN</organization> <organization>ICANN</organization>
<address> <address>
<email>roy.arends@icann.org</email> <email>roy.arends@icann.org</email>
</address> </address>
</author> </author>
<author initials="M." surname="Larson" fullname="Matt Larson"> <author initials="M." surname="Larson" fullname="Matt Larson">
<organization>ICANN</organization> <organization>ICANN</organization>
<address> <address>
<email>matt.larson@icann.org</email> <email>matt.larson@icann.org</email>
</address> </address>
</author> </author>
<date year="2024" month="April"/>
<date year="2024" month="March" day="04"/> <area>OPS</area>
<workgroup>dnsop</workgroup> <workgroup>dnsop</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>DNS error reporting is a lightweight reporting mechanism that provides
<t>DNS error reporting is a lightweight reporting mechanism that provides the op the operator of an authoritative server with reports on DNS resource records tha
erator of an authoritative server with reports on DNS resource records that fail t fail to resolve or validate. A domain owner or DNS hosting organization can us
to resolve or validate. A domain owner or DNS hosting organization can use thes e these reports to improve domain hosting. The reports are based on extended DNS
e reports to improve domain hosting. The reports are based on extended DNS error errors as described in RFC 8914.</t>
s as described in <xref target="RFC8914"/>.</t> <t>When a domain name fails to resolve or validate due to a misconfigurati
on or an attack, the operator of the authoritative server may be unaware of this
<t>When a domain name fails to resolve or validate due to a misconfiguration or . To mitigate this lack of feedback, this document describes a method for a vali
an attack, the operator of the authoritative server may be unaware of this. To m dating resolver to automatically signal an error to a monitoring agent specified
itigate this lack of feedback, this document describes a method for a validating by the authoritative server. The error is encoded in the QNAME; thus, the very
resolver to automatically signal an error to a monitoring agent specified by th act of sending the query is to report the error.</t>
e authoritative server. The error is encoded in the QNAME, thus the very act of
sending the query is to report the error.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<name>Introduction</name>
<t>When an authoritative server serves a stale DNSSEC-signed zone, the cry
ptographic signatures over the resource record sets (RRsets) may have lapsed. A
validating resolver will fail to validate these resource records.</t>
<t>Similarly, when there is a mismatch between the Delegation Signer (DS)
records at a parent zone and the key signing key at the child zone, a validating
resolver will fail to authenticate records in the child zone.</t>
<t>These are two of several failure scenarios that may go unnoticed for so
me time by the operator of a zone.</t>
<t>Today, there is no direct relationship between operators of validating
resolvers and authoritative servers. Outages are often noticed indirectly by end
users and reported via email or social media (if reported at all).</t>
<t>When records fail to validate, there is no facility to report this fail
ure in an automated way. If there is any indication that an error or warning has
happened, it may be buried in log files of the resolver or not logged at all.</
t>
<t>This document describes a method that can be used by validating resolve
rs to report DNSSEC validation errors in an automated way.</t>
<section anchor="introduction"><name>Introduction</name> <t>It allows an authoritative server to announce a monitoring agent to whi
<t>When an authoritative server serves a stale DNSSEC-signed zone, the cryptogra ch validating resolvers can report issues if those resolvers are configured to d
phic signatures over the resource record sets (RRsets) may have lapsed. A valida o so.</t>
ting resolver will fail to validate these resource records.</t> <t>The burden to report a failure falls on the validating resolver. It is
important that the effort needed to report failure is low, with minimal impact t
<t>Similarly, when there is a mismatch between the Delegation Signer (DS) record o its main functions. To accomplish this goal, the DNS itself is utilized to rep
s at a parent zone and the key signing key at the child zone, a validating resol ort the error.</t>
ver will fail to authenticate records in the child zone.</t> </section>
<section anchor="requirements-notation">
<t>These are two of several failure scenarios that may go unnoticed for some tim <name>Requirements Notation</name>
e by the operator of a zone.</t> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>Today, there is no direct relationship between operators of validating resolv "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
ers and authoritative servers. Outages are often noticed indirectly by end users ",
, and reported via E-Mail or social media (if reported at all).</t> "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t>When records fail to validate, there is no facility to report this failure in "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
an automated way. If there is any indication that an error or warning has happe be
ned, it may be buried in log files of the resolver or not logged at all.</t> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
<t>This document describes a method that can be used by validating resolvers to shown here.
report DNSSEC validation errors in an automated way.</t> </t>
</section>
<t>It allows an authoritative server to announce a monitoring agent where valida <section anchor="terminology">
ting resolvers can report issues if those resolvers are configured to do so.</t> <name>Terminology</name>
<t>The burden to report a failure falls on the validating resolver. It is import
ant that the effort needed to report failure is low, with minimal impact to its
main functions. To accomplish this goal, the DNS itself is utilized to report th
e error.</t>
</section>
<section anchor="requirements-notation"><name>Requirements Notation</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d
ocument are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <x
ref target="RFC8174"/> when, and only when, they appear in all capitals, as show
n here.</t>
</section>
<section anchor="terminology"><name>Terminology</name>
<t>DNS Terminology used in this document is from BCP 219 <xref target="RFC8499"/
>, with these additions:</t>
<dl>
<dt>Reporting resolver:</dt>
<dd>
<t>In the context of this document, "reporting resolver" is used as a shorth
and for a validating resolver that supports DNS error reporting.</t>
</dd>
<dt>Report query:</dt>
<dd>
<t>The DNS query used to report an error is called a report query. A report
query is for a DNS TXT resource record type. The content of the error report is
encoded in the QNAME of a DNS request to the monitoring agent.</t>
</dd>
<dt>Monitoring agent:</dt>
<dd>
<t>An authoritative server that receives and responds to report queries. Thi
s facility is indicated by a domain name, referred to as the agent domain.</t>
</dd>
<dt>Agent domain:</dt>
<dd>
<t>A domain name which is returned in the DNS Error Reporting EDNS0 option t
hat indicates where DNS resolvers can send error reports.</t>
</dd>
</dl>
</section>
<section anchor="overview"><name>Overview</name>
<t>An authoritative server indicates support for DNS error reporting by includin
g an EDNS0 Report-Channel option with OPTION-CODE [TBD] and the agent domain in
the response. The agent domain is a fully qualified, uncompressed domain name in
DNS wire format. The authoritative server MUST NOT include this option in the r
esponse if the configured agent domain is empty, or is the null label (which wou
ld indicate the DNS root).</t>
<t>The authoritative server includes the EDNS0 Report-Channel option unsolicited
. That is, the option is included in a response despite the EDNS0 Report-Channel
option being absent in the request.</t>
<t>If the authoritative server has indicated support for DNS error reporting and
there is an issue that can be reported via extended DNS errors, the reporting r
esolver encodes the error report in the QNAME of the report query. The reporting
resolver builds this QNAME by concatenating the _er label, the QTYPE, the QNAME
that resulted in failure, the extended error code (as described in <xref target
="RFC8914"/>), the label "_er" again, and the agent domain. See the example in <
xref target="example"/>. Note that a regular RCODE is not included because the R
CODE is not relevant to the extended error code.</t>
<t>The resulting report query is sent as a standard DNS query for a TXT DNS reso
urce record type by the reporting resolver.</t>
<t>The report query will ultimately arrive at the monitoring agent. A response i
s returned by the monitoring agent, which in turn can be cached by the reporting
resolver. This caching is essential. It dampens the number of report queries se
nt by a reporting resolver for the same problem, that is, once per TTL. However,
certain optimizations such as <xref target="RFC8020"/> and <xref target="RFC819
8"/> may reduce the number of error report queries as well.</t>
<t>This document gives no guidance on the content of the TXT resource record RDA
TA for this record.</t>
<section anchor="example"><name>Example</name>
<t>A query for "broken.test.", type A, is sent by a reporting resolver.</t>
<t>The domain "test." is hosted on a set of authoritative servers. One of these
authoritative servers serves a stale version of the "test." zone. This authorita
tive server has an agent domain configured: "a01.agent-domain.example.".</t>
<t>The authoritative server with the stale "test." zone receives the request for
"broken.test". It returns a response that includes the EDNS0 Report-Channel opt
ion with the domain name "a01.agent-domain.example.".</t>
<t>The reporting resolver is unable to validate the "broken.test" RRset for type <t>This document uses DNS terminology defined in BCP 219 <xref target="RFC
1 (an A record), due to an RRSIG record with an expired signature.</t> 9499"/>. This document also defines and uses the following terms:</t>
<dl>
<dt>Reporting resolver:</dt>
<dd>
<t>A validating resolver that supports DNS error reporting.</t>
</dd>
<dt>Report query:</dt>
<dd>
<t>The DNS query used to report an error. A report query is for a DNS
TXT resource record type. The content of the error report is encoded in the QNAM
E of a DNS request to the monitoring agent.</t>
</dd>
<dt>Monitoring agent:</dt>
<dd>
<t>An authoritative server that receives and responds to report querie
s. This facility is indicated by a domain name, referred to as the "agent domain
".</t>
</dd>
<dt>Agent domain:</dt>
<dd>
<t>A domain name that is returned in the EDNS0 Report-Channel option a
nd indicates where DNS resolvers can send error reports.</t>
</dd>
</dl>
</section>
<section anchor="overview">
<name>Overview</name>
<t>An authoritative server indicates support for DNS error reporting by in
cluding an EDNS0 Report-Channel option with OPTION-CODE 18 and the agent domain
in the response. The agent domain is a fully qualified, uncompressed domain name
in DNS wire format. The authoritative server <bcp14>MUST NOT</bcp14> include th
is option in the response if the configured agent domain is empty or is the null
label (which would indicate the DNS root).</t>
<t>The authoritative server includes the EDNS0 Report-Channel option unsol
icited. That is, the option is included in a response despite the EDNS0 Report-C
hannel option being absent in the request.</t>
<t>The reporting resolver constructs the QNAME "_er.1.broken.test.7._er.a01.agen <t>If the authoritative server has indicated support for DNS error reporti
t-domain.example." and resolves it. This QNAME indicates extended DNS error 7 oc ng and there is an issue that can be reported via extended DNS errors, the repor
curred while trying to validate "broken.test." type 1 record.</t> ting resolver encodes the error report in the QNAME of the report query. The rep
orting resolver builds this QNAME by concatenating the "_er" label, the QTYPE, t
he QNAME that resulted in failure, the extended DNS error code (as described in
<xref target="RFC8914"/>), the label "_er" again, and the agent domain. See the
example in <xref target="example"/> and the specification in <xref target="const
ructing-the-report-query"/>. Note that a regular RCODE is not included because t
he RCODE is not relevant to the extended DNS error code.</t>
<t>The resulting report query is sent as a standard DNS query for a TXT DN
S resource record type by the reporting resolver.</t>
<t>When this query is received at the monitoring agent (the operators of the aut <t>The report query will ultimately arrive at the monitoring agent. A resp
horitative server for a01.agent-domain.example), the agent can determine the "te onse is returned by the monitoring agent, which in turn can be cached by the rep
st." zone contained an expired signature record (extended error 7) for type A fo orting resolver. This caching is essential. It dampens the number of report quer
r the domain name "broken.test.". The monitoring agent can contact the operators ies sent by a reporting resolver for the same problem (that is, with caching, on
of "test." to fix the issue.</t> e report query per TTL is sent). However, certain optimizations, such as those d
escribed in <xref target="RFC8020"/> and <xref target="RFC8198"/>, may reduce th
e number of error report queries as well.</t>
<t>This document gives no guidance on the content of the RDATA in the TXT
resource
record.</t>
<section anchor="example">
<name>Example</name>
</section> <t>A query for "broken.test.", type A, is sent by a reporting resolver.<
</section> /t>
<section anchor="edns0-option-specification"><name>EDNS0 Option Specification</n <t>The domain "test." is hosted on a set of authoritative servers. One o
ame> f these authoritative servers serves a stale version of the "test." zone. This a
<t>This method uses an EDNS0 <xref target="RFC6891"/> option to indicate the age uthoritative server has an agent domain configured as "a01.agent-domain.example.
nt domain in DNS responses. The option is structured as follows:</t> ".</t>
<t>The authoritative server with the stale "test." zone receives the req
uest for "broken.test.". It returns a response that includes the EDNS0 Report-Ch
annel option with the domain name "a01.agent-domain.example.".</t>
<t>The reporting resolver is unable to validate the "broken.test." RRset
for type A (an RR type with value 1), due to an RRSIG record with an expired si
gnature.</t>
<figure><artwork><![CDATA[ <t>The reporting resolver constructs the QNAME "_er.1.broken.test.7._er.a
01.agent-domain.example." and resolves it. This QNAME indicates extended DNS err
or 7 occurred while trying to validate "broken.test." for a type A (an RR type w
ith value 1) record.
</t>
<t>When this query is received at the monitoring agent (the operators of
the authoritative server for "a01.agent-domain.example."), the agent can determ
ine the "test." zone contained an expired signature record (extended DNS error 7
) for type A for the domain name "broken.test.". The monitoring agent can contac
t the operators of "test." to fix the issue.</t>
</section>
</section>
<section anchor="edns0-option-specification">
<name>EDNS0 Option Specification</name>
<t>This method uses an EDNS0 <xref target="RFC6891"/> option to indicate t
he agent domain in DNS responses. The option is structured as follows:</t>
<artwork><![CDATA[
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION-CODE = TBD | OPTION-LENGTH | | OPTION-CODE = 18 | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AGENT DOMAIN / / AGENT DOMAIN /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork></figure> ]]></artwork>
<t>Field definition details:</t>
<t>Field definition details:</t> <dl>
<dt>OPTION-CODE:</dt>
<dl> <dd>
<dt>OPTION-CODE:</dt> <t>2 octets; an EDNS0 code that is used in an EDNS0 option to indicate
<dd> support for error reporting. The name for this EDNS0 option code is Report-Cha
<t>2 octets; an EDNS0 code that is used in an EDNS0 option to indicate suppo nnel.</t>
rt for error reporting. The name for this EDNS0 option code is Report-Channel.< </dd>
/t> <dt>OPTION-LENGTH:</dt>
</dd> <dd>
<dt>OPTION-LENGTH:</dt> <t>2 octets; contains the length of the AGENT DOMAIN field in octets.<
<dd> /t>
<t>2-octets; contains the length of the AGENT DOMAIN field in octets.</t> </dd>
</dd> <dt>AGENT DOMAIN:</dt>
<dt>AGENT DOMAIN:</dt> <dd>
<dd> <t>A fully qualified domain name <xref target="RFC9499"/> in uncompres
<t>A fully qualified domain name <xref target="RFC8499"/> in uncompressed DN sed DNS wire format.</t>
S wire format.</t> </dd>
</dd> </dl>
</dl> </section>
<section anchor="dns-error-reporting-specification">
</section> <name>DNS Error Reporting Specification</name>
<section anchor="dns-error-reporting-specification"><name>DNS error reporting sp <t>The various errors that a reporting resolver may encounter are listed i
ecification</name> n <xref target="RFC8914"/>. Note that not all listed errors may be supported by
<t>The various errors that a reporting resolver may encounter are listed in <xre the reporting resolver. This document does not specify what is or is not an erro
f target="RFC8914"/>. Note that not all listed errors may be supported by the re r.</t>
porting resolver. This document does not specify what is or is not an error.</t> <t>The DNS class is not specified in the error report.</t>
<section anchor="reporting-resolver-specification">
<t>The DNS class is not specified in the error report.</t> <name>Reporting Resolver Specification</name>
<section anchor="reporting-resolver-specification"><name>Reporting Resolver Spec <t>Care should be taken when additional DNS resolution is needed to resol
ification</name> ve the QNAME that contains the error report. This resolution itself could trigge
<t>Care should be taken when more DNS resolving is needed to resolve the error r r another error report to be created.
eporting QNAME. This resolving itself could trigger another error reporting to b A maximum expense or depth limit <bcp14>MUST</bcp14> be used to prevent
e created. A maximum expense or depth limit MUST be used to prevent
cascading errors.</t> cascading errors.</t>
<t>The EDNS0 Report-Channel option <bcp14>MUST NOT</bcp14> be included i n queries.</t>
<t>The EDNS0 Report-Channel option MUST NOT be included in queries.</t> <t>The reporting resolver <bcp14>MUST NOT</bcp14> use DNS error reportin
g if the authoritative server returned an empty AGENT DOMAIN field in the EDNS0
<t>The reporting resolver MUST NOT use DNS error reporting if the authoritative Report-Channel option.</t>
server returned an empty agent domain field in the EDNS0 Report-Channel option.<
/t>
<t>For the benefit of the monitoring agent to get more confidence that the repor
t is not spoofed, the reporting resolver SHOULD send error reports over TCP
<xref target="RFC7766"/> or other connection oriented protocols or SHOULD use DN
S COOKIEs <xref target="RFC7873"/>. This makes it harder to falsify the source
address.</t>
<t>A reporting resolver MUST validate responses received from the monitoring age
nt. There is no special treatment for responses to error-reporting queries. The
Security Considerations section contains the rationale behind this.</t>
<section anchor="constructing-the-report-query"><name>Constructing the Report Qu
ery</name>
<t>The QNAME for the report query is constructed by concatenating the following
elements:</t>
<t><list style="symbols">
<t>A label containing the string "_er".</t>
<t>The QTYPE that was used in the query that resulted in the extended DNS erro
r, presented as a decimal value, in a single DNS label. If additional QTYPEs wer
e present in the query, such as described in <xref target="I-D.ietf-dnssd-multi-
qtypes"/>, they are represented as unique, ordered decimal values separated by a
hyphen. As an example, if both QTYPE A and AAAA were present in the query, they
are presented as the label "1-28".</t>
<t>The list of non-null labels representing the query name which is the subjec
t of the DNS error report.</t>
<t>The extended DNS error, presented as a decimal value, in a single DNS label
.</t>
<t>A label containing the string "_er".</t>
<t>The agent domain. The agent domain as received in the EDNS0 Report-Channel
option set by the authoritative server.</t>
</list></t>
<t>If the report query QNAME exceeds 255 octets, it MUST NOT be sent.</t>
<t>The "_er" labels allow the monitoring agent to differentiate between the agen
t domain and the faulty query name. When the specified agent domain is empty, or
a null label (despite being not allowed in this specification), the report quer
y will have "_er" as a top-level domain as a result and not the original query.
The purpose of the first "_er" label is to indicate that a complete report query
has been received, instead of a shorter report query due to query minimization.
</t>
</section>
</section>
<section anchor="authoritative-server-specification"><name>Authoritative server
specification</name>
<t>The authoritative server MUST NOT include more than one EDNS0 Report-Channel
option in a response.</t>
<t>The authoritative server includes the EDNS0 Report-Channel option unsolicited
in responses. There is no requirement that the EDNS0 Report-Channel option is p
resent in queries.</t>
</section>
<section anchor="monitoring-agent-specification"><name>Monitoring agent specific
ation</name>
<t>It is RECOMMENDED that the authoritative server for the agent domain replies
with a positive response (i.e., not NODATA or NXDOMAIN) containing a TXT record.
</t>
<t>The monitoring agent SHOULD respond to queries received over UDP that have no
DNS COOKIE set with a response that has the truncation bit (TC bit) set to chal
lenge the resolver to re-query over TCP.</t>
</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>IANA is requested to assign the following DNS EDNS0 option code registry:</t>
<figure><artwork><![CDATA[
Value Name Status Reference
----- -------------- -------- ---------------
TBD Report-Channel Standard [this document]
]]></artwork></figure>
<t>IANA is requested to assign the following Underscored and Globally Scoped DNS
Node Name registry:</t>
<figure><artwork><![CDATA[
RR Type _NODE NAME Reference
----- ---------- ---------
TXT _er [this document]
]]></artwork></figure>
</section>
<section anchor="operational-considerations"><name>Operational Considerations</n
ame>
<section anchor="choosing-an-agent-domain"><name>Choosing an agent domain</name>
<t>It is RECOMMENDED that the agent domain be kept relatively short to allow for
a longer QNAME in the report query. The agent domain MUST NOT be a subdomain of
the domain it is reporting on. That is, if the authoritative server hosts the f
oo.example domain, then its agent domain MUST NOT end in foo.example.</t>
</section>
<section anchor="managing-caching-optimizations"><name>Managing Caching Optimiza
tions</name>
<t>The reporting resolver may utilize various caching optimizations that inhibit
subsequent error reporting to the same monitoring agent.</t>
<t>If the monitoring agent were to respond with NXDOMAIN (name error), <xref tar
get="RFC8020"/> states that any name at or below that domain should be considere
d unreachable, and negative caching would prohibit subsequent queries for anythi
ng at or below that domain for a period of time, depending on the negative TTL <
xref target="RFC2308"/>.</t>
<t>Since the monitoring agent may not know the contents of all the zones for whi
ch it acts as a monitoring agent, the monitoring agent MUST NOT respond with NXD
OMAIN for domains it is monitoring because that could inhibit subsequent queries
. One method to avoid NXDOMAIN is to use a wildcard domain name <xref target="RF
C4592"/> in the zone for the agent domain.</t>
<t>When the agent domain is signed, a resolver may use aggressive negative cachi
ng (described in <xref target="RFC8198"/>). This optimization makes use of NSEC
and NSEC3 (without opt-out) records and allows the resolver to do the wildcard s
ynthesis. When this happens, the resolver does not send subsequent queries becau
se it will be able to synthesize a response from previously cached material.</t>
<t>A solution is to avoid DNSSEC for the agent domain. Signing the agent domain
will incur an additional burden on the reporting resolver, as it has to validate
the response. However, this response has no utility to the reporting resolver o
ther than dampening the query load for error reports.</t>
</section>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>Use of DNS error reporting may expose local configuration mistakes in the rep
orting resolver, such as stale DNSSEC trust anchors to the monitoring agent.</t>
<t>DNS error reporting SHOULD be done using DNS query name minimization <xref ta
rget="RFC9156"/> to improve privacy.</t>
<t>DNS error reporting is done without any authentication between the reporting
resolver and the authoritative server of the agent domain.</t>
<t>Resolvers that send error reports SHOULD send these over TCP <xref target="RF
C7766"/> or SHOULD use DNS COOKIEs <xref target="RFC7873"/>. This makes it hard
to falsify the source address. The monitoring agent SHOULD respond to queries re
ceived over UDP that have no DNS COOKIE set with a response that has the truncat
ion bit (TC bit) set to challenge the resolver to re-query over TCP.</t>
<t>Well-known addresses of reporting resolvers can provide a higher level of con
fidence in the error reports, and potentially enable more automated processing o
f these reports.</t>
<t>Monitoring agents that receive error reports over UDP should consider that th <t>For the monitoring agent to gain more confidence that the report is no
e source of the reports and the reports itself may be false.</t> t spoofed, the reporting resolver <bcp14>SHOULD</bcp14> send error reports over
TCP
<xref target="RFC7766"/> or other connection-oriented protocols or <bcp14>SHOULD
</bcp14> use DNS Cookies <xref target="RFC7873"/>. This makes it harder to fals
ify the source address.</t>
<t>A reporting resolver <bcp14>MUST</bcp14> validate responses received
from the monitoring agent. There is no special treatment for responses to error-
reporting queries. <xref target="security-considerations"/> ("Security Considera
tions") contains the rationale behind this.</t>
<section anchor="constructing-the-report-query">
<name>Constructing the Report Query</name>
<t>The method described in this document will cause additional queries by the re <t>The QNAME for the report query is constructed by concatenating the
porting resolver to authoritative servers in order to resolve the report query.< following elements:</t>
/t> <ul spacing="normal">
<li>
<t>A label containing the string "_er".</t>
</li>
<li>
<t>The QTYPE that was used in the query that resulted in the exten
ded DNS error, presented as a decimal value, in a single DNS label. If additiona
l QTYPEs were present in the query, such as described in <xref target="I-D.ietf-
dnssd-multi-qtypes"/>, they are represented as unique, ordered decimal values se
parated by a hyphen. As an example, if both QTYPE A and AAAA were present in the
query, they are presented as the label "1-28".</t>
</li>
<li>
<t>The list of non-null labels representing the query name that is
the subject of the DNS error report.</t>
</li>
<li>
<t>The extended DNS error code, presented as a decimal value, in a
single DNS label.</t>
</li>
<li>
<t>A label containing the string "_er".</t>
</li>
<li>
<t>The agent domain. The agent domain as received in the EDNS0 Rep
ort-Channel option set by the authoritative server.</t>
</li>
</ul>
<t>This method can be abused by intentionally deploying broken zones with agent <t>If the QNAME of the report query exceeds 255 octets, it
domains that are delegated to victims. This is particularly effective when DNS <bcp14>MUST NOT</bcp14> be sent.</t>
requests that trigger error messages are sent through <t>The "_er" labels allow the monitoring agent to differentiate
open resolvers <xref target="RFC8499"/> or widely distributed network monitoring between the agent domain and the faulty query name. When the
systems that perform distributed queries from around the globe.</t> specified agent domain is empty, or is a null label (despite being
not allowed in this specification), the report query will have "_er"
as a top-level domain, and not the top-level domain from the query
name that was the subject of this error report. The purpose of the
first "_er" label is to indicate that a complete report query has
been received instead of a shorter report query due to query
minimization.</t>
</section>
</section>
<section anchor="authoritative-server-specification">
<name>Authoritative Server Specification</name>
<t>The authoritative server <bcp14>MUST NOT</bcp14> include more than on
e EDNS0 Report-Channel option in a response.</t>
<t>The authoritative server includes the EDNS0 Report-Channel option uns
olicited in responses. There is no requirement that the EDNS0 Report-Channel opt
ion be present in queries.</t>
</section>
<section anchor="monitoring-agent-specification">
<name>Monitoring Agent Specification</name>
<t>An adversary may create massive error report flooding to camouflage an attack <t>It is <bcp14>RECOMMENDED</bcp14> that the authoritative server for th
.</t> e agent domain reply with a positive response (i.e., not with NODATA or NXDOMAIN
) containing a TXT record.</t>
<t>The monitoring agent <bcp14>SHOULD</bcp14> respond to queries receive
d over UDP that have no DNS Cookie set with a response that has the truncation b
it (TC bit) set to challenge the resolver to requery over TCP.</t>
</section>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>IANA has assigned the following in the "DNS EDNS0 Option Codes (OPT)" r
egistry:</t>
<t>Though this document gives no guidance on the content of the TXT resource rec <table anchor="iana1">
ord RDATA for this record, if the RDATA content is logged, it MUST assume the co <name></name>
ntent can be malicious and take appropriate meassures to avoid exploitation. One <thead>
such method could be to log in hexadecimal. This would avoid remote code execut <tr>
ion through logging string attacks such as <xref target="CVE-2021-44228"/>.</t> <th>Value</th>
<th>Name</th>
<th>Status</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>18</td>
<td>Report-Channel</td>
<td>Standard</td>
<td>RFC 9567</td>
</tr>
</tbody>
</table>
<t>The rationale behind mandating DNSSEC validation for responses from a reporti <t>IANA has assigned the following in the "Underscored and Globally Scoped
ng agent, even if the agent domain is proposed to remain unsigned, is to mitigat DNS Node Names" registry:</t>
e the risk of a downgrade attack orchestrated by adversaries. In such an attack, <table anchor="iana2">
a victim's legitimately signed domain could be deceptively advertised as an age <name></name>
nt domain by malicious actors. Consequently, if the validating resolver treats i <thead>
t as unsigned, it is exposed to potential cache poisoning attacks. By enforcing <tr>
DNSSEC validation, this vulnerability is preemptively addressed.</t> <th>RR Type</th>
<th>_NODE NAME</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>TXT</td>
<td>_er</td>
<td>RFC 9567</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="acknowledgements"><name>Acknowledgements</name> <section anchor="operational-considerations">
<t>This document is based on an idea by Roy Arends and David Conrad. The authors <name>Operational Considerations</name>
would like to thank Peter van Dijk, Stephane Bortzmeyer, Shane Kerr, Vladimir C <section anchor="choosing-an-agent-domain">
unat, Paul Hoffman, Philip Homburg, Mark Andrews, Libor Peltan, Matthijs Mekking <name>Choosing an Agent Domain</name>
, Willem Toorop, Tom Carpay, Dick Franks, Ben Schwartz, Yaron Sheffer, Viktor Du <t>It is <bcp14>RECOMMENDED</bcp14> that the agent domain be kept relati
khovni, Wes Hardaker, James Gannon, Tim Wicinski, Warren Kumari, Gorry Fairhurst vely short to allow for a longer QNAME in the report query. The agent domain <bc
, Benno Overeinder, Paul Wouters and Petr Spacek for their contributions.</t> p14>MUST NOT</bcp14> be a subdomain of the domain it is reporting on. That is, i
f the authoritative server hosts the foo.example domain, then its agent domain <
bcp14>MUST NOT</bcp14> end in foo.example.</t>
</section>
<section anchor="managing-caching-optimizations">
<name>Managing Caching Optimizations</name>
<t>The reporting resolver may utilize various caching optimizations that
inhibit subsequent error reporting to the same monitoring agent.</t>
<t>If the monitoring agent were to respond with NXDOMAIN (name error), <
xref target="RFC8020"/> states that any name at or below that domain should be c
onsidered unreachable, and negative caching would prohibit subsequent queries fo
r anything at or below that domain for a period of time, depending on the negati
ve TTL <xref target="RFC2308"/>.</t>
<t>Since the monitoring agent may not know the contents of all the zones
for which it acts as a monitoring agent, the monitoring agent <bcp14>MUST NOT</
bcp14> respond with NXDOMAIN for domains it is monitoring because that could inh
ibit subsequent queries. One method to avoid NXDOMAIN is to use a wildcard domai
n name <xref target="RFC4592"/> in the zone for the agent domain.</t>
<t>When the agent domain is signed, a resolver may use aggressive negati
ve caching (described in <xref target="RFC8198"/>). This optimization makes use
of NSEC and NSEC3 (without opt-out) records and allows the resolver to do the wi
ldcard synthesis. When this happens, the resolver does not send subsequent queri
es because it will be able to synthesize a response from previously cached mater
ial.</t>
<t>A solution is to avoid DNSSEC for the agent domain. Signing the agent
domain will incur an additional burden on the reporting resolver, as it has to
validate the response. However, this response has no utility to the reporting re
solver other than dampening the query load for error reports.</t>
</section>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
<t>Use of DNS error reporting may expose local configuration mistakes in t
he reporting resolver, such as stale DNSSEC trust anchors, to the monitoring age
nt.</t>
<t>DNS error reporting <bcp14>SHOULD</bcp14> be done using DNS query name
minimization <xref target="RFC9156"/> to improve privacy.</t>
<t>DNS error reporting is done without any authentication between the repo
rting resolver and the authoritative server of the agent domain.</t>
<t>Resolvers that send error reports <bcp14>SHOULD</bcp14> send them over
TCP <xref target="RFC7766"/> or <bcp14>SHOULD</bcp14> use DNS Cookies <xref targ
et="RFC7873"/>. This makes it hard to falsify the source address. The monitoring
agent <bcp14>SHOULD</bcp14> respond to queries received over UDP that have no D
NS Cookie set with a response that has the truncation bit (TC bit) set to challe
nge the resolver to requery over TCP.</t>
<t>Well-known addresses of reporting resolvers can provide a higher level
of confidence in the error reports and potentially enable more automated process
ing of these reports.</t>
</section> <t>Monitoring agents that receive error reports over UDP should consider t
hat the source of the reports and the reports themselves may be false.</t>
<t>The method described in this document will cause additional queries by
the reporting resolver to authoritative servers in order to resolve the report q
uery.</t>
<t>This method can be abused by intentionally deploying broken zones with
agent domains that are delegated to victims. This is particularly effective whe
n DNS requests that trigger error messages are sent through
open resolvers <xref target="RFC9499"/> or widely distributed network monitoring
systems that perform distributed queries from around the globe.</t>
<t>An adversary may create massive error report flooding to camouflage an
attack.</t>
<t>Though this document gives no guidance on the content of the RDATA in
the TXT resource record, if the RDATA content is logged, the monitoring ag
ent
<bcp14>MUST</bcp14> assume the content can be malicious and take
appropriate measures to avoid exploitation. One such method could be to
log in hexadecimal. This would avoid remote code execution through
logging string attacks, such as the vulnerability described in <xref targe
t="CVE-2021-44228"/>.</t>
<t>The rationale behind mandating DNSSEC validation for responses from a r
eporting agent, even if the agent domain is proposed to remain unsigned, is to m
itigate the risk of a downgrade attack orchestrated by adversaries. In such an a
ttack, a victim's legitimately signed domain could be deceptively advertised as
an agent domain by malicious actors. Consequently, if the validating resolver tr
eats it as unsigned, it is exposed to potential cache poisoning attacks. By enfo
rcing DNSSEC validation, this vulnerability is preemptively addressed.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-dnssd-multi-qtypes" to="MULTI-QTYPES"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<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"/>
</references>
<references>
<name>Informative References</name>
<reference anchor="CVE-2021-44228" target="https://cve.mitre.org/cgi-bin
/cvename.cgi?name=CVE-2021-44228">
<front>
<title>CVE-2021-44228</title>
<author>
<organization>CVE</organization>
</author>
<date year="2021" month="November" day="26"/>
</front>
</reference>
<references title='Normative References'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
914.xml"/>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<front> 499.xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname='S. Bradner' initials='S.' surname='Bradner'/> 020.xml"/>
<date month='March' year='1997'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<abstract> 198.xml"/>
<t>In many standards track documents several words are used to signify the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
requirements in the specification. These words are often capitalized. This docu 891.xml"/>
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' target='https://www.rfc-editor.org/info/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>
</references>
<references title='Informative References'>
<reference anchor="CVE-2021-44228" target="https://cve.mitre.org/cgi-bin/cvename
.cgi?name=CVE-2021-44228">
<front>
<title>CVE-2021-44228</title>
<author >
<organization>Common Vulnerabilities and Exposures</organization>
</author>
<date year="2021" month="December" day="10"/>
</front>
</reference>
<reference anchor='RFC8914' target='https://www.rfc-editor.org/info/rfc8914'>
<front>
<title>Extended DNS Errors</title>
<author fullname='W. Kumari' initials='W.' surname='Kumari'/>
<author fullname='E. Hunt' initials='E.' surname='Hunt'/>
<author fullname='R. Arends' initials='R.' surname='Arends'/>
<author fullname='W. Hardaker' initials='W.' surname='Hardaker'/>
<author fullname='D. Lawrence' initials='D.' surname='Lawrence'/>
<date month='October' year='2020'/>
<abstract>
<t>This document defines an extensible method to return additional informa
tion about the cause of DNS errors. Though created primarily to extend SERVFAIL
to provide additional information about the cause of DNS and DNSSEC failures, th
e Extended DNS Errors option defined in this document allows all response types
to contain extended error information. Extended DNS Error information does not c
hange the processing of RCODEs.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='8914'/>
<seriesInfo name='DOI' value='10.17487/RFC8914'/>
</reference>
<reference anchor='RFC8499' target='https://www.rfc-editor.org/info/rfc8499'>
<front>
<title>DNS Terminology</title>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'/>
<author fullname='A. Sullivan' initials='A.' surname='Sullivan'/>
<author fullname='K. Fujiwara' initials='K.' surname='Fujiwara'/>
<date month='January' year='2019'/>
<abstract>
<t>The Domain Name System (DNS) is defined in literally dozens of 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='BCP' value='219'/>
<seriesInfo name='RFC' value='8499'/>
<seriesInfo name='DOI' value='10.17487/RFC8499'/>
</reference>
<reference anchor='RFC8020' target='https://www.rfc-editor.org/info/rfc8020'>
<front>
<title>NXDOMAIN: There Really Is Nothing Underneath</title>
<author fullname='S. Bortzmeyer' initials='S.' surname='Bortzmeyer'/>
<author fullname='S. Huque' initials='S.' surname='Huque'/>
<date month='November' year='2016'/>
<abstract>
<t>This document states clearly that when a DNS resolver receives a respon
se with a response code of NXDOMAIN, it means that the domain name which is thus
denied AND ALL THE NAMES UNDER IT do not exist.</t>
<t>This document clarifies RFC 1034 and modifies a portion of RFC 2308: it
updates both of them.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='8020'/>
<seriesInfo name='DOI' value='10.17487/RFC8020'/>
</reference>
<reference anchor='RFC8198' target='https://www.rfc-editor.org/info/rfc8198'>
<front>
<title>Aggressive Use of DNSSEC-Validated Cache</title>
<author fullname='K. Fujiwara' initials='K.' surname='Fujiwara'/>
<author fullname='A. Kato' initials='A.' surname='Kato'/>
<author fullname='W. Kumari' initials='W.' surname='Kumari'/>
<date month='July' year='2017'/>
<abstract>
<t>The DNS relies upon caching to scale; however, the cache lookup general
ly requires an exact match. This document specifies the use of NSEC/NSEC3 resour
ce records to allow DNSSEC-validating resolvers to generate negative answers wit
hin a range and positive answers from wildcards. This increases performance, dec
reases latency, decreases resource utilization on both authoritative and recursi
ve servers, and increases privacy. Also, it may help increase resilience to cert
ain DoS attacks in some circumstances.</t>
<t>This document updates RFC 4035 by allowing validating resolvers to gene
rate negative answers based upon NSEC/NSEC3 records and positive answers in the
presence of wildcards.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='8198'/>
<seriesInfo name='DOI' value='10.17487/RFC8198'/>
</reference>
<reference anchor='RFC6891' target='https://www.rfc-editor.org/info/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='I-D.ietf-dnssd-multi-qtypes' target='https://datatracker.ietf
.org/doc/html/draft-ietf-dnssd-multi-qtypes-00'>
<front>
<title>DNS Multiple QTYPEs</title>
<author fullname='Ray Bellis' initials='R.' surname='Bellis'>
<organization>Internet Systems Consortium, Inc.</organization>
</author>
<date day='4' month='December' year='2023'/>
<abstract>
<t> This document specifies a method for a DNS client to request
additional DNS record types to be delivered alongside the primary
record type specified in the question section of a DNS query.
</t>
</abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dnssd-multi-qtypes-00'/>
</reference>
<reference anchor='RFC2308' target='https://www.rfc-editor.org/info/rfc2308'>
<front>
<title>Negative Caching of DNS Queries (DNS NCACHE)</title>
<author fullname='M. Andrews' initials='M.' surname='Andrews'/>
<date month='March' year='1998'/>
<abstract>
<t>RFC1034 provided a description of how to cache negative responses. It h
owever had a fundamental flaw in that it did not allow a name server to hand out
those cached responses to other resolvers, thereby greatly reducing the effect
of the caching. This document addresses issues raise in the light of experience
and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='2308'/>
<seriesInfo name='DOI' value='10.17487/RFC2308'/>
</reference>
<reference anchor='RFC4592' target='https://www.rfc-editor.org/info/rfc4592'>
<front>
<title>The Role of Wildcards in the Domain Name System</title>
<author fullname='E. Lewis' initials='E.' surname='Lewis'/>
<date month='July' year='2006'/>
<abstract>
<t>This is an update to the wildcard definition of RFC 1034. The interacti
on with wildcards and CNAME is changed, an error condition is removed, and the w
ords defining some concepts central to wildcards are changed. The overall goal i
s not to change wildcards, but to refine the definition of RFC 1034. [STANDARDS-
TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='4592'/>
<seriesInfo name='DOI' value='10.17487/RFC4592'/>
</reference>
<reference anchor='RFC9156' target='https://www.rfc-editor.org/info/rfc9156'>
<front>
<title>DNS Query Name Minimisation to Improve Privacy</title>
<author fullname='S. Bortzmeyer' initials='S.' surname='Bortzmeyer'/>
<author fullname='R. Dolmans' initials='R.' surname='Dolmans'/>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'/>
<date month='November' year='2021'/>
<abstract>
<t>This document describes a technique called "QNAME minimisation" to impr
ove DNS privacy, where the DNS resolver no longer always sends the full original
QNAME and original QTYPE to the upstream name server. This document obsoletes R
FC 7816.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='9156'/>
<seriesInfo name='DOI' value='10.17487/RFC9156'/>
</reference>
<reference anchor='RFC7766' target='https://www.rfc-editor.org/info/rfc7766'> <!-- [I-D.ietf-dnssd-multi-qtypes] IESG state: I-D Exists as of 4/16/24 -->
<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='RFC7873' target='https://www.rfc-editor.org/info/rfc7873'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<front> ietf-dnssd-multi-qtypes.xml"/>
<title>Domain Name System (DNS) Cookies</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'/>
<author fullname='M. Andrews' initials='M.' surname='Andrews'/>
<date month='May' year='2016'/>
<abstract>
<t>DNS Cookies are a lightweight DNS transaction security mechanism that p
rovides limited protection to DNS servers and clients against a variety of incre
asingly common denial-of-service and amplification/ forgery or cache poisoning a
ttacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network A
ddress Translation - Protocol Translation), and anycast and can be incrementally
deployed. (Since DNS Cookies are only returned to the IP address from which the
y were originally received, they cannot be used to generally track Internet user
s.)</t>
</abstract>
</front>
<seriesInfo name='RFC' value='7873'/>
<seriesInfo name='DOI' value='10.17487/RFC7873'/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
308.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
592.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
156.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.7
873.xml"/>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>This document is based on an idea by <contact fullname="Roy Arends"/> an
d <contact fullname="David Conrad"/>. The authors would like to thank <contact f
ullname="Peter van Dijk"/>, <contact fullname="Stephane Bortzmeyer"/>, <contact
fullname="Shane Kerr"/>, <contact fullname="Vladimir Cunat"/>, <contact fullname
="Paul Hoffman"/>, <contact fullname="Philip Homburg"/>, <contact fullname="Mark
Andrews"/>, <contact fullname="Libor Peltan"/>, <contact fullname="Matthijs Mek
king"/>, <contact fullname="Willem Toorop"/>, <contact fullname="Tom Carpay"/>,
<contact fullname="Dick Franks"/>, <contact fullname="Ben Schwartz"/>, <contact
fullname="Yaron Sheffer"/>, <contact fullname="Viktor Dukhovni"/>, <contact full
name="Wes Hardaker"/>, <contact fullname="James Gannon"/>, <contact fullname="Ti
m Wicinski"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Gorry Fai
rhurst"/>, <contact fullname="Benno Overeinder"/>, <contact fullname="Paul Woute
rs"/>, and <contact fullname="Petr Spacek"/> for their contributions.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAKgk5mUAA91cbXMbN5L+zl+Bkz+cXEcykuzEtq62cookO9pYkiMxyaay
WylwBiQRDQfMYEYynfh++z3dDcwLOZST2nw6emOT8wJ0N/rl6UZjR6PRIHGp
zefHqipno5eD0paZOVZnV7fqvChcoW7MyhUlnhjo6bQw93xvdH4zSF2S6yWe
TQs9K0fW4P00925Ff48MvTwq4sujg5cDuyqOVVlUvjw6OHh1cDRIdGnmrlgf
K1+mA18WRi+P1cX55PUgxa1jdXRw9Hx08Gx08Bx3dZ7+rDOX4/ra+MEDSObp
BncPeCkvTZGbcnRGxAxW9lj9VLpkqDzmL8zM49t6KV8St1yavPT/GgxsPnPF
Upf23hwPlDr9/nyEOQ9Hz58fHb2kK0qVupib8lgtynLljz/7LLk346XFmGNX
zD9L5nY0tTldJWGM8ftL+vK37lA8kq7KhStkVKXw9rE6BSkuV99XWW4KPbWZ
La3xCqyq8/cr56sCnDIVsiw9o9aSOhwdHo0ODwaDQTPRiB+RZbpxa3VSmDyV
EXn+i9OTqyv+aZbaZseqcOux5of+xyY6z4nJjXEudVmqt7rwLn9kIAi1HGf8
VGukwWg0UnqKpdZJOSAlYz1RtZ4oC+5VZueL8sHQ361bS5MsdG79UpULXapV
4e5tCmmVC6PcCvIrMZKbQXpB1LbklVXeFPemUA+2XIThvILUaXrI11VFYvAl
cUXqZegZWFCl47sZBsC49zqzJOqxOlGpA4+5cg9YNLpHAy2cZyLBJWj8gIkx
A/hWlTdEoTf11BjYLol6E0cKL4/VZNE8hmVQU+1NSrSa9yUWBd9rmeEBr8B+
UtgprmOU33778ub16ctXh88/fhwPBj8sDAQRp6C1Y778DsZUWhm6pdXS+sTl
MzuvCmEDT5FMy1Ind8MtcdPvXnkv9VpNjapy/UC88KPWg0mHKUo7p0npisow
Lt2eGZNOwxy4DAdTkaHWXJJqLA1mStWMaIq0k9wDRwWzUJWOjDrRWbZW3s5z
nREHomvCo8st6Kc39Zzm8CuT2JmFJKfrnSzJAskwINDk8J0ie3rj26uTy3Oi
vRKdxAtrBT0n1jxWjyaj679WdMOGhaDF5ss87FhMZGnTNDODJ+TXCpdWCa1D
WNEd2s3/kITgKTNDenJ7fjoi5kHhB7hNWbmkWK9KNy/0amETkU1JXkY5Fh7r
X8ckMDCUcf/mhv59you60Jg20yvoJplDaxWaZXiwWVbbUa1j0RC6Rgemb+3S
wltk66F6IC7xIFSGnQHUEYuZLKBL8AlyT52ZzMxFO2+JxULtn90+ra0YNqzV
ihxZybyzR6X37owoBBFL37XIPlnYLEqpX606/NACYGhLAayeM2hBMxTYmjC/
pP3lgxM9wGBaRoLYlU8QNwrrguMh6c4dTCZ3GN2InnsH0y0t/gqq2XF29VQu
1ethI7jcqdSCNvKgGUvKL+yqFmIcw9MgPQxLEOrTNFjwdVXCasRFuRk8k4r0
2lwmhd2BWCg9+b8CQZdGE2XHU/dWq/PRJUmT+UssRLI0KS7v21nzHC1jlj2N
zixKelOtulzPdEJxdN0xL+trkdtoQ+QjMMmDXo/Vxaylcvma+UhEv3hhau+B
/8Gbsf4s4IAXerUysLChsmV0eNOqsOIVMjdXM5sZH/1krU4YBiKjB+Y1n6wv
n/B7TAyFFXKsXrxV7+o1zIsnqJ9yeYwffYIYDC6YFvfgd3oaMgAoaJXDgns8
6QPLsZcoIjxQZb2vwJgluThv2nqHt2P8AVWYLXXQEbEmEm5KPqBmT9cLOwPd
HNjZ+W7Pj1WmeSn44kWdlyJN9r2zGY2VIwDJlGHwWmcQpNzDUCDE0uZ2CYXF
OOTdKZzDQ3KUnUEobGoc5XQCqLnKrF+IBs6dzsQLUxTHSyab0dBVCYX90Jm4
HRCeAIP/WsGsGLWqK1fyMrI4yIc9sFHsXX53O9kbyr/q6pq/35x/+93FzfkZ
fb/9+uTt2/pLfOL26+vv3p4135o3T68vL8+vzuRlXFUbly5PftwTu967fje5
uL46ebsnTrCtw+z7HKmrJYi+Kgwb9gZ0+er0nTp8DgTzH0AwR4eHrz5+DD9e
Hr4AnOGgIJO5HL5FfkJI8OAwQF2wMsNDJ3oFbc3I4XjlF4BoitSRpTgxBZbO
webWA8aerQtiTFvUk9so3JLpOzp8FSHW81cgMGiDhDSdppYX/ngwqDOmWvOO
B5ShSHhwEMP7MqKheioItNh6b4+1w4vANPFTQGXzR+EPqbSvVoIhexD2OBIo
OIRImwSNFGDC87XsK28ADwEqIibe4xcIArR/s9CYPpbxPyZbiKJcr4xAKZZG
Xkb32CZ1F8CSoCfYHfN5NkC6u+mIwOjlxiVi9mSXVyPBgUBj70MGBrJXLk/b
vpQYRIJGxHNECZGGnIoEDPHIHdQ9xMszcCZS1YINxVXKUyD0pPWTiezA9gdA
tQVNAuOpirwRSE+Wrs5x8QDhvYldkTQfXHPMexqfTOi0I3zPBnONB+6teQB9
O4TWDB1Ujle+L6+bUkxNsopRMKYUMoXs0SmUOjdZpJrtSnzK6PT67Fz986fJ
V2f//FeN4trSi7KQ1fJBsbpPkPHMKkoGfq1gMwTzhwBZ5J3xGul7W9xWUsMH
SzGFywNhzD4JRG8buAsZTWBkgzSJdp3otkmnWa5KoDgxN3o2B9nA2lNIZ1/0
4MFVWVpLvtaDwrnyaQiSO9aKCZRhHxN/lUM3bGJLgvcT1iAf0z5hy8fBWBN1
wyCGh/81n5xialgNpp6dbJQSmzNBkEeSSgJdja19SuuCwkRcJ6ijA6I6mLQn
yx4G2jZdc/BNvsdvbTir5v3oLyf9I04rZA5eFEjehtFAV4jVXNw8jfUzHmWF
ENK+nfz47nzYmjI4Ml9lpaxPADHyTM2i0Ew8qP3HKglP5T1Rwb2fKSjpObR1
2GuNY3VrTJhIA/sYGS78+PhxTPAlrADpzbxC1qdu2MoZvpeNak1NokP1pPsE
Ehpzz/jN7eIpGIKIQaTcjVCseTrky3mqi7QVAiV8UejqqRFx+Iqp2PYy1jO3
5uPkkQghoA0vpIuCVDqAz63AxQE1uoyW1w9zbj4/jAECiocHo2YnOlk0L/UQ
KkGMHguFN3KFyGp1xkg5xZKZPHqh5dRwvtkNhCJGjng9Ck1ipLc9edVV4aaZ
WQ5DTIJhOUogkIaqyeTtWH3tHig3HqrEAJxTeQ2uYhkqaRRfwCHWK6jmwdEB
UCFpYLhw+OolLlAGBrdaJWaD7I6FRuIx3IPpybvmDAGQSs4r4Cui0rXAWwNX
+rDNzdnJ5CRwzmtHVymaPlHnwSJ+exLNYXDSUri9aeHuTD4uyQkCWbOanQxr
Zd0h5aBvIYTsydv0EhUVpXioqYbDuGlHOp+H6hwj2b5nNqtLdI0rgyKIOCuX
IkStdjpvyirbQa8JhsdqTx8cjvnuKLiTIKnx3mORLeLwQFybmgbRtULMlrj3
WOHFznw7ngX89AcDZ01HG018mqceyyHYn2vYy2b1rEu24qqcaBtpyyFcec7e
g7QOnjvWdHM8eXvxJiopE0rA/v3KEgqpy4C7KcIy+bKoktK3Qg2Fg/HhuK24
L8Z0bTfPEVnTqIjkZVAXGa+Bk9uRWL1QLkkqxtHwdySaYs0xsSWhrg1FodRG
+IOUFjFfHQeCfqS7nLHab1fc/KMFbw4bOzgPYVTGJA+dIhGm9NNsWRC7GbxK
RPWsUVzE/Y2w9+Jpowgnte/tqGJHOoJDtvgl2piApFRbrEcyIfOZfc/3GVJx
uiCmcS22cCv19CSWKiDqUMJCSPdNBiDu+wtgDbjvmLW4LrzdhPshKLOJemGj
QaaipQKuKRHlWhay8v/FJ2y9bXwOe/4c9fx5pp4N1AHffKaeq8/VF9DJl+rV
n7rW9xn81+jf/DP4PY7VTpv+ppA2yeXfu7ffnl+9mXzdIuF30DAa/Vv/DT7r
ZY4+J2/Or4Clri9PLq52PqQ++wto4FUevLYGKVJqZjbnqgwZG219QQ1a8qFE
+whOpTSl/+9GIxkSB5BSl4Xquz0q2k5CNostirVTNt8iJugMxLPhYjeijGtC
ZaWY1FEkNfgH8cSZyefw5sEvdSQ9YzEQlOIXqc7Qui11ho20uOMv2tUuGqaT
MW+myOQBenMwv+EJqDZbWFf5WIeuk4GtoENwjvKsikqHXErMrC97djtbWQUl
CFQJDE+GOUJpPizVH4DFTRHeGck6hA+qPYpqSI7O0+V1rTaW0pJMex/vN3uL
ITdsi0iwYVO/uYnMdz3oKXHvF5z7g5FSw5HLVtnSdWo6Acu3S9my17s5MT3I
YTdw3HpdKtMJT1YWdj4n6YOThdnS8FDcTQqjS9kOXOr3dlktKXAZwlB4OjUr
qGgGOF9KwSTuXuBl6NM95DxItE80V4dkyYIwH8Nbde2Fq8tNQSJW6XaCmfpF
Si97uxAeifJ1OkbLTuWabnyqje4TaBHUvQ4xempyuKo6rdgKyZDSHDCPF5rh
cmryxDS7F03BVLTNuRkVuHYULkKdf7vmJ1vAk9N3g99+g2m9ePHFFxSTkT/x
wmPm3CShIcCCLogASV3pEpexNYSBo0xPr6+/uTinjI0Ge/niGdmpqNoS2kvg
DwlBkcqO0kxnnqyLYbxkVDpNydeMFfzWzlWsoV8NCBpIx6X7/gx70towZPPU
maL+o5JtfsZCieOBuo1upnYd2KhbA1hKZeBTPI+1KWLKGqTVcddyk9KUqUHe
nYaeCHICT3gAhi+x1hMq9d8SWhVtFqAc0d1mVaNG6eLhtotHgofYyjLZT0JM
HMFqpb4TSI1PYyz6ylUf6kxgdrngJMr3oH1r4yR2NmwVoDo1mtrchmT6XvSI
CzEploH21bCklRlKZdFjfulmEAp5pzZutuBZJobS+MLE4TrEDOvCwWaB62J0
No49az4dLak8M/qV0LOnvR3ZW2K03SGzyu2vRJ0jxaV42Saa1nyli2YbYLFe
wUXDK3qB8pwKDMm9TGFUQZQnnBOd4PMYHzVBHXJapbnD0dHLPdIkWSaKf+RR
cpePmiKyb/jptqN0Nxp48avpLyapvdKmm6z14a9a2T+rh92y41bRX7ccwae9
MVdIHuv8qavSHZMTazTvE0Rbr44+/zxALW4HaIcnLxtSRKXUUMNq8Fb7Tq+f
2tnMFFyTK02n/6XLaijEzjSUeN1a0LEKGa9pYZDdWw66s9sQa/lSqw+wyj20
tkk7yO7pcFs8XPfkbqFQOCZlKN1qlCHmZ62V0sFfMCs0FWeeQB6WjLxVNl9V
xYraBYJSzmwBLW9JNLRVtdJHxpa8D2/KDfKoHDU10ljCikKqCdSoU9lk5P1W
U3RfCiUV+cGtAKFGKUDupLc3awsC/7G9JI74tOOrqCzwmPp2tmH+6l0gGr2b
b9exs2g6Exo88iihvu3fGqQG0W3u1m6ITZo3Wk0IzYQ7qzFbpoKlzKj0KxUw
BV2y/E5d8du3YzMesg5eXXMtF8Nc/UNSpqdtx6RD/TfUlnqLKQEShZ3kqDe2
DVIYdH139k64YWOBXBsAxZ4pkNutSy6C/0fAz0Ov0hRuZ39ySv8+5RcxY7Kg
Xft8buJeZN0nWZiRqHEEfpzEXZxcnWxAmQFf4xyBC6hxK5tqUhuwgrektxLc
wswRjqjbYNCUYb6naKCuKPA0n1ssIlJDBfVh15eY8PSIPvJ3/VFbX8InvCPl
jw1FvI37PT91GjD+xZT9CU6/Q9ArPFafU4FUvcnclBtObxO3CuHwiphnDnsl
cHOjJlSuUz9fUb2Gg8kOxuOX8Kv1VUVmoY38oQ3C+Onl8Ym6XpkIRDeXmizx
dOGcDxv1bfN51AbbZjalzqRVbD28pz0vdqYsTA55ssWWuZxyy1j93bFX2hm6
HVU1gZTYjT1r1zttKYsYAbvLW1vZj2V3tGviw0q7WLwNo3KEy7nbq58kSqko
BWzeFGSvLnWu50THadhtu25vbu3MU6lqEZrD6qJJ3K/rbo+FjYqFJQ8AoXhS
X1DYk63XO3I9DTMXOzJQxqVSS2BHxv4oekW1z+CRpwIK6OzQ+ZLL+aGHMsBM
fAdRiNYMfXQtx6a8kQSdhBlVOdIy+LApAWeGB9z4e29qSUhDBFLRLe6js2Vl
y9clP75rdtFIGIZ1HP+p43ZIpYvQuh32AOvpJ5O3gdejZwcvueX+1uZh53FL
grSUFFTu8oD3wl4il9WpXkXXqPov1AYkXlL/uBeEtL3t2ztRrYz9a0WDC8M+
GElrhGbHnRokQp/JLqnKvmHsS4Vd3zubNhMJEKPRNOHANCGXu11dfP75qyOp
LkYB9AbuZvNmu7dHetyHEh9bhkNTz+dUQqDl2lKb/b6WB95GfhoqYm0TCzWL
SrDnFXXUkjLSl2dqn2TsqpLeGOHfViM6NVFLO+1m9E3FFGvZ+HVOO7BUDWj2
qaS/uO5CCW83NUnyOD0KHxfSloLByVeG3cQ4zQfTBhRcKqFSHPkYeOvQPED9
CgU1BFAJBpNXEcPV6x26i3vXjFvzYw7XWTUmCsZSycmSJp8P7b2uHQraLpH7
Om3APhtbo00HWN1LEPbgA5P0ErAVe1TpD99RIpOCFwNv6YLo5sqZ0+lWtV9a
5nbUggbfid701Rq5yP2es5rMJTpT3cM3S8AGKZftlkmscbSPfshJO4g3WTjp
B++thA16T2EF3DqlyJdTrTZCu1axoJ37BPN5dfg5lQxbB5xWhb3XyXrHNAxN
cqOi+VCEaJ2tkE6xJuntWam6B6kvlse92q4fualbH6VXdrsO2q6QSlNEBMiB
z6Y0urPm+WWr6Lld8/xUxfP/STLxg8myEUW8PLImRyG2F1L6UMORPiqc2TmZ
oNQJ3Kxd9u7ZQwnnS1aulP6ljLaN2OFxBt0cccAECcUDCuex4aUx380E1Kt2
U3BfsZxEHVBLhCwNIg6L2mkB9LXGxt9hsyVsUJFSxPw9hNZOmOq2p7MbFU/f
8qF1ENi1xRWPMG23+RCOjhX59r5RB5MPOtv5odtMT+NxFMu4hknBOgA/ZY77
NKT5IGAc0cGWYUaMWFATKZ/tktTr3iYIwj7uHFD5QIObpOLTYnRwg6rs90b2
wlpt4WHAuH0li7fE4tcnl7wULQpXzRcDpGx5Sxs7W5+Ex7C0xA3lcHZaEXE5
PJMr7tp26tfIGJdhZiBJ2hrtvFMDUgq3GjMHZZgjd6Rlpz7rlAjQVFyCSsi+
Gr4KiOm0sc0y59IA6hO9dNUsA2/NUU1eKGJuQ2v+8va2OqOSu3EYPjRD55ua
aijYqJamM1nQn6WmYhMlOGwgcJZ0sqNwCCAsAEOvFqaFPBAzM2flLIxgUQ6D
US3rnVLHx7DolC1yslCJDj5ZMgcZrjBL2kPmcoV5jzAeGuhZPZgRXmGpRIuA
vWq1JXaPZnM6MOnb71lS9aEM8XTjYFZ330mUpGW/AfbTfmmdw25gYZKYqw9w
8NUqjwBZcFvr7C3Is/5Oip0pvPS80OR9mTloPSAgndSOuxlBMRn6X+SB9eZc
sA62+p9YdjO3dbNrOIJat/uFdcFKmFWoDfDQpY0HXTY6BKfrtnYk1Is0Znwl
oJfOjAZp9B6IIQviwMu7N7Us5IDJ+1padfAQ7Ivf1ru8tdhj9RWFFaxR0rt6
AW3et87yr0O5k0rskVMJg9wSqk4SCo6ZSeeyF7fRh4rv9QFwal5PjSZhNAf5
2VbONGImyQOL1z6oENU7s3dG4J/O79Q7ajsD1fCV9hes2m1pVrhh1FdQsg9L
syY8ectXvoG3GarvM50C5xXqtMo1tO+drjIA7NkMioxfC/C5wu8lkPt8qC41
POJJDiYfEJTf2ik0+p3JSnqW/o8DFvYXry7N3R1EOFQ/IH6ZpZo4B7Ud4t+l
OtXFis6xnlmo4OsCJGOcr6Dwt8niAZ7/w1D9CMeJ3wvy/USgvaOzsGfV3cLd
5xajwna+BsiCD8HtvwOrevWGTiyCholdYlYsoL+jJ3UBOapvqiXUeqjeuAJu
97W2xaIqfMnzwk3SMRhjqdoXuP8BWDWekIU8qVVDJ+YuJkGW98rF5/NZwMH/
ATq9h4hnQwAA
</rfc> </rfc>
 End of changes. 40 change blocks. 
793 lines changed or deleted 450 lines changed or added

This html diff was produced by rfcdiff 1.48.