rfc9461.original.xml   rfc9461.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!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.6.35 (Ruby 3.2. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-add-svcb-dns-09" number="9461" category="std" submissionType="IETF" consen
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft sus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
-ietf-add-svcb-dns-09" category="std" consensus="true" tocInclude="true" sortRef
s="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.3 --> <!-- xml2rfc v2v3 conversion 3.17.3 -->
<front> <front>
<title abbrev="SVCB for DNS">Service Binding Mapping for DNS Servers</title> <title abbrev="SVCB for DNS">Service Binding Mapping for DNS Servers</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-add-svcb-dns-09"/> <seriesInfo name="RFC" value="9461"/>
<author initials="B." surname="Schwartz" fullname="Benjamin Schwartz"> <author initials="B." surname="Schwartz" fullname="Benjamin Schwartz">
<organization>Meta Platforms, Inc.</organization> <organization>Meta Platforms, Inc.</organization>
<address> <address>
<email>ietf@bemasc.net</email> <email>ietf@bemasc.net</email>
</address> </address>
</author> </author>
<date year="2023" month="June" day="26"/> <date year="2023" month="November"/>
<area>General</area> <area>int</area>
<workgroup>add</workgroup> <workgroup>add</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<?line 32?>
<keyword>DoH</keyword>
<keyword>DoT</keyword>
<keyword>DoQ</keyword>
<keyword>DDR</keyword>
<keyword>DNR</keyword>
<abstract>
<t>The SVCB DNS resource record type expresses a bound collection of endpoint me tadata, for use when establishing a connection to a named service. DNS itself c an be such a service, when the server is identified by a domain name. This docu ment provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols.</t> <t>The SVCB DNS resource record type expresses a bound collection of endpoint me tadata, for use when establishing a connection to a named service. DNS itself c an be such a service, when the server is identified by a domain name. This docu ment provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Discussion Venues</name>
<t>Discussion of this document takes place on the
ADD Working Group mailing list (add@ietf.org),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/ad
d/"/>.</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/bemasc/svcb-dns"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 36?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The SVCB resource record type <xref target="SVCB"/> provides clients wi <t>The SVCB resource record (RR) type <xref target="SVCB"/> provides clien
th information about how to reach alternative endpoints for a service, which may ts with information about how to reach alternative endpoints for a service. The
have improved performance or privacy properties. The service is identified by se endpoints may offer improved performance or privacy properties. The service
a "scheme" indicating the service type, a hostname, and optionally other informa is identified by a "scheme" indicating the service type, a hostname, and, option
tion such as a port number. A DNS server is often identified only by its IP add ally, other information such as a port number. A DNS server is often identified
ress (e.g., in DHCP), but in some contexts it can also be identified by a hostna only by its IP address (e.g., in DHCP), but in some contexts it can also be ide
me (e.g., "NS" records, manual resolver configuration) and sometimes also a non- ntified by a hostname (e.g., "NS" records, manual resolver configuration) and so
default port number.</t> metimes also a non-default port number.</t>
<t>Use of the SVCB resource record type requires a mapping document for ea <t>The use of the SVCB RR type requires a mapping document for each servic
ch service type (<xref section="2.4.3" sectionFormat="of" target="SVCB"/>), indi e type (<xref section="2.4.3" sectionFormat="of" target="SVCB"/>), indicating ho
cating how a client for that service can interpret the contents of the SVCB SvcP w a client for that service can interpret the contents of the SVCB SvcParams. T
arams. This document provides the mapping for the "dns" service type, allowing his document provides the mapping for the "dns" service type, allowing DNS serve
DNS servers to offer alternative endpoints and transports, including encrypted t rs to offer alternative endpoints and transports, including encrypted transports
ransports like DNS over TLS (DoT) <xref target="RFC7858"/>, DNS over HTTPS (DoH) like DNS over TLS (DoT) <xref target="RFC7858"/>, DNS over HTTPS (DoH) <xref ta
<xref target="RFC8484"/>, and DNS over QUIC (DoQ) <xref target="RFC9250"/>.</t> rget="RFC8484"/>, and DNS over QUIC (DoQ) <xref target="RFC9250"/>.</t>
<t>The SVCB mapping described in this document is intended as a general-pu <t>The SVCB mapping described in this document is intended as a general-pu
rpose baseline. Subsequent specifications will adapt this mechanism as needed t rpose baseline. Subsequent specifications will adapt this mechanism as needed t
o support specific configurations (e.g., for communication between stub and recu o support specific configurations (e.g., for communication between stub resolver
rsive resolvers).</t> s and recursive resolvers).</t>
</section> </section>
<section anchor="conventions-and-definitions"> <section anchor="conventions-and-definitions">
<name>Conventions and Definitions</name> <name>Conventions and Definitions</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
OULD", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> < "<bcp14>SHOULD NOT</bcp14>",
xref target="RFC8174"/> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="identity"> <section anchor="identity">
<name>Identities and Names</name> <name>Identities and Names</name>
<t>SVCB record names (i.e., QNAMEs) for DNS services are formed using Port -Prefix Naming (<xref section="2.3" sectionFormat="of" target="SVCB"/>), with a scheme of "dns". For example, SVCB records for a DNS service identified as <tt> dns1.example.com</tt> would be queried at <tt>_dns.dns1.example.com</tt>.</t> <t>SVCB record names (i.e., QNAMEs) for DNS services are formed using Port Prefix Naming (<xref section="2.3" sectionFormat="of" target="SVCB"/>), with a scheme of "dns". For example, SVCB records for a DNS service identified as <tt> dns1.example.com</tt> would be queried at <tt>_dns.dns1.example.com</tt>.</t>
<t>In some use cases, the name used for retrieving these DNS records is di fferent from the server identity used to authenticate the secure transport. To distinguish between these, this document uses the following terms:</t> <t>In some use cases, the name used for retrieving these DNS records is di fferent from the server identity used to authenticate the secure transport. To distinguish between these, this document uses the following terms:</t>
<ul spacing="normal"> <dl spacing="normal">
<li>Binding authority - The service name (<xref section="1.4" sectionFor <dt>Binding authority:</dt><dd>The service name (<xref section="1.3" sec
mat="of" target="SVCB"/>) and optional port number used as input to Port-Prefix tionFormat="of" target="SVCB"/>) and optional port number used as input to Port
Naming.</li> Prefix Naming.</dd>
<li>Authentication name - The name used for secure transport authenticat <dt>Authentication name:</dt><dd>The name used for secure transport auth
ion. This MUST be a DNS hostname or a literal IP address. Unless otherwise spe entication. This <bcp14>MUST</bcp14> be a DNS hostname or a literal IP address.
cified, this is the service name from the binding authority.</li> Unless otherwise specified, this is the service name from the binding authorit
</ul> y.</dd>
</dl>
<section anchor="special-case-non-default-ports"> <section anchor="special-case-non-default-ports">
<name>Special case: non-default ports</name> <name>Special Case: Non-default Ports</name>
<t>Normally, a DNS service is identified by an IP address or a domain na <t>Normally, a DNS service is identified by an IP address or a domain na
me. When connecting to the service using unencrypted DNS over UDP or TCP, clien me. When connecting to the service using unencrypted DNS over UDP or TCP, clien
ts use the default port number for DNS (53). However, in rare cases, a DNS serv ts use the default port number for DNS (53). However, in rare cases, a DNS serv
ice might be identified by both a name and a port number. For example, the "<tt ice might be identified by both a name and a port number. For example, the DNS
>dns:</tt>" URI scheme <xref target="DNSURI"/> optionally includes an authority, URI scheme <xref target="RFC4501"/> optionally includes an authority, comprised
comprised of a host and a port number (with a default of 53). DNS URIs normall of a host and a port number (with a default of 53). DNS URIs normally omit the
y omit the authority, or specify an IP address, but a hostname and non-default p authority or specify an IP address, but a hostname and non-default port number a
ort number are allowed.</t> re allowed.</t>
<t>When the binding authority specifies a non-default port number, Port- <t>When the binding authority specifies a non-default port number, Port
Prefix Naming places the port number in an additional prefix on the name. For e Prefix Naming places the port number in an additional prefix on the name. For e
xample, if the binding authority is "<tt>dns1.example.com:9953</tt>", the client xample, if the binding authority is "<tt>dns1.example.com:9953</tt>", the client
would query for SVCB records at <tt>_9953._dns.dns1.example.com</tt>. If two D would query for SVCB records at <tt>_9953._dns.dns1.example.com</tt>. If two D
NS services operating on different port numbers provide different behaviors, thi NS services operating on different port numbers provide different behaviors, thi
s arrangement allows them to preserve the distinction when specifying alternativ s arrangement allows them to preserve the distinction when specifying alternativ
e endpoints.</t> e endpoints.</t>
</section> </section>
</section> </section>
<section anchor="applicable-existing-svcparamkeys"> <section anchor="applicable-existing-svcparamkeys">
<name>Applicable existing SvcParamKeys</name> <name>Applicable Existing SvcParamKeys</name>
<section anchor="alpn"> <section anchor="alpn">
<name>alpn</name> <name>&quot;alpn&quot;</name>
<t>This key indicates the set of supported protocols (<xref section="7.1 <t>This key indicates the set of supported protocols (<xref section="7.1
" sectionFormat="of" target="SVCB"/>). There is no default protocol, so the "<t " sectionFormat="of" target="SVCB"/>). There is no default protocol, so the "<t
t>no-default-alpn</tt>" key does not apply. If the "<tt>alpn</tt>" SvcParamKey t>no-default-alpn</tt>" key does not apply. If the "<tt>alpn</tt>" SvcParamKey
is absent, the client MUST treat the SVCB record as "incompatible" (see <xref se is absent, the client <bcp14>MUST</bcp14> treat the SVCB record as "incompatible
ction="8" sectionFormat="of" target="I-D.draft-ietf-dnsop-svcb-https"/>) unless " (as defined in <xref section="8" sectionFormat="of" target="SVCB"/>) unless so
some other recognized SvcParam indicates a supported protocol.</t> me other recognized SvcParam indicates a supported protocol.</t>
<t>If the protocol set contains any HTTP versions (e.g., "h2", "h3"), th <t>If the protocol set contains any HTTP versions (e.g., "h2", "h3"), th
en the record indicates support for DoH, and the "dohpath" key MUST be present ( en the record indicates support for DoH and the "dohpath" key <bcp14>MUST</bcp14
<xref target="dohpath"/>). All keys specified for use with the HTTPS record are > be present (<xref target="dohpath"/>). All keys specified for use with the HT
also permissible, and apply to the resulting HTTP connection.</t> TPS record are also permissible and apply to the resulting HTTP connection.</t>
<t>If the protocol set contains protocols with different default ports, <t>If the protocol set contains protocols with different default ports a
and no port key is specified, then protocols are contacted separately on their d nd no "port" key is specified, then protocols are contacted separately on their
efault ports. Note that in this configuration, ALPN negotiation does not defend default ports. Note that in this configuration, Application-Layer Protocol Nego
against cross-protocol downgrade attacks.</t> tiation (ALPN) negotiation does not defend against cross-protocol downgrade atta
cks.</t>
</section> </section>
<section anchor="port"> <section anchor="port">
<name>port</name> <name>&quot;port&quot;</name>
<t>This key is used to indicate the target port for connection (<xref se <t>This key is used to indicate the target port for connection (<xref se
ction="7.2" sectionFormat="of" target="SVCB"/>). If omitted, the client SHALL u ction="7.2" sectionFormat="of" target="SVCB"/>). If omitted, the client <bcp14>
se the default port number for each transport protocol (853 for DoT and DoQ, 443 SHALL</bcp14> use the default port number for each transport protocol (853 for D
for DoH).</t> oT and DoQ, 443 for DoH).</t>
<t>This key is automatically mandatory for this binding. This means tha <t>This key is automatically mandatory for this binding. This means tha
t a client that does not respect the "<tt>port</tt>" key MUST ignore any SVCB re t a client that does not respect the "<tt>port</tt>" key <bcp14>MUST</bcp14> ign
cord that contains this key. (See <xref section="8" sectionFormat="of" target=" ore any SVCB record that contains this key. (See <xref section="8" sectionForma
SVCB"/> for the definition of "automatically mandatory".)</t> t="of" target="SVCB"/> for the definition of "automatically mandatory".)</t>
<t>Support for the "<tt>port</tt>" key can be unsafe if the client has i <t>Support for the "<tt>port</tt>" key can be unsafe if the client has i
mplicit elevated access to some network service (e.g., a local service that is i mplicit elevated access to some network service (e.g., a local service that is i
naccessible to remote parties) and that service uses a TCP-based protocol other naccessible to remote parties) and that service uses a TCP-based protocol other
than TLS. A hostile DNS server might be able to manipulate this service by caus than TLS. A hostile DNS server might be able to manipulate this service by caus
ing the client to send a specially crafted TLS SNI or session ticket that can be ing the client to send a specially crafted TLS Server Name Indication (SNI) or s
misparsed as a command or exploit. To avoid such attacks, clients SHOULD NOT s ession ticket that can be misparsed as a command or exploit. To avoid such atta
upport the "<tt>port</tt>" key unless one of the following conditions applies:</ cks, clients <bcp14>SHOULD NOT</bcp14> support the "<tt>port</tt>" key unless on
t> e of the following conditions applies:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The client is being used with a DNS server that it trusts not to a ttempt this attack.</li> <li>The client is being used with a DNS server that it trusts not to a ttempt this attack.</li>
<li>The client is being used in a context where implicit elevated acce ss cannot apply.</li> <li>The client is being used in a context where implicit elevated acce ss cannot apply.</li>
<li>The client restricts the set of allowed TCP port values to exclude <li>The client restricts the set of allowed TCP port values to exclude
any ports where a confusion attack is likely to be possible (e.g., the "bad por any ports where a confusion attack is likely to be possible (e.g., the "bad por
ts" list from the "Port blocking" section of <xref target="FETCH"/>).</li> ts" list from Section&nbsp;<xref target="FETCH" section="2.9"
relative="https://fetch.spec.whatwg.org/#port-blocking" sectionFormat="bare">"Po
rt blocking"</xref> of <xref target="FETCH"/>).</li>
</ul> </ul>
</section> </section>
<section anchor="other-applicable-svcparamkeys"> <section anchor="other-applicable-svcparamkeys">
<name>Other applicable SvcParamKeys</name> <name>Other Applicable SvcParamKeys</name>
<t>These SvcParamKeys from <xref target="SVCB"/> apply to the "dns" sche me without modification:</t> <t>These SvcParamKeys from <xref target="SVCB"/> apply to the "dns" sche me without modification:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>mandatory</li> <li>mandatory</li>
<li>ipv4hint</li> <li>ipv4hint</li>
<li>ipv6hint</li> <li>ipv6hint</li>
</ul> </ul>
<t>Future SvcParamKeys might also be applicable.</t> <t>Future SvcParamKeys might also be applicable.</t>
</section> </section>
</section> </section>
<section anchor="new-svcparamkeys"> <section anchor="dohpath">
<name>New SvcParamKeys</name> <name>New SvcParamKey: "dohpath"</name>
<section anchor="dohpath"> <t>"<tt>dohpath</tt>" is a single-valued SvcParamKey whose value (in both
<name>dohpath</name> presentation format and wire format) <bcp14>MUST</bcp14> be a URI Template in re
<t>"<tt>dohpath</tt>" is a single-valued SvcParamKey whose value (both i lative form (<xref section="1.1" sectionFormat="comma" target="RFC6570"/>) encod
n presentation and wire format) MUST be a URI Template in relative form (<xref s ed in UTF-8 <xref target="RFC3629"/>. If the "<tt>alpn</tt>" SvcParam indicates
ection="1.1" sectionFormat="comma" target="RFC6570"/>) encoded in UTF-8 <xref ta support for HTTP, "<tt>dohpath</tt>" <bcp14>MUST</bcp14> be present. The URI T
rget="RFC3629"/>. If the "<tt>alpn</tt>" SvcParam indicates support for HTTP, " emplate <bcp14>MUST</bcp14> contain a "<tt>dns</tt>" variable, and <bcp14>MUST</
<tt>dohpath</tt>" MUST be present. The URI Template MUST contain a "<tt>dns</tt bcp14> be chosen such that the result after DoH URI Template expansion (<xref se
>" variable, and MUST be chosen such that the result after DoH template expansio ction="6" sectionFormat="of" target="RFC8484"/>) is always a valid and functiona
n (<xref section="6" sectionFormat="of" target="RFC8484"/>) is always a valid an l "<tt>:path</tt>" value (<xref section="8.3.1" sectionFormat="comma" target="RF
d functional "<tt>:path</tt>" value (<xref section="8.3.1" sectionFormat="comma" C9113"/>).</t>
target="RFC9113"/>).</t> <t>When using this SVCB record, the client <bcp14>MUST</bcp14> send any Do
<t>When using this SVCB record, the client MUST send any DoH requests to H requests to the HTTP origin identified by the "<tt>https</tt>" scheme, the aut
the HTTP origin identified by the "<tt>https</tt>" scheme, the authentication n hentication name, and the port from the "<tt>port</tt>" SvcParam (if present).
ame, and the port from the "<tt>port</tt>" SvcParam (if present). HTTP requests HTTP requests <bcp14>MUST</bcp14> be directed to the resource resulting from DoH
MUST be directed to the resource resulting from DoH template expansion of the " URI Template expansion of the "<tt>dohpath</tt>" value.</t>
<tt>dohpath</tt>" value.</t> <t>Clients <bcp14>SHOULD NOT</bcp14> query for any HTTPS RRs when using "<
<t>Clients SHOULD NOT query for any "HTTPS" RRs when using "<tt>dohpath< tt>dohpath</tt>". Instead, the SvcParams and address records associated with th
/tt>". Instead, the SvcParams and address records associated with this SVCB rec is SVCB record <bcp14>SHOULD</bcp14> be used for the HTTPS connection, with the
ord SHOULD be used for the HTTPS connection, with the same semantics as an HTTPS same semantics as an HTTPS RR. However, for consistency, service operators <bcp
RR. However, for consistency, service operators SHOULD publish an equivalent H 14>SHOULD</bcp14> publish an equivalent HTTPS RR, especially if clients might le
TTPS RR, especially if clients might learn about this DoH service through a diff arn about this DoH service through a different channel.</t>
erent channel.</t>
</section>
</section> </section>
<section anchor="limitations"> <section anchor="limitations">
<name>Limitations</name> <name>Limitations</name>
<t>This document is concerned exclusively with the DNS transport, and does not affect or inform the construction or interpretation of DNS messages. For e xample, nothing in this document indicates whether the service is intended for u se as a recursive or authoritative DNS server. Clients need to know the intende d use of services based on their context.</t> <t>This document is concerned exclusively with the DNS transport and does not affect or inform the construction or interpretation of DNS messages. For ex ample, nothing in this document indicates whether the service is intended for us e as a recursive or authoritative DNS server. Clients need to know the intended use of services based on their context.</t>
<t>Not all features of this specification will be applicable or effective in all contexts:</t> <t>Not all features of this specification will be applicable or effective in all contexts:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the authentication name is received over an insecure channel (e.g ., a glue NS record), this specification cannot prevent the client from connecti ng to an attacker.</li> <li>If the authentication name is received over an insecure channel (e.g ., a glue NS record), this specification cannot prevent the client from connecti ng to an attacker.</li>
<li>Different transports might prove to be popular for different purpose s (e.g., querying a recursive resolver vs. an authoritative server). Implemento rs are not obligated to implement all the defined transports, although doing so is beneficial for compatibility.</li> <li>Different transports might prove to be popular for different purpose s (e.g., querying a recursive resolver vs. an authoritative server). Implemento rs are not obligated to implement all the defined transports, although doing so is beneficial for compatibility.</li>
<li>Where resolution speed is a high priority, the SVCB TargetName SHOUL D follow the convention described in <xref section="10.2" sectionFormat="of" tar get="SVCB"/>, and the use of AliasMode records (<xref section="2.4.2" sectionFor mat="of" target="SVCB"/>) is NOT RECOMMENDED.</li> <li>Where resolution speed is a high priority, the SVCB TargetName <bcp1 4>SHOULD</bcp14> follow the convention described in <xref section="10.2" section Format="of" target="SVCB"/>, and the use of AliasMode records (<xref section="2. 4.2" sectionFormat="of" target="SVCB"/>) is <bcp14>NOT RECOMMENDED</bcp14>.</li>
</ul> </ul>
</section> </section>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A resolver known as <tt>simple.example</tt> that supports DNS over TLS on port 853 (implicitly, as this is its default port): </t> <t>A resolver known as <tt>simple.example</tt> that supports DNS over TLS on port 853 (implicitly, as this is its default port): </t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
_dns.simple.example. 7200 IN SVCB 1 simple.example. alpn=dot _dns.simple.example. 7200 IN SVCB 1 simple.example. alpn=dot
]]></artwork> ]]></sourcecode>
</li> </li>
<li> <li>
<t>A DoH-only resolver at <tt>https://doh.example/dns-query{?dns}</tt> . (DNS over TLS is not supported.): </t> <t>A DoH-only resolver at <tt>https://doh.example/dns-query{?dns}</tt> . (DNS over TLS is not supported.): </t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
_dns.doh.example. 7200 IN SVCB 1 doh.example. ( _dns.doh.example. 7200 IN SVCB 1 doh.example. (
alpn=h2 dohpath=/dns-query{?dns} ) alpn=h2 dohpath=/dns-query{?dns} )
]]></artwork> ]]></sourcecode>
</li> </li>
<li> <li>
<t>A resolver known as <tt>resolver.example</tt> that supports: </t> <t>A resolver known as <tt>resolver.example</tt> that supports: </t>
<ul spacing="normal"> <ul spacing="normal">
<li>DoT on <tt>resolver.example</tt> ports 853 (implicit in record 1 ) and 8530 (explicit in record 2), with "<tt>resolver.example</tt>" as the Authe ntication Domain Name,</li> <li>DoT on <tt>resolver.example</tt> ports 853 (implicit in record 1 ) and 8530 (explicit in record 2), with "<tt>resolver.example</tt>" as the Authe ntication Domain Name,</li>
<li>DoQ on <tt>resolver.example</tt> port 853 (record 1),</li> <li>DoQ on <tt>resolver.example</tt> port 853 (record 1),</li>
<li>DoH at <tt>https://resolver.example/q{?dns}</tt> (record 1), and </li> <li>DoH at <tt>https://resolver.example/q{?dns}</tt> (record 1), and </li>
<li> <li>
<t>an experimental protocol on <tt>fooexp.resolver.example:5353</t t> (record 3): </t> <t>an experimental protocol on <tt>fooexp.resolver.example:5353</t t> (record 3): </t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
_dns.resolver.example. 7200 IN \ _dns.resolver.example. 7200 IN \
SVCB 1 resolver.example. alpn=dot,doq,h2,h3 dohpath=/q{?dns} SVCB 1 resolver.example. alpn=dot,doq,h2,h3 dohpath=/q{?dns}
SVCB 2 resolver.example. alpn=dot port=8530 SVCB 2 resolver.example. alpn=dot port=8530
SVCB 3 fooexp.resolver.example. port=5353 alpn=foo foo-info=... SVCB 3 fooexp.resolver.example. port=5353 alpn=foo foo-info=...
]]></artwork> ]]></sourcecode>
</li> </li>
</ul> </ul>
</li> </li>
<li> <li>
<t>A nameserver named <tt>ns.example.</tt> whose service configuration <t>A name server named <tt>ns.example.</tt> whose service configuratio
is published on a different domain: </t> n is published on a different domain: </t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
_dns.ns.example. 7200 IN SVCB 0 _dns.ns.nic.example. _dns.ns.example. 7200 IN SVCB 0 _dns.ns.nic.example.
]]></artwork> ]]></sourcecode>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<section anchor="adversary-on-the-query-path"> <section anchor="adversary-on-the-query-path">
<name>Adversary on the query path</name> <name>Adversary on the Query Path</name>
<t>This section considers an adversary who can add or remove responses t o the SVCB query.</t> <t>This section considers an adversary who can add or remove responses t o the SVCB query.</t>
<t>During secure transport establishment, clients MUST authenticate the server to its authentication name, which is not influenced by the SVCB record co ntents. Accordingly, this draft does not mandate the use of DNSSEC. This draft also does not specify how clients authenticate the name (e.g., selection of roo ts of trust), which might vary according to the context.</t> <t>During secure transport establishment, clients <bcp14>MUST</bcp14> au thenticate the server to its authentication name, which is not influenced by the SVCB record contents. Accordingly, this document does not mandate the use of D NSSEC. This document also does not specify how clients authenticate the name (e .g., selection of roots of trust), as this procedure might vary according to the context.</t>
<section anchor="downgrade-attacks"> <section anchor="downgrade-attacks">
<name>Downgrade attacks</name> <name>Downgrade Attacks</name>
<t>This attacker cannot impersonate the secure endpoint, but it can fo <t>This attacker cannot impersonate the secure endpoint, but it can fo
rge a response indicating that the requested SVCB records do not exist. For a S rge a response indicating that the requested SVCB records do not exist. For a S
VCB-reliant client (<xref section="3" sectionFormat="comma" target="SVCB"/>) thi VCB-reliant client (<xref section="3" sectionFormat="comma" target="SVCB"/>), th
s only results in a denial of service. However, SVCB-optional clients will gene is only results in a denial of service. However, SVCB-optional clients will gen
rally fall back to insecure DNS in this case, exposing all DNS traffic to attack erally fall back to insecure DNS in this case, exposing all DNS traffic to attac
s.</t> ks.</t>
</section> </section>
<section anchor="redirection-attacks"> <section anchor="redirection-attacks">
<name>Redirection attacks</name> <name>Redirection Attacks</name>
<t>SVCB-reliant clients always enforce the authentication domain name, <t>SVCB-reliant clients always enforce the Authentication Domain Name,
but they are still subject to attacks using the transport, port number, and "do but they are still subject to attacks using the transport, port number, and "do
hpath" value, which are controlled by this adversary. By changing these values hpath" value, which are controlled by this adversary. By changing these values
in the SVCB answers, the adversary can direct DNS queries for $HOSTNAME to any p in the SVCB answers, the adversary can direct DNS queries for $HOSTNAME to any p
ort on $HOSTNAME, and any path on "<tt>https://$HOSTNAME</tt>". If the DNS clie ort on $HOSTNAME and any path on "<tt>https://$HOSTNAME</tt>". If the DNS clien
nt uses shared TLS or HTTP state, the client could be correctly authenticated (e t uses shared TLS or HTTP state, the client could be correctly authenticated (e.
.g., using a TLS client certificate or HTTP cookie).</t> g., using a TLS client certificate or HTTP cookie).</t>
<t>This behavior creates a number of possible attacks for certain serv <t>This behavior creates a number of possible attacks for certain serv
er configurations. For example, if <tt>https://$HOSTNAME/upload</tt> accepts an er configurations. For example, if <tt>https://$HOSTNAME/upload</tt> accepts an
y POST request as a public file upload, the adversary could forge a SVCB record y POST request as a public file upload, the adversary could forge a SVCB record
containing <tt>dohpath=/upload{?dns}</tt>. This would cause the client to uploa containing <tt>dohpath=/upload{?dns}</tt>. This would cause the client to uploa
d and publish every query, resulting in unexpected storage costs for the server d and publish every query, resulting in unexpected storage costs for the server
and privacy loss for the client. Similarly, if two DoH endpoints are available and privacy loss for the client. Similarly, if two DoH endpoints are available
on the same origin, and the service has designated one of them for use with this on the same origin and the service has designated one of them for use with this
specification, this adversary can cause clients to use the other endpoint inste specification, this adversary can cause clients to use the other endpoint instea
ad.</t> d.</t>
<t>To mitigate redirection attacks, a client of this SVCB mapping MUST <t>To mitigate redirection attacks, a client of this SVCB mapping <bcp
NOT identify or authenticate itself when performing DNS queries, except to serv 14>MUST NOT</bcp14> identify or authenticate itself when performing DNS queries,
ers that it specifically knows are not vulnerable to such attacks. If an endpoi except to servers that it specifically knows are not vulnerable to such attacks
nt sends an invalid response to a DNS query, the client SHOULD NOT send more que . If an endpoint sends an invalid response to a DNS query, the client <bcp14>SH
ries to that endpoint and MAY log this error. Multiple DNS services MUST NOT sh OULD NOT</bcp14> send more queries to that endpoint and <bcp14>MAY</bcp14> log t
are a hostname identifier (<xref target="identity"/>) unless they are so similar his error. Multiple DNS services <bcp14>MUST NOT</bcp14> share a hostname ident
that it is safe to allow an attacker to choose which one is used.</t> ifier (<xref target="identity"/>) unless they are so similar that it is safe to
allow an attacker to choose which one is used.</t>
</section> </section>
</section> </section>
<section anchor="adversary-on-the-transport-path"> <section anchor="adversary-on-the-transport-path">
<name>Adversary on the transport path</name> <name>Adversary on the Transport Path</name>
<t>This section considers an adversary who can modify network traffic be tween the client and the alternative service (identified by the TargetName).</t> <t>This section considers an adversary who can modify network traffic be tween the client and the alternative service (identified by the TargetName).</t>
<t>For a SVCB-reliant client, this adversary can only cause a denial of service. However, because DNS is unencrypted by default, this adversary can exe cute a downgrade attack against SVCB-optional clients. Accordingly, when use of this specification is optional, clients SHOULD switch to SVCB-reliant behavior if SVCB resolution succeeds. Specifications making using of this mapping MAY ad just this fallback behavior to suit their requirements.</t> <t>For a SVCB-reliant client, this adversary can only cause a denial of service. However, because DNS is unencrypted by default, this adversary can exe cute a downgrade attack against SVCB-optional clients. Accordingly, when the us e of this specification is optional, clients <bcp14>SHOULD</bcp14> switch to SVC B-reliant behavior if SVCB resolution succeeds. Specifications making use of th is mapping <bcp14>MAY</bcp14> adjust this fallback behavior to suit their requir ements.</t>
</section> </section>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>Per <xref target="SVCB"/> IANA is directed to add the following entry t <t>Per <xref target="SVCB"/>, IANA has added the following entry to the "S
o the SVCB Service Parameters registry.</t> ervice Parameter Keys (SvcParamKeys)" registry.</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">Number</th> <th align="left">Number</th>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Meaning</th> <th align="left">Meaning</th>
<th align="left">Format Reference</th>
<th align="left">Change Controller</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">7</td> <td align="center">7</td>
<td align="left">dohpath</td> <td align="left">dohpath</td>
<td align="left">DNS over HTTPS path template</td> <td align="left">DNS-over-HTTPS path template</td>
<td align="left">(This document)</td> <td align="left">RFC 9461</td>
<td align="left">IETF</td>
<td align="left">RFC 9461</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>Per <xref target="Attrleaf"/>, IANA is directed to add the following en try to the DNS Underscore Global Scoped Entry Registry:</t> <t>Per <xref target="RFC8552"/>, IANA has added the following entry to the DNS "Underscored and Globally Scoped DNS Node Names" registry:</t>
<table> <table>
<thead> <thead>
<tr> <tr>
<th align="left">RR TYPE</th> <th align="left">RR Type</th>
<th align="left">_NODE NAME</th> <th align="left">_NODE NAME</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">SVCB</td> <td align="left">SVCB</td>
<td align="left">_dns</td> <td align="left">_dns</td>
<td align="left">(This document)</td> <td align="left">RFC 9461</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC8552" to="Attrleaf"/>
<displayreference target="RFC4501" to="DNSURI"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<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.
This document defines these words as they should be interpreted in IETF documen
ts. 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="SVCB">
<front>
<title>Service binding and parameter specification via the DNS (DNS
SVCB and HTTPS RRs)</title>
<author fullname="Benjamin M. Schwartz" initials="B. M." surname="Sc
hwartz">
<organization>Google</organization>
</author>
<author fullname="Mike Bishop" initials="M." surname="Bishop">
<organization>Akamai Technologies</organization>
</author>
<author fullname="Erik Nygren" initials="E." surname="Nygren">
<organization>Akamai Technologies</organization>
</author>
<date day="11" month="March" year="2023"/>
<abstract>
<t> This document specifies the "SVCB" and "HTTPS" DNS resource
record
(RR) types to facilitate the lookup of information needed to make
connections to network services, such as for HTTP origins. SVCB
records allow a service to be provided from multiple alternative
endpoints, each with associated parameters (such as transport
protocol configuration), and are extensible to support future uses
(such as keys for encrypting the TLS ClientHello). They also enable
aliasing of apex domains, which is not possible with CNAME. The
HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By
providing more information to the client before it attempts to
establish a connection, these records offer potential benefits to
both performance and privacy.
TO BE REMOVED: This document is being collaborated on in Github at:
https://github.com/MikeBishop/dns-alt-svc
(https://github.com/MikeBishop/dns-alt-svc). The most recent working
version of the document, open issues, etc. should all be available
there. The authors (gratefully) accept pull requests.
</t> <!-- draft-ietf-dnsop-svcb-https (companion) (RFC 9460)-->
</abstract> <reference anchor="SVCB" target="https://www.rfc-editor.org/info/rfc9460
</front> ">
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-1
2"/>
</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
HTTP exchange.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8484"/>
<seriesInfo name="DOI" value="10.17487/RFC8484"/>
</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="I-D.draft-ietf-dnsop-svcb-https">
<front> <front>
<title>Service binding and parameter specification via the DNS (DNS <title>Service Binding and Parameter Specification via the DNS (SVCB
SVCB and HTTPS RRs)</title> and HTTPS Resource Records)</title>
<author fullname="Benjamin M. Schwartz" initials="B. M." surname="Sc <author fullname="Ben Schwartz" initials="B." surname="Schwartz"></a
hwartz"> uthor>
<organization>Google</organization>
</author>
<author fullname="Mike Bishop" initials="M." surname="Bishop"> <author fullname="Mike Bishop" initials="M." surname="Bishop">
<organization>Akamai Technologies</organization>
</author> </author>
<author fullname="Erik Nygren" initials="E." surname="Nygren"> <author fullname="Erik Nygren" initials="E." surname="Nygren">
<organization>Akamai Technologies</organization>
</author> </author>
<date day="11" month="March" year="2023"/> <date month="November" year="2023"/>
<abstract>
<t> This document specifies the "SVCB" and "HTTPS" DNS resource
record
(RR) types to facilitate the lookup of information needed to make
connections to network services, such as for HTTP origins. SVCB
records allow a service to be provided from multiple alternative
endpoints, each with associated parameters (such as transport
protocol configuration), and are extensible to support future uses
(such as keys for encrypting the TLS ClientHello). They also enable
aliasing of apex domains, which is not possible with CNAME. The
HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By
providing more information to the client before it attempts to
establish a connection, these records offer potential benefits to
both performance and privacy.
TO BE REMOVED: This document is being collaborated on in Github at:
https://github.com/MikeBishop/dns-alt-svc
(https://github.com/MikeBishop/dns-alt-svc). The most recent working
version of the document, open issues, etc. should all be available
there. The authors (gratefully) accept pull requests.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-1
2"/>
</reference>
<reference anchor="RFC6570">
<front>
<title>URI Template</title>
<author fullname="J. Gregorio" initials="J." surname="Gregorio"/>
<author fullname="R. Fielding" initials="R." surname="Fielding"/>
<author fullname="M. Hadley" initials="M." surname="Hadley"/>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
>
<author fullname="D. Orchard" initials="D." surname="Orchard"/>
<date month="March" year="2012"/>
<abstract>
<t>A URI Template is a compact sequence of characters for describi
ng a range of Uniform Resource Identifiers through variable expansion. This spe
cification defines the URI Template syntax and the process for expanding a URI T
emplate into a URI reference, along with guidelines for the use of URI Templates
on the Internet. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6570"/>
<seriesInfo name="DOI" value="10.17487/RFC6570"/>
</reference>
<reference anchor="RFC3629">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
<date month="November" year="2003"/>
<abstract>
<t>ISO/IEC 10646-1 defines a large character set called the Univer
sal Character Set (UCS) which encompasses most of the world's writing systems.
The originally proposed encodings of the UCS, however, were not compatible with
many current applications and protocols, and this has led to the development of
UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the
full US-ASCII range, providing compatibility with file systems, parsers and othe
r software that rely on US-ASCII values but are transparent to other values. Th
is memo obsoletes and replaces RFC 2279.</t>
</abstract>
</front>
<seriesInfo name="STD" value="63"/>
<seriesInfo name="RFC" value="3629"/>
<seriesInfo name="DOI" value="10.17487/RFC3629"/>
</reference>
<reference anchor="RFC9113">
<front>
<title>HTTP/2</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<author fullname="C. Benfield" initials="C." role="editor" surname="
Benfield"/>
<date month="June" year="2022"/>
<abstract>
<t>This specification describes an optimized expression of the sem
antics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2
(HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced
latency by introducing field compression and allowing multiple concurrent excha
nges on the same connection.</t>
<t>This document obsoletes RFCs 7540 and 8740.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="9113"/> <seriesInfo name="RFC" value="9460"/>
<seriesInfo name="DOI" value="10.17487/RFC9113"/> <seriesInfo name="DOI" value="10.17487/RFC9460"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
484.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
570.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
629.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
113.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="FETCH" target="https://fetch.spec.whatwg.org/"> <reference anchor="FETCH" target="https://fetch.spec.whatwg.org/">
<front> <front>
<title>Fetch Living Standard</title> <title>Fetch Living Standard</title>
<author> <author>
<organization/> <organization>WHATWG</organization>
</author> </author>
<date year="2022" month="February"/> <date year="2023" month="October"/>
</front>
</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 t
o those provided by TLS, while QUIC transport eliminates the head-of-line blocki
ng issues inherent with TCP and provides more efficient packet-loss recovery tha
n 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 as a general-purpose transport
for DNS and includes the use of DoQ for stub to recursive, recursive to authori
tative, and zone transfer scenarios.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9250"/>
<seriesInfo name="DOI" value="10.17487/RFC9250"/>
</reference>
<reference anchor="DNSURI">
<front>
<title>Domain Name System Uniform Resource Identifiers</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
<date month="May" year="2006"/>
<abstract>
<t>This document defines Uniform Resource Identifiers for Domain N
ame System resources. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4501"/>
<seriesInfo name="DOI" value="10.17487/RFC4501"/>
</reference>
<reference anchor="Attrleaf">
<front>
<title>Scoped Interpretation of DNS Resource Records through "Unders
cored" Naming of Attribute Leaves</title>
<author fullname="D. Crocker" initials="D." surname="Crocker"/>
<date month="March" year="2019"/>
<abstract>
<t>Formally, any DNS Resource Record (RR) may occur under any doma
in name. However, some services use an operational convention for defining spec
ific interpretations of an RRset by locating the records in a DNS branch under t
he parent domain to which the RRset actually applies. The top of this subordina
te branch is defined by a naming convention that uses a reserved node name, whic
h begins with the underscore character (e.g., "_name"). The underscored naming
construct defines a semantic scope for DNS record types that are associated with
the parent domain above the underscored branch. This specification explores th
e nature of this DNS usage and defines the "Underscored and Globally Scoped DNS
Node Names" registry with IANA. The purpose of this registry is to avoid collis
ions resulting from the use of the same underscored name for different services.
</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="222"/>
<seriesInfo name="RFC" value="8552"/>
<seriesInfo name="DOI" value="10.17487/RFC8552"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
858.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
250.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
501.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
552.xml"/>
</references> </references>
</references> </references>
<?line 188?>
<section anchor="mapping-summary"> <section anchor="mapping-summary">
<name>Mapping Summary</name> <name>Mapping Summary</name>
<t>This table serves as a non-normative summary of the DNS mapping for SVC B.</t> <t>This table serves as a non-normative summary of the DNS mapping for SVC B.</t>
<table> <table>
<thead>
<tr>
<th align="left"> </th>
<th align="left"> </th>
</tr>
</thead>
<tbody> <tbody>
<tr> <tr>
<td align="left"> <td align="left">
<strong>Mapped scheme</strong></td> <strong>Mapped scheme</strong></td>
<td align="left">"dns"</td> <td align="left">"dns"</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<strong>RR type</strong></td> <strong>RR type</strong></td>
<td align="left">SVCB (64)</td> <td align="left">SVCB (64)</td>
skipping to change at line 493 skipping to change at line 302
<tt>_dns</tt> for port 53, else <tt>_$PORT._dns</tt></td> <tt>_dns</tt> for port 53, else <tt>_$PORT._dns</tt></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<strong>Required keys</strong></td> <strong>Required keys</strong></td>
<td align="left"> <td align="left">
<tt>alpn</tt> or equivalent</td> <tt>alpn</tt> or equivalent</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<strong>Automatically Mandatory Keys</strong></td> <strong>Automatically mandatory keys</strong></td>
<td align="left"> <td align="left">
<tt>port</tt></td> <tt>port</tt></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<strong>Special behaviors</strong></td> <strong>Special behaviors</strong></td>
<td align="left">Supports all HTTPS RR SvcParamKeys</td> <td align="left">Supports all HTTPS RR SvcParamKeys</td>
</tr> </tr>
<tr> <tr>
<td align="left"> </td> <td/>
<td align="left">Overrides the HTTPS RR for DoH</td> <td align="left">Overrides the HTTPS RR for DoH</td>
</tr> </tr>
<tr> <tr>
<td align="left"> </td> <td/>
<td align="left">Default port is per-transport</td> <td align="left">Default port is per-transport</td>
</tr> </tr>
<tr> <tr>
<td align="left"> </td> <td/>
<td align="left">No encrypted -&gt; cleartext fallback</td> <td align="left">Cleartext fallback is discouraged</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>Thanks to the many reviewers and contributors, including Andrew Camplin g, Peter van Dijk, Paul Hoffman, Daniel Migault, Matt Norhoff, Eric Rescorla, An dreas Schulze, and Éric Vyncke.</t> <t>Thanks to the many reviewers and contributors, including <contact fulln ame="Andrew Campling"/>, <contact fullname="Peter van Dijk"/>, <contact fullname ="Paul Hoffman"/>, <contact fullname="Daniel Migault"/>, <contact fullname="Matt Nordhoff"/>, <contact fullname="Eric Rescorla"/>, <contact fullname="Andreas Sc hulze"/>, and <contact fullname="Éric Vyncke"/>.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA51b3XLbuJK+11PgKOfCTkmKf+JJ4qrsrMdOTlwndjy2c6am
drfGEAlJHFOEhiDtaBI/wHmufbH9uhsASUlOMpubyCLYaPTv193QcDjsVVmV
m0PVvzLlXZYY9VNWpFkxVWd6saD/J7ZUJ+dXip6b0vV7ejwuzR298a/jn8Lj
fi+1SaHnoJSWelINM1NNhjpNh+4uGQ/Twg13XvUSXZmpLZeHylVpr5ctykNV
lbWr9nZ2Xu3s9XRp9KH6hylMqfPevS1vp6WtF4cKhHq3Zolv0kN1WlSmLEw1
PKGdej1X6SL9Tee2wO5L43qL7FD9V2WTgXK2rEozcfi0nNOH/+n1dF3NbHnY
U8Oewr+scIfqp5G6Smb3uqz+5C/lJD+Z4nc9z4ruM1tOdZH9qavMFofqzFRa
XeS6giDm2Oe0SEa8zMx1lh8qksN/jvGHS0bgudcrsA7v3hlwoC7fHu/t7r46
hCyKSfvB2zfXx+8OmVBQ0FtTJTP1PrsjrVzRmXWZ9nlJCrkeqt1d9daMy1qX
S7W3s7cnb+tyaiq8PquqhTt89mxCZEZuYZLR/UxX99MRDvSs3+v1hsOh0mNX
lToBn9czo1jDpPzSOFuXsI7SJNCBqpYLo8ynBb53ximtxrYuUpXYPDcJCUbZ
iTJFurBZUak5ZAQW9YCtpXZG3c9MoQwUN84zN6MDabxcFP7lyuJv0kGqnJjl
SDEfWeVMPlGJLtTYKFdDIDosGQjVCnw7tlWVOZWlpqiySQZK4yXWphZqKZg2
SF7PsASGW8+xSi1Ke4f1jknw0ectHxB2iAmhDl3rPLf39BwvzIlpch2ycXC2
WMD0+EVTJOVyUeFlSLZw/D22gn3a3I1E7PMsTXPT6z0h4y5tWrMcWkrYqIDP
n/9GD1+fDk9GLa+Ds9mF+B0r/eGhOVqSZziqU/dZNVPR5iByDQ1Wambv6Rxw
Q5JsTn7GJhl16fhIHZlnWDrXSzXTWJfNaSucdWFKJl6AZ7yxKLM7nSyJETyp
MuNY/CYQ2qSrvksgV9MPYvWSjq+QDKAEMO0q0g4+wwbtgs4D1SyVxeqyc0qx
GDJYVkNRz8emBCdHLcUSK3ZSwZRaDNkC9MAVDFCdXlA8ItNXW2Y0HQ2whTp5
d3yxPVBjCBF/OTs3ZNCV+YQXsootVufOktmunjPwH6j1EU69nmFkEGGtczaA
nLgD1Uk2rUs+0DYfmXarsjk5Im0B17HFMDUTXedV56C93kc4H1yz+qpdleaP
OivZr4MHRCdhiybraGtBbX3+fOV9d2/0fLRPe7BtPjxsD9r6IwPT3gqZVoUY
FGmRlDKK7ggsFTPJMiSzazN9dZdc6FLP3ddduO299HcfjtFftZ7gwi3HJg+w
kwlkvdkDSOTRlR0dL8lrzpkbXN2pPLs1TN6S+q7fX6mtE3u9De/9EeH/xcuD
lw8Pg2bBu+vrC17yjpb8DUtePn/5nJbQvnHZzx9Pj2nVz4HQq72DnYeHUStm
RN0Zl5TZGFxlFB7b8iKvIwGneMhuMZXcO1zU5cLCVsYaATcrKFhe1WMHw6DX
KHvAgBO2QQomeQ6X0ItKyM9NMkOKdHOiWRhD1CHTEBTD211Tjs5E6krsfF4X
fgP4THVv4I+uqscsBRhrXTrSSnALtz2i6HlsiztyLiLH4jKTrMj4bxEMQIQi
FOFU/+zj1XV/IP+r8w/8+fIN5Hr55oQ+X707ev8+fggrrt59+Pgez3v+U/Pm
8YezszfnJ/IyvlUrX50d/doXJfY/XFyffjg/et8PGulFjQACkawoTARHEN10
tPjT8YXafQ7NewCBEO9tZfcFbKVHmdCHQwpc8id8AOFmsTCagiKZPhxukVUI
GgPawcE5C4WQaViWpxymKFQzoXNNAebzE4le1fKh1/MRhANHwY+3spGBCn8+
Pzp747YjdvQ+5/h0FI1xitqRbV7AIIYXQGbZJ9qBvurEEo4kMZBw1kLy4bxA
T9ilYZtvKSp90vNFDp9usRXSVYuJdvjFoW9AYXfk3x3B7m5gH3WekgZg7CUv
q9TNb1g3WlsLQZ36aE+wJoG3OBY0y4O+S5kDaBGU7nwGc8aDKmGRHDKjeMMx
sbTzDobx4hZaBIwAX+krxhmyEM5gmohDQdGCoqOAWwNeRf/hrQcrIaB2PlxO
bIQzBlAWmFQ9jdWAgGbiY9hJ25K3Go3tjp63NNZJyO1MJKfRFH0WyJg41roh
jGj/o+a0RJ63Ew66Al4VQltMeDEkCvZ1aFYsIiZetpE8qyj0tdI73vpY5JTn
GUncZ1CcD14m9XLMXAeTMLmow/Gq9MixnqgroqFzNpfDtWSNSHVOgAUIZrBq
umsgqWijET5GF+H+QpA4IGtSre2wK05YF03iignm48kFEbw+vhhE1Eg2Tq9v
wBbR17cO9rex8Tt7b0CGsVFJbu99o3ugeTadVeuYaGzZz1mYZEKrcK3j7pza
yY0Pb/rq4+VpCA9Ii9gKX7xGXHx+sLOLINkCh5K1Obg1+hlQ5gFWJbOCGQs2
W2dBbflIFASBtXJsOhy2RNrzKlR2ngmUaW1CBst2tKJBwY8tREg7PwLmOJYy
fDEpzOqXUPus2Vw0Wfc4MhxsCsSLXCc+NrT3pdRREMdZ8Gt5yxYx8K2qKJs8
whoMur8WgQ9fvTrYv+mLZj1UlJhMAXnJltaJ8Ryf6aXRI1FaqVNwcG+7yYgq
EUGlYL2JwK2zugAoW4/HBoVOZkvnA4AuEXOmRpI3qcPFcpDKY4ri4jMckCVK
cqHqLYAFsglnchI+WixyxLBxTuW2hPQIf/9plo7jic4XXCuCG8I3oQoNkYnN
04MvqsxC7dmO2y9Gu624LbVZyQGnsI27+zepr+LdrrDBnIbEBTyQOEitoRcr
Qhv50ouf1/tFrSPQHhrIsqg6CudIXaEQrdrFCkMNpI0+JAlHhcQgmb7acob8
PRzmJZcf36yKtxH4OLpz/pZikbaYFtmfkFPgsSVPvUGMBAHkdOEbFjkVLojD
FF6WjOkVodQ2zu3P9ggWzvb723xycR9/xmbPdisBRYGgOiln7AwSmInIQ2Zj
m4P8oFv/XPR5BLSHda5JYE0zhmIZUZTSI0iZwwsUDS+ZZ86RpGVzVmrIJNgO
yiez5EM2TZxvyaUxQ96/cbBOLhz4ECheeSvm0snBkFtDihMN7ZBU3DtaQIGV
oSjM0s3KLnXI5dwyjNJVLI46VclAHb2/OEcRM7VVJhgkGjdIGRLHlM6Dk5XW
uWE8bAowPS01YoeuwM+tk9xP+7Z91UVgF5tHJDNp26mo+VZzrOO1e12vhcQp
31ReNMGZpIL5Vvbmsn69R6W2Xh7se/O7lqrK/jxQz5+HL99tj7onQny31HBJ
OAHOqVNZWR+4WcQ+EQRUNjfYU5QQewP8VxQ1rAw6r3wQIfZuWmafTZFtDXta
O04wiWhvlWcQm25drYcLkWHsFaSxcOQy45ET9UfbqIJaDrrGn+9U1oXTExPy
oD/ijPDvnOI7EILJzZ3mUi9JKCZRvUxhqQB2t+VtREw+eACuWjDTdDPYgglP
y/vkrdLJm5OBww+okNv2waPVcqmlfwuYN6Rav4lrPiBicUFNC26SES7JctNu
lkUEp/2OEE62qHMxZHJWv9GYhCF4syUDOiY7kTg1izehoA1OqFVydX7KaImO
RD6cJbfGG4cXLWITTudCA4M6B1x1EPxY5Dbz9ZC+s1nq+3/ijw2sbSr5GG3X
FOlThS1i/6ypl2BjAoYcx0YIGsXTU65S/DHJ5g1DbWLUg8eWFEV9lQxDxOSp
1IMjz0NTRbgefY0uIbPQdSSMUZrH7QvSaxJ0lyicDdVqUnXwg0eaZCgSOO50
Xhu2U/OJkTT7n7S8ZG/mZVKz4oR74pfaYZI+KFtZb6rerFnsY50KnT4Wu1ZJ
3CeQqsaw/FucmVp5cdbw+TNPTCgKcpj9wMarG/TUBU3XXIS3v5NdEBQkDnRy
nG8cSllByqNW+dymsQXG6o5RAZ+zxd3zGUCcfPyBP/be1hXVqJ1dxX1CZ7jh
l8HfublfB3s+q6vPT0J+7/WAoeUzjDVjmAL55GbIOko7aOt+Rm09fqC2uM7K
igAa/CSgIAv1jRpdbbeKZqqurmGS7N1U2JlcQCstpcRELagfDl7sDFTTENgl
pIUC06Zioh+v3w5f+nbV/g97rx4evgIQHwFChDUGqn3sFfzjpwsdhnmJzwc0
XqDCA2/e6TLTEdwEOgnJyQ8M2DsbsKMoPHHiU1WgjViDHLaSnn9gHBo7uNus
m/xeL0lFUAECEm05qaUsQDjv3xz683gNiZhe7e7uNyJ9OdpnoYaqLwRVUG+l
v3U0LYEWTkqcU4/fUKzxNs7oDUXZNCtWinHRC2Pmm+AFg1jRrjRnGngquoqu
G2JpVOwWkqFXFvcLaP/IVNBCCjtkKNegzTCuCLCTt3hEFzZYVWMnLFdI7ng9
9jfVJQmpz2i4ry4vndRrIuYWLTJbAD+jvazjWEJQsm/KxCLVOYsEV4X4v6qv
wMm41dVqQHmD/wYNXnfUInAGgQc6cJz/Cr/+8rLdg/EI0iGawhGXg5iUpQRG
MRt2X9Q8kSVCNASCtMh8As2BMk2ahv5CApUolhtdhkEin4600gCU0tZT7plE
pE9TgsLkHOveZ8CtOnbqV4YUYD6hmX8qyYZa/9TWDoKgTBqBq5hgU4JiNyBH
GwaBYayEHFf79FE2vXYdEgqRnEN/esqjyk47A2R5Zr0+TonBChbj4VN3xBmG
LaH2YszSjDPI9nxzRAJrgxHARLBZGqmQR9wWNK6dmYZsLeO92OIQSBeLH48N
RtRh5G6FmqDArmnUx67S1FbepXmy00lMDKxYpMReGCP4Saf0jH0s3xAdSAQ4
rMloQsxdRh74+eatN4cG4k4pBMZG+fZgE4cex0B3d1I2xJjHgaHb+tQBiNAs
FJyeRFNszevEmHmMHVEKAVopklp9IhmRxXqew4dcZVifT6k7WFGr0yjaFc1y
4UaWRTZEvkhVLB3Kwhen2oe/LKxgiccaxXRnkTondAI/Sy2xAljBELHAUm45
++Ead06ynDvSkMMvjNeY11rm5AsyMYYSM4iDxve+dRmbMddcodJUKMQOAcTB
v/wcrju3ag0KdqR29VPiJm94Ez7KM+3OgBliAF2ZMbff5sy6MnLjqPJGXNYR
PjtqlEGOU/D0x7FYQ7fwxtdGgjRcd2qLfTmnUTW8FXA19+hdHAXQ9YB2eb1N
HsH/uDPZ3W2kXuzt7KjTcxHorlp9TFjodWor4R7RdMjTvHgM6nuGaz3ISuHF
Z3Tbiq3x84/4+HAzUludk2QSGWMva7TCZovWGo+dZ1v+LfnH7M72AkJ9vcqH
2n5UDeGrRxTB7D3l/gO0sGG1qKujGcGnnFl3pe7F4x0466e153thtNhfJ90X
9ZrVSdSJjFnI/geeuZ+/wpzwFvkJr7zr6HD11Wd/eAW236Sj8NuUoj8hf2cU
FLgNHwp3cDGxFg9HqxQPD/YP9hty+43ivepXX0BoCgbw3y1le2NYXx1MdpDa
PwazvcFsvzEHf5pVMntfIcOye02KW32Lmk8bjziSd+igQgbraO2Q0v/r0Wgk
Rsjzaim+5WbXDU4fSNz4MineS2m3BMl9PEyS3NqGNDJ967pTi3DXm3bi8yJL
4hqKW1eUQGhAckyoLTVlQEYoAI9S6iTTJT8/cRHcSjL2yCnUxYl/WWZc8TWc
Te4jpdwmoRaRZKoF1ptYETCLTBssnYAdyierY9Z4h2/ODfwACBm/b5hUS7PD
cpzcWD3IdTIfoKAxIAAgv1iHtPFyuBpEnamEvqGadxnG29RDakCg1OamnWAQ
Ea/eHMcbRLye6/D4UhjR0Z2lcLC1M7UvbjnTuv1YWuuvLVFPZzvelGN0cUd6
0IHrIPEGnj2Bnk9WG8heuwHBBOiDgAfFonzs3gcIcyR/J036ZUj/U8MARZTd
vVoXq1yuwqhx0J6ypZalwmMoj4g1rxiWBsma8LwAry3pojQF6z5laFZLyF/I
j07aVSg1CZc0oLVdtzD1eH+gubsIAOQvKoHchPDQmLpL3ET3x+fboqGjr+na
A4KFdTJty0PFMKFrSNJpiy36J+rSSN3ZNK6cXHZZOWms5g1VFonZBHtb43jR
hNzCAYfUSs2R4sa/c2c7MqGaJmmrpukMa/kSURz/cEkb7CtMQEq6iuv9howm
eD/E+9OSofa0uY3ie3lZ0TgZNr43pb/M0sQOMiIRDotQbsjILZu/v/twdU0X
fwRpSy+QYlR84MdHhQQretSPuS8ukrp6Eus6b1Tcp3YzHE8aw74JBCnC7ju9
jiRc34HZEqMwkbbXpsFbRcyaqYVX6WrqRJw7bJBYe5uZOOII41+V0GxSZuoy
QoEJx3ZmUCXDbRAlE/DRr3vpbcOkfF0kz+pFbnV6w73bRSUzxQs8DK7qr7RS
UkrUhDr08saa9lg0IQisBlMwSRK5iQlbiEQQKZFSJvHUyjcrjXxZzjoObQRy
46UkkUGrZwNp1AWBFxnToehBmQ0enL9f3EoWTM1fHs4h3vhc9qV7idk8Q3VG
oT/zU37gqtZ1TWpF32ms4fK1aFon0u5qSo+Q7mdy3S6bFmwvTc9/vjozXS1H
Byvexv4isgohgwTlRScTlnhNPpNmElmaRZ6ouPaD1NaC0aAZk4WyvXPhM9xo
DI28ZegrxMzl79FzX8vf1A6XYL1LU7wkY5MJjb8X66cU8cgUfgnENyXrXZ1T
XPazoPa4RbyaQGs4L/UjnXQApBkasxLf/w/MLFdGmc2shvqZc5r8hTDEeRQ8
xi24o3v0KyzHN0hNWVpqpZyRJS5aoyxul0TBcaBpX8SJLdGS0lu8A9ncIWjC
uqU6jiwyyoushMZ/dCwukVt9CPoymVnLP4qgAE7W5qfCo814rzWi/cuYj6cW
yzhVDCmwdUMwCDo4RftuShxCrneIm3YAhcpHwcFGB2FUIF7yDUAwNrKMs7vr
XFwDH77y3riH+QRcUPEGK7gqDvA3oo1VdOlbweaRhhlhHE9hbb7oEDRommC7
gokZJZs0d/JDH6ZGxDcpcXHVvXM917cy9+P7S56XGABg8jr9HbhTvieIxAgp
7sXOKRfTsjJc+J+bcO3o9Oj8aK32uIC1xgEZr+Cbq02HngqK7mQUBMtlp6AI
PzPjTrmpyFBLMwWk5DLjizqXZKq+cGlNNdQXdWY0Z6aN/74ArnHxlZjwDcgM
5Z/a8Gnjv/XHTOZF3CSM3b6s3tTnb+Ps4Yva6jSvt0HGC+7Ho6oqc6MndB/x
5cHBHnW9/h9i5CuGBbl4QrHvH7kdw1yvErvA62945aWX6CFJ9PJSXf968Qas
/Xb+4eSNYoj2nVJ7XDKsTJYM1bBRTBtOzz9wIusjwwq/Kryq53O4pg9eFScM
TjMyxuB7ivGXcjBVXh3mOdybb/24g3hh4/nmv+9YsiaNv2Azjy4EtadP6ewE
d3iC9vTpOm8yZ/4u3p4+hVrpJyzrdAI11tDWD8+3v4caO5tc5NxE8YtcgL9h
cXPqOdgHQsgRB29++/vFh8vrkTz3vEk8SfnG2aaTypiXZwnNlOkx3o46l2/O
4nWifwpxUOPZ4nfKLVy+jvc4u/xBbqH7S3VimHx1p/aB2re3VB8QKcr4k6RI
zt+c6vD2HdRO2le3qA9lymEDB/4qtXPb+sXS8D+Qr4wu+fJITBhCjS6iJgT0
UFJOOUv0Ph9K2WPS132sdqb/QM6si9vYQJpTmVKau8zcCx6RMqPMUAbz/dnm
h1NHRVqae3VMVRD+HqgLSg2oSwt1kv1+i79xbMCAyQREB+oE+cDk6gwImfP9
GTI5TlPOsGCg3pRANJeGwmOuB0IbQeUqmdX5n35C/b//pkX/WhbAYKPe/wFy
CaSeCD0AAA==
</rfc> </rfc>
 End of changes. 62 change blocks. 
611 lines changed or deleted 234 lines changed or added

This html diff was produced by rfcdiff 1.48.