<?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) --> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<?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:lang="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"> symRefs="true" version="3">
<front>
<title abbrev="DNS-ER">DNS abbrev="DNS Error Reporting">DNS Error Reporting</title>
<seriesInfo name="RFC" value="9567"/>
<author initials="R." surname="Arends" fullname="Roy Arends">
<organization>ICANN</organization>
<address>
<email>roy.arends@icann.org</email>
</address>
</author>
<author initials="M." surname="Larson" fullname="Matt Larson">
<organization>ICANN</organization>
<address>
<email>matt.larson@icann.org</email>
</address>
</author>
<date year="2024" month="March" day="04"/> month="April"/>
<area>OPS</area>
<workgroup>dnsop</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>DNS error reporting is a lightweight reporting mechanism that provides the operator of an authoritative server with reports on DNS resource records that fail to resolve or validate. A domain owner or DNS hosting organization can use these reports to improve domain hosting. The reports are based on extended DNS errors as described in <xref target="RFC8914"/>.</t> RFC 8914.</t>
<t>When a domain name fails to resolve or validate due to a misconfiguration or an attack, the operator of the authoritative server may be unaware of this. To mitigate this lack of feedback, this document describes a method for a validating resolver to automatically signal an error to a monitoring agent specified by the authoritative server. The error is encoded in the QNAME, thus QNAME; thus, the very act of sending the query is to report the error.</t>
</abstract>
</front>
<middle>
<section anchor="introduction"><name>Introduction</name> anchor="introduction">
<name>Introduction</name>
<t>When an authoritative server serves a stale DNSSEC-signed zone, the cryptographic 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 some 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, users and reported via E-Mail email or social media (if reported at all).</t>
<t>When records fail to validate, there is no facility to report this failure 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 resolvers to report DNSSEC validation errors in an automated way.</t>
<t>It allows an authoritative server to announce a monitoring agent where to which validating resolvers can report issues if those resolvers are configured to do so.</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 to its main functions. To accomplish this goal, the DNS itself is utilized to report the error.</t>
</section>
<section anchor="requirements-notation"><name>Requirements anchor="requirements-notation">
<name>Requirements Notation</name>
<t>The
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
interpreted as described in BCP 14 BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.</t> here.
</t>
</section>
<section anchor="terminology"><name>Terminology</name>
<t>DNS Terminology used in this anchor="terminology">
<name>Terminology</name>
<t>This document is from uses DNS terminology defined in BCP 219 <xref target="RFC8499"/>, with these additions:</t> target="RFC9499"/>. This document also defines and uses the following terms:</t>
<dl>
<dt>Reporting resolver:</dt>
<dd>
<t>In the context of this document, "reporting resolver" is used as a shorthand for a
<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 is called a report query. error. 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. This facility is indicated by a domain name, referred to as the agent domain.</t> "agent domain".</t>
</dd>
<dt>Agent domain:</dt>
<dd>
<t>A domain name which that is returned in the DNS Error Reporting EDNS0 Report-Channel option that and indicates where DNS resolvers can send error reports.</t>
</dd>
</dl>
</section>
<section anchor="overview"><name>Overview</name> anchor="overview">
<name>Overview</name>
<t>An authoritative server indicates support for DNS error reporting by including an EDNS0 Report-Channel option with OPTION-CODE [TBD] 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 MUST NOT <bcp14>MUST NOT</bcp14> include this option in the response if the configured agent domain is empty, empty or is the null label (which would 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 resolver encodes the error report in the QNAME of the report query. The reporting resolver builds this QNAME by concatenating the _er "_er" label, the QTYPE, the 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"/>. target="example"/> and the specification in <xref target="constructing-the-report-query"/>. Note that a regular RCODE is not included because the 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 DNS resource record type by the reporting resolver.</t>
<t>The report query will ultimately arrive at the monitoring agent. A response is 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 sent by a reporting resolver for the same problem, that problem (that is, once with caching, one report query per TTL. TTL is sent). However, certain optimizations optimizations, such as those described in <xref target="RFC8020"/> and <xref target="RFC8198"/> target="RFC8198"/>, may reduce the 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 RDATA for this
record.</t>
<section anchor="example"><name>Example</name> 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 authoritative server has an agent domain configured: configured as "a01.agent-domain.example.".</t>
<t>The authoritative server with the stale "test." zone receives the request for "broken.test". "broken.test.". It returns a response that includes the EDNS0 Report-Channel option with the domain name "a01.agent-domain.example.".</t>
<t>The reporting resolver is unable to validate the "broken.test" "broken.test." RRset for type 1 (an A record), (an RR type with value 1), due to an RRSIG record with an expired signature.</t>
<t>The reporting resolver constructs the QNAME "_er.1.broken.test.7._er.a01.agent-domain.example." and resolves it. This QNAME indicates extended DNS error 7 occurred while trying to validate "broken.test." for a type 1 record.</t> A (an RR type with 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), "a01.agent-domain.example."), the agent can determine 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 contact the operators of "test." to fix the issue.</t>
</section>
</section>
<section anchor="edns0-option-specification"><name>EDNS0 anchor="edns0-option-specification">
<name>EDNS0 Option Specification</name>
<t>This method uses an EDNS0 <xref target="RFC6891"/> option to indicate the agent domain in DNS responses. The option is structured as follows:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION-CODE = TBD 18 | OPTION-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
/ AGENT DOMAIN /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork></figure>
]]></artwork>
<t>Field definition details:</t>
<dl>
<dt>OPTION-CODE:</dt>
<dd>
<t>2 octets; an EDNS0 code that is used in an EDNS0 option to indicate support for error reporting. The name for this EDNS0 option code is Report-Channel.</t>
</dd>
<dt>OPTION-LENGTH:</dt>
<dd>
<t>2-octets;
<t>2 octets; contains the length of the AGENT DOMAIN field in octets.</t>
</dd>
<dt>AGENT DOMAIN:</dt>
<dd>
<t>A fully qualified domain name <xref target="RFC8499"/> target="RFC9499"/> in uncompressed DNS wire format.</t>
</dd>
</dl>
</section>
<section anchor="dns-error-reporting-specification"><name>DNS error reporting specification</name> anchor="dns-error-reporting-specification">
<name>DNS Error Reporting Specification</name>
<t>The various errors that a reporting resolver may encounter are listed in <xref target="RFC8914"/>. Note that not all listed errors may be supported by the reporting 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"><name>Reporting anchor="reporting-resolver-specification">
<name>Reporting Resolver Specification</name>
<t>Care should be taken when more additional DNS resolving resolution is needed to resolve the QNAME that contains the error reporting QNAME. report. This resolving resolution itself could trigger another error reporting report to be created.
A maximum expense or depth limit MUST <bcp14>MUST</bcp14> be used to prevent
cascading errors.</t>
<t>The EDNS0 Report-Channel option MUST NOT <bcp14>MUST NOT</bcp14> be included in queries.</t>
<t>The reporting resolver MUST NOT <bcp14>MUST NOT</bcp14> use DNS error reporting if the authoritative server returned an empty agent domain AGENT DOMAIN field in the EDNS0 Report-Channel option.</t>
<t>For the benefit of the monitoring agent to get gain more confidence that the report is not spoofed, the reporting resolver SHOULD <bcp14>SHOULD</bcp14> send error reports over TCP
<xref target="RFC7766"/> or other connection oriented connection-oriented protocols or SHOULD <bcp14>SHOULD</bcp14> use DNS COOKIEs Cookies <xref target="RFC7873"/>. This makes it harder to falsify the source address.</t>
<t>A reporting resolver MUST <bcp14>MUST</bcp14> validate responses received from the monitoring agent. There is no special treatment for responses to error-reporting queries. The Security Considerations section <xref target="security-considerations"/> ("Security Considerations") contains the rationale behind this.</t>
<section anchor="constructing-the-report-query"><name>Constructing anchor="constructing-the-report-query">
<name>Constructing the Report Query</name>
<t>The QNAME for the report query is constructed by concatenating the following elements:</t>
<t><list style="symbols">
<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 extended DNS error, presented as a decimal value, in a single DNS label. If additional 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 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>
</li>
<li>
<t>The list of non-null labels representing the query name which that is the subject of the DNS error report.</t>
</li>
<li>
<t>The extended DNS error, 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 Report-Channel option set by the authoritative server.</t>
</list></t>
</li>
</ul>
<t>If the QNAME of the report query QNAME exceeds 255 octets, it MUST NOT
<bcp14>MUST NOT</bcp14> be sent.</t>
<t>The "_er" labels allow the monitoring agent to differentiate
between the agent domain and the faulty query name. When the
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 as a result domain, and not the original query. 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, received instead of a shorter report query due to query
minimization.</t>
</section>
</section>
<section anchor="authoritative-server-specification"><name>Authoritative server specification</name> anchor="authoritative-server-specification">
<name>Authoritative Server Specification</name>
<t>The authoritative server MUST NOT <bcp14>MUST NOT</bcp14> 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 be present in queries.</t>
</section>
<section anchor="monitoring-agent-specification"><name>Monitoring agent specification</name> anchor="monitoring-agent-specification">
<name>Monitoring Agent Specification</name>
<t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the authoritative server for the agent domain replies reply with a positive response (i.e., not with NODATA or NXDOMAIN) containing a TXT record.</t>
<t>The monitoring agent SHOULD <bcp14>SHOULD</bcp14> respond to queries received over UDP that have no DNS COOKIE Cookie set with a response that has the truncation bit (TC bit) set to challenge the resolver to re-query requery over TCP.</t>
</section>
</section>
<section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
<name>IANA Considerations</name>
<t>IANA is requested to assign has assigned the following DNS in the "DNS EDNS0 option code Option Codes (OPT)" registry:</t>
<figure><artwork><![CDATA[
Value Name Status Reference
----- -------------- -------- ---------------
TBD Report-Channel Standard [this document]
]]></artwork></figure>
<table anchor="iana1">
<name></name>
<thead>
<tr>
<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>IANA is requested to assign has assigned the following Underscored in the "Underscored and Globally Scoped DNS Node Name Names" registry:</t>
<figure><artwork><![CDATA[
RR Type _NODE NAME Reference
----- ---------- ---------
TXT _er [this document]
]]></artwork></figure>
<table anchor="iana2">
<name></name>
<thead>
<tr>
<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 anchor="operational-considerations"><name>Operational anchor="operational-considerations">
<name>Operational Considerations</name>
<section anchor="choosing-an-agent-domain"><name>Choosing anchor="choosing-an-agent-domain">
<name>Choosing an agent domain</name> Agent Domain</name>
<t>It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that the agent domain be kept relatively short to allow for a longer QNAME in the report query. The agent domain MUST NOT <bcp14>MUST NOT</bcp14> be a subdomain of the domain it is reporting on. That is, if the authoritative server hosts the foo.example domain, then its agent domain MUST NOT <bcp14>MUST NOT</bcp14> end in foo.example.</t>
</section>
<section anchor="managing-caching-optimizations"><name>Managing 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 considered unreachable, and negative caching would prohibit subsequent queries for anything 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 which it acts as a monitoring agent, the monitoring agent MUST NOT <bcp14>MUST NOT</bcp14> respond with NXDOMAIN 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="RFC4592"/> in the zone for the agent domain.</t>
<t>When the agent domain is signed, a resolver may use aggressive negative 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 wildcard synthesis. When this happens, the resolver does not send subsequent queries because 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 other than dampening the query load for error reports.</t>
</section>
</section>
<section anchor="security-considerations"><name>Security anchor="security-considerations">
<name>Security Considerations</name>
<t>Use of DNS error reporting may expose local configuration mistakes in the reporting resolver, such as stale DNSSEC trust anchors anchors, to the monitoring agent.</t>
<t>DNS error reporting SHOULD <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 reporting resolver and the authoritative server of the agent domain.</t>
<t>Resolvers that send error reports SHOULD <bcp14>SHOULD</bcp14> send these them over TCP <xref target="RFC7766"/> or SHOULD <bcp14>SHOULD</bcp14> use DNS COOKIEs Cookies <xref target="RFC7873"/>. This makes it hard to falsify the source address. The monitoring agent SHOULD <bcp14>SHOULD</bcp14> respond to queries received over UDP that have no DNS COOKIE Cookie set with a response that has the truncation bit (TC bit) set to challenge the resolver to re-query requery over TCP.</t>
<t>Well-known addresses of reporting resolvers can provide a higher level of confidence in the error reports, reports and potentially enable more automated processing of these reports.</t>
<t>Monitoring agents that receive error reports over UDP should consider that the source of the reports and the reports itself 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 query.</t>
<t>This method can be abused by intentionally deploying broken zones with agent domains that are delegated to victims. This is particularly effective when DNS requests that trigger error messages are sent through
open resolvers <xref target="RFC8499"/> 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 RDATA for this record, if the RDATA content is logged, it MUST the monitoring agent
<bcp14>MUST</bcp14> assume the content can be malicious and take
appropriate meassures measures to avoid exploitation. One such method could be to
log in hexadecimal. This would avoid remote code execution through
logging string attacks attacks, such as the vulnerability described in <xref target="CVE-2021-44228"/>.</t>
<t>The rationale behind mandating DNSSEC validation for responses from a reporting agent, even if the agent domain is proposed to remain unsigned, is to mitigate the risk of a downgrade attack orchestrated by adversaries. In such an attack, a victim's legitimately signed domain could be deceptively advertised as an agent domain by malicious actors. Consequently, if the validating resolver treats it as unsigned, it is exposed to potential cache poisoning attacks. By enforcing DNSSEC validation, this vulnerability is preemptively addressed.</t>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>This document is based on an idea by Roy Arends and David Conrad. The authors would like to thank Peter van Dijk, Stephane Bortzmeyer, Shane Kerr, Vladimir Cunat, Paul Hoffman, Philip Homburg, Mark Andrews, Libor Peltan, Matthijs Mekking, Willem Toorop, Tom Carpay, Dick Franks, Ben Schwartz, Yaron Sheffer, Viktor Dukhovni, Wes Hardaker, James Gannon, Tim Wicinski, Warren Kumari, Gorry Fairhurst, Benno Overeinder, Paul Wouters and Petr Spacek for their contributions.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'/>
<date month='March' year='1997'/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC8174' 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 specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<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.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<references title='Informative 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>Common Vulnerabilities and Exposures</organization>
<author>
<organization>CVE</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 information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.</t>
</abstract> month="November" day="26"/>
</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 different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8914.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8020.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8198.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/>
<!-- [I-D.ietf-dnssd-multi-qtypes] IESG state: I-D Exists as of the terms used in the DNS in a single document.</t>
<t>This document obsoletes RFC 7719 and updates RFC 2308.</t>
</abstract>
</front>
<seriesInfo name='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> 4/16/24 -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnssd-multi-qtypes.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4592.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9156.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7766.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7873.xml"/>
</references>
</references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>This document states clearly that when a DNS resolver receives a response 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 generally requires an exact match. This document specifies the use of NSEC/NSEC3 resource records to allow DNSSEC-validating resolvers to generate negative answers within a range and positive answers from wildcards. This increases performance, decreases latency, decreases resource utilization on both authoritative and recursive servers, and increases privacy. Also, it may help increase resilience to certain DoS attacks in some circumstances.</t>
<t>This document updates RFC 4035 by allowing validating resolvers to generate 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 fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.</t>
<t>This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.</t>
</abstract>
</front>
<seriesInfo name='STD' value='75'/>
<seriesInfo name='RFC' value='6891'/>
<seriesInfo name='DOI' value='10.17487/RFC6891'/>
</reference>
<reference anchor='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 however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces RFC1034 Section 4.3.4. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='2308'/>
<seriesInfo name='DOI' value='10.17487/RFC2308'/>
</reference>
<reference anchor='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 interaction with wildcards and CNAME is changed, an error condition is removed, idea by <contact fullname="Roy Arends"/> and the words defining some concepts central to wildcards are changed. <contact fullname="David Conrad"/>. The overall goal is 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 improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME and original QTYPE authors would like to the upstream name server. This document obsoletes RFC 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'>
<front>
<title>DNS Transport over TCP - Implementation Requirements</title>
<author fullname='J. Dickinson' initials='J.' surname='Dickinson'/>
<author fullname='S. Dickinson' initials='S.' surname='Dickinson'/>
<author fullname='R. Bellis' initials='R.' surname='Bellis'/>
<author fullname='A. Mankin' initials='A.' surname='Mankin'/>
<author fullname='D. Wessels' initials='D.' surname='Wessels'/>
<date month='March' year='2016'/>
<abstract>
<t>This document specifies the requirement for support of TCP as a transport protocol thank <contact fullname="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 Mekking"/>, <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 fullname="Wes Hardaker"/>, <contact fullname="James Gannon"/>, <contact fullname="Tim Wicinski"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Gorry Fairhurst"/>, <contact fullname="Benno Overeinder"/>, <contact fullname="Paul Wouters"/>, and <contact fullname="Petr Spacek"/> 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'>
<front>
<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 provides limited protection to DNS servers and clients against a variety of increasingly common denial-of-service and amplification/ forgery or cache poisoning attacks by off-path attackers. DNS Cookies are tolerant of NAT, NAT-PT (Network Address Translation - Protocol Translation), and anycast and can be incrementally deployed. (Since DNS Cookies are only returned to the IP address from which they were originally received, they cannot be used to generally track Internet users.)</t>
</abstract>
</front>
<seriesInfo name='RFC' value='7873'/>
<seriesInfo name='DOI' value='10.17487/RFC7873'/>
</reference>
</references> their contributions.</t>
</section>
</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>