<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!-- pre-edited by ST 05/28/24 --> <!-- draft submitted in xml v3 --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 3.2.2) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-add-resolver-info-13" number="9606" updates="" obsoletes="" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.21.0 -->version="3" xml:lang="en"> <front> <title abbrev="DNS Resolver Information">DNS Resolver Information</title> <seriesInfoname="Internet-Draft" value="draft-ietf-add-resolver-info-13"/>name="RFC" value="9606"/> <author fullname="TirumaleswarReddy">Reddy.K" initials="T." surname="Reddy.K"> <organization>Nokia</organization> <address> <postal> <country>India</country> </postal> <email>kondtir@gmail.com</email> </address> </author> <author fullname="MohamedBoucadair">Boucadair" initials="M." surname="Boucadair"> <organization>Orange</organization> <address> <postal> <city>Rennes</city> <code>35000</code> <country>France</country> </postal> <email>mohamed.boucadair@orange.com</email> </address> </author> <date year="2024"month="April" day="26"/> <area>Internet</area> <workgroup>ADD</workgroup>month="June"/> <area>INT</area> <workgroup>add</workgroup> <keyword>Transparency</keyword> <keyword>User Experience</keyword> <keyword>DNS server selection</keyword> <abstract><?line 50?><t>This document specifies a method for DNS resolvers to publish information about themselves. DNS clients can use the resolver information to identify the capabilities of DNS resolvers. How DNS clients use suchaninformation is beyond the scope of this document.</t> </abstract><note removeInRFC="true"> <name>Discussion Venues</name> <t>Discussion of this document takes place on the Adaptive DNS Discovery Working Group mailing list (add@ietf.org), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/add/"/>.</t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/boucadair/add-resolver-information"/>.</t> </note></front> <middle> <?line 56?> <section anchor="introduction"> <name>Introduction</name> <t>Historically, DNS clients communicated with recursive resolvers without needing to know anything about the features supported by these resolvers. However, more and more recursive resolvers expose different features that may impact delivered DNS services (privacy preservation, filtering, transparent behavior, etc.). DNS clients can discover and authenticate encrypted DNS resolvers provided by a local network, for example, using the Discovery of Network-designated Resolvers (DNR) <xref target="RFC9463"/> and the Discovery of Designated Resolvers (DDR) <xref target="RFC9462"/>. However, these DNS clients can't retrieve information from the discovered recursive resolvers about their capabilities to feed the resolver selection process. Instead of depending on opportunistic approaches, DNS clients need a more reliable mechanism to discover the features that are configured on these resolvers.</t> <t>This document fills that void by specifying a mechanism that allows communication of DNS resolver information to DNS clients for use in resolver selection decisions. For example, the resolver selection procedure may use the retrieved resolver information to prioritize privacy-preserving resolvers over those that don't enable QNAMEminimizationminimisation <xref target="RFC9156"/>. Another example is when a DNS client selects a resolver based on its filtering capability. For instance, a DNS client can choose a resolver that filters domains according to a security policy using the Blocked (15) Extended DNS Error (EDE) <xref target="RFC8914"/>. Alternatively, the client may have a policy not to select a resolver that forges responses using the Forged Answer (4) EDE. However, it is out of the scope of this document to define the selection procedure and policies. Once a resolver is selected by a DNS client, and unless explicitly mentioned, this document does not interfere withDNS operations withthatresolver.</t>resolver's DNS operations.</t> <t>Specifically, this document defines a new resource record (RR) type for DNS clients to query the recursive resolvers. The initial information that a resolver might want to expose is defined in <xref target="key-val"/>. That information is scoped to cover properties that are used to infer privacy and transparency policies of a resolver. Other information can be registered in the future per the guidance in <xref target="key-reg"/>. The information is not intended forend userend-user consumption.</t> </section> <section anchor="terminology"> <name>Terminology</name> <t>The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t><?line -18?><t>This document makes use of the terms defined in <xref target="RFC8499"/>. The following additional terms are used:</t> <dl> <dt>Encrypted DNS:</dt><dd> <t>Refers<dd>Refers to a DNS scheme where DNS exchanges are transported over an encrypted channel between a DNS client and server (e.g., DNS over HTTPS (DoH) <xref target="RFC8484"/>, DNS over TLS (DoT) <xref target="RFC7858"/>, or DNS over QUIC (DoQ) <xreftarget="RFC9250"/>).</t>target="RFC9250"/>). </dd> <dt>Encrypted DNS resolver:</dt><dd> <t>Refers<dd>Refers to a DNS resolver that supports any encrypted DNSscheme.</t>scheme. </dd> <dt>Reputation:</dt><dd> <t>"The<dd>Defined as "the estimation in which an identifiable actor is held, especially by the community or the Internet public generally"(<xrefper <xref section="1" sectionFormat="of"target="RFC7070"/>).</t>target="RFC7070"/>. </dd> </dl> </section> <section anchor="retreive"> <name>Retrieving Resolver Information</name> <t>A DNS client that wants to retrieve the resolver information may use the RR type "RESINFO" defined in this document. The content of the RDATA in a response to a query for RESINFO RR QTYPE is defined in <xref target="key-val"/>. If the resolver understands the RESINFO RR type, theRRSetRRset <bcp14>MUST</bcp14> have exactly one record. Invalid records <bcp14>MUST</bcp14> be silently ignored by DNS clients. RESINFO is a property of the resolver and is not subject to recursive resolution.</t> <t>A DNS client can retrieve the resolver information using the RESINFO RR type and the QNAME of the domain name that is used to authenticate the DNS resolver (referred to as the Authentication Domain Name (ADN) in DNR <xref target="RFC9463"/>).</t> <t>If the Special-Use Domain Name "resolver.arpa", defined in <xref target="RFC9462"/>, is used to discover an encrypted DNS resolver, the client can retrieve the resolver information using the RESINFO RR type and QNAME of "resolver.arpa". In this case, a client has to contend with the risk that a resolver does not support RESINFO. The resolver might pass the query upstream, and then the client can receive a positive RESINFO responseeitherfrom either a legitimate DNS resolver or an attacker.</t> <t>The DNS client <bcp14>MUST</bcp14> set the Recursion Desired (RD) bit of the query to 0. The DNS client <bcp14>MUST</bcp14> discard the response if the AA flag in the response is set to 0, indicating that the DNS resolver is not authoritative for the response.</t> <t>If a group of resolvers is sharing the same ADN and/or anycast address, then these instances <bcp14>SHOULD</bcp14> expose a consistent RESINFO.</t> </section> <section anchor="format"> <name>Format of the Resolver Information</name> <t>The resolver information record uses the same format as DNS TXT records. The format rules for TXT records are defined in the base DNS specification (<xref section="3.3.14" sectionFormat="of" target="RFC1035"/>) and are further elaborated in the DNS-based Service Discovery (DNS-SD) specification (<xref section="6.1" sectionFormat="of" target="RFC6763"/>). The recommendations to limit the TXT record size are discussed in <xref section="6.1" sectionFormat="of" target="RFC6763"/>.</t><t>Similar<!--[rfced] FYI: After "key/value" is introduced, we removed the quote marks as this term does not contain quote marks in RFC 6763. Please let us know of any objections. Original: Similar to DNS-SD, the RESINFO RR type uses "key/value" pairs to convey the resolver information. Each "key/value" pair is encoded using the format rules defined in Section 6.3 of [RFC6763]. Using standardized "key/value" syntax within the RESINFO RR type makes it easier for future keys to be defined. Current: Similar to DNS-SD, the RESINFO RR type uses "key/value" pairs to convey the resolver information. Each key/value pair is encoded using the format rules defined in Section 6.3 of [RFC6763]. Using standardized key/value syntax within the RESINFO RR type makes it easier for future keys to be defined. --> <t>Similar to DNS-SD, the RESINFO RR type uses "key/value" pairs to convey the resolver information. Each key/value pair is encoded using the format rules defined in <xref section="6.3" sectionFormat="of" target="RFC6763"/>. Using standardized"key/value"key/value syntax within the RESINFO RR type makes it easier for future keys to be defined. If a DNS client sees unknown keys in a RESINFO RR type, it <bcp14>MUST</bcp14> silently ignore them. The same rules for thekeyskeys, asthosedefined in <xref section="6.4" sectionFormat="of"target="RFC6763"/>target="RFC6763"/>, <bcp14>MUST</bcp14> be followed for RESINFO.</t> <t>Resolver information keys <bcp14>MUST</bcp14> either be defined in the IANA registry (<xref target="key-reg"/>) or begin with the substring "temp-" for names defined for local use only.</t> </section> <section anchor="key-val"> <name>Resolver Information Keys/Values</name> <t>The following resolver information keys are defined:</t> <dl> <dt>qnamemin:</dt> <dd> <t>The presence of this key indicates that the DNS resolver supports QNAME minimisation <xref target="RFC9156"/> to improve DNS privacy. Note that, per the rules for the keys defined in <xref section="6.4" sectionFormat="of" target="RFC6763"/>, if there is no '=' in a key, then it is a boolean attribute, simply identified as being present, with no value. </t> <t>The presence of this key indicates that the DNS resolver is configured to minimise the amount of privacy-sensitive data sent to an authoritative name server.</t> <t>This is an optional attribute.</t> </dd> <dt>exterr:</dt> <dd> <t>If the DNS resolver supportsextended DNS errors (EDE)the EDE option defined in <xref target="RFC8914"/> to return additional information about the cause of DNS errors, the value of this key lists the possibleextended DNS errorEDE codes that can be returned by this DNS resolver. A value can be an individual EDE or a range of EDEs. Range values <bcp14>MUST</bcp14> be identified by "-". When multiple non-contiguous values are present, these values <bcp14>MUST</bcp14> be comma-separated. </t> <t>Returned EDEs (e.g., Blocked (15), Censored (16), and Filtered (17)) indicate whether the DNS resolver is configured to reveal the reason why a query wasfiltered/blocked,filtered/blocked when such an event happens. If the resolver's capabilities are updated to include new similar error codes, the resolver can terminate the TLS session, prompting the client to initiate a new TLS connection and retrieve the resolver information again. This allows the client to become aware of the resolver's updated capabilities. Alternatively, if the client receives an EDE for a DNS request, but that EDE was not listed in the "exterr", the client can query the resolver again to learn about the updated resolver's capabilities to return new error codes. If a mismatch still exists, the client can identify that the resolver information is inaccurate and discard it.</t> <t>This is an optional attribute.</t> </dd> <dt>infourl:</dt> <dd><t>An<t>A URL that points to the generic unstructured resolver information (e.g., DoH APIs supported, possible HTTP status codes returned by the DoH server, or how to report a problem) for troubleshooting purposes. The server that exposes such information is called "resolver information server". </t> <t>The resolver information server <bcp14>MUST</bcp14> support only the content-type'text/html'"text/html" for the resolver information. The DNS client <bcp14>MUST</bcp14> rejectinvalidthe URL as invalid if the scheme is not "https". Invalid URLs <bcp14>MUST</bcp14> be ignored. The URL <bcp14>MUST</bcp14> be treated only as diagnostic information for IT staff. It is not intended forend userend-user consumption as the URL can possibly provide misleading information.</t> <t>This key can be used by IT staff to retrieve other useful information about the resolver and also the procedure to report problems (e.g., invalid filtering).</t> <t>This is an optional attribute.</t> </dd> </dl> <t>New keys can be defined as per the procedure defined in <xref target="key-reg"/>.</t> </section> <section anchor="an-example"> <name>An Example</name> <t><xref target="ex-1"/> shows an example of a published resolver information record.</t> <figure anchor="ex-1"> <name>An Example of a Resolver Information Record</name> <artwork align="center"><![CDATA[ resolver.example.net. 7200 IN RESINFO qnamemin exterr=15-17 infourl=https://resolver.example.com/guide ]]></artwork> </figure> <t>As mentioned in <xref target="retreive"/>, a DNS client that discovers the ADN "resolver.example.net" of its resolver using DNR will issue a query for RESINFO RR QTYPE for that ADN and will learnthat the resolver:</t>that:</t> <ul spacing="normal"><li> <t>enables<li>the resolver enables QNAMEminimisation,</t>minimisation, </li><li> <t>can<li>the resolver can return Blocked (15), Censored (16), and Filtered (17) EDEs,and</t>and </li><li> <t>that more<li>more information can be retrieved fromhttps://resolver.example.com/guide.</t>"https://resolver.example.com/guide". </li> </ul> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>DNS clients communicating with discovered DNS resolvers <bcp14>MUST</bcp14> use one of the following measures to prevent DNS response forgery attacks:</t> <ol spacing="normal"type="1"><li> <t>Establishtype="1"> <li> Establish an authenticated secure connection to the DNSresolver.</t>resolver. </li><li> <t>Implement<li>Implement local DNSSEC validation (<xref section="10" sectionFormat="of" target="RFC8499"/>) to verify the authenticity of the resolverinformation.</t>information. </li> </ol> <t>It is important to note that, of these two measures, only the first one can apply to queries for'resolver.arpa'.</t>"resolver.arpa".</t> <t>An encrypted resolver may return incorrect information in RESINFO. If the client cannot validate the attributes received from the resolver,thatwhich will be used for resolver selection or displayed to theend-user,end user, the client should process those attributes only if the encrypted resolver has sufficient reputation according to local policy (e.g., user configuration, administrative configuration, or a built-in list of reputable resolvers). This approach limits the ability of a malicious encrypted resolver to cause harm with false claims.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name><ul empty="true"> <li> <t>Note to the RFC Editor: Please update "RFCXXXX" occurrences with the RFC number to be assigned to this document.</t> </li> </ul><section anchor="resinfo-rr-type"> <name>RESINFO RR Type</name><t>This document requests IANA to update this entry from<t>IANA has updated the "Resource Record (RR) TYPEs" registryofunder the "Domain Name System (DNS) Parameters" registry groupavailable at<xreftarget="RRTYPE"/>:</t> <artwork><![CDATA[ Type: RESINFO Value: 261 Meaning: Resolvertarget="RRTYPE"/> as follows:</t> <dl spacing="compact"> <dt>Type:</dt><dd>RESINFO</dd> <dt>Value:</dt><dd>261</dd> <dt>Meaning:</dt><dd>Resolver Information as Key/ValuePairs Reference: RFCXXXX ]]></artwork>Pairs</dd> <dt>Reference:</dt><dd>RFC 9606</dd> </dl> </section> <section anchor="key-reg"> <name>DNS Resolver InformationKeyKeys Registration</name><t>This document requests IANA to create<t>IANA has created a new registryentitledcalled "DNS Resolver Information Keys" under the "Domain Name System (DNS) Parameters" registry group(<xref target="IANA-DNS"/>).<xref target="IANA-DNS"/>. This new registry contains definitions of the keys that can be used to provide the resolver information.</t> <t>The registration procedure is Specification Required (<xref section="4.6" sectionFormat="of" target="RFC8126"/>). Designated experts should carefully consider the security implications of allowing a resolver to include new keys in this registry. Additional considerations are provided in <xref target="sec-de"/>.</t> <t>The structure of the registry is as follows:</t> <dl> <dt>Name:</dt><dd> <t>The<dd>The key name. The name <bcp14>MUST</bcp14> conform to the definition in <xref target="format"/> of this document. The IANA registry <bcp14>MUST NOT</bcp14> register names that begin with"temp-","temp-" so that these names can be used freely by anyimplementer.</t>implementer. </dd> <dt>Description:</dt><dd> <t>A<dd>A description of the registeredkey.</t>key. </dd><dt>Specification:</dt> <dd> <t>The<dt>Reference:</dt> <dd>The reference specification for the registeredelement.</t>element. </dd> </dl> <t>The initialcontentcontents of this registryisare provided in <xref target="initial"/>.</t> <table anchor="initial"> <name>InitialRESINFOContents of the DNS Resolver Information Keys Registry</name> <thead> <tr> <thalign="center">Name</th>align="left">Name</th> <th align="left">Description</th> <thalign="center">Specification</th>align="center">Reference</th> </tr> </thead> <tbody> <tr> <tdalign="center">qnamemin</td>align="left">qnamemin</td> <td align="left">The presence of the key name indicates that QNAMEminimizationminimisation isenabled</td>enabled.</td> <tdalign="center">RFCXXXX</td>align="center">RFC 9606</td> </tr> <tr> <tdalign="center">exterr</td>align="left">exterr</td> <td align="left">Lists the set of enabled extended DNS errors. It must be an INFO-CODE decimal value in the "Extended DNS Error Codes"registry.</td>registry <eref target="https://www.iana.org/assignments/dns-parameters/" brackets="angle" />. </td> <tdalign="center">RFCXXXX</td>align="center">RFC 9606</td> </tr> <tr> <tdalign="center">infourl</td>align="left">infourl</td> <td align="left">Providesana URL that points toanunstructured resolver information that is used fortroubleshooting</td>troubleshooting.</td> <tdalign="center">RFCXXXX</td>align="center">RFC 9606</td> </tr> </tbody> </table> </section> <section anchor="sec-de"> <name>Guidelines for the Designated Experts</name> <t>It is suggested that multiple designated experts be appointed for registry change requests.</t> <t>Criteria that should be applied by the designated experts include determining whether the proposed registration duplicates existing entries and whether the registration description is clear and fits the purpose of this registry.</t> <t>Registration requests are evaluated within athree-weektwo-week review period on the advice of one or more designated experts. Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.</t> </section> </section> </middle> <back> <displayreference target="I-D.pp-add-resinfo" to="RESINFO"/> <references> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC9463"> <front> <title>DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)</title> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="T. Reddy.K" initials="T." role="editor" surname="Reddy.K"/> <author fullname="D. Wing" initials="D." surname="Wing"/> <author fullname="N. Cook" initials="N." surname="Cook"/> <author fullname="T. Jensen" initials="T." surname="Jensen"/> <date month="November" year="2023"/> <abstract> <t>This document specifies new DHCP and IPv6 Router Advertisement options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, and DNS over QUIC). Particularly, it allows a host to learn an Authentication Domain Name together with a list of IP addresses and a set of service parameters to reach such encrypted DNS resolvers.</t> </abstract> </front> <seriesInfo name="RFC" value="9463"/> <seriesInfo name="DOI" value="10.17487/RFC9463"/> </reference> <reference anchor="RFC9462"> <front> <title>Discovery of Designated Resolvers</title> <author fullname="T. Pauly" initials="T." surname="Pauly"/> <author fullname="E. Kinnear" initials="E." surname="Kinnear"/> <author fullname="C. A. Wood" initials="C. A." surname="Wood"/> <author fullname="P. McManus" initials="P." surname="McManus"/> <author fullname="T. Jensen" initials="T." surname="Jensen"/> <date month="November" year="2023"/> <abstract> <t>This document defines Discovery of Designated Resolvers (DDR), a set of mechanisms for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner is referred to as a "Designated Resolver". These mechanisms can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a resolver is known. These mechanisms are designed to be limited to cases where Unencrypted DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols when the name of an Encrypted DNS Resolver is known.</t> </abstract> </front> <seriesInfo name="RFC" value="9462"/> <seriesInfo name="DOI" value="10.17487/RFC9462"/> </reference> <reference anchor="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 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="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC1035"> <front> <title>Domain names - implementation and specification</title> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t>This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication.</t> </abstract> </front> <seriesInfo name="STD" value="13"/> <seriesInfo name="RFC" value="1035"/> <seriesInfo name="DOI" value="10.17487/RFC1035"/> </reference> <reference anchor="RFC6763"> <front> <title>DNS-Based Service Discovery</title> <author fullname="S. Cheshire" initials="S." surname="Cheshire"/> <author fullname="M. Krochmal" initials="M." surname="Krochmal"/> <date month="February" year="2013"/> <abstract> <t>This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t> </abstract> </front> <seriesInfo name="RFC" value="6763"/> <seriesInfo name="DOI" value="10.17487/RFC6763"/> </reference> <reference anchor="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> </front> <seriesInfo name="RFC" value="8914"/> <seriesInfo name="DOI" value="10.17487/RFC8914"/> </reference> <reference anchor="RFC8126"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author fullname="M. Cotton" initials="M." surname="Cotton"/> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <author fullname="T. Narten" initials="T." surname="Narten"/> <date month="June" year="2017"/> <abstract> <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t>This is the third edition of this document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9463.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9462.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.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/> <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.8126.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="RRTYPE"target="https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml">target="https://www.iana.org/assignments/dns-parameters/"> <front> <title>Resource Record (RR) TYPEs</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference> <reference anchor="IANA-DNS"target="http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4">target="https://www.iana.org/assignments/dns-parameters/"> <front> <title>Domain Name System (DNS) Parameters</title> <author> <organization>IANA</organization> </author> <date/> </front> </reference><reference anchor="RFC8499"> <front> <title>DNS Terminology</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <author fullname="A. Sullivan" initials="A." surname="Sullivan"/> <author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/> <date month="January" year="2019"/> <abstract> <t>The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document.</t> <t>This document obsoletes RFC 7719 and updates RFC 2308.</t> </abstract> </front> <seriesInfo name="RFC" value="8499"/> <seriesInfo name="DOI" value="10.17487/RFC8499"/> </reference> <reference anchor="RFC8484"> <front> <title>DNS Queries over HTTPS (DoH)</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <author fullname="P. McManus" initials="P." surname="McManus"/> <date month="October" year="2018"/> <abstract> <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.</t> </abstract> </front> <seriesInfo name="RFC" value="8484"/> <seriesInfo name="DOI" value="10.17487/RFC8484"/> </reference> <reference anchor="RFC7858"> <front> <title>Specification for DNS over Transport Layer Security (TLS)</title> <author fullname="Z. Hu" initials="Z." surname="Hu"/> <author fullname="L. Zhu" initials="L." surname="Zhu"/> <author fullname="J. Heidemann" initials="J." surname="Heidemann"/> <author fullname="A. Mankin" initials="A." surname="Mankin"/> <author fullname="D. Wessels" initials="D." surname="Wessels"/> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="May" year="2016"/> <abstract> <t>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t> <t>This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t> </abstract> </front> <seriesInfo name="RFC" value="7858"/> <seriesInfo name="DOI" value="10.17487/RFC7858"/> </reference> <reference anchor="RFC9250"> <front> <title>DNS over Dedicated QUIC Connections</title> <author fullname="C. Huitema" initials="C." surname="Huitema"/> <author fullname="S. Dickinson" initials="S." surname="Dickinson"/> <author fullname="A. Mankin" initials="A." surname="Mankin"/> <date month="May" year="2022"/> <abstract> <t>This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7070.xml"/> <!-- [I-D.pp-add-resinfo] IESG state: Expired asa general-purpose transport for DNS and includes the useofDoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.</t> </abstract> </front> <seriesInfo name="RFC" value="9250"/> <seriesInfo name="DOI" value="10.17487/RFC9250"/> </reference> <reference anchor="RFC7070"> <front> <title>An Architecture for Reputation Reporting</title> <author fullname="N. Borenstein" initials="N." surname="Borenstein"/> <author fullname="M. Kucherawy" initials="M." surname="Kucherawy"/> <date month="November" year="2013"/> <abstract> <t>This document describes a general architecture for a reputation-based service, allowing one to request reputation-related data over06/24/24; entered theInternet, where "reputation" referslong way topredictions or expectations about an entity or an identifier such as a domain name. The document roughly followsget therecommendations of RFC 4101 for describing a protocol model.</t> </abstract> </front> <seriesInfo name="RFC" value="7070"/> <seriesInfo name="DOI" value="10.17487/RFC7070"/> </reference>correct initials--> <referenceanchor="I-D.pp-add-resinfo">anchor="I-D.pp-add-resinfo" target="https://datatracker.ietf.org/doc/html/draft-pp-add-resinfo-02"> <front> <title>DNS Resolver Information Self-publication</title> <author fullname="Puneet Sood" initials="P." surname="Sood"> <organization>Google</organization> </author> <author fullname="PaulE.Hoffman"initials="P. E."initials="P." surname="Hoffman"> <organization>ICANN</organization> </author> <date day="30" month="June" year="2020"/><abstract> <t> This document describes methods for DNS resolvers to self-publish information about themselves. The information is returned as a JSON object. The names in this object are defined in an IANA registry that allows for light-weight registration. Applications and operating systems can use the methods defined here to get the information from resolvers in order to make choices about how to send future queries to those resolvers. </t> </abstract></front> <seriesInfo name="Internet-Draft" value="draft-pp-add-resinfo-02"/> </reference> </references> </references><?line 313?><section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>This specification leverages the work that has been documented in <xref target="I-D.pp-add-resinfo"/>.</t> <t>Thanks toTommy Jensen, Vittorio Bertola, Vinny Parla, Chris Box, Ben Schwartz, Tony Finch, Daniel<contact fullname="Tommy Jensen"/>, <contact fullname="Vittorio Bertola"/>, <contact fullname="Vinny Parla"/>, <contact fullname="Chris Box"/>, <contact fullname="Ben Schwartz"/>, <contact fullname="Tony Finch"/>, <contact fullname="Daniel KahnGillmor, Eric Rescorla, Shashank Jain, Florian Obser, Richard Baldry, and Martin ThomsonGillmor"/>, <contact fullname="Eric Rescorla"/>, <contact fullname="Shashank Jain"/>, <contact fullname="Florian Obser"/>, <contact fullname="Richard Baldry"/>, and <contact fullname="Martin Thomson"/> for the discussion and comments.</t> <t>Thanks toMark Andrews, Joe Abley, Paul Wouters,<contact fullname="Mark Andrews"/>, <contact fullname="Joe Abley"/>, <contact fullname="Paul Wouters"/>, andTim Wicinski<contact fullname="Tim Wicinski"/> for the discussion ontheRR formatting rules.</t> <t>Special thanks toTommy Jensen<contact fullname="Tommy Jensen"/> for the careful and thoughtful Shepherd review.</t> <t>Thanks toJohan Stenstam and Jim Reid<contact fullname="Johan Stenstam"/> and <contact fullname="Jim Reid"/> for the dns-dir reviews,Ray Bellis<contact fullname="Ray Bellis"/> for the RRTYPE allocation review,Arnt Gulbrandsen<contact fullname="Arnt Gulbrandsen"/> for the ART review, andMallory Knodel<contact fullname="Mallory Knodel"/> for the gen-art review.</t> <t>Thanks toEric Vyncke<contact fullname="Éric Vyncke"/> for the AD review.</t> <t>Thanks toGunter<contact fullname="Gunter Van deVelde, Erik Kline, Paul Wouters, Orie Steele, Warren Kumari, Roman Danyliw, and Murray KucherawyVelde"/>, <contact fullname="Erik Kline"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Orie Steele"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Murray Kucherawy"/> for the IESG review.</t> </section> </back><!-- ##markdown-source: H4sIAAAAAAAAA6Vb2XYbR5J9x1fkQA8i+wCQqN087XZDImXRkiiZpOzuM2ce EqgEkMNCFbqyihBMc75lvmW+bG4sWQsAepnRi4hCZWRkrDciA8PhsFf6MnXH pn9yfmkuXMjTG1eYs2yWF0tb+jzr9+xkUrib33xlaks3z4vNsQll0usl+TSz S1BNCjsrh96Vs6FNkmGhi4cei4dHT3uhmix9CKBRblZ4/+z06m0vq5YTVxz3 EhA97k3zLLgsVOHYlEXlemDkac8WzoKhs6x0RebKfm+dF9fzIq9WeDo+Oen3 rt0Gz5Ljnhmaq8JmYYU12XRDn78E8H/6deUKj0eOHtHR8JQOFlzqpnSsXs9W 5SIviEbP4N+sSlM515UvqqVNXVjbAiJJkg2/kBdzm/lfWCjH5jy/9pafT/Mq K0k6Z1mij9zS+vTYXOdZUvri73P6OJrmy929PuYL/J+Y13k1tYn1xZ6tPuGE c9fd6y2eTfWZL/HgwmWZC/pSAspPnz9+/LjNzVK2Gk3iVn/PmTAz1stE3zdQ Ss9H7dMnYy4urv75+fSYaalBkaFUxdThjykUYQ4uLg4NvSUc1KI1ehoIZ3w+ Fgq2mLvy2CzKchWOHz1ar9cjbzM7wmuPLMxlni1dVoZHSRaG0Ct4hh1sfxx9 XZTLlAmyJZmZTYPr4QFtNITGO/ye5JBBZs6x2lxuQumW5gDvHJrPNcU/xfj/ k+8H3YfDZ7sHGQ6Hxk5CWdhpSccyVwsfDHyvol1MWLmpn3kXjDUgssgTA52x pUc/DKbMzaqapD4siIBvfBqU86o05cIt4RA3LowML52mno5gpjYzVXD0Qk1u mwSI+wRv+9mG35valZ341JfEVD7rsjIy7/J1ZwsiH6rpwmCrNlkccuI2cBwm Gqb5yhG1sn36kYhn6ZMkhageQOnwijyp1LPB6TsfyrzwU5umm0H3bPlyWWWe glpi1r5cgMtpVQQYOy1spEffkZQy5xKfzenA1xlOYbMNuMGDWohm5mxZFeJ+ oVqt8oKIT1gwwW2JweGvAbyxcCCVyB81C6393ddVjsWJn81cQTqPu4CqLc3S boxfrmAeJnEplhbYEgdlHhDs/BRvHqwKf2OnG7PCOjxkGQ/MzKewO5xhgLAb w2cJwS/sjc/BnSuno8NRW25Elswi8dAJRVLindyFTICEaRBti82qFC5a51gV +Q0sheXB4THNoRaItaS4PmC7dV/tcpW6AcyCRQ2ZnuhGG1L/ubw8TBz5GamO CF3Ue8CZEYBub//t4u2bb569eHp3x/zt0Dmp1zeLidLByUl7/ZO7u5aqRIlb /vGwxBFL5Bgxm7YJz4p8yVtHWWG3fQqu7ccXXe+Bpc1gdB33azIXCRS6hTGd ZYhkNqGDJW7lMjZTvJCzBcLIA1Rj7AoL7BSH6DoC2TVFD7G/1NtJ6hBLpguk nrAkJmpdt21crA8GA0/KZn5e0fEoHmyZeq/XjViwuVQX3+SerUGC2IZ9qb0z b5Cm+brtrXTyrbDS24pH7dORVVGMQdTfI8IEGxMwgRDfts3vtySe4KTsdU1k FP0nvXrJFkPwPgSh0v/ijDriUB2RztxYggo5Z8I4fJKTfbmMVfLj+fjjKYJd 5pcKCaKhHj1/QYY6znKwU/T0FBRC13BLyLQRiB6G0kXN7MQGUZ0necWQ0Jji RoTjYWUENgZdghQMpouceG7RJPZ7Qot0T1kXe04JJGgMtWAFvgDyZpWnfrpp +fxrhIZr8HRw9PwQGK6ESWs4OS0KsHJwenJKborDv/rm6BkfnrbKGKtQpOdM JAxCVT3EM2JPN4KciAMRxTbXZDFzmDcergiVhhZfb+mrBIIOa7x98AzMnZy2 IoQvSejkzZyqtvJWr/YB8ik385nYzz77oqjF3HpKyp8g9jaf2EQWaTRt6WPA S6sMsJVTB5Eo042hfbGFSwZbvCQ5jkgS8YSzKcVINiSSYL5gS5MsKPKJXMCz LwV9aHbt5GY9IBla5ta8iIFi0QKKVA7UcCU6LGTzr4rCtLjWTrgcAQGRO8Od kD06jsbxopHS0s8XpVlbEbimUWKROUuwtnd7ixJieGNTMqErWr+FQViBCa2X CAgNQSYSnWP8q4K8gaX8hmRazjutmqRWJ5lDwyWUS07b2ZdcakJHniNyc9rw mcTeikKvWWkonlc+IY+kr+UkWCIncdsHiRpmT+JUS2ZCNRLVXtVyRS+OGERd uQJRJk/z+YaCtzOgbKjOCqb/8cvlVX8g/5vzT/z3xemPX84uTk/o78t34w8f 6j96+sblu09fPpw0fzUr33z6+PH0/EQW46npPOr1P47/2ReT7n/6fHX26Xz8 oS/SaNsaaQEKmDgxYsRW8gwLK3dhWviJSPD1m8//899HzzRqPjk6+gbwQD68 OnqJKMLhUnbLM/iMfISkNz0kT2dJS5SQKDT6Evgc78JEFvk6M9Chg/j+8u8k mf84Nn+dTFdHz/6mD+jAnYdRZp2HLLPdJzuLRYh7Hu3ZppZm5/mWpLv8jv/Z +Rzl3nr41+9SCl7Do1ff/a23neCX9toJrtcgCI0s214HmX9HMn/2zTfRWGc5 pXkGAEniyRTh27Iuehjq0dM2sjzuUfk50/pGQmAAukFltyZl8AP3lcAEhXOQ IXwmHim4XOFrC7DSy5lLYUjl2m1nTjIL7R4cuNF8NCB6HCXp0burq8+XwI/5 u8P6fK9gU4PmlasP/MJVfOHlq+ev6IW86FCCYbyh936M733z5Pnju7vD0ZYA 6hCyTxLdlKa1SKCaZQufi8hA+8KtqlI6DaDXJ6044MYYQTJI1WuZJuWeAEXU HTknpIVLkVscYznKB1r2cL0g4A2ZPpfAFVs6UpZOzdxlSDRY1DcHt7eXmg2P yIBYUI9fqgAQni4EbZGt7GtTmdsHhMcccsYdV4Djtg5ZGpQRWFQRuHXhXjtw EnYAjYj0Li4kZyFwXZ6dv/3Ub1t1tzRls0ZoLWlbdYSLk/HVmGOIVpgMMERp kvMoMCtt2uxHaqV0U5bppKyzWZf3CuG9IJiWhCj8FjnifaAHuYT0OTIxNAJk nBJKAEDQDE1VBTbxiX4O8jZCbPApzoSXUUHlhSCQVgIf1Tt6Sv6aMDdRBjWr 5E6al0I1+U9CYqySTsKvNCtt65Ey5O9rrwFuyhLLQ3UY60KB1cqdIFVDPTmx FR/q9N4pclW4HVc7KMgJC32bFWDGzSLiqN1/OhifnB+SRlGzdkrWQzmw6vZS HGr4hWrP1vJ+jSBssbJIkh0baQrYQesMRLZVuN9TqnfQ8x+StPjIlrA7kq6l vMU2mZl4zhRVCJUWuu/CBkFdjFloA0Wg4MCH6x2wV8NYjXWRC3HELiYkaisb REPieNUqIGjY5SDaRbYrhCkFFa4igqc6oz5o7cnOcwFGnV2q/a1JAeE4hrqu qeQsfluWFnVOMdLGXru5IO4WnDSWLsQtyIJc8GRiBxcnh2biKbZwXqtPAqE9 Hu0lRpq3Rd1OEJa9WNl4bGapnUeg2XwdhAcQHUh/I2FbZlVbYa5zMnVpaaD6 kgsyDmttsrWBW8P9fDKMpgqmPRe2iOYUyNrhK6SZRyy4DWylJKSANWFQa4ur fKlRg1FApKjfMsolNJ01lsFg9y3bcB2h92cU+fuuVtPeaKOVTRVcaPiWryka kJSu/nEVw+ko0tI3igoVGwuq9RKDn1a5ooqmgl2Sd6y/mIFW6nw6ejoC0sWp KBAcPX76HGGFTXtWFdFGXWonecFNMFU7aA6lG3ApncNW14z65MNLGF1nU26a Nfu+GB3FTV+8lFimAiMMAEfWahL2lPqlF/tpDozc8ouLUI3MtQohRrR7txBj ugS5FAhd2j9gdLA3FrF2+sigj5DcKtdHHPCMmwSnZDduc2+UGxlzagGBtpeT wSKS5ol0I5tA2FFtJzw3h3m6dRhjvtB67t5SHofDQiZJZ9OwyUr7lQOiKm77 mILBPUc6Z4PHQci0tH4EqaD1knI1Um/sNIoIxWfU6mYt8yLCLruIwsdo1UUG fK8wEisnZ2DQU5t5uVBGOFNyh3u/hJ51JcRbEalJLBu0oG3cutUS7ngob8ec SqBuCSB6AN3yaOFNNt+qqg8paE/wTdZJRsAueJU03i/dcjXsMy8EIBqV0xNp dnNVhNJSYs/eaPMeTD76iRQdEHki1us14SJWSnuDkEi0iRrHvPBfxA9qer7Q OmY63H+k3kG8VKEiX6N7bG7sBPe6jmj3IsNuL1LvzagnsqS2v5DRzggs4jwv BV8NYi9DV+wxjz9mFQNNZEWkxHnIPPz2odgsSGmikB6dNZM8T50k4cJPqhJ2 HMBtuokEtMrhRgIUTyIXoYFrVj/os0OKxZn/u1gJ/TQ9dEhNBSuAyy7pspcI xt4xXZULAkE8pT6qdLjoMJ20yzBWStaGR88J1tLtgNbZtQTkJfcVxVmhpqIg dL8VuHZn1lFnNmhrVmirJLXFwo1aLbuqImtX+nuvJIG6tImgt1nEG28ioZ1l 35FzCq+V3IukHzyVp20W2zT4clz1UbfbiK14X+dD59Aj1B+yob7N15WJv/FJ hQPg0IzpDN+kE1N4QqUQf7wRb44FVMuysFV/CBBsfoZpKn/LKi099e+zPBsS /oVd5FWIVMi5azsU1LNFn1KthZHQxTKSe1Q9Vc5yQOJNexidVvvAvIFlcU13 cPTiULDwW27i86OXh4e1LVOThWPo71tzgdKB2jmcVm3IqZWwqUvetY2XDi55 NBFuBnJxwffCWMzlwGrl6Jpmq+J9GLpXZtwtWiUMarglO02rxHELOghC2LWC reseUnDJLVAt9LhxA9wQ+M4U8YyapZriY18h14506bThTWsghkwDFkmyXUbF eLcvhts5iryRuKpef3W3mhCawkZrOm2+I5B4/rZgdi5IJFwqG0paSxyODmTR MzZpUS6UFWBwk0qbKPQ9qY7APvmdRGhmpS8RpL9TR7b7+rELQGdV+EVXws4W 7RAQj3KfuptoQjJv6XQkeAZBFEKFFYXSpymiAUWIHb5a8wu2jLnrPphP8TOz U9RjrGzoNdZVvqxd7Q+EWaJZFanG2XFmvlx8ENGucq8NKm7yU2/MTwHFgDOq aVkVLXnEXNXiT/36JH9nxp/PQjOHMGiiIjUrCV6WVRBx1ebYDoGOiUj+oC6l WeRrkTgX2NzbAbXlIRlKFBvKOTwLizxnH1lVBRVgemuj7VM+pVRmQZx8S8B0 oUSYd68ChEi/Jet7NKW7CTTVrgD39cumNTdkuPywhMk+oomch+1adU8FoHV1 1294h8JxD8tr14xIkEZ9vAjkzrRWx30eeuo3PTa82coP0ldT5IyvdLf4PTUq uH9NZ4ELJt5iBd/xd8YPcJCzK1LzbEb4vmwjoz9wGRRbWHQK8hK1noiPdJyD XAxey7e6bUl1PIGSs+ZN7kTBvCJnnT4s31/TK7PqPlDQ6R/aNIiTNBenjX2q ddaZLmqmvuE+/DPueo74wnhUzxFhKYQUr+MaJnbatXIvR6Afjn4q9/O93u2t +zo8AiiiKyTePV7d8xWhzmy13H1PvwFE/wv/6tGDkZIYZa4cmZdPHj82Z+d1 yRYLAQV53x49Hx69VCFs/9MA9W0c0NvZAUnoEV1BOuHg9tg8oPPIrN23D5uT 0nH21joyNfgQWVvGeqCfefZtf+rofqCPomccmotrkWbd3L/bmkOQgQltV2jz 9eS81W9sCabfA0c07dA0zrlop07smhKFD6Fyv92VlziBPbFLj4yRF0oCq2F+ c0XT+4vOcewrngb4VhutlMv+HCZjOMfPQUVGwqj43nuhrIMq0p78fcVKmXoZ 5zTeUA8tiSMBvd7+cToSJNdHrbGn7iQYBzIphWv80tS1S2BEHqLjwRmBf7pe epI8oAG1SPs0QLZHI3OKaMLuEsug2KpPZM7EtdGYptYOwO89QTim4/MlppTr eOHy9I3huLHTYzt6HO+n5CbzkMiCUhyErJnwe24/uqHyjGtSVJ+IWzqukDUl sqylanCd19IZNKls5otQsixJzwDK6SZOUXitph92uu4PseW43f1v2uN2E40Q 0DkvCklpreScNY11heINkKK0orLS0jXG0BCxZdJMxbWvG+hWjtwnJgjiec/8 FZ7CqFap3Qi8JzJIXUNKXR1Uh4BapUmckNP+Uosblp2m5j1ioMuHUM1mNK/B uDhejXZHmMRIdKhIs0zMolz/6JilTcjZaYaXy/KtbxlkTyq49BDSJSwt7XDa k8Ba7TeHsSbQQT5poUqo00ktSRxLS5MmVDPuORtdqnBhvbDFUhyVR40hOuuX QVye22Db7v437duI3GH35hQVfF4cm88IeyGiddPHV//Av77JCSbT9IsLTceM Fsr0v/YgZWg6arQ73/vgQecG8wpobc8UtJYnQfgGGeWEqTmalK/Njhb37x9b 7zfNP3XZ/u7MuEyKdsfGWwvlSsPeWJSbfEVe0qgaD8/f3R1rvr7in0LEe0nu 9x2bJy+Oeh+dzWBfx/szJgzzvdtIfxC7w/N7fPVPMj42KnjZgWR33485iAi+ mKtR8iVHxCl/RL5ThqD1bJcenKJdycBdIfK9Dc6+3FTfJ+Dfly7icBzw50sG YbjDDSF8HjtkNObl4qG5LZMmeKv/E+95I7D9jXhdVx0tATboD4xcdi5mLiA+ ubRrssez0YvYwXx19OQFH6I1lezohytliIEM9SVhYgHfU/VLKSxicqbepW4o I2b1RE3H99sdkdjSZzeJchuZcd2Ya++mlKX9pJPcjMjAwTBx8R6Gy7xYqDZp T3Xiud0vuT5Ib5rU3upLU6lAIFWrH25hMl6gqAkVxPDTKFUvxrjRqBd1d7s/ FRBy3fZ+nMyqJ+20b89WUbf6jXb7tb8/MFJzBKdvt81nVjgnoy82qxvJEVTE LuwJD6WtZNRGqn+TNM+6QmP4BKHoLVfbrlpSK2IM2LoSbIrZSCu2v4SlRmdx oLIzstIyC1JdV++6ghXf+1Xc15hfO+fDx64r/Nr79XjI/47jH/Kv+wnfgmRd rfy6p7femMp2f33PoDSnAQrGCWhplCRetA5ivj/U3WO68cYeccWeNjfAD2B2 FUptBVMQH775dHLKE+XIv9os1lul/p4Z5jfUd+m33K7FmWHetACjLz6L5LlG 3NMnop/p7GsP7Y7HxlkQNoytXk17f+KACrpoFlrTnenHOiUr9w/vJFV/T1VD ynO/0fRaQe1Ug9rtA40ZMgbAXIVqPnfcRpQSJjbBk92YSCJf8eHlIDJMFaM+ z/vVGUsM/A0iJMCwFdoaU4VM6pt21569NFzyfbSTrjDXN63mN0045YGl3koH SSXh2AXpOuqdLoER7lNTwdgi0l3bciDqhlFRKZf3Xn6Aw9tKZ23HUeP9Z4te nb4peDuyzPpHT3w5Vi4QtoZr566pV++RGehXk3n8OQfwK88CSO7kmq2QGnNX YHSV0VxLd6gNIvzaI2YG/3opy/D2hjdJXLbZEY+oW/vR3bJTQr7+poMcg+L9 SGJuBrut82nMgtxyQT2R2dil584428WUvH8QDZMhMAjJWJJ2QumaXfljfqiZ SQUHUrX+Nm2CCpXbPlO6SEc0mfOPA+FbAoFd8m2f4Xe/hbu6MTyl3xbYuU6V UJ9EzHjB15Iuq3NcPSNye/vd2fBktFrF3+NSGGgStM2u+RBXkN3G/ODop7cD 85Mv6ZdyuXkNjeSppScZxA8QRh/eLApw9jr/OsALvMvldLG2RfnLAITw3lvI dDEwJ0CvLjXv7SIz30OrS/oZ2Sk1sAEGAbaJ1iVYJy6Iyg+AaAPzNsXWUMan CVdyFx5uDFz+2qZJsZGex0fsBbO6WuTL0MpsOiWi2ovTpjyIuHVcELg24ywp 3BrV8w+5M2MoGNQ/2yo1P+cVAU3Z68ozxv8ZVVQWrv2+zdQ1UJNIhGX74+vr VqbmW6994q4pKrDTqbO8mi9K+ni5cCv4QqIetH2UH3L8aS6RU0Jpl7z4B7+E hH3S8JqFYeILpYCDXaC2f+1SFJj1O1KUMFScxlBBbw/MuAAG+L5KJwXNkrYY Hl9cxZfYHVgzWI/Q+z5DSkvrN+cuG0Jn9xyBTeKnTTa9bsbDxif3vPx9RejJ /ES/O3TmJ5cmjo3q2rynZLOtwk8IsSQdR/77s6UK1LyvlrbwkAKKjYysdJP6 tVoWalTI5n01hcjtelPzc3Z6+X3N0f8CF3nrgUc/AAA= --></rfc>