rfc9606.original.xml   rfc9606.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!-- pre-edited by ST 05/28/24 -->
<!-- draft submitted in xml v3 -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?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"
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRef
-ietf-add-resolver-info-13" category="std" consensus="true" submissionType="IETF s="true" version="3" xml:lang="en">
" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.21.0 -->
<front> <front>
<title abbrev="DNS Resolver Information">DNS Resolver Information</title> <title abbrev="DNS Resolver Information">DNS Resolver Information</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-add-resolver-info-13"/> <seriesInfo name="RFC" value="9606"/>
<author fullname="Tirumaleswar Reddy"> <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<postal> <postal>
<country>India</country> <country>India</country>
</postal> </postal>
<email>kondtir@gmail.com</email> <email>kondtir@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Mohamed Boucadair"> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<city>Rennes</city> <city>Rennes</city>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<date year="2024" month="April" day="26"/> <date year="2024" month="June"/>
<area>Internet</area>
<workgroup>ADD</workgroup> <area>INT</area>
<workgroup>add</workgroup>
<keyword>Transparency</keyword> <keyword>Transparency</keyword>
<keyword>User Experience</keyword> <keyword>User Experience</keyword>
<keyword>DNS server selection</keyword> <keyword>DNS server selection</keyword>
<abstract> <abstract>
<?line 50?>
<t>This document specifies a method for DNS resolvers to publish <t>This document specifies a method for DNS resolvers to publish
information about themselves. DNS clients can use the resolver information about themselves. DNS clients can use the resolver
information to identify the capabilities of DNS resolvers. How DNS clients us information to identify the capabilities of DNS resolvers. How DNS clients us
e such an information is beyond the scope of this document.</t> e such information is beyond the scope of this document.</t>
</abstract> </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> </front>
<middle> <middle>
<?line 56?> <?line 56?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Historically, DNS clients communicated with recursive <t>Historically, DNS clients communicated with recursive
resolvers without needing to know anything about the features resolvers without needing to know anything about the features
supported by these resolvers. However, more and more recursive resolvers expo se different features that may impact delivered DNS supported by these resolvers. However, more and more recursive resolvers expo se different features that may impact delivered DNS
services (privacy preservation, filtering, transparent behavior, etc.). DNS c lients services (privacy preservation, filtering, transparent behavior, etc.). DNS c lients
can discover and authenticate encrypted DNS resolvers provided by a can discover and authenticate encrypted DNS resolvers provided by a
local network, for example, using the Discovery of Network-designated local network, for example, using the Discovery of Network-designated
Resolvers (DNR) <xref target="RFC9463"/> and the Discovery of Designated Reso lvers Resolvers (DNR) <xref target="RFC9463"/> and the Discovery of Designated Reso lvers
(DDR) <xref target="RFC9462"/>. However, these DNS clients can't retrieve (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 ap proaches, DNS clients need a more reliable mechanism to discover the features th at are configured on these resolvers.</t> information from the discovered recursive resolvers about their capabilities to feed the resolver selection process. Instead of depending on opportunistic ap proaches, DNS clients need a more reliable mechanism to discover the features th at are configured on these resolvers.</t>
<t>This document fills that void by specifying a mechanism that allows com munication of DNS resolver <t>This document fills that void by specifying a mechanism that allows com munication of DNS resolver
information to DNS clients for use in resolver selection decisions. For example, the resolver selection procedure may use the retrieved 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 QNAME minimization <xref target="RFC9156"/>. Another resolver information to prioritize privacy-preserving resolvers over those that don't enable QNAME minimisation <xref target="RFC9156"/>. Another
example is when a DNS client selects a resolver based on its filtering capabilit y. For instance, a DNS client can choose a resolver that example is when a DNS client selects a resolver based on its filtering capabilit y. For instance, a DNS client can choose a resolver that
filters domains according to a security policy using the Blocked (15) Extended D NS Error (EDE) <xref target="RFC8914"/>. Alternatively, the client may filters domains according to a security policy using the Blocked (15) Extended D NS Error (EDE) <xref target="RFC8914"/>. Alternatively, the client may
have a policy not to select a resolver that forges responses using the Forged An swer (4) EDE. However, it is out of the scope of this have a policy not to select a resolver that forges responses using the Forged An swer (4) EDE. However, it is out of the scope of this
document to define the selection procedure and policies. Once a resolver is sele cted by a DNS client, and unless explicitly mentioned, this document to define the selection procedure and policies. Once a resolver is sele cted by a DNS client, and unless explicitly mentioned, this
document does not interfere with DNS operations with that resolver.</t> document does not interfere with that 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 re solver might want to expose is defined in <t>Specifically, this document defines a new resource record (RR) type for DNS clients to query the recursive resolvers. The initial information that a re solver might want to expose is defined in
<xref target="key-val"/>. That information is scoped to cover properties that ar e used to infer privacy and transparency policies of a resolver. Other informati on can be registered in the future per the guidance in <xref target="key-reg"/>. The information is not intended for end user consumption.</t> <xref target="key-val"/>. That information is scoped to cover properties that ar e used to infer privacy and transparency policies of a resolver. Other informati on can be registered in the future per the guidance in <xref target="key-reg"/>. The information is not intended for end-user consumption.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <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>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t> 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> <t>This document makes use of the terms defined in <xref target="RFC8499"/>. The following additional terms are used:</t>
<dl> <dl>
<dt>Encrypted DNS:</dt> <dt>Encrypted DNS:</dt>
<dd> <dd>Refers to a DNS scheme where DNS exchanges are
<t>Refers to a DNS scheme where DNS exchanges are
transported over an encrypted channel between a DNS client and server (e.g., 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 HTTPS (DoH) <xref target="RFC8484"/>, DNS over TLS (DoT) <xref target= "RFC7858"/>, or
DNS over QUIC (DoQ) <xref target="RFC9250"/>).</t> DNS over QUIC (DoQ) <xref target="RFC9250"/>).
</dd> </dd>
<dt>Encrypted DNS resolver:</dt> <dt>Encrypted DNS resolver:</dt>
<dd> <dd>Refers to a DNS resolver that supports any encrypted DNS scheme.
<t>Refers to a DNS resolver that supports any encrypted DNS scheme.</t
>
</dd> </dd>
<dt>Reputation:</dt> <dt>Reputation:</dt>
<dd> <dd>Defined as "the estimation in which an identifiable actor is held, e
<t>"The estimation in which an identifiable actor is held, especially specially by the
by the community or the Internet public generally" per <xref section="1" sectionFormat
community or the Internet public generally" (<xref section="1" sectionFormat="o ="of" target="RFC7070"/>.
f" target="RFC7070"/>).</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="retreive"> <section anchor="retreive">
<name>Retrieving Resolver Information</name> <name>Retrieving Resolver Information</name>
<t>A DNS client that wants to retrieve the resolver information may <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 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 response to a query for RESINFO RR QTYPE is defined in <xref target="key-val" />. If the resolver understands the
RESINFO RR type, the RRSet <bcp14>MUST</bcp14> have exactly one record. Inval id 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> RESINFO RR type, the RRset <bcp14>MUST</bcp14> have exactly one record. Inval id 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 <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 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 <xre f target="RFC9463"/>).</t> DNS resolver (referred to as the Authentication Domain Name (ADN) in DNR <xre f target="RFC9463"/>).</t>
<t>If the Special-Use Domain Name "resolver.arpa", defined in <xref target ="RFC9462"/>, is used to <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 info rmation discover an encrypted DNS resolver, the client can retrieve the resolver info rmation
using the RESINFO RR type and QNAME of "resolver.arpa". In this case, a clien using the RESINFO RR type and QNAME of "resolver.arpa". In this case, a clien
t has to contend t has to contend with the risk that a resolver does not support RESINFO. The res
with the risk that a resolver does not support RESINFO. The resolver might olver might
pass the query upstream, and then the client can receive a positive RESINFO r pass the query upstream, and then the client can receive a positive RESINFO r
esponse either esponse from either
from a legitimate DNS resolver or an attacker.</t> a legitimate DNS resolver or an attacker.</t>
<t>The DNS client <bcp14>MUST</bcp14> set the Recursion Desired (RD) bit o f <t>The DNS client <bcp14>MUST</bcp14> set the Recursion Desired (RD) bit o f
the query to 0. The DNS client <bcp14>MUST</bcp14> discard the response if th e AA flag in the response is set to 0, the query to 0. The DNS client <bcp14>MUST</bcp14> discard the response if th e AA flag in the response is set to 0,
indicating that the DNS resolver is not authoritative for the response.</t> 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> <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>
<section anchor="format"> <section anchor="format">
<name>Format of the Resolver Information</name> <name>Format of the Resolver Information</name>
<t>The resolver information record uses the same format as DNS TXT records . <t>The resolver information record uses the same format as DNS TXT records .
The format rules for TXT records are defined in The format rules for TXT records are defined in
the base DNS specification (<xref section="3.3.14" sectionFormat="of" target= "RFC1035"/>) and further 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 elaborated in the DNS-based Service Discovery (DNS-SD) specification
(<xref section="6.1" sectionFormat="of" target="RFC6763"/>). The recommendati ons to limit the TXT record size are (<xref section="6.1" sectionFormat="of" target="RFC6763"/>). The recommendati ons to limit the TXT record size are
discussed in <xref section="6.1" sectionFormat="of" target="RFC6763"/>.</t> discussed in <xref section="6.1" sectionFormat="of" target="RFC6763"/>.</t
<t>Similar to DNS-SD, the RESINFO RR type uses "key/value" pairs to >
<!--[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 convey the resolver information. Each "key/value" pair is encoded
using the format rules defined in <xref section="6.3" sectionFormat="of" targ et="RFC6763"/>. Using using the format rules defined in Section 6.3 of [RFC6763]. Using
standardized "key/value" syntax within the RESINFO RR type makes it 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" targ
et="RFC6763"/>. Using
standardized key/value syntax within the RESINFO RR type makes it
easier for future keys to be defined. If a DNS client sees unknown 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 keys in a RESINFO RR type, it <bcp14>MUST</bcp14> silently ignore them. The s
same ame rules for the keys, as defined in <xref section="6.4" sectionFormat="of" tar
rules for the keys as those defined in <xref section="6.4" sectionFormat="of" get="RFC6763"/>, <bcp14>MUST</bcp14> be followed for RESINFO.</t>
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 <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> with the substring "temp-" for names defined for local use only.</t>
</section> </section>
<section anchor="key-val"> <section anchor="key-val">
<name>Resolver Information Keys/Values</name> <name>Resolver Information Keys/Values</name>
<t>The following resolver information keys are defined:</t> <t>The following resolver information keys are defined:</t>
<dl> <dl>
<dt>qnamemin:</dt> <dt>qnamemin:</dt>
<dd> <dd>
<t>The presence of this key indicates that the DNS resolver supports Q NAME minimisation <xref target="RFC9156"/> <t>The presence of this key indicates that the DNS resolver supports Q NAME minimisation <xref target="RFC9156"/>
to improve DNS privacy. Note that, per the to improve DNS privacy. Note that, per the
rules for the keys defined in <xref section="6.4" sectionFormat="of" target="RF C6763"/>, if there rules for the keys defined in <xref section="6.4" sectionFormat="of" target="RF C6763"/>, if there
is no '=' in a key, then it is a boolean attribute, simply is no '=' in a key, then it is a boolean attribute, simply
identified as being present, with no value. identified as being present, with no value.
</t> </t>
<t>The presence of this key indicates that the DNS resolver is configu red to minimise the amount of privacy-sensitive data sent to an authoritative na me server.</t> <t>The presence of this key indicates that the DNS resolver is configu red to minimise the amount of privacy-sensitive data sent to an authoritative na me server.</t>
<t>This is an optional attribute.</t> <t>This is an optional attribute.</t>
</dd> </dd>
<dt>exterr:</dt> <dt>exterr:</dt>
<dd> <dd>
<t>If the DNS resolver supports extended DNS errors (EDE) option <t>If the DNS resolver supports the EDE option defined in
<xref target="RFC8914"/> to return additional information about the cause of DN S <xref target="RFC8914"/> to return additional information about the cause of DN S
errors, the value of this key lists the possible extended DNS errors, the value of this key lists the possible EDE codes that can be returned
error codes that can be returned by this DNS resolver. A value can be an indivi by this DNS resolver. A value can be an individual EDE or a range of EDEs. Rang
dual EDE or a range of EDEs. Range values <bcp14>MUST</bcp14> be identified by " e values <bcp14>MUST</bcp14> be identified by "-". When
-". When
multiple non-contiguous values are present, these values <bcp14>MUST</bcp14> be comma-separated. multiple non-contiguous values are present, these values <bcp14>MUST</bcp14> be comma-separated.
</t> </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 que ry was filtered/blocked, when such event happens. If the resolver's capabilities are updated to include new similar <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 que ry was filtered/blocked when such an event happens. If the resolver's capabiliti es are updated to include new similar
error codes, the resolver can terminate the TLS session, prompting the client t o initiate a new TLS connection and retrieve the error codes, the resolver can terminate the TLS session, prompting the client t o initiate a new TLS connection and retrieve the
resolver information again. This allows the client to become aware of the resol ver's updated capabilities. Alternatively, if the resolver information again. This allows the client to become aware of the resol ver'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 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 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> the resolver information is inaccurate and discard it.</t>
<t>This is an optional attribute.</t> <t>This is an optional attribute.</t>
</dd> </dd>
<dt>infourl:</dt> <dt>infourl:</dt>
<dd> <dd>
<t>An URL that points to the generic unstructured resolver <t>A URL that points to the generic unstructured resolver
information (e.g., DoH APIs supported, possible HTTP status codes information (e.g., DoH APIs supported, possible HTTP status codes
returned by the DoH server, or how to report a problem) for returned by the DoH server, or how to report a problem) for
troubleshooting purposes. The server that exposes such information is called "r esolver information server". troubleshooting purposes. The server that exposes such information is called "r esolver information server".
</t> </t>
<t>The resolver information server <bcp14>MUST</bcp14> support only th <t>The resolver information server <bcp14>MUST</bcp14> support only th
e content-type 'text/html' for the resolver information. The DNS e content-type "text/html" for the resolver information. The DNS
client <bcp14>MUST</bcp14> reject invalid the URL if the scheme is not "https". client <bcp14>MUST</bcp14> reject the URL as invalid if the scheme is not "http
Invalid URLs <bcp14>MUST</bcp14> be ignored. The URL s". Invalid URLs <bcp14>MUST</bcp14> be ignored. The URL
<bcp14>MUST</bcp14> be treated only as diagnostic information for IT staff. It <bcp14>MUST</bcp14> be treated only as diagnostic information for IT staff. It
is not intended for end user consumption as the URL can possibly is not intended for end-user consumption as the URL can possibly provide mislea
provide misleading information.</t> ding information.</t>
<t>This key can be used by IT staff to retrieve other useful informati on about the resolver and also the procedure to report problems (e.g., invalid f iltering).</t> <t>This key can be used by IT staff to retrieve other useful informati on about the resolver and also the procedure to report problems (e.g., invalid f iltering).</t>
<t>This is an optional attribute.</t> <t>This is an optional attribute.</t>
</dd> </dd>
</dl> </dl>
<t>New keys can be defined as per the procedure defined in <xref target="k ey-reg"/>.</t> <t>New keys can be defined as per the procedure defined in <xref target="k ey-reg"/>.</t>
</section> </section>
<section anchor="an-example"> <section anchor="an-example">
<name>An Example</name> <name>An Example</name>
<t><xref target="ex-1"/> shows an example of a published resolver informat ion record.</t> <t><xref target="ex-1"/> shows an example of a published resolver informat ion record.</t>
<figure anchor="ex-1"> <figure anchor="ex-1">
<name>An Example of Resolver Information Record</name> <name>An Example of a Resolver Information Record</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
resolver.example.net. 7200 IN RESINFO qnamemin exterr=15-17 resolver.example.net. 7200 IN RESINFO qnamemin exterr=15-17
infourl=https://resolver.example.com/guide infourl=https://resolver.example.com/guide
]]></artwork> ]]></artwork>
</figure> </figure>
<t>As mentioned in <xref target="retreive"/>, a DNS client that discovers the ADN "resolver.example.net" <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 of its resolver using DNR will issue a query for RESINFO RR QTYPE for that ADN a
and will learn that the resolver:</t> nd will learn that:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>the resolver enables QNAME minimisation,
<t>enables QNAME minimisation,</t>
</li> </li>
<li> <li>the resolver can return Blocked (15), Censored (16), and Filtered (1
<t>can return Blocked (15), Censored (16), and Filtered (17) EDEs, and 7) EDEs, and
</t>
</li> </li>
<li> <li>more information can be retrieved from "https://resolver.example.com
<t>that more information can be retrieved from https://resolver.exampl /guide".
e.com/guide.</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>DNS clients communicating with discovered DNS resolvers <bcp14>MUST</bc p14> use one of the following measures <t>DNS clients communicating with discovered DNS resolvers <bcp14>MUST</bc p14> use one of the following measures
to prevent DNS response forgery attacks:</t> to prevent DNS response forgery attacks:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal" type="1">
<t>Establish an authenticated secure connection to the DNS resolver.</ <li> Establish an authenticated secure connection to the DNS resolver.
t>
</li> </li>
<li> <li>Implement local DNSSEC validation (<xref section="10" sectionFormat=
<t>Implement local DNSSEC validation (<xref section="10" sectionFormat "of" target="RFC8499"/>) to verify the authenticity of the resolver information.
="of" target="RFC8499"/>) to verify the authenticity of the resolver information
.</t>
</li> </li>
</ol> </ol>
<t>It is important to note that, of these two measures, only the first one <t>It is important to note that, of these two measures, only the first one
can apply to queries for 'resolver.arpa'.</t> can apply to queries for "resolver.arpa".</t>
<t>An encrypted resolver may return incorrect information in RESINFO. If t <t>An encrypted resolver may return incorrect information in RESINFO. If t
he client cannot validate the attributes received from the resolver, that will b he client cannot validate the attributes received from the resolver, which will
e used for resolver selection or displayed to the end-user, the client should pr be used for resolver selection or displayed to the end user, the client should p
ocess those attributes only if the encrypted resolver has sufficient reputation rocess those attributes only if the encrypted resolver has sufficient reputation
according to local policy (e.g., user configuration, administrative configuratio according to local policy (e.g., user configuration, administrative configurati
n, or a built-in list of reputable resolvers). This approach limits the ability on, 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> of a malicious encrypted resolver to cause harm with false claims.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<ul empty="true">
<li>
<t>Note to the RFC Editor: Please update "RFCXXXX" occurrences with th
e RFC number to be assigned to this document.</t>
</li>
</ul>
<section anchor="resinfo-rr-type"> <section anchor="resinfo-rr-type">
<name>RESINFO RR Type</name> <name>RESINFO RR Type</name>
<t>This document requests IANA to update this entry from the <t>IANA has updated the "Resource Record (RR) TYPEs" registry under the
"Resource Record (RR) TYPEs" registry of the "Domain Name System "Domain Name System
(DNS) Parameters" registry group available at <xref target="RRTYPE"/>:</t> (DNS) Parameters" registry group <xref target="RRTYPE"/> as follows:</t>
<artwork><![CDATA[ <dl spacing="compact">
Type: RESINFO <dt>Type:</dt><dd>RESINFO</dd>
Value: 261 <dt>Value:</dt><dd>261</dd>
Meaning: Resolver Information as Key/Value Pairs <dt>Meaning:</dt><dd>Resolver Information as Key/Value Pairs</dd>
Reference: RFCXXXX <dt>Reference:</dt><dd>RFC 9606</dd>
]]></artwork> </dl>
</section> </section>
<section anchor="key-reg"> <section anchor="key-reg">
<name>DNS Resolver Information Key Registration</name> <name>DNS Resolver Information Keys Registration</name>
<t>This document requests IANA to create a new registry entitled "DNS <t>IANA has created a new registry called "DNS Resolver Information Keys
Resolver Information Keys" under the "Domain Name System (DNS) Parameters" re " under the "Domain Name System (DNS) Parameters" registry group <xref target="I
gistry group (<xref target="IANA-DNS"/>). This new registry contains definition ANA-DNS"/>. This new registry contains definitions of the keys that can be used
s of to provide the resolver information.</t>
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 <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 consider the security implications of allowing a resolver to include new keys
in this registry. Additional in this registry. Additional considerations are provided in <xref target="sec-d
considerations are provided in <xref target="sec-de"/>.</t> e"/>.</t>
<t>The structure of the registry is as follows:</t> <t>The structure of the registry is as follows:</t>
<dl> <dl>
<dt>Name:</dt> <dt>Name:</dt>
<dd> <dd>The key name. The name <bcp14>MUST</bcp14> conform to the definit
<t>The key name. The name <bcp14>MUST</bcp14> conform to the defini ion in
tion in
<xref target="format"/> of this document. The IANA registry <bcp14>MUST NOT</b cp14> register names that begin <xref target="format"/> of this document. The IANA registry <bcp14>MUST NOT</b cp14> register names that begin
with "temp-", so these names can be used freely by any with "temp-" so that these names can be used freely by any
implementer.</t> implementer.
</dd> </dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>A description of the registered key.
<t>A description of the registered key.</t>
</dd> </dd>
<dt>Specification:</dt> <dt>Reference:</dt>
<dd> <dd>The reference specification for the registered element.
<t>The reference specification for the registered
element.</t>
</dd> </dd>
</dl> </dl>
<t>The initial content of this registry is provided in <xref target="ini tial"/>.</t> <t>The initial contents of this registry are provided in <xref target="i nitial"/>.</t>
<table anchor="initial"> <table anchor="initial">
<name>Initial RESINFO Registry</name> <name>Initial Contents of the DNS Resolver Information Keys Registry</ name>
<thead> <thead>
<tr> <tr>
<th align="center">Name</th> <th align="left">Name</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="center">Specification</th> <th align="center">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">qnamemin</td> <td align="left">qnamemin</td>
<td align="left">The presence of the key name indicates that QNAME <td align="left">The presence of the key name indicates that QNAME
minimization is enabled</td> minimisation is enabled.</td>
<td align="center">RFCXXXX</td> <td align="center">RFC 9606</td>
</tr> </tr>
<tr> <tr>
<td align="center">exterr</td> <td align="left">exterr</td>
<td align="left">Lists the set of enabled extended DNS errors. It <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.</ must be an INFO-CODE decimal value in the "Extended DNS Error Codes" registry <e
td> ref target="https://www.iana.org/assignments/dns-parameters/" brackets="angle" /
<td align="center">RFCXXXX</td> >. </td>
<td align="center">RFC 9606</td>
</tr> </tr>
<tr> <tr>
<td align="center">infourl</td> <td align="left">infourl</td>
<td align="left">Provides an URL that points to an unstructured re <td align="left">Provides a URL that points to unstructured resolv
solver information that is used for troubleshooting</td> er information that is used for troubleshooting.</td>
<td align="center">RFCXXXX</td> <td align="center">RFC 9606</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="sec-de"> <section anchor="sec-de">
<name>Guidelines for the Designated Experts</name> <name>Guidelines for the Designated Experts</name>
<t>It is suggested that multiple designated experts be appointed for <t>It is suggested that multiple designated experts be appointed for
registry change requests.</t> registry change requests.</t>
<t>Criteria that should be applied by the designated experts include <t>Criteria that should be applied by the designated experts include
determining whether the proposed registration duplicates existing determining whether the proposed registration duplicates existing
entries and whether the registration description is clear and fits entries and whether the registration description is clear and fits
the purpose of this registry.</t> the purpose of this registry.</t>
<t>Registration requests are evaluated within a three-week review period on the advice of <t>Registration requests are evaluated within a two-week review period o n the advice of
one or more designated experts. Within the review period, the one or more designated experts. Within the review period, the
designated experts will either approve or deny the registration designated experts will either approve or deny the registration
request, communicating this decision to IANA. request, communicating this decision to IANA.
Denials should include an explanation and, if applicable, suggestions Denials should include an explanation and, if applicable, suggestions
as to how to make the request successful.</t> as to how to make the request successful.</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.pp-add-resinfo" to="RESINFO"/>
<references> <references>
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC9463">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.94
<title>DHCP and Router Advertisement Options for the Discovery of Ne 63.xml"/>
twork-designated Resolvers (DNR)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.94
<author fullname="M. Boucadair" initials="M." role="editor" surname= 62.xml"/>
"Boucadair"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.91
<author fullname="T. Reddy.K" initials="T." role="editor" surname="R 56.xml"/>
eddy.K"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<author fullname="D. Wing" initials="D." surname="Wing"/> 19.xml"/>
<author fullname="N. Cook" initials="N." surname="Cook"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<author fullname="T. Jensen" initials="T." surname="Jensen"/> 74.xml"/>
<date month="November" year="2023"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.10
<abstract> 35.xml"/>
<t>This document specifies new DHCP and IPv6 Router Advertisement <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.67
options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS, 63.xml"/>
and DNS over QUIC). Particularly, it allows a host to learn an Authentication D <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.89
omain Name together with a list of IP addresses and a set of service parameters 14.xml"/>
to reach such encrypted DNS resolvers.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
</abstract> 26.xml"/>
</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 D
NS Resolvers and their Designated Resolvers are operated by the same entity or c
ooperating entities. It can also be used to discover support for encrypted DNS p
rotocols 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 obs
oletes 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</tit
le>
<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 sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, 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</ti
tle>
<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 protoco
l 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 forma
t used in the implementation of the Domain Name System. It obsoletes RFC-883. Th
is 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 clien
t 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 desi
red service, using standard DNS queries. This mechanism is referred to as DNS-ba
sed 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 S
ERVFAIL to provide additional information about the cause of DNS and DNSSEC fail
ures, the Extended DNS Errors option defined in this document allows all respons
e types to contain extended error information. Extended DNS Error information do
es 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 con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations 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 des
cribing the conditions under which new values should be assigned, as well as whe
n 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 Consideratio
ns 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 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RRTYPE" target="https://www.iana.org/assignments/dns-
parameters/dns-parameters.xhtml"> <reference anchor="RRTYPE" target="https://www.iana.org/assignments/dns-
parameters/">
<front> <front>
<title>Resource Record (RR) TYPEs</title> <title>Resource Record (RR) TYPEs</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<reference anchor="IANA-DNS" target="http://www.iana.org/assignments/dns
-parameters/dns-parameters.xhtml#dns-parameters-4"> <reference anchor="IANA-DNS" target="https://www.iana.org/assignments/dn
s-parameters/">
<front> <front>
<title>Domain Name System (DNS) Parameters</title> <title>Domain Name System (DNS) Parameters</title>
<author> <author>
<organization>IANA</organization> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </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 proto
cols, and by operators of DNS systems, has sometimes changed in the decades sinc
e 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 ge
tting DNS responses over HTTPS. Each DNS query-response pair is mapped into an H
TTP 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)</ti
tle>
<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 (TL
S) to provide privacy for DNS. Encryption provided by TLS eliminates opportuniti
es 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 profil
es for DNS over TLS and provides advice on performance considerations to minimiz
e 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 applica
tions 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 co
nfidentiality for DNS. The encryption provided by QUIC has similar properties to
those provided by TLS, while QUIC transport eliminates the head-of-line blockin
g 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) s
pecified in RFC 7858, and latency characteristics similar to classic DNS over UD
P. This specification describes the use of DoQ as a general-purpose transport fo
r DNS and includes the use of DoQ for stub to recursive, recursive to authoritat
ive, 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 over the Interne
t, where "reputation" refers to predictions or expectations about an entity or a
n identifier such as a domain name. The document roughly follows the recommendat
ions of RFC 4101 for describing a protocol model.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7070"/>
<seriesInfo name="DOI" value="10.17487/RFC7070"/>
</reference>
<reference anchor="I-D.pp-add-resinfo">
<front>
<title>DNS Resolver Information Self-publication</title>
<author fullname="Puneet Sood" initials="P." surname="Sood">
<organization>Google</organization>
</author>
<author fullname="Paul E. Hoffman" initials="P. E." surname="Hoffman
">
<organization>ICANN</organization>
</author>
<date day="30" month="June" year="2020"/>
<abstract>
<t> This document describes methods for DNS resolvers to self-pu
blish
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> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
</abstract> 99.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
<seriesInfo name="Internet-Draft" value="draft-pp-add-resinfo-02"/> 84.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.78
58.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.92
50.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.70
70.xml"/>
<!-- [I-D.pp-add-resinfo] IESG state: Expired as of 06/24/24; entered the long w
ay to get the correct initials-->
<reference 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="Paul Hoffman" initials="P." surname="Hoffman">
<organization>ICANN</organization>
</author>
<date day="30" month="June" year="2020"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-pp-add-resinfo-02"/>
</reference>
</references> </references>
</references> </references>
<?line 313?>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>This specification leverages the work that has been documented in <t>This specification leverages the work that has been documented in
<xref target="I-D.pp-add-resinfo"/>.</t> <xref target="I-D.pp-add-resinfo"/>.</t>
<t>Thanks to Tommy Jensen, Vittorio Bertola, Vinny Parla, Chris Box, Ben <t>Thanks to <contact fullname="Tommy Jensen"/>, <contact fullname="Vittor
Schwartz, Tony Finch, Daniel Kahn Gillmor, Eric Rescorla, Shashank io Bertola"/>, <contact fullname="Vinny Parla"/>, <contact fullname="Chris Box"/
Jain, Florian Obser, Richard Baldry, and Martin Thomson for the discussion an >, <contact fullname="Ben Schwartz"/>, <contact fullname="Tony Finch"/>, <contac
d t fullname="Daniel Kahn Gillmor"/>, <contact fullname="Eric Rescorla"/>, <contac
comments.</t> t fullname="Shashank Jain"/>, <contact fullname="Florian Obser"/>, <contact full
<t>Thanks to Mark Andrews, Joe Abley, Paul Wouters, and Tim name="Richard Baldry"/>, and <contact fullname="Martin Thomson"/> for the discus
Wicinski for the discussion on the RR formatting rules.</t> sion and comments.</t>
<t>Special thanks to Tommy Jensen for the careful and thoughtful Shepherd <t>Thanks to <contact fullname="Mark Andrews"/>, <contact fullname="Joe Ab
review.</t> ley"/>, <contact fullname="Paul Wouters"/>, and <contact fullname="Tim Wicinski"
<t>Thanks to Johan Stenstam and Jim Reid for the dns-dir reviews, Ray Bell /> for the discussion on RR formatting rules.</t>
is for the RRTYPE allocation review, Arnt Gulbrandsen for the ART review, <t>Special thanks to <contact fullname="Tommy Jensen"/> for the careful an
and Mallory Knodel for the gen-art review.</t> d thoughtful Shepherd review.</t>
<t>Thanks to Eric Vyncke for the AD review.</t> <t>Thanks to <contact fullname="Johan Stenstam"/> and <contact fullname="J
<t>Thanks to Gunter Van de Velde, Erik Kline, Paul Wouters, Orie Steele, W im Reid"/> for the dns-dir reviews, <contact fullname="Ray Bellis"/> for the RRT
arren Kumari, Roman Danyliw, and Murray Kucherawy for the IESG review.</t> YPE allocation review, <contact fullname="Arnt Gulbrandsen"/> for the ART review
, and <contact fullname="Mallory Knodel"/> for the gen-art review.</t>
<t>Thanks to <contact fullname="Éric Vyncke"/> for the AD review.</t>
<t>Thanks to <contact fullname="Gunter Van de Velde"/>, <contact fullname=
"Erik Kline"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Orie Stee
le"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Roman Danyliw"/>,
and <contact fullname="Murray Kucherawy"/> for the IESG review.</t>
</section> </section>
</back> </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> </rfc>
 End of changes. 63 change blocks. 
621 lines changed or deleted 222 lines changed or added

This html diff was produced by rfcdiff 1.48.