rfc9460.original.xml   rfc9460.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.26 (Ruby 2.7. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
4) --> -ietf-dnsop-svcb-https-12" number="9460" submissionType="IETF" category="std" co
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft nsensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsol
-ietf-dnsop-svcb-https-12" category="std" consensus="true" tocInclude="true" sor etes="" xml:lang="en" version="3">
tRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.16.0 --> <!-- xml2rfc v2v3 conversion 3.16.0 -->
<front> <front>
<title abbrev="SVCB and HTTPS RRs for DNS">Service binding and parameter spe <title abbrev="SVCB and HTTPS RRs for DNS">Service Binding and Parameter Spe
cification via the DNS (DNS SVCB and HTTPS RRs)</title> cification via the DNS (SVCB and HTTPS Resource Records)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-latest"
/> <seriesInfo name="RFC" value="9460"/>
<author initials="B." surname="Schwartz" fullname="Ben Schwartz"> <author initials="B." surname="Schwartz" fullname="Ben Schwartz">
<organization>Google</organization> <organization>Meta Platforms, Inc.</organization>
<address> <address>
<email>ietf@bemasc.net</email> <email>ietf@bemasc.net</email>
</address> </address>
</author> </author>
<author initials="M." surname="Bishop" fullname="Mike Bishop"> <author initials="M." surname="Bishop" fullname="Mike Bishop">
<organization>Akamai Technologies</organization> <organization>Akamai Technologies</organization>
<address> <address>
<email>mbishop@evequefou.be</email> <email>mbishop@evequefou.be</email>
</address> </address>
</author> </author>
<author initials="E." surname="Nygren" fullname="Erik Nygren"> <author initials="E." surname="Nygren" fullname="Erik Nygren">
<organization>Akamai Technologies</organization> <organization>Akamai Technologies</organization>
<address> <address>
<email>erik+ietf@nygren.org</email> <email>erik+ietf@nygren.org</email>
</address> </address>
</author> </author>
<date/> <date year="2023" month="November" />
<area>General</area> <area>ops</area>
<workgroup>DNSOP Working Group</workgroup> <workgroup>dnsop</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>multi-CDN</keyword>
<keyword>HSTS</keyword>
<keyword>ECH</keyword>
<keyword>CNAME</keyword>
<keyword>apex</keyword>
<keyword>ALPN</keyword>
<keyword>HTTP/3</keyword>
<keyword>alias</keyword>
<keyword>SvcParam</keyword>
<keyword>AliasMode</keyword>
<keyword>ServiceMode</keyword>
<abstract> <abstract>
<t>This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) <t>This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR)
types to facilitate the lookup of information needed to make connections types to facilitate the lookup of information needed to make connections
to network services, such as for HTTP origins. SVCB records to network services, such as for HTTP origins. SVCB records
allow a service to be provided from multiple alternative endpoints, allow a service to be provided from multiple alternative endpoints,
each with associated parameters (such as transport protocol each with associated parameters (such as transport protocol
configuration), and are extensible to support future uses configuration), and are extensible to support future uses
(such as keys for encrypting the TLS ClientHello). They also (such as keys for encrypting the TLS ClientHello). They also
enable aliasing of apex domains, which is not possible with CNAME. enable aliasing of apex domains, which is not possible with CNAME.
The HTTPS RR is a variation of SVCB for use with HTTP <xref target="HTTP"/>. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Seman tics").
By providing more information to the client before it attempts to By providing more information to the client before it attempts to
establish a connection, these records offer potential benefits to establish a connection, these records offer potential benefits to
both performance and privacy.</t> both performance and privacy.</t>
<t>TO BE REMOVED: This document is being collaborated on in Github at:
<eref target="https://github.com/MikeBishop/dns-alt-svc">https://github.com/Mike
Bishop/dns-alt-svc</eref>.
The most recent working version of the document, open issues, etc. should all be
available there. The authors (gratefully) accept pull requests.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>The SVCB ("Service Binding") and HTTPS RRs provide clients with complet e instructions <t>The SVCB ("Service Binding") and HTTPS resource records (RRs) provide c lients with complete instructions
for access to a service. This information enables improved for access to a service. This information enables improved
performance and privacy by avoiding transient connections to a suboptimal performance and privacy by avoiding transient connections to a suboptimal
default server, negotiating a preferred protocol, and providing relevant default server, negotiating a preferred protocol, and providing relevant
public keys.</t> public keys.</t>
<t>For example, HTTP clients currently resolve only A and/or AAAA records for <t>For example, HTTP clients currently resolve only A and/or AAAA records for
the origin hostname, learning only its IP addresses. If an HTTP client learns the origin hostname, learning only its IP addresses. If an HTTP client learns
more about the origin before connecting, it may be able to upgrade "http" URLs more about the origin before connecting, it may be able to upgrade "http" URLs
to "https", enable HTTP/3 or Encrypted ClientHello <xref target="ECH"/>, to "https", enable HTTP/3 or Encrypted ClientHello <xref target="I-D.ietf-tls-es ni"/>,
or switch to an or switch to an
operationally preferable endpoint. It is highly desirable to minimize the operationally preferable endpoint. It is highly desirable to minimize the
number of round-trips and lookups required to number of round trips and lookups required to
learn this additional information.</t> learn this additional information.</t>
<t>The SVCB and HTTPS RRs also help when the operator of a service <t>The SVCB and HTTPS RRs also help when the operator of a service
wishes to delegate operational control to one or more other domains, e.g. wishes to delegate operational control to one or more other domains, e.g.,
delegating the origin "https://example.com" to a service aliasing the origin "https://example.com" to a service
operator endpoint at "svc.example.net". While this case can sometimes operator endpoint at "svc.example.net". While this case can sometimes
be handled by a CNAME, that does not cover all use-cases. CNAME is also be handled by a CNAME, that does not cover all use cases. CNAME is also
inadequate when the service operator needs to provide a bound inadequate when the service operator needs to provide a bound
collection of consistent configuration parameters through the DNS collection of consistent configuration parameters through the DNS
(such as network location, protocol, and keying information).</t> (such as network location, protocol, and keying information).</t>
<t>This document first describes the SVCB RR as a general-purpose resource <t>This document first describes the SVCB RR as a general-purpose RR that
record that can be applied directly and efficiently to a wide range can be applied directly and efficiently to a wide range
of services (<xref target="svcb"/>). It also describes the rules for defining o ther of services (<xref target="svcb"/>). It also describes the rules for defining o ther
SVCB-compatible RR types (<xref target="svcb-compatible"/>), starting with the H TTPS SVCB-compatible RR types (<xref target="svcb-compatible"/>), starting with the H TTPS
RR type (<xref target="https"/>), which provides improved efficiency and conveni ence RR type (<xref target="https"/>), which provides improved efficiency and conveni ence
with HTTP by avoiding the need for an Attrleaf label <xref target="Attrleaf"/> with HTTP by avoiding the need for an Attrleaf label <xref target="RFC8552"/>
(<xref target="httpsnames"/>).</t> (<xref target="httpsnames"/>).</t>
<t>The SVCB RR has two modes: 1) "AliasMode", which simply delegates opera tional <t>The SVCB RR has two modes: 1) "AliasMode", which simply delegates opera tional
control for a resource; 2) "ServiceMode", which binds together control for a resource and 2) "ServiceMode", which binds together
configuration information for a service endpoint. configuration information for a service endpoint.
ServiceMode provides additional key=value parameters ServiceMode provides additional key=value parameters
within each RDATA set.</t> within each RDATA set.</t>
<section anchor="goals-of-the-svcb-rr"> <section anchor="goals">
<name>Goals of the SVCB RR</name> <name>Goals</name>
<t>The goal of the SVCB RR is to allow clients to resolve a single <t>The goal of the SVCB RR is to allow clients to resolve a single
additional DNS RR in a way that:</t> additional DNS RR in a way that:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Provides alternative endpoints that are authoritative for the serv ice, <li>Provides alternative endpoints that are authoritative for the serv ice,
along with parameters associated with each of these endpoints.</li> along with parameters associated with each of these endpoints.</li>
<li>Does not assume that all alternative endpoints have the same param eters <li>Does not assume that all alternative endpoints have the same param eters
or capabilities, or are even or capabilities, or are even
operated by the same entity. This is important, as DNS does not operated by the same entity. This is important, as DNS does not
provide any way to tie together multiple RRSets for the same name. provide any way to tie together multiple RRsets for the same name.
For example, if www.example.com is a CNAME alias that switches For example, if "www.example.com" is a CNAME alias that switches
between one of three CDNs or hosting environments, successive queries between one of three Content Delivery Networks (CDNs) or hosting environments, s
uccessive queries
for that name may return records that correspond to different environments.</li> for that name may return records that correspond to different environments.</li>
<li>Enables CNAME-like functionality at a zone apex (such as <li>Enables CNAME-like functionality at a zone apex (such as
"example.com") for participating protocols, and generally "example.com") for participating protocols and generally
enables delegation of operational authority for an origin within the enables extending operational authority for a service identified
DNS to an alternate name.</li> by a domain name to other instances with alternate names.</li>
</ul> </ul>
<t>Additional goals specific to HTTPS RRs and the HTTP use-cases include :</t> <t>Additional goals specific to HTTPS RRs and the HTTP use cases include :</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Connect directly to HTTP/3 (QUIC transport) <li>Connecting directly to HTTP/3 (QUIC transport)
alternative endpoints <xref target="HTTP3"/></li> alternative endpoints <xref target="RFC9114"/>.</li>
<li>Support non-default TCP and UDP ports</li> <li>Supporting non-default TCP and UDP ports.</li>
<li>Enable SRV-like benefits (e.g. apex delegation, as mentioned above <li>Enabling SRV-like benefits (e.g., apex aliasing, as mentioned abov
) for HTTP, e) for HTTP,
where SRV <xref target="SRV"/> has not been widely adopted</li> where SRV <xref target="RFC2782"/> has not been widely adopted.</li>
<li>Provide an HSTS-like indication <xref target="HSTS"/> signaling th <li>Providing an indication signaling that the "https" scheme should
at the "https" be used instead of "http" for all HTTP requests to this host and port,
scheme should be used instead of "http" for all HTTP requests to this host and p similar to HTTP Strict Transport Security <xref
ort (see target="RFC6797"/> (see
<xref target="hsts"/>).</li> <xref target="hsts"/>).</li>
<li>Enable the conveyance of Encrypted ClientHello <xref target="ECH"/ > keys associated <li>Enabling the conveyance of Encrypted ClientHello keys <xref target ="I-D.ietf-tls-esni"/> associated
with an alternative endpoint.</li> with an alternative endpoint.</li>
</ul> </ul>
</section> </section>
<section anchor="overview-of-the-svcb-rr"> <section anchor="overview-of-the-svcb-rr">
<name>Overview of the SVCB RR</name> <name>Overview of the SVCB RR</name>
<t>This subsection briefly describes the SVCB RR with forward references to <t>This subsection briefly describes the SVCB RR with forward references to
the full exposition of each component. (As mentioned above, this all the full exposition of each component. (As discussed in <xref target="svcb-comp
applies equally to the HTTPS RR which shares atible"/>, this all
applies equally to the HTTPS RR, which shares
the same encoding, format, and high-level semantics.)</t> the same encoding, format, and high-level semantics.)</t>
<t>The SVCB RR has two modes: AliasMode (<xref target="alias-mode"/>), w <t>The SVCB RR has two modes: 1) AliasMode (<xref target="alias-mode"/>)
hich aliases a name , which aliases a name
to another name, and ServiceMode (<xref target="service-mode"/>), which provides to another name and 2) ServiceMode (<xref target="service-mode"/>), which provid
connection es connection
information bound to a service endpoint domain. Placing both forms in a single information bound to a service endpoint domain. Placing both forms in a single
RR type allows clients to RR type allows clients to
fetch the relevant information with a single query (<xref target="svcb-names"/>) .</t> fetch the relevant information with a single query (<xref target="svcb-names"/>) .</t>
<t>The SVCB RR has two required fields and one optional field. The fiel ds are:</t> <t>The SVCB RR has two required fields and one optional field. The fiel ds are:</t>
<ol spacing="normal" type="1"><li>SvcPriority (<xref target="pri"/>): Th <dl spacing="normal" newline="false"><dt>SvcPriority (<xref target="pri"
e priority of this record (relative to others, />):</dt><dd>The priority of this record (relative to others,
with lower values preferred). A value of 0 indicates AliasMode.</li> with lower values preferred). A value of 0 indicates AliasMode.</dd>
<li>TargetName: The domain name of either the alias target (for <dt>TargetName:</dt><dd>The domain name of either the alias target (fo
AliasMode) or the alternative endpoint (for ServiceMode).</li> r
<li>SvcParams (optional): A list of key=value pairs AliasMode) or the alternative endpoint (for ServiceMode).</dd>
<dt>SvcParams (optional):</dt><dd>A list of key=value pairs
describing the alternative endpoint at describing the alternative endpoint at
TargetName (only used in ServiceMode and otherwise ignored). TargetName (only used in ServiceMode and otherwise ignored).
Described in <xref target="presentation"/>.</li> SvcParams are described in <xref target="presentation"/>.</dd>
</ol> </dl>
<t>Cooperating DNS recursive resolvers will perform subsequent record <t>Cooperating DNS recursive resolvers will perform subsequent record
resolution (for SVCB, A, and AAAA records) and return them in the resolution (for SVCB, A, and AAAA records) and return them in the
Additional Section of the response (<xref target="recursive-behavior"/>). Clien Additional section of the response (<xref target="recursive-behavior"/>). Clien
ts either use responses ts either use responses
included in the additional section returned by the recursive resolver included in the Additional section returned by the recursive resolver
or perform necessary SVCB, A, and AAAA record resolutions (<xref target="client- behavior"/>). DNS or perform necessary SVCB, A, and AAAA record resolutions (<xref target="client- behavior"/>). DNS
authoritative servers can attach in-bailiwick SVCB, A, AAAA, and CNAME authoritative servers can attach in-bailiwick SVCB, A, AAAA, and CNAME
records in the Additional Section to responses for a SVCB query (<xref target="a uthoritative-behavior"/>).</t> records in the Additional section to responses for a SVCB query (<xref target="a uthoritative-behavior"/>).</t>
<t>In ServiceMode, the SvcParams of the SVCB RR <t>In ServiceMode, the SvcParams of the SVCB RR
provide an extensible data model for describing alternative provide an extensible data model for describing alternative
endpoints that are authoritative for a service, along with endpoints that are authoritative for a service, along with
parameters associated with each of these alternative endpoints (<xref target="ke ys"/>).</t> parameters associated with each of these alternative endpoints (<xref target="ke ys"/>).</t>
<t>For HTTP use-cases, the HTTPS RR (<xref target="https"/>) enables man <t>For HTTP use cases, the HTTPS RR (<xref target="https"/>) enables man
y of the benefits of Alt-Svc y of the benefits of Alt-Svc
<xref target="AltSvc"/> <xref target="RFC7838"/>
without waiting for a full HTTP connection initiation (multiple roundtrips) without waiting for a full HTTP connection initiation (multiple round trips)
before learning of the preferred alternative, before learning of the preferred alternative,
and without necessarily revealing the user's and without necessarily revealing the user's
intended destination to all entities along the network path.</t> intended destination to all entities along the network path.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>Our terminology is based on the common case where the SVCB record is used to <t>Terminology in this document is based on the common case where the SV CB record is used to
access a resource identified by a URI whose <tt>authority</tt> field contains a DNS access a resource identified by a URI whose <tt>authority</tt> field contains a DNS
hostname as the <tt>host</tt>.</t> hostname as the <tt>host</tt>.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The "service" is the information source identified by the <tt>auth ority</tt> and <li>The "service" is the information source identified by the <tt>auth ority</tt> and
<tt>scheme</tt> of the URI, capable of providing access to the resource. For "h ttps" <tt>scheme</tt> of the URI, capable of providing access to the resource. For "h ttps"
URIs, the "service" corresponds to an "origin" <xref target="RFC6454"/>.</li> URIs, the "service" corresponds to an "origin" <xref target="RFC6454"/>.</li>
<li>The "service name" is the <tt>host</tt> portion of the authority.< /li> <li>The "service name" is the <tt>host</tt> portion of the authority.< /li>
<li>The "authority endpoint" is the authority's hostname and a port nu mber implied <li>The "authority endpoint" is the authority's hostname and a port nu mber implied
by the scheme or specified in the URI.</li> by the scheme or specified in the URI.</li>
<li>An "alternative endpoint" is a hostname, port number, and other as sociated <li>An "alternative endpoint" is a hostname, port number, and other as sociated
instructions to the client on how to reach an instance of service.</li> instructions to the client on how to reach an instance of a service.</li>
</ul> </ul>
<t>Additional DNS terminology intends to be consistent <t>Additional DNS terminology intends to be consistent
with <xref target="DNSTerm"/>.</t> with <xref target="RFC8499"/>.</t>
<t>SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR, <t>SVCB is a contraction of "service binding". The SVCB RR, HTTPS RR,
and future RR types that share SVCB's formats and registry are and future RR types that share SVCB's formats and registry are
collectively known as SVCB-compatible RR types. The contraction "SVCB" is also collectively known as SVCB-compatible RR types. The contraction "SVCB" is also
used to refer to this system as a whole.</t> used to refer to this system as a whole.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"MAY", and "OPTIONAL" in this document are to be interpreted as "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and "<bcp14>SHOULD NOT</bcp14>",
only when, they "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
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> </section>
<section anchor="svcb"> <section anchor="svcb">
<name>The SVCB record type</name> <name>The SVCB Record Type</name>
<t>The SVCB DNS resource record (RR) type (RR type 64)
<t>The SVCB DNS RR type (RR type 64)
is used to locate alternative endpoints for a service.</t> is used to locate alternative endpoints for a service.</t>
<t>The algorithm for resolving SVCB records and associated <t>The algorithm for resolving SVCB records and associated
address records is specified in <xref target="client-behavior"/>.</t> address records is specified in <xref target="client-behavior"/>.</t>
<t>Other SVCB-compatible resource record types
can also be defined as-needed (see <xref target="svcb-compatible"/>). In partic <t>Other SVCB-compatible RR types
ular, the can also be defined as needed (see <xref target="svcb-compatible"/>). In partic
ular, the
HTTPS RR (RR type 65) provides special handling HTTPS RR (RR type 65) provides special handling
for the case of "https" origins as described in <xref target="https"/>.</t> for the case of "https" origins as described in <xref target="https"/>.</t>
<t>SVCB RRs are extensible by a list of SvcParams, which are pairs consist ing of a <t>SVCB RRs are extensible by a list of SvcParams, which are pairs consist ing of a
SvcParamKey and a SvcParamValue. Each SvcParamKey has a presentation name and a SvcParamKey and a SvcParamValue. Each SvcParamKey has a presentation name and a
registered number. Values are in a format specific to the SvcParamKey. Each registered number. Values are in a format specific to the SvcParamKey. Each
SvcParam has a specified presentation format (used in zone files) and SvcParam has a specified presentation format (used in zone files) and
wire encoding wire encoding
(e.g., domain names, binary data, or numeric values). The initial SvcParamKeys (e.g., domain names, binary data, or numeric values). The initial SvcParamKeys
and their formats are defined in <xref target="keys"/>.</t> and their formats are defined in <xref target="keys"/>.</t>
<section anchor="presentation"> <section anchor="presentation">
<name>Zone file presentation format</name> <name>Zone-File Presentation Format</name>
<t>The presentation format <tt>&lt;RDATA&gt;</tt> of the record (<xref s ection="5.1" sectionFormat="comma" target="RFC1035"/>) has <t>The presentation format <tt>&lt;RDATA&gt;</tt> of the record (<xref s ection="5.1" sectionFormat="comma" target="RFC1035"/>) has
the form:</t> the form:</t>
<artwork><![CDATA[ <sourcecode type="pseudocode"><![CDATA[
SvcPriority TargetName SvcParams SvcPriority TargetName SvcParams
]]></artwork> ]]></sourcecode>
<t>The SVCB record is defined specifically within <t>The SVCB record is defined specifically within
the Internet ("IN") Class (<xref section="3.2.4" sectionFormat="comma" target="R FC1035"/>).</t> the Internet ("IN") Class (<xref section="3.2.4" sectionFormat="comma" target="R FC1035"/>).</t>
<t>SvcPriority is a number in the range 0-65535, <t>SvcPriority is a number in the range 0-65535,
TargetName is a <tt>&lt;domain-name&gt;</tt> (<xref section="5.1" sectionFormat= "comma" target="RFC1035"/>), TargetName is a <tt>&lt;domain-name&gt;</tt> (<xref section="5.1" sectionFormat= "comma" target="RFC1035"/>),
and the SvcParams are a whitespace-separated list, with each SvcParam and the SvcParams are a whitespace-separated list with each SvcParam
consisting of a SvcParamKey=SvcParamValue pair or a standalone SvcParamKey. consisting of a SvcParamKey=SvcParamValue pair or a standalone SvcParamKey.
SvcParamKeys are subject to IANA control (<xref target="svcparamregistry"/>).</t SvcParamKeys are registered by IANA (<xref target="svcparamregistry"/>).</t>
> <t>Each SvcParamKey <bcp14>SHALL</bcp14> appear at most once in the SvcP
<t>Each SvcParamKey SHALL appear at most once in the SvcParams. arams.
In presentation format, SvcParamKeys are lower-case alphanumeric strings. In presentation format, SvcParamKeys are lowercase alphanumeric strings.
Key names contain 1-63 characters from the ranges "a"-"z", "0"-"9", and "-". Key names contain 1-63 characters from the ranges "a"-"z", "0"-"9", and "-".
In ABNF <xref target="RFC5234"/>,</t> In ABNF <xref target="RFC5234"/>,</t>
<artwork><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
alpha-lc = %x61-7A ; a-z alpha-lc = %x61-7A ; a-z
SvcParamKey = 1*63(alpha-lc / DIGIT / "-") SvcParamKey = 1*63(alpha-lc / DIGIT / "-")
SvcParam = SvcParamKey ["=" SvcParamValue] SvcParam = SvcParamKey ["=" SvcParamValue]
SvcParamValue = char-string ; See Appendix A SvcParamValue = char-string ; See Appendix A.
value = *OCTET ; Value before key-specific parsing value = *OCTET ; Value before key-specific parsing
]]></artwork> ]]></sourcecode>
<t>The SvcParamValue is parsed using the <t>The SvcParamValue is parsed using the
character-string decoding algorithm (<xref target="decoding"/>), producing a <tt >value</tt>. character-string decoding algorithm (<xref target="decoding"/>), producing a <tt >value</tt>.
The <tt>value</tt> is then validated and converted into wire-format in a manner The <tt>value</tt> is then validated and converted into wire format in a manner
specific to each key.</t> specific to each key.</t>
<t>When the optional "=" and SvcParamValue are omitted, the <tt>value</t t> is <t>When the optional "=" and SvcParamValue are omitted, the <tt>value</t t> is
interpreted as empty.</t> interpreted as empty.</t>
<t>Arbitrary keys can be represented using the unknown-key presentation format <t>Arbitrary keys can be represented using the unknown-key presentation format
"keyNNNNN" where NNNNN is the numeric "keyNNNNN" where NNNNN is the numeric
value of the key type without leading zeros. value of the key type without leading zeros.
A SvcParam in this form SHALL be parsed as specified above, and A SvcParam in this form <bcp14>SHALL</bcp14> be parsed as specified above, and
the decoded <tt>value</tt> SHALL be used as its wire format encoding.</t> the decoded <tt>value</tt> <bcp14>SHALL</bcp14> be used as its wire-format encod
ing.</t>
<t>For some SvcParamKeys, the <tt>value</tt> corresponds to a list or se t of <t>For some SvcParamKeys, the <tt>value</tt> corresponds to a list or se t of
items. Presentation formats for such keys SHOULD use a comma-separated list items. Presentation formats for such keys <bcp14>SHOULD</bcp14> use a comma-sep arated list
(<xref target="value-list"/>).</t> (<xref target="value-list"/>).</t>
<t>SvcParams in presentation format MAY appear in any order, but keys MU ST NOT be <t>SvcParams in presentation format <bcp14>MAY</bcp14> appear in any ord er, but keys <bcp14>MUST NOT</bcp14> be
repeated.</t> repeated.</t>
</section> </section>
<section anchor="rdata-wire-format"> <section anchor="rdata-wire-format">
<name>RDATA wire format</name> <name>RDATA Wire Format</name>
<t>The RDATA for the SVCB RR consists of:</t> <t>The RDATA for the SVCB RR consists of:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>a 2-octet field for SvcPriority as an integer in network <li>a 2-octet field for SvcPriority as an integer in network
byte order.</li> byte order.</li>
<li>the uncompressed, fully-qualified TargetName, represented as <li>the uncompressed, fully qualified TargetName, represented as
a sequence of length-prefixed labels as in <xref section="3.1" sectionFormat="of a sequence of length-prefixed labels per <xref section="3.1" sectionFormat="of"
" target="RFC1035"/>.</li> target="RFC1035"/>.</li>
<li>the SvcParams, consuming the remainder of the record <li>the SvcParams, consuming the remainder of the record
(so smaller than 65535 octets and constrained by the RDATA (so smaller than 65535 octets and constrained by the RDATA
and DNS message sizes).</li> and DNS message sizes).</li>
</ul> </ul>
<t>When the list of SvcParams is non-empty, it contains a series of <t>When the list of SvcParams is non-empty, it contains a series of
SvcParamKey=SvcParamValue pairs, represented as:</t> SvcParamKey=SvcParamValue pairs, represented as:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>a 2-octet field containing the SvcParamKey as an <li>a 2-octet field containing the SvcParamKey as an
integer in network byte order. (See <xref target="iana-keys"/> for the defined values.)</li> integer in network byte order. (See <xref target="iana-keys"/> for the defined values.)</li>
<li>a 2-octet field containing the length of the SvcParamValue <li>a 2-octet field containing the length of the SvcParamValue
as an integer between 0 and 65535 in network byte order.</li> as an integer between 0 and 65535 in network byte order.</li>
<li>an octet string of this length whose contents are the SvcParamValu e in a <li>an octet string of this length whose contents are the SvcParamValu e in a
format determined by the SvcParamKey.</li> format determined by the SvcParamKey.</li>
</ul> </ul>
<t>SvcParamKeys SHALL appear in increasing numeric order.</t> <t>SvcParamKeys <bcp14>SHALL</bcp14> appear in increasing numeric order.
<t>Clients MUST consider an RR malformed if:</t> </t>
<t>Clients <bcp14>MUST</bcp14> consider an RR malformed if:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the end of the RDATA occurs within a SvcParam.</li> <li>the end of the RDATA occurs within a SvcParam.</li>
<li>SvcParamKeys are not in strictly increasing numeric order.</li> <li>SvcParamKeys are not in strictly increasing numeric order.</li>
<li>the SvcParamValue for an SvcParamKey does not have the expected fo rmat.</li> <li>the SvcParamValue for a SvcParamKey does not have the expected for mat.</li>
</ul> </ul>
<t>Note that the second condition implies that there are no duplicate <t>Note that the second condition implies that there are no duplicate
SvcParamKeys.</t> SvcParamKeys.</t>
<t>If any RRs are malformed, the client MUST reject the entire RRSet and <t>If any RRs are malformed, the client <bcp14>MUST</bcp14> reject the e ntire RRset and
fall back to non-SVCB connection establishment.</t> fall back to non-SVCB connection establishment.</t>
</section> </section>
<section anchor="svcb-names"> <section anchor="svcb-names">
<name>SVCB query names</name> <name>SVCB Query Names</name>
<t>When querying the SVCB RR, a service is translated into a QNAME by pr epending <t>When querying the SVCB RR, a service is translated into a QNAME by pr epending
the service name with a label indicating the scheme, prefixed with an underscore , the service name with a label indicating the scheme, prefixed with an underscore ,
resulting in a domain name like "_examplescheme.api.example.com.". This resulting in a domain name like "_examplescheme.api.example.com.". This
follows the Attrleaf naming pattern <xref target="Attrleaf"/>, so the scheme MUS T be follows the Attrleaf naming pattern <xref target="RFC8552"/>, so the scheme <bcp 14>MUST</bcp14> be
registered appropriately with IANA (see <xref target="other-standards"/>).</t> registered appropriately with IANA (see <xref target="other-standards"/>).</t>
<t>Protocol mapping documents MAY specify additional underscore-prefixed <t>Protocol mapping documents <bcp14>MAY</bcp14> specify additional unde
labels rscore-prefixed labels
to be prepended. For schemes that specify a port (<xref section="3.2.3" section to be prepended. For schemes that specify a port (<xref section="3.2.3" section
Format="of" target="URI"/>), one reasonable possibility is to prepend the indica Format="of" target="RFC3986"/>), one reasonable possibility is to prepend the in
ted port dicated port
number if a non-default port number is specified. We term this behavior number if a non-default port number is specified. This document terms this beha
"Port Prefix Naming", and use it in the examples throughout this document.</t> vior
<t>See <xref target="httpsnames"/> for the HTTPS RR behavior.</t> "Port Prefix Naming" and uses it in the examples throughout.</t>
<t>See <xref target="httpsnames"/> for information regarding HTTPS RR be
havior.</t>
<t>When a prior CNAME or SVCB record has aliased to <t>When a prior CNAME or SVCB record has aliased to
a SVCB record, each RR SHALL be returned under its own owner name, as in a SVCB record, each RR <bcp14>SHALL</bcp14> be returned under its own owner name , as in
ordinary CNAME processing (<xref section="3.6.2" sectionFormat="comma" target="R FC1034"/>). For details, see ordinary CNAME processing (<xref section="3.6.2" sectionFormat="comma" target="R FC1034"/>). For details, see
the recommendations regarding aliases for clients (<xref target="client-behavior "/>), the recommendations regarding aliases for clients (<xref target="client-behavior "/>),
servers (<xref target="server-behavior"/>), and zones (<xref target="zone-struct ures"/>).</t> servers (<xref target="server-behavior"/>), and zones (<xref target="zone-struct ures"/>).</t>
<t>Note that none of these forms alter the origin or authority for valid ation <t>Note that none of these forms alter the origin or authority for valid ation
purposes. purposes.
For example, TLS clients MUST continue to validate TLS certificates For example, TLS clients <bcp14>MUST</bcp14> continue to validate TLS certificat es
for the original service name.</t> for the original service name.</t>
<t>As an example, the owner of example.com could publish this record:</t <t>As an example, the owner of "example.com" could publish this record:<
> /t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
_8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net.
]]></artwork> ]]></sourcecode>
<t>to indicate that "foo://api.example.com:8443" is aliased to "svc4.exa <t>This record would indicate that "foo://api.example.com:8443" is alias
mple.net". ed to "svc4.example.net".
The owner of example.net, in turn, could publish this record:</t> The owner of "example.net", in turn, could publish this record:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
svc4.example.net. 7200 IN SVCB 3 svc4.example.net. ( svc4.example.net. 7200 IN SVCB 3 svc4.example.net. (
alpn="bar" port="8004" ) alpn="bar" port="8004" )
]]></artwork> ]]></sourcecode>
<t>to indicate that these services are served on port number 8004, <t>This record would indicate that these services are served on port num
ber 8004,
which supports the protocol "bar" and its associated transport in which supports the protocol "bar" and its associated transport in
addition to the default transport protocol for "foo://".</t> addition to the default transport protocol for "foo://".</t>
<t>(Parentheses are used to ignore a line break in DNS zone file present <t>(Parentheses are used to ignore a line break in DNS zone-file present
ation ation
format (<xref section="5.1" sectionFormat="comma" target="RFC1035"/>).)</t> format, per <xref section="5.1" sectionFormat="of" target="RFC1035"/>.)</t>
</section> </section>
<section anchor="interpretation"> <section anchor="interpretation">
<name>Interpretation</name> <name>Interpretation</name>
<section anchor="pri"> <section anchor="pri">
<name>SvcPriority</name> <name>SvcPriority</name>
<t>When SvcPriority is 0 the SVCB record is in AliasMode (<xref target ="alias-mode"/>). <t>When SvcPriority is 0, the SVCB record is in AliasMode (<xref targe t="alias-mode"/>).
Otherwise, it is in ServiceMode (<xref target="service-mode"/>).</t> Otherwise, it is in ServiceMode (<xref target="service-mode"/>).</t>
<t>Within a SVCB RRSet, <t>Within a SVCB RRset,
all RRs SHOULD have the same Mode. all RRs <bcp14>SHOULD</bcp14> have the same mode.
If an RRSet contains a record in AliasMode, the recipient MUST ignore If an RRset contains a record in AliasMode, the recipient <bcp14>MUST</bcp14> ig
nore
any ServiceMode records in the set.</t> any ServiceMode records in the set.</t>
<t>RRSets are explicitly unordered collections, so the <t>RRsets are explicitly unordered collections, so the
SvcPriority field is used to impose an ordering on SVCB RRs. SvcPriority field is used to impose an ordering on SVCB RRs.
A smaller SvcPriority indicates that the domain owner recommends use of this A smaller SvcPriority indicates that the domain owner recommends the use of this
record over ServiceMode RRs with a larger SvcPriority value.</t> record over ServiceMode RRs with a larger SvcPriority value.</t>
<t>When receiving an RRSet containing multiple SVCB records with the <t>When receiving an RRset containing multiple SVCB records with the
same SvcPriority value, clients SHOULD apply a random shuffle within a same SvcPriority value, clients <bcp14>SHOULD</bcp14> apply a random shuffle wit
hin a
priority level to the records before using them, to ensure uniform priority level to the records before using them, to ensure uniform
load-balancing.</t> load balancing.</t>
</section> </section>
<section anchor="alias-mode"> <section anchor="alias-mode">
<name>AliasMode</name> <name>AliasMode</name>
<t>In AliasMode, the SVCB record aliases a service to a <t>In AliasMode, the SVCB record aliases a service to a
TargetName. SVCB RRSets SHOULD only have a single resource TargetName. SVCB RRsets <bcp14>SHOULD</bcp14> only have a single RR in AliasMod
record in AliasMode. If multiple are present, clients or recursive e. If multiple AliasMode RRs are present, clients or recursive
resolvers SHOULD pick one at random.</t> resolvers <bcp14>SHOULD</bcp14> pick one at random.
</t>
<t>The primary purpose of AliasMode is to allow aliasing at the zone <t>The primary purpose of AliasMode is to allow aliasing at the zone
apex, where CNAME is not allowed (see e.g. <xref section="2.4" sectionFormat="co mma" target="RFC1912"/>). apex, where CNAME is not allowed (see, for example, <xref section="2.4" sectionF ormat="comma" target="RFC1912"/>).
In AliasMode, the TargetName will In AliasMode, the TargetName will
be the name of a domain that resolves to SVCB, be the name of a domain that resolves to SVCB,
AAAA, and/or A records. (See <xref target="svcb-compatible"/> for aliasing of S VCB-compatible RR types.) AAAA, and/or A records. (See <xref target="svcb-compatible"/> for aliasing of S VCB-compatible RR types.)
Unlike CNAME, AliasMode records do not affect the resolution of other RR Unlike CNAME, AliasMode records do not affect the resolution of other RR
types, and apply only to a specific service, not an entire domain name.</t> types and apply only to a specific service, not an entire domain name.</t>
<t>The AliasMode TargetName SHOULD NOT be equal <t>The AliasMode TargetName <bcp14>SHOULD NOT</bcp14> be equal
to the owner name, as this would result in a loop. to the owner name, as this would result in a loop.
In AliasMode, recipients MUST ignore any SvcParams that are present. In AliasMode, recipients <bcp14>MUST</bcp14> ignore any SvcParams that are prese
Zone-file parsers MAY emit a warning if an AliasMode record has SvcParams. nt.
Zone-file parsers <bcp14>MAY</bcp14> emit a warning if an AliasMode record has S
vcParams.
The use of SvcParams in AliasMode records is currently not defined, but a The use of SvcParams in AliasMode records is currently not defined, but a
future specification could extend AliasMode records to include SvcParams.</t> future specification could extend AliasMode records to include SvcParams.</t>
<t>For example, the operator of foo://example.com:8080 could <t>For example, the operator of "foo://example.com:8080" could
point requests to a service operating at foosvc.example.net point requests to a service operating at "foosvc.example.net"
by publishing:</t> by publishing:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
_8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net. _8080._foo.example.com. 3600 IN SVCB 0 foosvc.example.net.
]]></artwork> ]]></sourcecode>
<t>Using AliasMode maintains a separation of concerns: the owner of <t>Using AliasMode maintains a separation of concerns: the owner of
foosvc.example.net can add or remove ServiceMode SVCB records without "foosvc.example.net" can add or remove ServiceMode SVCB records without
requiring a corresponding change to example.com. Note that if requiring a corresponding change to "example.com". Note that if
foosvc.example.net promises to always publish a SVCB record, this AliasMode "foosvc.example.net" promises to always publish a SVCB record, this AliasMode
record can be replaced by a CNAME at the same owner name, which would likely record can be replaced by a CNAME at the same owner name.</t>
improve performance.</t>
<t>AliasMode is especially useful for SVCB-compatible RR types that do not <t>AliasMode is especially useful for SVCB-compatible RR types that do not
require an underscore prefix, such as the HTTPS RR type. For example, require an underscore prefix, such as the HTTPS RR type. For example,
the operator of https://example.com could point requests to a server the operator of "https://example.com" could point requests to a server
at svc.example.net by publishing this record at the zone apex:</t> at "svc.example.net" by publishing this record at the zone apex:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
example.com. 3600 IN HTTPS 0 svc.example.net. example.com. 3600 IN HTTPS 0 svc.example.net.
]]></artwork> ]]></sourcecode>
<t>Note that the SVCB record's owner name MAY be the canonical name <t>Note that the SVCB record's owner name <bcp14>MAY</bcp14> be the ca
of a CNAME record, and the TargetName MAY be the owner of a CNAME nonical name
record. Clients and recursive resolvers MUST follow CNAMEs as normal.</t> of a CNAME record, and the TargetName <bcp14>MAY</bcp14> be the owner of a CNAME
<t>To avoid unbounded alias chains, clients and recursive resolvers MU record. Clients and recursive resolvers <bcp14>MUST</bcp14> follow CNAMEs as nor
ST impose a mal.</t>
<t>To avoid unbounded alias chains, clients and recursive resolvers <b
cp14>MUST</bcp14> impose a
limit on the total number of SVCB aliases they will follow for each resolution limit on the total number of SVCB aliases they will follow for each resolution
request. This limit MUST NOT be zero, i.e. implementations MUST be able to request. This limit <bcp14>MUST NOT</bcp14> be zero, i.e., implementations <bcp 14>MUST</bcp14> be able to
follow at least one AliasMode record. The exact value of this limit follow at least one AliasMode record. The exact value of this limit
is left to implementations.</t> is left to implementations.</t>
<t>Zones that require following multiple AliasMode records could encou nter <t>Zones that require following multiple AliasMode records could encou nter
compatibility and performance issues.</t> compatibility and performance issues.</t>
<t>As legacy clients will not know to use this record, service <t>As legacy clients will not know to use this record, service
operators will likely need to retain fallback AAAA and A records operators will likely need to retain fallback AAAA and A records
alongside this SVCB record, although in a common case alongside this SVCB record, although in a common case
the target of the SVCB record might offer better performance, and the target of the SVCB record might offer better performance, and
therefore would be preferable for clients implementing this specification therefore would be preferable for clients implementing this specification
to use.</t> to use.</t>
<t>AliasMode records only apply to queries for the specific RR type. <t>AliasMode records only apply to queries for the specific RR type.
For example, a SVCB record cannot alias to an HTTPS record, For example, a SVCB record cannot alias to an HTTPS record or vice versa.</t>
nor vice-versa.</t>
</section> </section>
<section anchor="service-mode"> <section anchor="service-mode">
<name>ServiceMode</name> <name>ServiceMode</name>
<t>In ServiceMode, the TargetName and SvcParams within each resource r ecord <t>In ServiceMode, the TargetName and SvcParams within each RR
associate an alternative endpoint for the service with its connection associate an alternative endpoint for the service with its connection
parameters.</t> parameters.</t>
<t>Each protocol scheme that uses SVCB MUST define a protocol mapping that <t>Each protocol scheme that uses SVCB <bcp14>MUST</bcp14> define a pr otocol mapping that
explains how SvcParams are applied for connections of that scheme. explains how SvcParams are applied for connections of that scheme.
Unless specified otherwise by the Unless specified otherwise by the
protocol mapping, clients MUST ignore any SvcParam that they do protocol mapping, clients <bcp14>MUST</bcp14> ignore any SvcParam that they do
not recognize.</t> not recognize.</t>
<t>Some SvcParams impose requirements on other SvcParams in the RR. A <t>Some SvcParams impose requirements on other SvcParams in the RR. A
ServiceMode RR is called "self-consistent" if its SvcParams all comply with ServiceMode RR is called "self-consistent" if its SvcParams all comply with
each other's requirements. Clients MUST reject any RR whose recognized each other's requirements. Clients <bcp14>MUST</bcp14> reject any RR whose reco
SvcParams are not self-consistent, and MAY reject the entire RRSet. To gnized
help zone operators avoid this condition, zone-file implementations SHOULD SvcParams are not self-consistent and <bcp14>MAY</bcp14> reject the entire RRset
. To
help zone operators avoid this condition, zone-file implementations <bcp14>SHOUL
D</bcp14>
enforce self-consistency as well.</t> enforce self-consistency as well.</t>
</section> </section>
</section> </section>
<section anchor="dot"> <section anchor="dot">
<name>Special handling of "." in TargetName</name> <name>Special Handling of "." in TargetName</name>
<t>If TargetName has the value "." (represented in the wire format as a <t>If TargetName has the value "." (represented in the wire format as a
zero-length label), special rules apply.</t> zero-length label), special rules apply.</t>
<section anchor="aliasdot"> <section anchor="aliasdot">
<name>AliasMode</name> <name>AliasMode</name>
<t>For AliasMode SVCB RRs, a TargetName of "." indicates that the serv ice <t>For AliasMode SVCB RRs, a TargetName of "." indicates that the serv ice
is not available or does not exist. This indication is advisory: is not available or does not exist. This indication is advisory:
clients encountering this indication MAY ignore it and attempt to connect clients encountering this indication <bcp14>MAY</bcp14> ignore it and attempt to connect
without the use of SVCB.</t> without the use of SVCB.</t>
</section> </section>
<section anchor="servicemode"> <section anchor="servicemode">
<name>ServiceMode</name> <name>ServiceMode</name>
<t>For ServiceMode SVCB RRs, if TargetName has the value ".", then the <t>For ServiceMode SVCB RRs, if TargetName has the value ".", then the
owner name of this record MUST be used as the effective TargetName. owner name of this record <bcp14>MUST</bcp14> be used as the effective TargetNam e.
If the record has a wildcard owner name in the zone file, the recipient If the record has a wildcard owner name in the zone file, the recipient
SHALL use the response's synthesized owner name as the effective TargetName.</t> <bcp14>SHALL</bcp14> use the response's synthesized owner name as the effective
<t>For example, in the following example "svc2.example.net" TargetName.</t>
is the effective TargetName:</t> <t>Here, for example, "svc2.example.net" is the effective TargetName:<
<artwork><![CDATA[ /t>
<sourcecode type="dns-rr"><![CDATA[
example.com. 7200 IN HTTPS 0 svc.example.net. example.com. 7200 IN HTTPS 0 svc.example.net.
svc.example.net. 7200 IN CNAME svc2.example.net. svc.example.net. 7200 IN CNAME svc2.example.net.
svc2.example.net. 7200 IN HTTPS 1 . port=8002 svc2.example.net. 7200 IN HTTPS 1 . port=8002
svc2.example.net. 300 IN A 192.0.2.2 svc2.example.net. 300 IN A 192.0.2.2
svc2.example.net. 300 IN AAAA 2001:db8::2 svc2.example.net. 300 IN AAAA 2001:db8::2
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="client-behavior"> <section anchor="client-behavior">
<name>Client behavior</name> <name>Client Behavior</name>
<t>"SVCB resolution" is the process of enumerating the priority-ordered en <t>"SVCB resolution" is the process of enumerating and ordering the availa
dpoints ble endpoints
for a service, as performed by the client. SVCB resolution is implemented as fo llows:</t> for a service, as performed by the client. SVCB resolution is implemented as fo llows:</t>
<ol spacing="normal" type="1"><li>Let $QNAME be the service name plus appr opriate prefixes for the <ol spacing="normal" type="1"><li>Let $QNAME be the service name plus appr opriate prefixes for the
scheme (see <xref target="svcb-names"/>).</li> scheme (see <xref target="svcb-names"/>).</li>
<li>Issue a SVCB query for $QNAME.</li> <li>Issue a SVCB query for $QNAME.</li>
<li>If an AliasMode SVCB record is returned for $QNAME (after following CNAMEs <li>If an AliasMode SVCB record is returned for $QNAME (after following CNAMEs
as normal), set $QNAME to its TargetName (without as normal), set $QNAME to its TargetName (without
additional prefixes) and loop back to step 2, additional prefixes) and loop back to Step 2,
subject to chain length limits and loop detection heuristics (see subject to chain length limits and loop detection heuristics (see
<xref target="client-failures"/>).</li> <xref target="client-failures"/>).</li>
<li>If one or more "compatible" (<xref target="mandatory"/>) ServiceMode records are returned, <li>If one or more "compatible" (<xref target="mandatory"/>) ServiceMode records are returned,
these represent the alternative endpoints.</li> these represent the alternative endpoints. Sort the records by ascending SvcPrio
<li>Otherwise, SVCB resolution has failed, and the list of known endpoin rity.</li>
ts is <li>Otherwise, SVCB resolution has failed, and the list of available end
points is
empty.</li> empty.</li>
</ol> </ol>
<t>This procedure does not rely on any recursive or authoritative DNS serv er to <t>This procedure does not rely on any recursive or authoritative DNS serv er to
comply with this specification or have any awareness of SVCB.</t> comply with this specification or have any awareness of SVCB.</t>
<t>A client is called "SVCB-optional" if it can connect without the use of <t>A client is called "SVCB-optional" if it can connect without the use of
ServiceMode records, and "SVCB-reliant" otherwise. Clients for pre-existing ServiceMode records; otherwise, it is called "SVCB-reliant". Clients for pre-ex
protocols (e.g. HTTP) SHALL implement SVCB-optional behavior (except as isting
protocols (e.g., HTTP) <bcp14>SHALL</bcp14> implement SVCB-optional behavior (ex
cept as
noted in <xref target="client-failures"/> or when modified by future specificati ons).</t> noted in <xref target="client-failures"/> or when modified by future specificati ons).</t>
<t>SVCB-optional clients SHOULD issue in parallel any other DNS queries th at might <t>SVCB-optional clients <bcp14>SHOULD</bcp14> issue in parallel any other DNS queries that might
be needed for connection establishment if the SVCB record is absent, in order to minimize delay be needed for connection establishment if the SVCB record is absent, in order to minimize delay
in that case and enable the optimizations discussed in <xref target="optimizatio ns"/>.</t> in that case and enable the optimizations discussed in <xref target="optimizatio ns"/>.</t>
<t>Once SVCB resolution has concluded, whether successful or not, <t>Once SVCB resolution has concluded, whether successful or not,
if at least one AliasMode record was processed, if at least one AliasMode record was processed,
SVCB-optional clients SHALL append to the priority list an SVCB-optional clients <bcp14>SHALL</bcp14> append to the list of endpoints an
endpoint consisting of the final value of $QNAME, the authority endpoint consisting of the final value of $QNAME, the authority
endpoint's port number, and no SvcParams. (This endpoint will be endpoint's port number, and no SvcParams. (This endpoint will be
attempted before falling back to non-SVCB connection modes. This ensures that attempted before falling back to non-SVCB connection modes. This ensures that
SVCB-optional clients will make use of an AliasMode record whose TargetName has SVCB-optional clients will make use of an AliasMode record whose TargetName has
A and/or AAAA records but no SVCB records.)</t> A and/or AAAA records but no SVCB records.)</t>
<t>The client proceeds with connection establishment using the resolved li <t>The client proceeds with connection establishment using this list of
st of endpoints. Clients <bcp14>SHOULD</bcp14> try higher-priority alternatives first
endpoints. Clients SHOULD try higher-priority alternatives first, with , with
fallback to lower-priority alternatives. Clients resolve AAAA and/or A fallback to lower-priority alternatives. Clients resolve AAAA and/or A
records for the selected TargetName, and MAY choose between them using an records for the selected TargetName and <bcp14>MAY</bcp14> choose between them u
approach such as Happy Eyeballs <xref target="HappyEyeballsV2"/>.</t> sing an
<t>If the client is SVCB-optional, and connecting using this list of endpo approach such as Happy Eyeballs <xref target="RFC8305"/>.</t>
ints has <t>If the client is SVCB-optional and connecting using this list of endpoi
nts has
failed, the client now attempts to use non-SVCB connection modes.</t> failed, the client now attempts to use non-SVCB connection modes.</t>
<t>Some important optimizations are discussed in <xref target="optimizatio ns"/> <t>Some important optimizations are discussed in <xref target="optimizatio ns"/>
to avoid additional latency in comparison to ordinary AAAA/A lookups.</t> to avoid additional latency in comparison to ordinary AAAA/A lookups.</t>
<section anchor="client-failures"> <section anchor="client-failures">
<name>Handling resolution failures</name> <name>Handling Resolution Failures</name>
<t>If DNS responses are cryptographically protected (e.g. using DNSSEC o <t>If DNS responses are cryptographically protected (e.g., using DNSSEC
r or
TLS <xref target="DoT"/><xref target="DoH"/>), and SVCB resolution fails TLS <xref target="RFC7858"/> <xref target="RFC8484"/>) and SVCB resolution fails
due to an authentication error, SERVFAIL response, transport error, or due to an authentication error, SERVFAIL response, transport error, or
timeout, the client SHOULD abandon its attempt to reach the service, even timeout, the client <bcp14>SHOULD</bcp14> abandon its attempt to reach the servi ce, even
if the client is SVCB-optional. Otherwise, an active attacker if the client is SVCB-optional. Otherwise, an active attacker
could mount a downgrade attack by denying the user access to the SvcParams.</t> could mount a downgrade attack by denying the user access to the SvcParams.</t>
<t>A SERVFAIL error can occur if the domain is DNSSEC-signed, the recurs ive <t>A SERVFAIL error can occur if the domain is DNSSEC-signed, the recurs ive
resolver is DNSSEC-validating, and the attacker is between the recursive resolver is DNSSEC-validating, and the attacker is between the recursive
resolver and the authoritative DNS server. A transport error or timeout can resolver and the authoritative DNS server. A transport error or timeout can
occur if an active attacker between the client and the recursive resolver is occur if an active attacker between the client and the recursive resolver is
selectively dropping SVCB queries or responses, based on their size or selectively dropping SVCB queries or responses, based on their size or
other observable patterns.</t> other observable patterns.</t>
<t>If the client enforces DNSSEC validation on A/AAAA responses, it SHOU LD <t>If the client enforces DNSSEC validation on A/AAAA responses, it <bcp 14>SHOULD</bcp14>
apply the same validation policy to SVCB. Otherwise, an attacker could apply the same validation policy to SVCB. Otherwise, an attacker could
defeat the A/AAAA protection by forging SVCB responses that direct the defeat the A/AAAA protection by forging SVCB responses that direct the
client to other IP addresses.</t> client to other IP addresses.</t>
<t>If DNS responses are not cryptographically protected, clients MAY tre at <t>If DNS responses are not cryptographically protected, clients <bcp14> MAY</bcp14> treat
SVCB resolution failure as fatal or nonfatal.</t> SVCB resolution failure as fatal or nonfatal.</t>
<t>If the client is unable to complete SVCB resolution due to its chain length <t>If the client is unable to complete SVCB resolution due to its chain length
limit, the client MUST fall back to the authority endpoint, as if the limit, the client <bcp14>MUST</bcp14> fall back to the authority endpoint, as if
origin's SVCB record did not exist.</t> the
service's SVCB record did not exist.</t>
</section> </section>
<section anchor="clients-using-a-proxy"> <section anchor="clients-using-a-proxy">
<name>Clients using a Proxy</name> <name>Clients Using a Proxy</name>
<t>Clients using a domain-oriented transport proxy like HTTP CONNECT <t>Clients using a domain-oriented transport proxy like HTTP CONNECT
(<xref section="4.3.6" sectionFormat="comma" target="RFC7231"/>) or SOCKS5 (<xre (<xref section="4.3.6" sectionFormat="comma" target="RFC7231"/>) or SOCKS5 <xref
f target="RFC1928"/>) have the option to target="RFC1928"/> have the option of
use named destinations, in which case the client does not perform using named destinations, in which case the client does not perform
any A or AAAA queries for destination domains. If the client is configured any A or AAAA queries for destination domains. If the client is configured
to use named to use named
destinations with a proxy that does not provide SVCB query capability destinations with a proxy that does not provide SVCB query capability
(e.g. through an affiliated DNS resolver), the client would have to perform (e.g., through an affiliated DNS resolver), the client would have to perform
SVCB resolution separately, likely disclosing the destinations to additional par SVCB resolution separately, likely disclosing the destinations to additional par
ties than just the proxy. ties and not just the proxy.
Clients in this configuration SHOULD arrange for a separate SVCB resolution Clients in this configuration <bcp14>SHOULD</bcp14> arrange for a separate SVCB
resolution
procedure with appropriate privacy properties. If this is not possible, procedure with appropriate privacy properties. If this is not possible,
SVCB-optional clients MUST disable SVCB resolution entirely, and SVCB-reliant SVCB-optional clients <bcp14>MUST</bcp14> disable SVCB resolution entirely, and
clients MUST treat the configuration as invalid.</t> SVCB-reliant
<t>If the client does use SVCB and named destinations, the client SHOULD clients <bcp14>MUST</bcp14> treat the configuration as invalid.</t>
follow <t>If the client does use SVCB and named destinations, the client <bcp14
>SHOULD</bcp14> follow
the standard SVCB resolution process, selecting the smallest-SvcPriority the standard SVCB resolution process, selecting the smallest-SvcPriority
option that is compatible with the client and the proxy. When connecting option that is compatible with the client and the proxy. When connecting
using a SVCB record, clients MUST provide the final TargetName and port to the using a SVCB record, clients <bcp14>MUST</bcp14> provide the final TargetName an d port to the
proxy, which will perform any required A and AAAA lookups.</t> proxy, which will perform any required A and AAAA lookups.</t>
<t>This arrangement has several benefits:</t> <t>This arrangement has several benefits:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Compared to disabling SVCB: <t>Compared to disabling SVCB:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>It allows the client to use the SvcParams, if present, which a re <li>It allows the client to use the SvcParams, if present, which a re
only usable with a specific TargetName. The SvcParams may only usable with a specific TargetName. The SvcParams may
include information that enhances performance (e.g. alpn) and privacy.</li> include information that enhances performance (e.g., supported protocols) and pr
<li>It allows the service to delegate the apex domain.</li> ivacy.</li>
<li>It allows a service on an apex domain to use aliasing.</li>
</ul> </ul>
</li> </li>
<li> <li>
<t>Compared to providing the proxy with an IP address: <t>Compared to providing the proxy with an IP address:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>It allows the proxy to select between IPv4 and IPv6 addresses for the <li>It allows the proxy to select between IPv4 and IPv6 addresses for the
server according to its configuration.</li> server according to its configuration.</li>
<li>It ensures that the proxy receives addresses based on its netw ork <li>It ensures that the proxy receives addresses based on its netw ork
geolocation, not the client's.</li> geolocation, not the client's.</li>
<li>It enables faster fallback for TCP destinations with multiple addresses <li>It enables faster fallback for TCP destinations with multiple addresses
of the same family.</li> of the same family.</li>
</ul> </ul>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="server-behavior"> <section anchor="server-behavior">
<name>DNS Server Behavior</name> <name>DNS Server Behavior</name>
<section anchor="authoritative-behavior"> <section anchor="authoritative-behavior">
<name>Authoritative servers</name> <name>Authoritative Servers</name>
<t>When replying to a SVCB query, authoritative DNS servers SHOULD retur <t>When replying to a SVCB query, authoritative DNS servers <bcp14>SHOUL
n D</bcp14> return
A, AAAA, and SVCB records in the Additional Section for any TargetNames A, AAAA, and SVCB records in the Additional section for any TargetNames
that are in the zone. If the zone is signed, the server SHOULD also that are in the zone. If the zone is signed, the server <bcp14>SHOULD</bcp14> a
include positive or negative DNSSEC responses for these records in the Additiona lso
l include DNSSEC records authenticating the existence or nonexistence of these rec
section.</t> ords
in the Additional section.</t>
<t>See <xref target="ecs"/> for exceptions.</t> <t>See <xref target="ecs"/> for exceptions.</t>
</section> </section>
<section anchor="recursive-behavior"> <section anchor="recursive-behavior">
<name>Recursive resolvers</name> <name>Recursive Resolvers</name>
<t>Whether the recursive resolver is aware of SVCB or not, the normal re sponse <t>Whether the recursive resolver is aware of SVCB or not, the normal re sponse
construction process (i.e. unknown RR type resolution under <xref target="RFC359 7"/>) construction process used for unknown RR types <xref target="RFC3597"/>
generates the Answer section of the response. generates the Answer section of the response.
Recursive resolvers that are aware of SVCB SHOULD help the client to Recursive resolvers that are aware of SVCB <bcp14>SHOULD</bcp14> help the client to
execute the procedure in <xref target="client-behavior"/> with minimum overall execute the procedure in <xref target="client-behavior"/> with minimum overall
latency by incorporating additional useful information into the latency by incorporating additional useful information into the
Additional section of the response as follows:</t> Additional section of the response as follows:
</t>
<ol spacing="normal" type="1"><li>Incorporate the results of SVCB resolu tion. If the recursive resolver's <ol spacing="normal" type="1"><li>Incorporate the results of SVCB resolu tion. If the recursive resolver's
local chain length limit (which may be different from the client's limit) has local chain length limit (which may be different from the client's limit) has
been reached, terminate.</li> been reached, terminate.</li>
<li> <li>
<t>If any of the resolved SVCB records are in AliasMode, choose one of them <t>If any of the resolved SVCB records are in AliasMode, choose one of them
at random, and resolve SVCB, A, and AAAA records for its at random, and resolve SVCB, A, and AAAA records for its
TargetName. </t> TargetName. </t>
<ul spacing="normal"> <ul spacing="normal">
<li>If any SVCB records are resolved, go to step 1.</li> <li>If any SVCB records are resolved, go to Step 1.</li>
<li>Otherwise, incorporate the results of A and AAAA resolution, a nd <li>Otherwise, incorporate the results of A and AAAA resolution, a nd
terminate.</li> terminate.</li>
</ul> </ul>
</li> </li>
<li>All the resolved SVCB records are in ServiceMode. Resolve A and A AAA <li>All the resolved SVCB records are in ServiceMode. Resolve A and A AAA
queries for each TargetName (or for the owner name if TargetName queries for each TargetName (or for the owner name if TargetName
is "."), incorporate all the results, and terminate.</li> is "."), incorporate all the results, and terminate.</li>
</ol> </ol>
<t>In this procedure, "resolve" means the resolver's ordinary recursive <t>In this procedure, "resolve" means the resolver's ordinary recursive
resolution procedure, as if processing a query for that RRSet. resolution procedure, as if processing a query for that RRset.
This includes following any aliases that the resolver would ordinarily This includes following any aliases that the resolver would ordinarily
follow (e.g. CNAME, DNAME <xref target="DNAME"/>). Errors or anomalies in follow (e.g., CNAME, DNAME <xref target="RFC6672"/>). Errors or anomalies in
obtaining additional records MAY cause this process to terminate, but obtaining additional records <bcp14>MAY</bcp14> cause this process to terminate
MUST NOT themselves cause the resolver to send a failure response.</t> but
<bcp14>MUST NOT</bcp14> themselves cause the resolver to send a failure response
.</t>
<t>See <xref target="alias-mode"/> for additional safeguards for recursi ve resolvers <t>See <xref target="alias-mode"/> for additional safeguards for recursi ve resolvers
to implement to mitigate loops.</t> to implement to mitigate loops.</t>
<t>See <xref target="incomplete-response"/> for possible optimizations o f this procedure.</t> <t>See <xref target="incomplete-response"/> for possible optimizations o f this procedure.</t>
<section anchor="dns64"> <section anchor="dns64">
<name>DNS64</name> <name>DNS64</name>
<t>DNS64 resolvers synthesize responses to AAAA queries for names that only <t>DNS64 resolvers synthesize responses to AAAA queries for names that only
have an A record (<xref section="5.1.7" sectionFormat="of" target="RFC6147"/>). SVCB-aware DNS64 have an A record (<xref section="5.1.7" sectionFormat="of" target="RFC6147"/>). SVCB-aware DNS64
resolvers SHOULD apply the same synthesis logic when resolving AAAA resolvers <bcp14>SHOULD</bcp14> apply the same synthesis logic when resolving AA
records for the TargetName for inclusion as Additionals (Step 2 in AA
<xref target="recursive-behavior"/>), and MAY omit the Additional A records.</t> records for the TargetName for inclusion in the Additional section (Step 2 in
<t>DNS64 resolvers MUST NOT extrapolate the AAAA synthesis logic to th <xref target="recursive-behavior"/>) and <bcp14>MAY</bcp14> omit the A records f
e IP rom this section.</t>
<t>DNS64 resolvers <bcp14>MUST NOT</bcp14> extrapolate the AAAA synthe
sis logic to the IP
hints in the SvcParams (<xref target="svcparamkeys-iphints"/>). Modifying the I P hints hints in the SvcParams (<xref target="svcparamkeys-iphints"/>). Modifying the I P hints
would break DNSSEC validation for the SVCB record and would not improve would break DNSSEC validation for the SVCB record and would not improve
performance when the above recommendation is implemented.</t> performance when the above recommendation is implemented.</t>
</section> </section>
</section> </section>
<section anchor="general-requirements"> <section anchor="general-requirements">
<name>General requirements</name> <name>General Requirements</name>
<t>Recursive resolvers MUST be able to convey SVCB records with unrecogn <t>Recursive resolvers <bcp14>MUST</bcp14> be able to convey SVCB record
ized s with unrecognized
SvcParamKeys, and MAY treat the entire SvcParams portion of the record as SvcParamKeys. Resolvers <bcp14>MAY</bcp14> accomplish this by treating
opaque, even if the contents are invalid. Alternatively, recursive the entire SvcParams portion of the record as opaque, even if the contents
resolvers MAY report an error such as SERVFAIL to avoid returning a are invalid. If a recognized SvcParamKey is followed by a value that is
SvcParamValue that is invalid according to the SvcParam's specification. invalid according to the SvcParam's specification, a recursive resolver
<bcp14>MAY</bcp14> report an error such as SERVFAIL instead of returning
the record.
For complex value types whose interpretation might differ For complex value types whose interpretation might differ
between implementations or have additional future between implementations or have additional future
allowed values added (e.g. URIs or "alpn"), resolvers allowed values added (e.g., URIs or "alpn"), resolvers
SHOULD limit validation to specified constraints.</t> <bcp14>SHOULD</bcp14> limit validation to specified constraints.</t>
<t>When responding to a query that includes the DNSSEC OK bit (<xref tar <t>When responding to a query that includes the DNSSEC OK bit <xref targ
get="RFC3225"/>), et="RFC3225"/>,
DNSSEC-capable recursive and authoritative DNS servers MUST accompany DNSSEC-capable recursive and authoritative DNS servers <bcp14>MUST</bcp14> accom
each RRSet in the Additional section with the same DNSSEC-related records pany
that they would send when providing that RRSet as an Answer (e.g. RRSIG, NSEC, each RRset in the Additional section with the same DNSSEC-related records
that they would send when providing that RRset as an Answer (e.g., RRSIG, NSEC,
NSEC3).</t> NSEC3).</t>
<t>According to <xref section="5.4.1" sectionFormat="of" target="RFC2181 "/>, "Unauthenticated RRs received <t>According to <xref section="5.4.1" sectionFormat="of" target="RFC2181 "/>, "Unauthenticated RRs received
and cached from ... the additional data section ... should not be cached in and cached from ... the additional data section ... should not be cached in
such a way that they would ever be returned as answers to a received query. such a way that they would ever be returned as answers to a received query.
They may be returned as additional information where appropriate.". They may be returned as additional information where appropriate."
Recursive resolvers therefore MAY cache records from the Additional section Recursive resolvers therefore <bcp14>MAY</bcp14> cache records from the Addition
for use in populating Additional section responses, and MAY cache them al section
for use in populating Additional section responses and <bcp14>MAY</bcp14> cache
them
for general use if they are authenticated by DNSSEC.</t> for general use if they are authenticated by DNSSEC.</t>
</section> </section>
<section anchor="ecs"> <section anchor="ecs">
<name>EDNS Client Subnet (ECS)</name> <name>EDNS Client Subnet (ECS)</name>
<t>The EDNS Client Subnet option (ECS, <xref target="RFC7871"/>) allows recursive <t>The EDNS Client Subnet (ECS) option <xref target="RFC7871"/> allows r ecursive
resolvers to request IP addresses that are suitable for a particular client resolvers to request IP addresses that are suitable for a particular client
IP range. SVCB records may contain IP addresses (in ipv*hint SvcParams), IP range. SVCB records may contain IP addresses (in ipv*hint SvcParams)
or direct users to a subnet-specific TargetName, so recursive resolvers or direct users to a subnet-specific TargetName, so recursive resolvers
SHOULD include the same ECS option in SVCB queries as in A/AAAA queries.</t> <bcp14>SHOULD</bcp14> include the same ECS option in SVCB queries as in A/AAAA q ueries.</t>
<t>According to <xref section="7.3.1" sectionFormat="of" target="RFC7871 "/>, "Any records from [the <t>According to <xref section="7.3.1" sectionFormat="of" target="RFC7871 "/>, "Any records from [the
Additional section] MUST NOT be tied to a network". Accordingly, Additional section] <bcp14>MUST NOT</bcp14> be tied to a network." Accordingly,
when processing a response whose QTYPE is SVCB-compatible, when processing a response whose QTYPE is SVCB-compatible,
resolvers SHOULD treat any records in the Additional section as having resolvers <bcp14>SHOULD</bcp14> treat any records in the Additional section as h
SOURCE PREFIX-LENGTH zero and SCOPE PREFIX-LENGTH as specified aving
in the ECS option. Authoritative servers MUST omit such records if they are SOURCE PREFIX-LENGTH set to zero and SCOPE PREFIX-LENGTH as specified
in the ECS option. Authoritative servers <bcp14>MUST</bcp14> omit such records
if they are
not suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH to not suitable for use by any stub resolvers that set SOURCE PREFIX-LENGTH to
zero. This will cause the resolver to perform a follow-up query that can zero. This will cause the resolver to perform a follow-up query that can
receive properly tailored ECS. (This is similar to the usage of CNAME with receive a properly tailored ECS. (This is similar to the usage of CNAME with
ECS discussed in <xref section="7.2.1" sectionFormat="comma" target="RFC7871"/>. the ECS option as discussed in <xref section="7.2.1" sectionFormat="comma" targe
)</t> t="RFC7871"/>.)</t>
<t>Authoritative servers that omit Additional records can avoid the adde d <t>Authoritative servers that omit Additional records can avoid the adde d
latency of a follow-up query by following the advice in <xref target="zone-perfo rmance"/>.</t> latency of a follow-up query by following the advice in <xref target="zone-perfo rmance"/>.</t>
</section> </section>
</section> </section>
<section anchor="optimizations"> <section anchor="optimizations">
<name>Performance optimizations</name> <name>Performance Optimizations</name>
<t>For optimal performance (i.e. minimum connection setup time), clients <t>For optimal performance (i.e., minimum connection setup time), clients
SHOULD implement a client-side DNS cache. <bcp14>SHOULD</bcp14> implement a client-side DNS cache.
Responses in the Additional section of a SVCB response SHOULD be placed Responses in the Additional section of a SVCB response <bcp14>SHOULD</bcp14> be
placed
in cache before performing any follow-up queries. in cache before performing any follow-up queries.
With this behavior, and conforming DNS servers, With this behavior, and with conforming DNS servers,
using SVCB does not add network latency to connection setup.</t> using SVCB does not add network latency to connection setup.</t>
<t>To improve performance when using a non-conforming recursive resolver, clients <t>To improve performance when using a non-conforming recursive resolver, clients
SHOULD issue speculative A and/or AAAA queries in parallel with each SVCB <bcp14>SHOULD</bcp14> issue speculative A and/or AAAA queries in parallel with e ach SVCB
query, based on a predicted value of TargetName (see <xref target="zone-performa nce"/>).</t> query, based on a predicted value of TargetName (see <xref target="zone-performa nce"/>).</t>
<t>After a ServiceMode RRSet is received, clients MAY try more than one op <t>After a ServiceMode RRset is received, clients <bcp14>MAY</bcp14> try m
tion ore than one option
in parallel, and MAY prefetch A and AAAA records for multiple TargetNames.</t> in parallel and <bcp14>MAY</bcp14> prefetch A and AAAA records for multiple Targ
etNames.</t>
<section anchor="optimistic-pre-connection-and-connection-reuse"> <section anchor="optimistic-pre-connection-and-connection-reuse">
<name>Optimistic pre-connection and connection reuse</name> <name>Optimistic Pre-connection and Connection Reuse</name>
<t>If an address response arrives before the corresponding SVCB response , the <t>If an address response arrives before the corresponding SVCB response , the
client MAY initiate a connection as if the SVCB query returned NODATA, but client <bcp14>MAY</bcp14> initiate a connection as if the SVCB query returned NO
MUST NOT transmit any information that could be altered by the SVCB response DATA but
<bcp14>MUST NOT</bcp14> transmit any information that could be altered by the SV
CB response
until it arrives. For example, future SvcParamKeys could be defined that until it arrives. For example, future SvcParamKeys could be defined that
alter the TLS ClientHello.</t> alter the TLS ClientHello.</t>
<t>Clients <t>Clients
implementing this optimization SHOULD wait for 50 milliseconds before implementing this optimization <bcp14>SHOULD</bcp14> wait for 50 milliseconds be fore
starting optimistic pre-connection, as per the guidance in starting optimistic pre-connection, as per the guidance in
<xref target="HappyEyeballsV2"/>.</t> <xref target="RFC8305"/>.</t>
<t>A SVCB record is consistent with a connection <t>A SVCB record is consistent with a connection
if the client would attempt an equivalent connection when making use of if the client would attempt an equivalent connection when making use of
that record. If a SVCB record is consistent with an active or in-progress that record. If a SVCB record is consistent with an active or in-progress
connection C, the client MAY prefer that record and use C as its connection. connection C, the client <bcp14>MAY</bcp14> prefer that record and use C as its
For example, suppose the client receives this SVCB RRSet for a protocol connection.
For example, suppose the client receives this SVCB RRset for a protocol
that uses TLS over TCP:</t> that uses TLS over TCP:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
_1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. ( _1234._bar.example.com. 300 IN SVCB 1 svc1.example.net. (
ipv6hint=2001:db8::1 port=1234 ) ipv6hint=2001:db8::1 port=1234 )
SVCB 2 svc2.example.net. ( SVCB 2 svc2.example.net. (
ipv6hint=2001:db8::2 port=1234 ) ipv6hint=2001:db8::2 port=1234 )
]]></artwork> ]]></sourcecode>
<t>If the client has an in-progress TCP connection to <tt>[2001:db8::2]: 1234</tt>, <t>If the client has an in-progress TCP connection to <tt>[2001:db8::2]: 1234</tt>,
it MAY proceed with TLS on that connection, even it <bcp14>MAY</bcp14> proceed with TLS on that connection, even
though the other record in the RRSet has higher priority.</t> though the other record in the RRset has higher priority.</t>
<t>If none of the SVCB records are consistent <t>If none of the SVCB records are consistent
with any active or in-progress connection, with any active or in-progress connection,
clients proceed with connection establishment as described in clients proceed with connection establishment as described in
<xref target="client-behavior"/>.</t> <xref target="client-behavior"/>.</t>
</section> </section>
<section anchor="incomplete-response"> <section anchor="incomplete-response">
<name>Generating and using incomplete responses</name> <name>Generating and Using Incomplete Responses</name>
<t>When following the procedure in <xref target="recursive-behavior"/>, recursive <t>When following the procedure in <xref target="recursive-behavior"/>, recursive
resolvers MAY terminate the procedure early and produce a reply that omits resolvers <bcp14>MAY</bcp14> terminate the procedure early and produce a reply t
some of the associated RRSets. This is REQUIRED when the chain length limit hat omits
is reached (<xref target="recursive-behavior"/> step 1), but might also be appro some of the associated RRsets. This is <bcp14>REQUIRED</bcp14> when the chain l
priate ength limit
when the maximum response size is reached, or when responding before fully is reached (Step 1 in <xref target="recursive-behavior"/>) but might also be app
ropriate
when the maximum response size is reached or when responding before fully
chasing dependencies would improve performance. When omitting certain chasing dependencies would improve performance. When omitting certain
RRSets, recursive resolvers SHOULD prioritize information for RRsets, recursive resolvers <bcp14>SHOULD</bcp14> prioritize information for
smaller-SvcPriority records.</t> smaller-SvcPriority records.</t>
<t>As discussed in <xref target="client-behavior"/>, clients MUST be abl e to fetch additional <t>As discussed in <xref target="client-behavior"/>, clients <bcp14>MUST </bcp14> be able to fetch additional
information that is required to use a SVCB record, if it is not included information that is required to use a SVCB record, if it is not included
in the initial response. As a performance optimization, if some of the SVCB in the initial response. As a performance optimization, if some of the SVCB
records in the response can be used without requiring additional DNS queries, records in the response can be used without requiring additional DNS queries,
the client MAY prefer those records, regardless of their priorities.</t> the client <bcp14>MAY</bcp14> prefer those records, regardless of their prioriti es.</t>
</section> </section>
</section> </section>
<section anchor="svcb-compatible"> <section anchor="svcb-compatible">
<name>SVCB-compatible</name> <name>SVCB-Compatible RR Types</name>
<t>An RR type is called "SVCB-compatible" if it permits an implementation that is <t>An RR type is called "SVCB-compatible" if it permits an implementation that is
identical to SVCB in its:</t> identical to SVCB in its:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>RDATA presentation format</li> <li>RDATA presentation format</li>
<li>RDATA wire format</li> <li>RDATA wire format</li>
<li>IANA registry used for SvcParamKeys</li> <li>IANA registry used for SvcParamKeys</li>
<li>Authoritative server Additional Section processing</li> <li>Authoritative server Additional section processing</li>
<li>Recursive resolution process</li> <li>Recursive resolution process</li>
<li>Relevant Class (i.e. Internet ("IN") <xref target="RFC1035"/>)</li> <li>Relevant Class (i.e., Internet ("IN") <xref target="RFC1035"/>)</li>
</ul> </ul>
<t>This allows authoritative and recursive DNS servers to apply identical <t>This allows authoritative and recursive DNS servers to apply identical
processing to all SVCB-compatible RR types.</t> processing to all SVCB-compatible RR types.</t>
<t>All other behaviors described as applying to the SVCB RR also apply <t>All other behaviors described as applying to the SVCB RR also apply
to all SVCB-compatible RR types unless explicitly stated otherwise. to all SVCB-compatible RR types unless explicitly stated otherwise.
When following an AliasMode record (<xref target="alias-mode"/>) of RR type $T , When following an AliasMode record (<xref target="alias-mode"/>) of RR type $T,
the the
followup query to the TargetName MUST also be for type $T.</t> follow-up query to the TargetName <bcp14>MUST</bcp14> also be for type $T.</t>
<t>This document defines one SVCB-compatible RR type (other than SVCB itse lf): <t>This document defines one SVCB-compatible RR type (other than SVCB itse lf):
the HTTPS RR type (<xref target="https"/>), which avoids Attrleaf label prefixes <xref target="Attrleaf"/> in order to improve the HTTPS RR type (<xref target="https"/>), which avoids Attrleaf label prefixes <xref target="RFC8552"/> in order to improve
compatibility with wildcards and CNAMEs, which are widely used with HTTP.</t> compatibility with wildcards and CNAMEs, which are widely used with HTTP.</t>
<t>Standards authors should consider carefully whether to use SVCB or defi ne a <t>Standards authors should consider carefully whether to use SVCB or defi ne a
new SVCB-compatible RR type, as this choice cannot easily be reversed after new SVCB-compatible RR type, as this choice cannot easily be reversed after
deployment.</t> deployment.</t>
</section> </section>
<section anchor="keys"> <section anchor="keys">
<name>Initial SvcParamKeys</name> <name>Initial SvcParamKeys</name>
<t>A few initial SvcParamKeys are defined here. These keys are useful for the <t>A few initial SvcParamKeys are defined here. These keys are useful for the
"https" scheme, and most are expected to be generally applicable to other "https" scheme, and most are expected to be generally applicable to other
schemes as well.</t> schemes as well.</t>
<t>Each new protocol <t>Each new protocol
mapping document MUST specify which keys are applicable and safe to use. mapping document <bcp14>MUST</bcp14> specify which keys are applicable and safe
Protocol mappings MAY alter the interpretation of SvcParamKeys but MUST NOT to use.
Protocol mappings <bcp14>MAY</bcp14> alter the interpretation of SvcParamKeys bu
t <bcp14>MUST NOT</bcp14>
alter their presentation or wire formats.</t> alter their presentation or wire formats.</t>
<section anchor="alpn-key"> <section anchor="alpn-key">
<name>"alpn" and "no-default-alpn"</name> <name>"alpn" and "no-default-alpn"</name>
<t>The "alpn" and "no-default-alpn" SvcParamKeys together <t>The "alpn" and "no-default-alpn" SvcParamKeys together
indicate the set of Application Layer Protocol Negotiation (ALPN) indicate the set of Application-Layer Protocol Negotiation (ALPN)
protocol identifiers <xref target="ALPN"/> protocol identifiers <xref target="RFC7301"/>
and associated transport protocols supported by this service endpoint (the and associated transport protocols supported by this service endpoint (the
"SVCB ALPN set").</t> "SVCB ALPN set").</t>
<t>As with Alt-Svc <xref target="AltSvc"/>, each ALPN protocol identifie r is used to <t>As with Alt-Svc <xref target="RFC7838"/>, each ALPN protocol identifi er is used to
identify the application protocol and associated suite identify the application protocol and associated suite
of protocols supported by the endpoint (the "protocol suite"). of protocols supported by the endpoint (the "protocol suite").
The presence of an ALPN protocol identifier in the SVCB ALPN set indicates that this The presence of an ALPN protocol identifier in the SVCB ALPN set indicates that this
service endpoint, described by TargetName and the other parameters (e.g. service endpoint, described by TargetName and the other parameters (e.g.,
"port") offers service with the protocol suite associated with this ALPN identif "port"), offers service with the protocol suite associated with this ALPN identi
ier.</t> fier.</t>
<t>Clients filter the set of ALPN identifiers to match the protocol suit es they <t>Clients filter the set of ALPN identifiers to match the protocol suit es they
support, and this informs the underlying transport protocol used (such support, and this informs the underlying transport protocol used (such
as QUIC-over-UDP or TLS-over-TCP). ALPN protocol identifiers that do not unique as QUIC over UDP or TLS over TCP). ALPN protocol identifiers that do not unique
ly ly
identify a protocol suite (e.g. an Identification Sequence that identify a protocol suite (e.g., an Identification Sequence that
can be used with both TLS and DTLS) are not compatible with this can be used with both TLS and DTLS) are not compatible with this
SvcParamKey and MUST NOT be included in the SVCB ALPN set.</t> SvcParamKey and <bcp14>MUST NOT</bcp14> be included in the SVCB ALPN set.</t>
<section anchor="representation"> <section anchor="representation">
<name>Representation</name> <name>Representation</name>
<t>ALPNs are identified by their registered "Identification Sequence" <t>ALPNs are identified by their registered "Identification Sequence"
(<tt>alpn-id</tt>), which is a sequence of 1-255 octets.</t> (<tt>alpn-id</tt>), which is a sequence of 1-255 octets.</t>
<artwork><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
alpn-id = 1*255OCTET alpn-id = 1*255OCTET
]]></artwork> ]]></sourcecode>
<t>For "alpn", the presentation <tt>value</tt> SHALL be <t>For "alpn", the presentation <tt>value</tt> <bcp14>SHALL</bcp14> be
a comma-separated list (<xref target="value-list"/>) a comma-separated list (<xref target="value-list"/>)
of one or more <tt>alpn-id</tt>s. Zone file implementations MAY disallow the of one or more <tt>alpn-id</tt>s. Zone-file implementations <bcp14>MAY</bcp14>
"," and "\" characters instead of implementing the <tt>value-list</tt> escaping disallow the
procedure, relying on the opaque key format (e.g. <tt>key1=\002h2</tt>) in the "," and "\" characters in ALPN IDs instead of implementing the <tt>value-list</t
t> escaping
procedure, relying on the opaque key format (e.g., <tt>key1=\002h2</tt>) in the
event that these characters are needed.</t> event that these characters are needed.</t>
<t>The wire format value for "alpn" consists of at least one <t>The wire-format value for "alpn" consists of at least one
<tt>alpn-id</tt> prefixed by its length as a single octet, and these length-valu e <tt>alpn-id</tt> prefixed by its length as a single octet, and these length-valu e
pairs are concatenated to form the SvcParamValue. These pairs MUST exactly pairs are concatenated to form the SvcParamValue. These pairs <bcp14>MUST</bcp1 4> exactly
fill the SvcParamValue; otherwise, the SvcParamValue is malformed.</t> fill the SvcParamValue; otherwise, the SvcParamValue is malformed.</t>
<t>For "no-default-alpn", the presentation and wire format values MUST be <t>For "no-default-alpn", the presentation and wire-format values <bcp 14>MUST</bcp14> be
empty. When "no-default-alpn" is specified in an RR, empty. When "no-default-alpn" is specified in an RR,
"alpn" must also be specified in order for the RR "alpn" must also be specified in order for the RR
to be "self-consistent" (<xref target="service-mode"/>).</t> to be "self-consistent" (<xref target="service-mode"/>).</t>
<t>Each scheme that uses this SvcParamKey defines a "default set" of A <t>Each scheme that uses this SvcParamKey defines a "default set" of A
LPNs LPN IDs
that are supported by nearly all clients and servers, which MAY that are supported by nearly all clients and servers; this set <bcp14>MAY</bcp14
>
be empty. To determine the SVCB ALPN set, the client starts with the list of be empty. To determine the SVCB ALPN set, the client starts with the list of
<tt>alpn-id</tt>s from the "alpn" SvcParamKey, and adds the default set unless t he <tt>alpn-id</tt>s from the "alpn" SvcParamKey, and it adds the default set unles s the
"no-default-alpn" SvcParamKey is present.</t> "no-default-alpn" SvcParamKey is present.</t>
</section> </section>
<section anchor="use"> <section anchor="use">
<name>Use</name> <name>Use</name>
<t>To establish a connection to the endpoint, clients MUST</t> <t>To establish a connection to the endpoint, clients <bcp14>MUST</bcp 14></t>
<ol spacing="normal" type="1"><li>Let SVCB-ALPN-Intersection be the se t of protocols in the SVCB ALPN set <ol spacing="normal" type="1"><li>Let SVCB-ALPN-Intersection be the se t of protocols in the SVCB ALPN set
that the client supports.</li> that the client supports.</li>
<li>Let Intersection-Transports be the set of transports (e.g. TLS, DTLS, QUIC) <li>Let Intersection-Transports be the set of transports (e.g., TLS, DTLS, QUIC)
implied by the protocols in SVCB-ALPN-Intersection.</li> implied by the protocols in SVCB-ALPN-Intersection.</li>
<li>For each transport in Intersection-Transports, construct a Proto colNameList <li>For each transport in Intersection-Transports, construct a Proto colNameList
containing the Identification Sequences of all the client's supported ALPN containing the Identification Sequences of all the client's supported ALPN
protocols for that transport, without regard to the SVCB ALPN set.</li> protocols for that transport, without regard to the SVCB ALPN set.</li>
</ol> </ol>
<t>For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the cl ient <t>For example, if the SVCB ALPN set is ["http/1.1", "h3"] and the cli ent
supports HTTP/1.1, HTTP/2, and HTTP/3, the client could attempt to connect using supports HTTP/1.1, HTTP/2, and HTTP/3, the client could attempt to connect using
TLS over TCP with a ProtocolNameList of ["http/1.1", "h2"], and could also TLS over TCP with a ProtocolNameList of ["http/1.1", "h2"] and could also
attempt a connection using QUIC, with a ProtocolNameList of ["h3"].</t> attempt a connection using QUIC with a ProtocolNameList of ["h3"].</t>
<t>Once the client has constructed a ClientHello, protocol negotiation in that <t>Once the client has constructed a ClientHello, protocol negotiation in that
handshake proceeds as specified in <xref target="ALPN"/>, without regard to the SVCB ALPN handshake proceeds as specified in <xref target="RFC7301"/>, without regard to t he SVCB ALPN
set.</t> set.</t>
<t>Clients MAY implement a fallback procedure, using a less-preferred transport <t>Clients <bcp14>MAY</bcp14> implement a fallback procedure, using a less-preferred transport
if more-preferred transports fail to connect. This fallback behavior is if more-preferred transports fail to connect. This fallback behavior is
vulnerable to manipulation by a network attacker who blocks the more-preferred vulnerable to manipulation by a network attacker who blocks the more-preferred
transports, but it may be necessary for compatibility with existing networks.</t > transports, but it may be necessary for compatibility with existing networks.</t >
<t>With this procedure in place, an attacker who can modify DNS and ne twork <t>With this procedure in place, an attacker who can modify DNS and ne twork
traffic can prevent a successful transport connection, but cannot otherwise traffic can prevent a successful transport connection but cannot otherwise
interfere with ALPN protocol selection. This procedure also ensures that interfere with ALPN protocol selection. This procedure also ensures that
each ProtocolNameList includes at least one protocol from the SVCB ALPN set.</t> each ProtocolNameList includes at least one protocol from the SVCB ALPN set.</t>
<t>Clients SHOULD NOT attempt connection to a service endpoint whose S VCB <t>Clients <bcp14>SHOULD NOT</bcp14> attempt connection to a service e ndpoint whose SVCB
ALPN set does not contain any supported protocols.</t> ALPN set does not contain any supported protocols.</t>
<t>To ensure <t>To ensure
consistency of behavior, clients MAY reject the entire SVCB RRSet and fall consistency of behavior, clients <bcp14>MAY</bcp14> reject the entire SVCB RRset and fall
back to basic connection establishment if all of the compatible RRs indicate back to basic connection establishment if all of the compatible RRs indicate
"no-default-alpn", even if connection could have succeeded using a "no-default-alpn", even if connection could have succeeded using a
non-default alpn.</t> non-default ALPN protocol.</t>
<t>Zone operators SHOULD ensure that at least one RR in each RRSet sup <t>Zone operators <bcp14>SHOULD</bcp14> ensure that at least one RR in
ports the each RRset supports the
default transports. This enables compatibility with the greatest number of default transports. This enables compatibility with the greatest number of
clients.</t> clients.</t>
</section> </section>
</section> </section>
<section anchor="svcparamkeys-port"> <section anchor="svcparamkeys-port">
<name>"port"</name> <name>"port"</name>
<t>The "port" SvcParamKey defines the TCP or UDP port <t>The "port" SvcParamKey defines the TCP or UDP port
that should be used to reach this alternative endpoint. that should be used to reach this alternative endpoint.
If this key is not present, clients SHALL use the authority endpoint's port If this key is not present, clients <bcp14>SHALL</bcp14> use the authority endpo int's port
number.</t> number.</t>
<t>The presentation <tt>value</tt> of the SvcParamValue is a single deci mal integer <t>The presentation <tt>value</tt> of the SvcParamValue is a single deci mal integer
between 0 and 65535 in ASCII. Any other <tt>value</tt> (e.g. an empty value) between 0 and 65535 in ASCII. Any other <tt>value</tt> (e.g., an empty value)
is a syntax error. To enable simpler parsing, this SvcParam MUST NOT contain is a syntax error. To enable simpler parsing, this SvcParamValue <bcp14>MUST NO
T</bcp14> contain
escape sequences.</t> escape sequences.</t>
<t>The wire format of the SvcParamValue <t>The wire format of the SvcParamValue
is the corresponding 2 octet numeric value in network byte order.</t> is the corresponding 2-octet numeric value in network byte order.</t>
<t>If a port-restricting firewall is in place between some client and th e service <t>If a port-restricting firewall is in place between some client and th e service
endpoint, changing the port number might cause that client to lose access to endpoint, changing the port number might cause that client to lose access to
the service, so operators should exercise caution when using this SvcParamKey the service, so operators should exercise caution when using this SvcParamKey
to specify a non-default port.</t> to specify a non-default port.</t>
</section> </section>
<section anchor="svcparamkeys-iphints"> <section anchor="svcparamkeys-iphints">
<name>"ipv4hint" and "ipv6hint"</name> <name>"ipv4hint" and "ipv6hint"</name>
<t>The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients M AY use to <t>The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients < bcp14>MAY</bcp14> use to
reach the service. If A and AAAA records for TargetName are locally reach the service. If A and AAAA records for TargetName are locally
available, the client SHOULD ignore these hints. Otherwise, clients available, the client <bcp14>SHOULD</bcp14> ignore these hints. Otherwise, clie
SHOULD perform A and/or AAAA queries for TargetName as in nts
<xref target="client-behavior"/>, and clients SHOULD use the IP address in those <bcp14>SHOULD</bcp14> perform A and/or AAAA queries for TargetName per
responses for future connections. Clients MAY opt to terminate any <xref target="client-behavior"/>, and clients <bcp14>SHOULD</bcp14> use the IP a
ddress in those
responses for future connections. Clients <bcp14>MAY</bcp14> opt to terminate an
y
connections using the addresses in hints and instead switch to the connections using the addresses in hints and instead switch to the
addresses in response to the TargetName query. Failure to use A and/or addresses in response to the TargetName query. Failure to use A and/or
AAAA response addresses could negatively impact load balancing or other AAAA response addresses could negatively impact load balancing or other
geo-aware features and thereby degrade client performance.</t> geo-aware features and thereby degrade client performance.</t>
<t>The presentation <tt>value</tt> SHALL be a comma-separated list (<xre f target="value-list"/>) <t>The presentation <tt>value</tt> <bcp14>SHALL</bcp14> be a comma-separ ated list (<xref target="value-list"/>)
of one or more IP addresses of the appropriate of one or more IP addresses of the appropriate
family in standard textual format <xref target="RFC5952"/><xref target="RFC4001" family in standard textual format <xref target="RFC5952"/> <xref target="RFC4001
/>. To enable simpler parsing, "/>. To enable simpler parsing,
this SvcParamValue MUST NOT contain escape sequences.</t> this SvcParamValue <bcp14>MUST NOT</bcp14> contain escape sequences.</t>
<t>The wire format for each parameter is a sequence of IP addresses in n etwork <t>The wire format for each parameter is a sequence of IP addresses in n etwork
byte order (for the respective address-family). byte order (for the respective address family).
Like an A or AAAA RRSet, the list of addresses represents an Like an A or AAAA RRset, the list of addresses represents an
unordered collection, and clients SHOULD pick addresses to use in a random order unordered collection, and clients <bcp14>SHOULD</bcp14> pick addresses to use in
. a random order.
An empty list of addresses is invalid.</t> An empty list of addresses is invalid.</t>
<t>When selecting between IPv4 and IPv6 addresses to use, clients may us e an <t>When selecting between IPv4 and IPv6 addresses to use, clients may us e an
approach such as Happy Eyeballs <xref target="HappyEyeballsV2"/>. approach such as Happy Eyeballs <xref target="RFC8305"/>.
When only "ipv4hint" is present, NAT64 clients may synthesize When only "ipv4hint" is present, NAT64 clients may synthesize
IPv6 addresses as specified in <xref target="RFC7050"/> or ignore the "ipv4hint" key and IPv6 addresses as specified in <xref target="RFC7050"/> or ignore the "ipv4hint" key and
wait for AAAA resolution (<xref target="client-behavior"/>). wait for AAAA resolution (<xref target="client-behavior"/>).
For best performance, server operators SHOULD include an "ipv6hint" parameter For best performance, server operators <bcp14>SHOULD</bcp14> include an "ipv6hin t" parameter
whenever they include an "ipv4hint" parameter.</t> whenever they include an "ipv4hint" parameter.</t>
<t>These parameters are intended to minimize additional connection laten cy <t>These parameters are intended to minimize additional connection laten cy
when a recursive resolver is not compliant with the requirements in when a recursive resolver is not compliant with the requirements in
<xref target="server-behavior"/>, and SHOULD NOT be included if most clients are <xref target="server-behavior"/> and <bcp14>SHOULD NOT</bcp14> be included if mo
using st clients are using
compliant recursive resolvers. When TargetName is the origin hostname compliant recursive resolvers. When TargetName is the service name
or the owner name (which can be written as "."), server operators or the owner name (which can be written as "."), server operators
SHOULD NOT include these hints, because they are unlikely to convey any <bcp14>SHOULD NOT</bcp14> include these hints, because they are unlikely to conv ey any
performance benefit.</t> performance benefit.</t>
</section> </section>
<section anchor="svcparamkey-mandatory"> <section anchor="svcparamkey-mandatory">
<name>"mandatory"</name> <name>"mandatory"</name>
<t>See <xref target="mandatory"/>.</t> <t>See <xref target="mandatory"/>.</t>
</section> </section>
</section> </section>
<section anchor="mandatory"> <section anchor="mandatory">
<name>ServiceMode RR compatibility and mandatory keys</name> <name>ServiceMode RR Compatibility and Mandatory Keys</name>
<t>In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will not <t>In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will not
function correctly for clients that ignore this SvcParamKey. Each SVCB function correctly for clients that ignore this SvcParamKey. Each SVCB
protocol mapping SHOULD specify a set of keys that are "automatically protocol mapping <bcp14>SHOULD</bcp14> specify a set of keys that are "automatic
mandatory", i.e. mandatory if they are present in an RR. The SvcParamKey ally
mandatory", i.e., mandatory if they are present in an RR. The SvcParamKey
"mandatory" is used to indicate any mandatory keys for this RR, in addition to "mandatory" is used to indicate any mandatory keys for this RR, in addition to
any automatically mandatory keys that are present.</t> any automatically mandatory keys that are present.</t>
<t>A ServiceMode RR is considered "compatible" by a client if the client <t>A ServiceMode RR is considered "compatible" by a client if the client
recognizes all the mandatory keys, and their values indicate that successful recognizes all the mandatory keys and their values indicate that successful
connection establishment is possible. If the SVCB RRSet contains connection establishment is possible. Incompatible RRs are ignored (see step 5
no compatible RRs, the client will generally act as if the RRSet is empty.</t> of the procedure defined in <xref target="client-behavior"/>).</t>
<t>The presentation <tt>value</tt> SHALL be a comma-separated list <t>The presentation <tt>value</tt> <bcp14>SHALL</bcp14> be a comma-separat
ed list
(<xref target="value-list"/>) of one or more valid (<xref target="value-list"/>) of one or more valid
SvcParamKeys, either by their registered name or in the unknown-key format SvcParamKeys, either by their registered name or in the unknown-key format
(<xref target="presentation"/>). Keys MAY appear in any order, but MUST NOT app (<xref target="presentation"/>). Keys <bcp14>MAY</bcp14> appear in any order bu
ear more t <bcp14>MUST NOT</bcp14> appear more
than once. For self-consistency (<xref target="service-mode"/>), listed keys MU than once. For self-consistency (<xref target="service-mode"/>), listed keys <b
ST also cp14>MUST</bcp14> also
appear in the SvcParams.</t> appear in the SvcParams.</t>
<t>To enable simpler parsing, this <t>To enable simpler parsing, this
SvcParamValue MUST NOT contain escape sequences.</t> SvcParamValue <bcp14>MUST NOT</bcp14> contain escape sequences.</t>
<t>For example, the following is a valid list of SvcParams:</t> <t>For example, the following is a valid list of SvcParams:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
ipv6hint=... key65333=ex1 key65444=ex2 mandatory=key65444,ipv6hint ipv6hint=... key65333=ex1 key65444=ex2 mandatory=key65444,ipv6hint
]]></artwork> ]]></sourcecode>
<t>In wire format, the keys are represented by their numeric values in <t>In wire format, the keys are represented by their numeric values in
network byte order, concatenated in strictly increasing numeric order.</t> network byte order, concatenated in strictly increasing numeric order.</t>
<t>This SvcParamKey is always automatically mandatory, and MUST NOT appear <t>This SvcParamKey is always automatically mandatory and <bcp14>MUST NOT<
in its /bcp14> appear in its
own value-list. Other automatically mandatory keys SHOULD NOT appear in the own value-list. Other automatically mandatory keys <bcp14>SHOULD NOT</bcp14> ap
pear in the
list either. (Including them wastes space and otherwise has no effect.)</t> list either. (Including them wastes space and otherwise has no effect.)</t>
</section> </section>
<section anchor="https"> <section anchor="https">
<name>Using Service Bindings with HTTP</name> <name>Using Service Bindings with HTTP</name>
<t>Use of any protocol with SVCB requires a protocol-specific mapping <t>The use of any protocol with SVCB requires a protocol-specific mapping
specification. This section specifies the mapping for the "http" and "https" specification. This section specifies the mapping for the "http" and "https"
URI schemes <xref target="HTTP"/>.</t> URI schemes <xref target="RFC9110"/>.</t>
<t>To enable special handling for HTTP use-cases, <t>To enable special handling for HTTP use cases,
the HTTPS RR type is defined as a SVCB-compatible RR type, the HTTPS RR type is defined as a SVCB-compatible RR type,
specific to the "https" and "http" schemes. Clients MUST NOT specific to the "https" and "http" schemes. Clients <bcp14>MUST NOT</bcp14>
perform SVCB queries or accept SVCB responses for "https" perform SVCB queries or accept SVCB responses for "https"
or "http" schemes.</t> or "http" schemes.</t>
<t>The presentation format of the record is:</t> <t>The presentation format of the record is:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
Name TTL IN HTTPS SvcPriority TargetName SvcParams Name TTL IN HTTPS SvcPriority TargetName SvcParams
]]></artwork> ]]></sourcecode>
<t>All the SvcParamKeys defined in <xref target="keys"/> are permitted for use in <t>All the SvcParamKeys defined in <xref target="keys"/> are permitted for use in
HTTPS RRs. The default set of ALPN IDs is the single value "http/1.1". HTTPS RRs. The default set of ALPN IDs is the single value "http/1.1".
The "automatically mandatory" keys (<xref target="mandatory"/>) are "port" The "automatically mandatory" keys (<xref target="mandatory"/>) are "port"
and "no-default-alpn". (As described in <xref target="mandatory"/>, clients mus t and "no-default-alpn". (As described in <xref target="mandatory"/>, clients mus t
either implement these keys or ignore any RR in which they appear.) either implement these keys or ignore any RR in which they appear.)
Clients that restrict the destination port in "https" URIs Clients that restrict the destination port in "https" URIs
(e.g. using the "bad ports" list from <xref target="FETCH"/>) SHOULD apply the (e.g., using the "bad ports" list from <xref target="FETCH"/>) <bcp14>SHOULD</bc p14> apply the
same restriction to the "port" SvcParam.</t> same restriction to the "port" SvcParam.</t>
<t>The presence of an HTTPS RR for an origin also indicates <t>The presence of an HTTPS RR for an origin also indicates
that clients should connect securely and use the "https" scheme, as that clients should connect securely and use the "https" scheme, as
discussed in <xref target="hsts"/>. This allows HTTPS RRs to apply to discussed in <xref target="hsts"/>. This allows HTTPS RRs to apply to
pre-existing "http" scheme URLs, while ensuring that the client uses a pre-existing "http" scheme URLs, while ensuring that the client uses a
secure and authenticated connection.</t> secure and authenticated connection.</t>
<t>The HTTPS RR parallels the concepts <t>The HTTPS RR parallels the concepts
introduced in the HTTP Alternative Services proposed standard introduced in "HTTP Alternative Services" <xref target="RFC7838"/>. Clients and
<xref target="AltSvc"/>. Clients and servers that implement HTTPS RRs are servers that implement HTTPS RRs are
not required to implement Alt-Svc.</t> not required to implement Alt-Svc.</t>
<section anchor="httpsnames"> <section anchor="httpsnames">
<name>Query names for HTTPS RRs</name> <name>Query Names for HTTPS RRs</name>
<t>The HTTPS RR uses Port Prefix Naming (<xref target="svcb-names"/>), <t>The HTTPS RR uses Port Prefix Naming (<xref target="svcb-names"/>),
with one modification: if the scheme is "https" and the port is 443, with one modification: if the scheme is "https" and the port is 443,
then the client's original QNAME is then the client's original QNAME is
equal to the service name (i.e. the origin's hostname), equal to the service name (i.e., the origin's hostname),
without any prefix labels.</t> without any prefix labels.</t>
<t>By removing the Attrleaf labels <xref target="Attrleaf"/> <t>By removing the Attrleaf labels <xref target="RFC8552"/>
used in SVCB, this construction enables offline DNSSEC signing of used in SVCB, this construction enables offline DNSSEC signing of
wildcard domains, which are commonly used with HTTP. Using the wildcard domains, which are commonly used with HTTP. Using the
service name as the owner name of the HTTPS record, without prefixes, service name as the owner name of the HTTPS record, without prefixes,
also allows the targets of existing CNAME chains also allows the targets of existing CNAME chains
(e.g. CDN hosts) to start returning HTTPS RR responses without (e.g., CDN hosts) to start returning HTTPS RR responses without
requiring origin domains to configure and maintain an additional requiring origin domains to configure and maintain an additional
delegation.</t> delegation.</t>
<t>Following of HTTPS AliasMode RRs and CNAME aliases is unchanged from SVCB.</t> <t>The procedure for following HTTPS AliasMode RRs and CNAME aliases is unchanged from SVCB (as described in Sections&nbsp;<xref target="alias-mode" for mat="counter"/> and <xref target="client-behavior" format="counter"/>).</t>
<t>Clients always convert "http" URLs to "https" before performing an <t>Clients always convert "http" URLs to "https" before performing an
HTTPS RR query using the process described in <xref target="hsts"/>, so domain o wners HTTPS RR query using the process described in <xref target="hsts"/>, so domain o wners
MUST NOT publish HTTPS RRs with a prefix of "_http".</t> <bcp14>MUST NOT</bcp14> publish HTTPS RRs with a prefix of "_http".</t>
<t>Note that none of these forms alter the HTTPS origin or authority. <t>Note that none of these forms alter the HTTPS origin or authority.
For example, clients MUST continue to validate TLS certificate For example, clients <bcp14>MUST</bcp14> continue to validate TLS certificate
hostnames based on the origin.</t> hostnames based on the origin.</t>
</section> </section>
<section anchor="comparison-with-alt-svc"> <section anchor="comparison-with-alt-svc">
<name>Comparison with Alt-Svc</name> <name>Comparison with Alt-Svc</name>
<t>Publishing a ServiceMode HTTPS RR in DNS is intended <t>Publishing a ServiceMode HTTPS RR in DNS is intended
to be similar to transmitting an Alt-Svc field value over to be similar to transmitting an Alt-Svc field value over
HTTP, and receiving an HTTPS RR is intended to be similar to HTTP, and receiving an HTTPS RR is intended to be similar to
receiving that field value over HTTP. However, there are some receiving that field value over HTTP. However, there are some
differences in the intended client and server behavior.</t> differences in the intended client and server behavior.</t>
<section anchor="alpn-usage"> <section anchor="alpn-usage">
<name>ALPN usage</name> <name>ALPN Usage</name>
<t>Unlike Alt-Svc Field Values, HTTPS RRs can contain multiple ALPN ID <t>Unlike Alt-Svc field values, HTTPS RRs can contain multiple ALPN ID
s. The s. The
meaning and use of these IDs is discussed in <xref target="use"/>.</t> meaning and use of these IDs are discussed in <xref target="use"/>.</t>
</section> </section>
<section anchor="untrusted-channel"> <section anchor="untrusted-channel">
<name>Untrusted channel</name> <name>Untrusted Channels</name>
<t>HTTPS records do not require or provide any assurance of authentici ty. (DNSSEC <t>HTTPS records do not require or provide any assurance of authentici ty. (DNSSEC
signing and verification, which would provide such assurance, are OPTIONAL.) signing and verification, which would provide such assurance, are <bcp14>OPTIONA L</bcp14>.)
The DNS resolution process is modeled as an untrusted channel that might be The DNS resolution process is modeled as an untrusted channel that might be
controlled by an attacker, so controlled by an attacker, so
Alt-Svc parameters that cannot be safely received in this model MUST NOT Alt-Svc parameters that cannot be safely received in this model <bcp14>MUST NOT< /bcp14>
have a corresponding defined SvcParamKey. For example, there is no have a corresponding defined SvcParamKey. For example, there is no
SvcParamKey corresponding to the Alt-Svc "persist" parameter, because SvcParamKey corresponding to the Alt-Svc "persist" parameter, because
this parameter is not safe to accept over an untrusted channel.</t> this parameter is not safe to accept over an untrusted channel.</t>
</section> </section>
<section anchor="cache-lifetime"> <section anchor="cache-lifetime">
<name>Cache lifetime</name> <name>Cache Lifetime</name>
<t>There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) parameter. <t>There is no SvcParamKey corresponding to the Alt-Svc "ma" (max age) parameter.
Instead, server operators encode the expiration time in the DNS TTL.</t> Instead, server operators encode the expiration time in the DNS TTL.</t>
<t>The appropriate TTL value might be different from the "ma" value <t>The appropriate TTL value might be different from the "ma" value
used for Alt-Svc, depending on the desired efficiency and used for Alt-Svc, depending on the desired efficiency and
agility. Some DNS caches incorrectly extend the lifetime of DNS agility. Some DNS caches incorrectly extend the lifetime of DNS
records beyond the stated TTL, so server operators cannot rely on records beyond the stated TTL, so server operators cannot rely on
HTTPS RRs expiring on time. Shortening the TTL to compensate HTTPS RRs expiring on time. Shortening the TTL to compensate
for incorrect caching is NOT RECOMMENDED, as this practice impairs the for incorrect caching is <bcp14>NOT RECOMMENDED</bcp14>, as this practice impair s the
performance of correctly functioning caches and does not guarantee performance of correctly functioning caches and does not guarantee
faster expiration from incorrect caches. Instead, server operators faster expiration from incorrect caches. Instead, server operators
SHOULD maintain compatibility with expired records until they observe <bcp14>SHOULD</bcp14> maintain compatibility with expired records until they obs erve
that nearly all connections have migrated to the new configuration.</t> that nearly all connections have migrated to the new configuration.</t>
</section> </section>
<section anchor="granularity"> <section anchor="granularity">
<name>Granularity</name> <name>Granularity</name>
<t>Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc <t>Sending Alt-Svc over HTTP allows the server to tailor the Alt-Svc
Field Value specifically to the client. When using an HTTPS RR, field value specifically to the client. When using an HTTPS RR,
groups of clients will necessarily receive the same SvcParams. groups of clients will necessarily receive the same SvcParams.
Therefore, HTTPS RRs are not suitable for uses that require Therefore, HTTPS RRs are not suitable for uses that require
single-client granularity.</t> single-client granularity.</t>
</section> </section>
</section> </section>
<section anchor="interaction-with-alt-svc"> <section anchor="interaction-with-alt-svc">
<name>Interaction with Alt-Svc</name> <name>Interaction with Alt-Svc</name>
<t>Clients that implement support for both Alt-Svc and HTTPS records and <t>Clients that implement support for both Alt-Svc and HTTPS records and
are making a connection based on a cached Alt-Svc response SHOULD are making a connection based on a cached Alt-Svc response <bcp14>SHOULD</bcp14>
retrieve any HTTPS records for the Alt-Svc alt-authority, and ensure that retrieve any HTTPS records for the Alt-Svc alt-authority and ensure that
their connection attempts are consistent with both the Alt-Svc parameters their connection attempts are consistent with both the Alt-Svc parameters
and any received HTTPS SvcParams. If present, the HTTPS record's TargetName and any received HTTPS SvcParams. If present, the HTTPS record's TargetName
and port are used for connection establishment (as in <xref target="client-behav ior"/>). and port are used for connection establishment (per <xref target="client-behavio r"/>).
For example, suppose that For example, suppose that
"https://example.com" sends an Alt-Svc field value of:</t> "https://example.com" sends an Alt-Svc field value of:</t>
<sourcecode type="HTTP"><![CDATA[ <sourcecode type="http-message"><![CDATA[
Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443" Alt-Svc: h2="alt.example:443", h2="alt2.example:443", h3=":8443"
]]></sourcecode> ]]></sourcecode>
<t>The client would retrieve the following HTTPS records:</t> <t>The client would retrieve the following HTTPS records:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
alt.example. IN HTTPS 1 . alpn=h2,h3 foo=... alt.example. IN HTTPS 1 . alpn=h2,h3 foo=...
alt2.example. IN HTTPS 1 alt2b.example. alpn=h3 foo=... alt2.example. IN HTTPS 1 alt2b.example. alpn=h3 foo=...
_8443._https.example.com. IN HTTPS 1 alt3.example. ( _8443._https.example.com. IN HTTPS 1 alt3.example. (
port=9443 alpn=h2,h3 foo=... ) port=9443 alpn=h2,h3 foo=... )
]]></artwork> ]]></sourcecode>
<t>Based on these inputs, the following connection attempts would always be <t>Based on these inputs, the following connection attempts would always be
allowed:</t> allowed:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>HTTP/2 to <tt>alt.example:443</tt></li> <li>HTTP/2 to <tt>alt.example:443</tt></li>
<li>HTTP/3 to <tt>alt3.example:9443</tt></li> <li>HTTP/3 to <tt>alt3.example:9443</tt></li>
<li>Fallback to the client's non-Alt-Svc connection behavior</li> <li>Fallback to the client's non-Alt-Svc connection behavior</li>
</ul> </ul>
<t>The following connection attempts would not be allowed:</t> <t>The following connection attempts would not be allowed:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>HTTP/3 to <tt>alt.example:443</tt> (not consistent with Alt-Svc)</ li> <li>HTTP/3 to <tt>alt.example:443</tt> (not consistent with Alt-Svc)</ li>
<li>Any connection to <tt>alt2b.example</tt> (no ALPN consistent with both the HTTPS <li>Any connection to <tt>alt2b.example</tt> (no ALPN ID consistent wi th both the HTTPS
record and Alt-Svc)</li> record and Alt-Svc)</li>
<li>HTTPS over TCP to any port on <tt>alt3.example</tt> (not consisten t with Alt-Svc)</li> <li>HTTPS over TCP to any port on <tt>alt3.example</tt> (not consisten t with Alt-Svc)</li>
</ul> </ul>
<t>Suppose that "foo" is a SvcParamKey that renders the client SVCB-reli ant. <t>Suppose that "foo" is a SvcParamKey that renders the client SVCB-reli ant.
The following Alt-Svc-only connection attempts would be allowed only if The following Alt-Svc-only connection attempts would be allowed only if
the client does not support "foo", as they rely on SVCB-optional fallback the client does not support "foo", as they rely on SVCB-optional fallback
behavior:</t> behavior:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>HTTP/2 to <tt>alt2.example:443</tt></li> <li>HTTP/2 to <tt>alt2.example:443</tt></li>
<li>HTTP/3 to <tt>example.com:8443</tt></li> <li>HTTP/3 to <tt>example.com:8443</tt></li>
</ul> </ul>
<t>Alt-authorities SHOULD carry the same SvcParams as the origin unless <t>Alt-authorities <bcp14>SHOULD</bcp14> carry the same SvcParams as the origin unless
a deviation is specifically known to be safe. a deviation is specifically known to be safe.
As noted in <xref section="2.4" sectionFormat="of" target="AltSvc"/>, clients MA As noted in <xref section="2.4" sectionFormat="of" target="RFC7838"/>, clients <
Y disallow any Alt-Svc bcp14>MAY</bcp14> disallow any Alt-Svc
connection according to their own criteria, e.g. disallowing Alt-Svc connection according to their own criteria, e.g., disallowing Alt-Svc
connections that lack support for privacy features that are available on connections that lack support for privacy features that are available on
the origin endpoint.</t> the authority endpoint.</t>
</section> </section>
<section anchor="requiring-server-name-indication"> <section anchor="requiring-server-name-indication">
<name>Requiring Server Name Indication</name> <name>Requiring Server Name Indication</name>
<t>Clients MUST NOT use an HTTPS RR response unless the <t>Clients <bcp14>MUST NOT</bcp14> use an HTTPS RR response unless the
client supports TLS Server Name Indication (SNI) and client supports the TLS Server Name Indication (SNI) extension and
indicates the origin name in the TLS ClientHello (which might be indicates the origin name in the TLS ClientHello (which might be
encrypted via a future specification such as ECH). encrypted via a future specification such as <xref target="I-D.ietf-tls-esni"/>) .
This supports the conservation of IP addresses.</t> This supports the conservation of IP addresses.</t>
<t>Note that the TLS SNI (and also the HTTP "Host" or ":authority") will indicate <t>Note that the TLS SNI (and also the HTTP "Host" or ":authority") will indicate
the origin, not the TargetName.</t> the origin, not the TargetName.</t>
</section> </section>
<section anchor="hsts"> <section anchor="hsts">
<name>HTTP Strict Transport Security</name> <name>HTTP Strict Transport Security (HSTS)</name>
<t>An HTTPS RR directs the client to communicate with this host only ove r a <t>An HTTPS RR directs the client to communicate with this host only ove r a
secure transport, similar to HTTP Strict Transport Security <xref target="HSTS"/ secure transport, similar to HSTS <xref target="RFC6797"/>.
>. Prior to making an "http" scheme request, the client <bcp14>SHOULD</bcp14> perfo
Prior to making an "http" scheme request, the client SHOULD perform a lookup rm a lookup
to determine if any HTTPS RRs exist for that origin. To do so, to determine if any HTTPS RRs exist for that origin. To do so,
the client SHOULD construct a corresponding "https" URL as follows:</t> the client <bcp14>SHOULD</bcp14> construct a corresponding "https" URL as follow s:</t>
<ol spacing="normal" type="1"><li>Replace the "http" scheme with "https" .</li> <ol spacing="normal" type="1"><li>Replace the "http" scheme with "https" .</li>
<li>If the "http" URL explicitly specifies port 80, specify port 443.< /li> <li>If the "http" URL explicitly specifies port 80, specify port 443.< /li>
<li>Do not alter any other aspect of the URL.</li> <li>Do not alter any other aspect of the URL.</li>
</ol> </ol>
<t>This construction is equivalent to <xref section="8.3" sectionFormat= <t>This construction is equivalent to <xref section="8.3" sectionFormat=
"of" target="HSTS"/>, point 5.</t> "of" target="RFC6797"/>, Step 5.</t>
<t>If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS <t>If an HTTPS RR query for this "https" URL returns any AliasMode HTTPS
RRs, RRs
or any compatible ServiceMode HTTPS RRs (see <xref target="mandatory"/>), the cl ient or any compatible ServiceMode HTTPS RRs (see <xref target="mandatory"/>), the cl ient
SHOULD behave as if it has received an HTTP 307 (Temporary Redirect) status code <bcp14>SHOULD</bcp14> behave as if it has received an HTTP 307 (Temporary Redire ct) status code
with this "https" URL in the "Location" field. (Receipt of an incompatible Serv iceMode RR does not with this "https" URL in the "Location" field. (Receipt of an incompatible Serv iceMode RR does not
trigger the redirect behavior.) trigger the redirect behavior.)
Because HTTPS RRs are received over an often-insecure channel (DNS), Because HTTPS RRs are received over an often-insecure channel (DNS),
clients MUST NOT place any more trust in this signal than if they clients <bcp14>MUST NOT</bcp14> place any more trust in this signal than if they
had received a 307 (Temporary Redirect) response over cleartext HTTP.</t> had received a 307 (Temporary Redirect) response over cleartext HTTP.</t>
<t>Publishing an HTTPS RR has the potential to have unexpected results <t>Publishing an HTTPS RR can potentially lead to unexpected results
or a loss in functionality in cases where the "http" resource neither or a loss in functionality in cases where the "http" resource neither
redirects to the "https" resource nor references the same underlying resource.</ t> redirects to the "https" resource nor references the same underlying resource.</ t>
<t>When an "https" connection fails due to an error in the underlying se cure <t>When an "https" connection fails due to an error in the underlying se cure
transport, such as an error in certificate validation, some clients transport, such as an error in certificate validation, some clients
currently offer a "user recourse" that allows the user to bypass the currently offer a "user recourse" that allows the user to bypass the
security error and connect anyway. security error and connect anyway.
When making an "https" scheme request to an origin with an HTTPS RR, When making an "https" scheme request to an origin with an HTTPS RR,
either directly or via the above redirect, such a client MAY remove the user either directly or via the above redirect, such a client <bcp14>MAY</bcp14> remo
recourse option. Origins that publish HTTPS RRs therefore MUST NOT rely ve the user
on user recourse for access. For more information, see Section <xref target="HS recourse option. Origins that publish HTTPS RRs therefore <bcp14>MUST NOT</bcp1
TS" section="8.4" sectionFormat="bare"/> and Section <xref target="HSTS" section 4> rely
="12.1" sectionFormat="bare"/> of <xref target="HSTS"/>.</t> on user recourse for access. For more information, see Sections <xref target="R
FC6797" section="8.4" sectionFormat="bare"/> and <xref target="RFC6797" section=
"12.1" sectionFormat="bare"/> of <xref target="RFC6797"/>.</t>
</section> </section>
<section anchor="use-of-https-rrs-in-other-protocols"> <section anchor="use-of-https-rrs-in-other-protocols">
<name>Use of HTTPS RRs in other protocols</name> <name>Use of HTTPS RRs in Other Protocols</name>
<t>All HTTP connections to named origins are eligible to use HTTPS RRs, even <t>All HTTP connections to named origins are eligible to use HTTPS RRs, even
when HTTP is used as part of another protocol or without an explicit HTTP when HTTP is used as part of another protocol or without an explicit HTTP-relate
URL. For example, clients that d URI
support HTTPS RRs and implement the altered WebSocket <xref target="WebSocket"/> scheme (<relref target="RFC9110" section="4.2"/>). For example, clients that
opening handshake from the W3C Fetch specification <xref target="FETCH"/> SHOULD support HTTPS RRs and implement <xref target="RFC6455"/> using the altered
use HTTPS RRs opening handshake from <xref target="FETCH-WEBSOCKETS"/> <bcp14>SHOULD</bcp14> u
se HTTPS RRs
for the <tt>requestURL</tt>.</t> for the <tt>requestURL</tt>.</t>
<t>When HTTP is used in a context where URLs or redirects are not applic able <t>When HTTP is used in a context where URLs or redirects are not applic able
(e.g. connections to an HTTP proxy), clients that find a corresponding HTTPS RR (e.g., connections to an HTTP proxy), clients that find a corresponding HTTPS RR
SHOULD implement a security upgrade behavior equivalent to the one specified in <bcp14>SHOULD</bcp14> implement security upgrade behavior equivalent to that
specified in
<xref target="hsts"/>.</t> <xref target="hsts"/>.</t>
<t>Such protocols MAY define their own SVCB mappings, which MAY <t>Such protocols <bcp14>MAY</bcp14> define their own SVCB mappings, whi ch <bcp14>MAY</bcp14>
be defined to take precedence over HTTPS RRs.</t> be defined to take precedence over HTTPS RRs.</t>
</section> </section>
</section> </section>
<section anchor="zone-structures"> <section anchor="zone-structures">
<name>Zone Structures</name> <name>Zone Structures</name>
<section anchor="structuring-zones-for-flexibility"> <section anchor="structuring-zones-for-flexibility">
<name>Structuring zones for flexibility</name> <name>Structuring Zones for Flexibility</name>
<t>Each ServiceMode RRSet can only serve a single scheme. The scheme is <t>Each ServiceMode RRset can only serve a single scheme. The scheme is
indicated indicated
by the owner name and the RR type. For the generic SVCB RR type, this means tha t by the owner name and the RR type. For the generic SVCB RR type, this means tha t
each owner name can only be used for a single scheme. The underscore prefixing each owner name can only be used for a single scheme. The underscore prefixing
requirement (<xref target="svcb-names"/>) ensures that this is true for the init ial query, requirement (<xref target="svcb-names"/>) ensures that this is true for the init ial query,
but it is the responsibility of zone owners to choose names that satisfy this but it is the responsibility of zone owners to choose names that satisfy this
constraint when using aliases, including CNAME and AliasMode records.</t> constraint when using aliases, including CNAME and AliasMode records.</t>
<t>When using the generic SVCB RR type with aliasing, zone owners SHOULD <t>When using the generic SVCB RR type with aliasing, zone owners <bcp14
choose alias >SHOULD</bcp14> choose alias
target names that indicate the scheme in use (e.g. <tt>foosvc.example.net</tt> f target names that indicate the scheme in use (e.g., "foosvc.example.net" for
or "foo" schemes). This will help to avoid confusion when another scheme needs to
<tt>foo://</tt> schemes). This will help to avoid confusion when another scheme
needs to
be added to the configuration. When multiple port numbers are in use, it may be be added to the configuration. When multiple port numbers are in use, it may be
helpful to repeat the prefix labels in the alias target name (e.g. helpful to repeat the prefix labels in the alias target name (e.g.,
<tt>_1234._foo.svc.example.net</tt>).</t> "_1234._foo.svc.example.net").</t>
</section> </section>
<section anchor="zone-performance"> <section anchor="zone-performance">
<name>Structuring zones for performance</name> <name>Structuring Zones for Performance</name>
<t>To avoid a delay for clients using a nonconforming recursive resolver <t>To avoid a delay for clients using a non-conforming recursive resolve
, r,
domain owners SHOULD minimize the use of AliasMode records, and SHOULD domain owners <bcp14>SHOULD</bcp14> minimize the use of AliasMode records and <b
cp14>SHOULD</bcp14>
choose TargetName according to a predictable convention that is known choose TargetName according to a predictable convention that is known
to the client, so that clients can issue A and/or AAAA queries for TargetName to the client, so that clients can issue A and/or AAAA queries for TargetName
in advance (see <xref target="optimizations"/>). Unless otherwise specified, th e in advance (see <xref target="optimizations"/>). Unless otherwise specified, th e
convention is to set TargetName to the service name for an initial convention is to set TargetName to the service name for an initial
ServiceMode record, or to "." if it is reached via an alias.</t> ServiceMode record, or to "." if it is reached via an alias.</t>
<figure> <figure>
<name>foo://foo.example.com:8080 is delegated to foosvc.example.net, b <name>"foo://foo.example.com:8080" Is Available at "foosvc.example.net
ut bar://bar.example.com:9090 is served locally.</name> ", but "bar://bar.example.com:9090" Is Served Locally</name>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
$ORIGIN example.com. ; Origin $ORIGIN example.com. ; Origin
foo 3600 IN CNAME foosvc.example.net. foo 3600 IN CNAME foosvc.example.net.
_8080._foo.foo 3600 IN CNAME foosvc.example.net. _8080._foo.foo 3600 IN CNAME foosvc.example.net.
bar 300 IN AAAA 2001:db8::2 bar 300 IN AAAA 2001:db8::2
_9090._bar.bar 3600 IN SVCB 1 bar key65444=... _9090._bar.bar 3600 IN SVCB 1 bar key65444=...
$ORIGIN example.net. ; Service provider zone $ORIGIN example.net. ; Service provider zone
foosvc 3600 IN SVCB 1 . key65333=... foosvc 3600 IN SVCB 1 . key65333=...
foosvc 300 IN AAAA 2001:db8::1 foosvc 300 IN AAAA 2001:db8::1
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>Domain owners SHOULD avoid using a TargetName that is below a DNAME, as <t>Domain owners <bcp14>SHOULD</bcp14> avoid using a TargetName that is below a DNAME, as
this is likely unnecessary and makes responses slower and larger. this is likely unnecessary and makes responses slower and larger.
Also, zone structures that require following more than 8 aliases Also, zone structures that require following more than eight aliases
(counting both AliasMode and CNAME records) are NOT RECOMMENDED.</t> (counting both AliasMode and CNAME records) are <bcp14>NOT RECOMMENDED</bcp14>.<
/t>
</section> </section>
<section anchor="operational-considerations"> <section anchor="operational-considerations">
<name>Operational considerations</name> <name>Operational Considerations</name>
<t>Note that some implementations may not allow A or AAAA records on nam <t>Some authoritative DNS servers may not allow A or AAAA records on nam
es es
starting with an underscore due to various interpretations of RFCs. starting with an underscore (e.g., <xref target="BIND-CHECK-NAMES"/>).
This could be an operational issue when the TargetName contains an attrleaf labe This could create an operational issue when the TargetName contains an Attrleaf
l, label,
as well as using an TargetName of "." when the owner name contains an attrleaf l or when using a TargetName of "." if the owner name contains an Attrleaf label.<
abel.</t> /t>
</section> </section>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<section anchor="protocol-enhancements"> <section anchor="protocol-enhancements">
<name>Protocol enhancements</name> <name>Protocol Enhancements</name>
<t>Consider a simple zone of the form:</t> <t>Consider a simple zone of the form:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
$ORIGIN simple.example. ; Simple example zone $ORIGIN simple.example. ; Simple example zone
@ 300 IN A 192.0.2.1 @ 300 IN A 192.0.2.1
AAAA 2001:db8::1 AAAA 2001:db8::1
]]></artwork> ]]></sourcecode>
<t>The domain owner could add this record:</t> <t>The domain owner could add this record:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
@ 7200 IN HTTPS 1 . alpn=h3 @ 7200 IN HTTPS 1 . alpn=h3
]]></artwork> ]]></sourcecode>
<t>to indicate that https://simple.example supports QUIC <t>This record would indicate that "https://simple.example" supports Q
UIC
in addition to HTTP/1.1 over TLS over TCP (the implicit default). in addition to HTTP/1.1 over TLS over TCP (the implicit default).
The record could also include other information (e.g. non-standard port). The record could also include other information (e.g., a non-standard port).
For https://simple.example:8443, the record would be:</t> For "https://simple.example:8443", the record would be:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
_8443._https 7200 IN HTTPS 1 . alpn=h3 _8443._https 7200 IN HTTPS 1 . alpn=h3
]]></artwork> ]]></sourcecode>
<t>These records also respectively tell clients to replace the scheme with "https" when <t>These records also respectively tell clients to replace the scheme with "https" when
loading http://simple.example or http://simple.example:8443.</t> loading "http://simple.example" or "http://simple.example:8443".</t>
</section> </section>
<section anchor="apex-aliasing"> <section anchor="apex-aliasing">
<name>Apex aliasing</name> <name>Apex Aliasing</name>
<t>Consider a zone that is using CNAME aliasing:</t> <t>Consider a zone that is using CNAME aliasing:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
$ORIGIN aliased.example. ; A zone that is using a hosting service $ORIGIN aliased.example. ; A zone that is using a hosting service
; Subdomain aliased to a high-performance server pool ; Subdomain aliased to a high-performance server pool
www 7200 IN CNAME pool.svc.example. www 7200 IN CNAME pool.svc.example.
; Apex domain on fixed IPs because CNAME is not allowed at the apex ; Apex domain on fixed IPs because CNAME is not allowed at the apex
@ 300 IN A 192.0.2.1 @ 300 IN A 192.0.2.1
IN AAAA 2001:db8::1 IN AAAA 2001:db8::1
]]></artwork> ]]></sourcecode>
<t>With HTTPS RRs, the owner of aliased.example could alias the apex b y <t>With HTTPS RRs, the owner of aliased.example could alias the apex b y
adding one additional record:</t> adding one additional record:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
@ 7200 IN HTTPS 0 pool.svc.example. @ 7200 IN HTTPS 0 pool.svc.example.
]]></artwork> ]]></sourcecode>
<t>With this record in place, HTTPS-RR-aware clients will use the same <t>With this record in place, HTTPS-RR-aware clients will use the same
server pool for aliased.example and www.aliased.example. (They will server pool for aliased.example and www.aliased.example. (They will
also upgrade "http://aliased.example/..." to "https".) Non-HTTPS-RR-aware also upgrade "http://aliased.example/..." to "https".) Non-HTTPS-RR-aware
clients will just ignore the new record.</t> clients will just ignore the new record.</t>
<t>Similar to CNAME, HTTPS RRs have no impact on the origin name. <t>Similar to CNAME, HTTPS RRs have no impact on the origin name.
When connecting, clients will continue to treat the authoritative When connecting, clients will continue to treat the authoritative
origins as "https://www.aliased.example" and "https://aliased.example", origins as "https://www.aliased.example" and "https://aliased.example",
respectively, and will validate TLS server certificates accordingly.</t> respectively, and will validate TLS server certificates accordingly.</t>
</section> </section>
<section anchor="parameter-binding"> <section anchor="parameter-binding">
<name>Parameter binding</name> <name>Parameter Binding</name>
<t>Suppose that svc.example's primary server pool supports HTTP/3, but <t>Suppose that svc.example's primary server pool supports HTTP/3 but
its its
backup server pool does not. This can be expressed in the following form:</t> backup server pool does not. This can be expressed in the following form:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
$ORIGIN svc.example. ; A hosting provider. $ORIGIN svc.example. ; A hosting provider
pool 7200 IN HTTPS 1 . alpn=h2,h3 pool 7200 IN HTTPS 1 . alpn=h2,h3
HTTPS 2 backup alpn=h2 port=8443 HTTPS 2 backup alpn=h2 port=8443
pool 300 IN A 192.0.2.2 pool 300 IN A 192.0.2.2
AAAA 2001:db8::2 AAAA 2001:db8::2
backup 300 IN A 192.0.2.3 backup 300 IN A 192.0.2.3
AAAA 2001:db8::3 AAAA 2001:db8::3
]]></artwork> ]]></sourcecode>
<t>This configuration is entirely compatible with the "Apex aliasing" <t>This configuration is entirely compatible with the "apex aliasing"
example, example,
whether the client supports HTTPS RRs or not. If the client does support whether the client supports HTTPS RRs or not. If the client does support
HTTPS RRs, all connections will be upgraded to HTTPS, and clients will HTTPS RRs, all connections will be upgraded to HTTPS, and clients will
use HTTP/3 if they can. Parameters are "bound" to each server pool, so use HTTP/3 if they can. Parameters are "bound" to each server pool, so
each server pool can have its own protocol, port number, etc.</t> each server pool can have its own protocol, port number, etc.</t>
</section> </section>
<section anchor="multicdn"> <section anchor="multicdn">
<name>Multi-CDN</name> <name>Multi-CDN Configuration</name>
<t>The HTTPS RR is intended to support HTTPS services operated by <t>The HTTPS RR is intended to support HTTPS services operated by
multiple independent entities, such as different Content Delivery multiple independent entities, such as different CDNs or different hosting provi
Networks (CDNs) or different hosting providers. This includes ders. This includes
the case where a service is migrated from one operator to another, the case where a service is migrated from one operator to another,
as well as the case where the service is multiplexed between as well as the case where the service is multiplexed between
multiple operators for performance, redundancy, etc.</t> multiple operators for performance, redundancy, etc.</t>
<t>This example shows such a configuration, with www.customer.example <t>This example shows such a configuration, with www.customer.example
having different DNS responses to different queries, either over time having different DNS responses to different queries, either over time
or due to logic within the authoritative DNS server:</t> or due to logic within the authoritative DNS server:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
; This zone contains/returns different CNAME records ; This zone contains/returns different CNAME records
; at different points-in-time. The RRset for "www" can ; at different points in time. The RRset for "www" can
; only ever contain a single CNAME. ; only ever contain a single CNAME.
; Sometimes the zone has: ; Sometimes the zone has:
$ORIGIN customer.example. ; A Multi-CDN customer domain $ORIGIN customer.example. ; A multi-CDN customer domain
www 900 IN CNAME cdn1.svc1.example. www 900 IN CNAME cdn1.svc1.example.
; and other times it contains: ; and other times it contains:
$ORIGIN customer.example. $ORIGIN customer.example.
www 900 IN CNAME customer.svc2.example. www 900 IN CNAME customer.svc2.example.
; and yet other times it contains: ; and yet other times it contains:
$ORIGIN customer.example. $ORIGIN customer.example.
www 900 IN CNAME cdn3.svc3.example. www 900 IN CNAME cdn3.svc3.example.
; With the following remaining constant and always included: ; With the following remaining constant and always included:
$ORIGIN customer.example. ; A Multi-CDN customer domain $ORIGIN customer.example. ; A multi-CDN customer domain
; The apex is also aliased to www to match its configuration ; The apex is also aliased to www to match its configuration.
@ 7200 IN HTTPS 0 www @ 7200 IN HTTPS 0 www
; Non-HTTPS-aware clients use non-CDN IPs ; Non-HTTPS-aware clients use non-CDN IPs.
A 203.0.113.82 A 203.0.113.82
AAAA 2001:db8:203::2 AAAA 2001:db8:203::2
; Resolutions following the cdn1.svc1.example ; Resolutions following the cdn1.svc1.example
; path use these records. ; path use these records.
; This CDN uses a different alternative service for HTTP/3. ; This CDN uses a different alternative service for HTTP/3.
$ORIGIN svc1.example. ; domain for CDN 1 $ORIGIN svc1.example. ; domain for CDN 1
cdn1 1800 IN HTTPS 1 h3pool alpn=h3 cdn1 1800 IN HTTPS 1 h3pool alpn=h3
HTTPS 2 . alpn=h2 HTTPS 2 . alpn=h2
A 192.0.2.2 A 192.0.2.2
skipping to change at line 1322 skipping to change at line 1337
A 198.51.100.4 A 198.51.100.4
AAAA 2001:db8:198::7 AAAA 2001:db8:198::7
AAAA 2001:db8:198::12 AAAA 2001:db8:198::12
; Resolutions following the cdn3.svc3.example ; Resolutions following the cdn3.svc3.example
; path use these records. ; path use these records.
; Note that this CDN has no HTTPS records. ; Note that this CDN has no HTTPS records.
$ORIGIN svc3.example. ; domain operated by CDN 3 $ORIGIN svc3.example. ; domain operated by CDN 3
cdn3 60 IN A 203.0.113.8 cdn3 60 IN A 203.0.113.8
AAAA 2001:db8:113::8 AAAA 2001:db8:113::8
]]></artwork> ]]></sourcecode>
<t>Note that in the above example, the different CDNs have different <t>Note that in the above example, the different CDNs have different
configurations and different capabilities, but clients will use HTTPS RRs configurations and different capabilities, but clients will use HTTPS RRs
as a bound-together unit.</t> as a bound-together unit.</t>
<t>Domain owners should be cautious when using a multi-CDN configurati on, as it <t>Domain owners should be cautious when using a multi-CDN configurati on, as it
introduces a number of complexities highlighted by this example:</t> introduces a number of complexities highlighted by this example:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If CDN 1 supports a desired protocol or feature, and CDN 2 does not, the <li>If CDN 1 supports a desired protocol or feature and CDN 2 does n ot, the
client is vulnerable to client is vulnerable to
downgrade by a network adversary who forces clients to get CDN 2 records.</li> downgrade by a network adversary who forces clients to get CDN 2 records.</li>
<li>Aliasing the apex to its subdomain simplifies the zone file but likely <li>Aliasing the apex to its subdomain simplifies the zone file but likely
increases resolution latency, especially when using a non-HTTPS-aware increases resolution latency, especially when using a non-HTTPS-aware
recursive resolver. An alternative would be to alias the zone recursive resolver. An alternative would be to alias the zone
apex directly to a name managed by a CDN.</li> apex directly to a name managed by a CDN.</li>
<li>The A, AAAA, and HTTPS resolutions are independent lookups, so r esolvers may <li>The A, AAAA, and HTTPS resolutions are independent lookups, so r esolvers may
observe and follow different CNAMEs to different CDNs. observe and follow different CNAMEs to different CDNs.
Clients may thus find that the A and AAAA responses do not correspond to the Clients may thus find that the A and AAAA responses do not correspond to the
TargetName in the HTTPS response, and will need to perform additional TargetName in the HTTPS response; these clients will need to perform additional
queries to retrieve the correct IP addresses. queries to retrieve the correct IP addresses.
Including ipv6hint and ipv4hint will reduce the performance Including ipv6hint and ipv4hint will reduce the performance
impact of this case.</li> impact of this case.</li>
<li>If not all CDNs publish HTTPS records, clients will sometimes <li>If not all CDNs publish HTTPS records, clients will sometimes
receive NODATA for HTTPS queries (as with cdn3.svc3.example above), receive NODATA for HTTPS queries (as with cdn3.svc3.example above)
but could receive A/AAAA records from a different CDN. Clients will but could receive A/AAAA records from a different CDN. Clients will
attempt to connect to this CDN without the benefit of its HTTPS attempt to connect to this CDN without the benefit of its HTTPS
records.</li> records.</li>
</ul> </ul>
</section> </section>
<section anchor="non-http-uses"> <section anchor="non-http-uses">
<name>Non-HTTP uses</name> <name>Non-HTTP Uses</name>
<t>For protocols other than HTTP, the SVCB RR and an Attrleaf label <x <t>For protocols other than HTTP, the SVCB RR and an Attrleaf label <x
ref target="Attrleaf"/> ref target="RFC8552"/>
will be used. For example, to reach an example resource of will be used. For example, to reach an example resource of
"baz://api.example.com:8765", the following SVCB "baz://api.example.com:8765", the following SVCB
record would be used to alias it to "svc4-baz.example.net." record would be used to alias it to "svc4-baz.example.net.",
which in-turn could return AAAA/A records and/or SVCB which in turn could return AAAA/A records and/or SVCB
records in ServiceMode:</t> records in ServiceMode:</t>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
_8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net.
]]></artwork> ]]></sourcecode>
<t>HTTPS RRs use similar Attrleaf labels if the origin contains <t>HTTPS RRs use similar Attrleaf labels if the origin contains
a non-default port.</t> a non-default port.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="other-standards"> <section anchor="other-standards">
<name>Interaction with other standards</name> <name>Interaction with Other Standards</name>
<t>This standard is intended to reduce connection latency and <t>This standard is intended to reduce connection latency and
improve user privacy. Server operators implementing this standard improve user privacy. Server operators implementing this standard
SHOULD also implement TLS 1.3 <xref target="RFC8446"/> and OCSP Stapling <bcp14>SHOULD</bcp14> also implement TLS 1.3 <xref target="RFC8446"/> and
<xref target="RFC6066"/>, both of which confer substantial performance and priva Online Certificate Status Protocol (OCSP) Stapling (i.e., Certificate Status
cy Request in <xref target="RFC6066" section="8" sectionFormat="of"/>),
both of which confer substantial performance and privacy
benefits when used in combination with SVCB records.</t> benefits when used in combination with SVCB records.</t>
<t>To realize the greatest privacy benefits, this proposal is intended for <t>To realize the greatest privacy benefits, this proposal is intended for
use over a privacy-preserving DNS transport (like DNS over TLS use over a privacy-preserving DNS transport (like DNS over TLS
<xref target="DoT"/> or DNS over HTTPS <xref target="DoH"/>). <xref target="RFC7858"/> or DNS over HTTPS <xref target="RFC8484"/>).
However, performance improvements, and some modest privacy improvements, However, performance improvements, and some modest privacy improvements,
are possible without the use of those standards.</t> are possible without the use of those standards.</t>
<t>Any specification for use of SVCB with a protocol MUST have an entry fo <t>Any specification for the use of SVCB with a protocol <bcp14>MUST</bcp1
r its 4> have an entry for its
scheme under the SVCB RR type in the IANA DNS Underscore Global Scoped Entry scheme under the SVCB RR type in the IANA DNS "Underscored and Globally Scoped D
Registry <xref target="Attrleaf"/>. The scheme MUST have an entry in the IANA U NS Node Names" registry <xref target="RFC8552"/>. The scheme <bcp14>MUST</bcp14
RI Schemes > have an entry in the "Uniform Resource Identifier (URI) Schemes" registry <xre
Registry <xref target="RFC7595"/>, and MUST have a defined specification for use f target="RFC7595"/> and <bcp14>MUST</bcp14> have a defined specification for us
e
with SVCB.</t> with SVCB.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>SVCB/HTTPS RRs permit distribution over untrusted <t>SVCB/HTTPS RRs permit distribution over untrusted
channels, and clients are REQUIRED to verify that the alternative endpoint channels, and clients are <bcp14>REQUIRED</bcp14> to verify that the alternative
is authoritative for the service (similar to <xref section="2.1" sectionFormat=" endpoint
of" target="AltSvc"/>). is authoritative for the service (similar to <xref section="2.1" sectionFormat="
Therefore, DNSSEC signing and validation are OPTIONAL for publishing of" target="RFC7838"/>).
Therefore, DNSSEC signing and validation are <bcp14>OPTIONAL</bcp14> for publish
ing
and using SVCB and HTTPS RRs.</t> and using SVCB and HTTPS RRs.</t>
<t>Clients MUST ensure that their DNS cache is partitioned for each local <t>Clients <bcp14>MUST</bcp14> ensure that their DNS cache is partitioned for each local
network, or flushed on network changes, to prevent a local adversary in one network, or flushed on network changes, to prevent a local adversary in one
network from implanting a forged DNS record that allows them to network from implanting a forged DNS record that allows them to
track users or hinder their connections after they leave that network.</t> track users or hinder their connections after they leave that network.</t>
<t>An attacker who can prevent SVCB resolution can deny clients any associ ated <t>An attacker who can prevent SVCB resolution can deny clients any associ ated
security benefits. A hostile recursive resolver can always deny service to security benefits. A hostile recursive resolver can always deny service to
SVCB queries, but network intermediaries can often prevent resolution as well, SVCB queries, but network intermediaries can often prevent resolution as well,
even when the client and recursive resolver validate DNSSEC and use a secure even when the client and recursive resolver validate DNSSEC and use a secure
transport. These downgrade attacks can prevent the "https" upgrade provided by transport. These downgrade attacks can prevent the "https" upgrade provided by
the HTTPS RR (<xref target="hsts"/>), and disable any other protections coordina ted via the HTTPS RR (<xref target="hsts"/>) and can disable any other protections coord inated via
SvcParams. To prevent downgrades, <xref target="client-failures"/> SvcParams. To prevent downgrades, <xref target="client-failures"/>
recommends that clients abandon the connection attempt when such an attack is recommends that clients abandon the connection attempt when such an attack is
detected.</t> detected.</t>
<t>A hostile DNS intermediary might forge AliasMode "." records (<xref tar get="aliasdot"/>) as <t>A hostile DNS intermediary might forge AliasMode "." records (<xref tar get="aliasdot"/>) as
a way to block clients from accessing particular services. Such an adversary a way to block clients from accessing particular services. Such an adversary
could already block entire domains by forging erroneous responses, but this could already block entire domains by forging erroneous responses, but this
mechanism allows them to target particular protocols or ports within a domain. mechanism allows them to target particular protocols or ports within a domain.
Clients that might be subject to such attacks SHOULD ignore AliasMode "." Clients that might be subject to such attacks <bcp14>SHOULD</bcp14> ignore Alias Mode "."
records.</t> records.</t>
<t>A hostile DNS intermediary or origin can return SVCB records indicating any IP <t>A hostile DNS intermediary or authoritative server can return SVCB reco rds indicating any IP
address and port number, including IP addresses inside the local network and address and port number, including IP addresses inside the local network and
port numbers assigned to internal services. If the attacker can influence the port numbers assigned to internal services. If the attacker can influence the
client's payload (e.g. TLS session ticket contents), and an internal service client's payload (e.g., TLS session ticket contents) and an internal service
has a sufficiently lax parser, it's possible that the attacker could gain has a sufficiently lax parser, the attacker could gain access to the
unintended access. (The same concerns apply to SRV records, HTTP Alt-Svc, internal service. (The same concerns apply to SRV records, HTTP Alt-Svc,
and HTTP redirects.) As a mitigation, SVCB mapping documents SHOULD indicate and HTTP redirects.) As a mitigation, SVCB mapping documents <bcp14>SHOULD</bcp
14> indicate
any port number restrictions that are appropriate for the supported transports.< /t> any port number restrictions that are appropriate for the supported transports.< /t>
</section> </section>
<section anchor="privacy-considerations"> <section anchor="privacy-considerations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>Standard address queries reveal the user's intent to access a particula r <t>Standard address queries reveal the user's intent to access a particula r
domain. This information is visible to the recursive resolver, and to domain. This information is visible to the recursive resolver, and to
many other parties when plaintext DNS transport is used. SVCB queries, many other parties when plaintext DNS transport is used. SVCB queries,
like queries for SRV records and other specific RR types, additionally like queries for SRV records and other specific RR types, additionally
reveal the user's intent to use a particular protocol. This is not reveal the user's intent to use a particular protocol. This is not
normally sensitive information, but it should be considered when adding normally sensitive information, but it should be considered when adding
SVCB support in a new context.</t> SVCB support in a new context.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section anchor="svcb-rrtype"> <section anchor="svcb-rrtype">
<name>SVCB RRType</name> <name>SVCB RR Type</name>
<t>This document defines a new DNS RR type, SVCB, whose value 64 has
been allocated by IANA from the "Resource Record (RR) TYPEs" <t>IANA has registered the following new DNS RR type in the "Resource Re
cord (RR) TYPEs"
registry on the "Domain Name System (DNS) Parameters" page:</t> registry on the "Domain Name System (DNS) Parameters" page:</t>
<ul spacing="normal"> <dl spacing="compact">
<li>Type: SVCB</li> <dt>Type:</dt><dd>SVCB</dd>
<li>Value: 64</li> <dt>Value:</dt><dd>64</dd>
<li>Meaning: General Purpose Service Binding</li> <dt>Meaning:</dt><dd>General-purpose service binding</dd>
<li>Reference: This document</li> <dt>Reference:</dt><dd>RFC 9460</dd>
</ul> </dl>
</section> </section>
<section anchor="https-rrtype"> <section anchor="https-rrtype">
<name>HTTPS RRType</name> <name>HTTPS RR Type</name>
<t>This document defines a new DNS RR type, "HTTPS", whose value 65 has
been allocated by IANA from the "Resource Record (RR) TYPEs" <t>IANA has registered the following new DNS RR type
registry on the "Domain Name System (DNS) Parameters" page:</t> in the "Resource Record (RR) TYPEs" registry
<ul spacing="normal"> on the "Domain Name System (DNS) Parameters" page:</t>
<li>Type: HTTPS</li>
<li>Value: 65</li> <dl spacing="compact">
<li>Meaning: Service Binding type for use with HTTP</li> <dt>Type:</dt><dd>HTTPS</dd>
<li>Reference: This document</li> <dt>Value:</dt><dd>65</dd>
</ul> <dt>Meaning:</dt><dd>SVCB-compatible type for use with HTTP</dd>
<dt>Reference:</dt><dd>RFC 9460</dd>
</dl>
</section> </section>
<section anchor="svcparamregistry"> <section anchor="svcparamregistry">
<name>New registry for Service Parameters</name> <name>New Registry for Service Parameters</name>
<t>IANA is requested to create a new registry, entitled <t>IANA has created the "Service Parameter Keys (SvcParamKeys)"
"Service Parameter Keys (SvcParamKeys)". This registry defines the namespace registry in the "Domain Name System (DNS) Parameters" category
on a new page entitled "DNS Service Bindings (SVCB)". This registry
defines the namespace
for parameters, including string representations and numeric for parameters, including string representations and numeric
SvcParamKey values. This registry is shared with other SVCB-compatible SvcParamKey values. This registry is shared with other SVCB-compatible
RR types, such as the HTTPS RR.</t> RR types, such as the HTTPS RR.</t>
<t>ACTION: create this registry, on a new page entitled
"DNS Service Bindings (SVCB)" under the "Domain Name System (DNS) Parameters"
category.</t>
<section anchor="procedure"> <section anchor="procedure">
<name>Procedure</name> <name>Procedure</name>
<t>A registration MUST include the following fields:</t> <t>A registration <bcp14>MUST</bcp14> include the following fields:</t
<ul spacing="normal"> >
<li>Number: wire format numeric identifier (range 0-65535)</li> <dl spacing="compact">
<li>Name: unique presentation name</li> <dt>Number:</dt><dd>Wire-format numeric identifier (range 0-65535)</
<li>Meaning: a short description</li> dd>
<li>Format Reference: pointer to specification text</li> <dt>Name:</dt><dd>Unique presentation name</dd>
<li>Change Controller: Person or entity, with contact information if <dt>Meaning:</dt><dd>A short description</dd>
appropriate.</li> <dt>Reference:</dt><dd>Location of specification or registration sou
</ul> rce</dd>
<t>The characters in the registered Name MUST be lower-case alphanumer <dt>Change Controller:</dt><dd>Person or entity, with contact inform
ic or "-" ation if appropriate</dd>
(<xref target="presentation"/>). The name MUST NOT start with "key" or "invalid </dl>
".</t> <t>The characters in the registered Name field entry <bcp14>MUST</bcp1
<t>New entries in this registry are subject to an Expert Review regist 4> be lowercase alphanumeric or "-"
ration (<xref target="presentation"/>). The name <bcp14>MUST NOT</bcp14> start with "k
policy (<xref section="4.5" sectionFormat="comma" target="RFC8126"/>). The desi ey" or "invalid".</t>
gnated expert MUST ensure that <t>The registration policy for new entries is Expert Review (<xref sec
the Format Reference is stable and publicly available, and that it specifies tion="4.5" sectionFormat="comma" target="RFC8126"/>). The designated expert <bc
p14>MUST</bcp14> ensure that
the reference is stable and publicly available and that it specifies
how to convert the SvcParamValue's presentation format to wire format. The how to convert the SvcParamValue's presentation format to wire format. The
Format Reference MAY be any individual's Internet-Draft, or a document from reference <bcp14>MAY</bcp14> be any individual's Internet-Draft or a document fr om
any other source with similar assurances of stability and availability. any other source with similar assurances of stability and availability.
An entry MAY specify a Format Reference of An entry <bcp14>MAY</bcp14> specify a reference of
the form "Same as (other key Name)" if it uses the same presentation and wire the form "Same as (other key name)" if it uses the same presentation and wire
formats as an existing key.</t> formats as an existing key.
</t>
<t>This arrangement supports the development of new parameters while e nsuring that <t>This arrangement supports the development of new parameters while e nsuring that
zone files can be made interoperable.</t> zone files can be made interoperable.</t>
</section> </section>
<section anchor="iana-keys"> <section anchor="iana-keys">
<name>Initial contents</name> <name>Initial Contents</name>
<t>The "Service Binding (SVCB) Parameter Registry" shall initially <t>The "Service Parameter Keys (SvcParamKeys)" registry has been
be populated with the registrations below:</t> populated with the following initial registrations:</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">Reference</th>
<th align="left">Change Controller</th> <th align="left">Change Controller</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">mandatory</td> <td align="left">mandatory</td>
<td align="left">Mandatory keys in this RR</td> <td align="left">Mandatory keys in this RR</td>
<td align="left">(This document) <xref target="mandatory"/></td> <td align="left">RFC 9460, <xref target="mandatory"/></td>
<td align="left">IETF</td> <td align="left">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">alpn</td> <td align="left">alpn</td>
<td align="left">Additional supported protocols</td> <td align="left">Additional supported protocols</td>
<td align="left">(This document) <xref target="alpn-key"/></td> <td align="left">RFC 9460, <xref target="alpn-key"/></td>
<td align="left">IETF</td> <td align="left">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">2</td> <td align="left">2</td>
<td align="left">no-default-alpn</td> <td align="left">no-default-alpn</td>
<td align="left">No support for default protocol</td> <td align="left">No support for default protocol</td>
<td align="left">(This document) <xref target="alpn-key"/></td> <td align="left">RFC 9460, <xref target="alpn-key"/></td>
<td align="left">IETF</td> <td align="left">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">3</td> <td align="left">3</td>
<td align="left">port</td> <td align="left">port</td>
<td align="left">Port for alternative endpoint</td> <td align="left">Port for alternative endpoint</td>
<td align="left">(This document) <xref target="svcparamkeys-port "/></td> <td align="left">RFC 9460, <xref target="svcparamkeys-port"/></t d>
<td align="left">IETF</td> <td align="left">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">4</td> <td align="left">4</td>
<td align="left">ipv4hint</td> <td align="left">ipv4hint</td>
<td align="left">IPv4 address hints</td> <td align="left">IPv4 address hints</td>
<td align="left">(This document) <xref target="svcparamkeys-iphi nts"/></td> <td align="left">RFC 9460, <xref target="svcparamkeys-iphints"/> </td>
<td align="left">IETF</td> <td align="left">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">5</td> <td align="left">5</td>
<td align="left">ech</td> <td align="left">ech</td>
<td align="left">RESERVED (will be used for ECH)</td> <td align="left">RESERVED (held for Encrypted ClientHello)</td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">IETF</td> <td align="left">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">6</td> <td align="left">6</td>
<td align="left">ipv6hint</td> <td align="left">ipv6hint</td>
<td align="left">IPv6 address hints</td> <td align="left">IPv6 address hints</td>
<td align="left">(This document) <xref target="svcparamkeys-iphi nts"/></td> <td align="left">RFC 9460, <xref target="svcparamkeys-iphints"/> </td>
<td align="left">IETF</td> <td align="left">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">65280-65534</td> <td align="left">65280-65534</td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">Private Use</td> <td align="left">Reserved for Private Use</td>
<td align="left">(This document)</td> <td align="left">RFC 9460</td>
<td align="left">IETF</td> <td align="left">IETF</td>
</tr> </tr>
<tr> <tr>
<td align="left">65535</td> <td align="left">65535</td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">Reserved ("Invalid key")</td> <td align="left">Reserved ("Invalid key")</td>
<td align="left">(This document)</td> <td align="left">RFC 9460</td>
<td align="left">IETF</td> <td align="left">IETF</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="other-registry-updates"> <section anchor="other-registry-updates">
<name>Other registry updates</name> <name>Other Registry Updates</name>
<t>Per <xref target="Attrleaf"/>, please add the following entry to the <t>Per <xref target="RFC8552"/>, the following entry has been added to t
DNS Underscore he DNS "Underscored and Globally Scoped DNS Node Names" registry:</t>
Global Scoped Entry 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">Meaning</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">HTTPS</td> <td align="left">HTTPS</td>
<td align="left">_https</td> <td align="left">_https</td>
<td align="left">HTTPS SVCB info</td> <td align="left">RFC 9460</td>
<td align="left">(This document)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</section> </section>
<section anchor="acknowledgments-and-related-proposals">
<name>Acknowledgments and Related Proposals</name>
<t>There have been a wide range of proposed solutions over the years to
the "CNAME at the Zone Apex" challenge proposed. These include
<xref target="I-D.bellis-dnsop-http-record"/>,
<xref target="I-D.ietf-dnsop-aname"/>, and others.</t>
<t>Thank you to Ian Swett, Ralf Weber, Jon Reed,
Martin Thomson, Lucas Pardue, Ilari Liusvaara,
Tim Wicinski, Tommy Pauly, Chris Wood, David Benjamin,
Mark Andrews, Emily Stark, Eric Orth, Kyle Rose,
Craig Taylor, Dan McArdle, Brian Dickson,
Willem Toorop, Pieter Lexis, Puneet Sood,
Olivier Poitrey, Mashooq Muhaimen,
Tom Carpay, and many others for their feedback
and suggestions on this draft.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC8552" to="Attrleaf"/>
<displayreference target="RFC8305" to="HappyEyeballsV2"/>
<displayreference target="RFC7858" to="DoT"/>
<displayreference target="RFC8484" to="DoH"/>
<displayreference target="RFC7301" to="ALPN"/>
<displayreference target="RFC6455" to="WebSocket"/>
<displayreference target="I-D.ietf-tls-esni" to="ECH"/>
<displayreference target="RFC9114" to="HTTP/3"/>
<displayreference target="RFC2782" to="SRV"/>
<displayreference target="RFC6797" to="HSTS"/>
<displayreference target="RFC7838" to="AltSvc"/>
<displayreference target="RFC8499" to="DNSTerm"/>
<displayreference target="RFC3986" to="URI"/>
<displayreference target="RFC6672" to="DNAME"/>
<displayreference target="I-D.bellis-dnsop-http-record" to="HTTP-DNS-RR"/>
<displayreference target="I-D.ietf-dnsop-aname" to="ANAME-DNS-RR"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="HTTP">
<front>
<title>HTTP Semantics</title>
<author fullname="Roy T. Fielding" initials="R. T." surname="Fieldin
g">
<organization>Adobe</organization>
</author>
<author fullname="Mark Nottingham" initials="M." surname="Nottingham
">
<organization>Fastly</organization>
</author>
<author fullname="Julian Reschke" initials="J." surname="Reschke">
<organization>greenbytes GmbH</organization>
</author>
<date day="12" month="September" year="2021"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
on-level protocol for distributed, collaborative, hypertext information systems.
This document describes the overall architecture of HTTP, establishes common te
rminology, and defines aspects of the protocol that are shared by all versions.
In this definition are core protocol elements, extensibility mechanisms, and the
"http" and "https" Uniform Resource Identifier (URI) schemes.
This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, <!-- draft-ietf-httpbis-semantics (RFC 9110) -->
7538, 7615, 7694, and portions of 7230. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"
</t> />
</abstract>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml"
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantics- />
19"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
</reference> />
<reference anchor="Attrleaf"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
<front> />
<title>Scoped Interpretation of DNS Resource Records through "Unders <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"
cored" Naming of Attribute Leaves</title> />
<author fullname="D. Crocker" initials="D." surname="Crocker"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
<organization/> />
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"
<date month="March" year="2019"/> />
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"
<t>Formally, any DNS Resource Record (RR) may occur under any doma />
in name. However, some services use an operational convention for defining spec <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"
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 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"
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 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7231.xml"
construct defines a semantic scope for DNS record types that are associated with />
the parent domain above the underscored branch. This specification explores th <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1928.xml"
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 collisi <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3597.xml"
ons resulting from the use of the same underscored name for different services.< />
/t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3225.xml"
<seriesInfo name="BCP" value="222"/> />
<seriesInfo name="RFC" value="8552"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml"
<seriesInfo name="DOI" value="10.17487/RFC8552"/> />
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7871.xml"
<reference anchor="RFC2119"> />
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"
<title>Key words for use in RFCs to Indicate Requirement Levels</tit />
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5952.xml"
<author fullname="S. Bradner" initials="S." surname="Bradner"> />
<organization/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4001.xml"
</author> />
<date month="March" year="1997"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7050.xml"
<abstract> />
<t>In many standards track documents several words are used to sig <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6455.xml"
nify the requirements in the specification. These words are often capitalized. />
This document defines these words as they should be interpreted in IETF document <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"
s. This document specifies an Internet Best Current Practices for the Internet />
Community, and requests discussion and suggestions for improvements.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7595.xml"
<seriesInfo name="BCP" value="14"/> />
<seriesInfo name="RFC" value="2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
<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">
<organization/>
</author>
<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 tha
t 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
">
<organization/>
</author>
<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. T
his 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="RFC5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author fullname="D. Crocker" initials="D." role="editor" surname="C
rocker">
<organization/>
</author>
<author fullname="P. Overell" initials="P." surname="Overell">
<organization/>
</author>
<date month="January" year="2008"/>
<abstract>
<t>Internet technical specifications often need to define a formal
syntax. Over the years, a modified version of Backus-Naur Form (BNF), called A
ugmented BNF (ABNF), has been popular among many Internet specifications. The c
urrent specification documents ABNF. It balances compactness and simplicity with
reasonable representational power. The differences between standard BNF and AB
NF involve naming rules, repetition, alternatives, order-independence, and value
ranges. This specification also supplies additional rule definitions and encod
ing for a core lexical analyzer of the type common to several Internet specifica
tions. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC1034">
<front>
<title>Domain names - concepts and facilities</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetris
">
<organization/>
</author>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised basic definition of The Domain Name Sys
tem. It obsoletes RFC-882. This memo describes the domain style names and thei
r used for host address look up and electronic mail forwarding. It discusses th
e clients and servers in the domain name system and the protocol used between th
em.</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1034"/>
<seriesInfo name="DOI" value="10.17487/RFC1034"/>
</reference>
<reference anchor="HappyEyeballsV2">
<front>
<title>Happy Eyeballs Version 2: Better Connectivity Using Concurren
cy</title>
<author fullname="D. Schinazi" initials="D." surname="Schinazi">
<organization/>
</author>
<author fullname="T. Pauly" initials="T." surname="Pauly">
<organization/>
</author>
<date month="December" year="2017"/>
<abstract>
<t>Many communication protocols operating over the modern Internet
use hostnames. These often resolve to multiple IP addresses, each of which may
have different performance and connectivity characteristics. Since specific ad
dresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optima
l on a network, clients that attempt multiple connections in parallel have a cha
nce of establishing a connection more quickly. This document specifies requirem
ents for algorithms that reduce this user-visible delay and provides an example
algorithm, referred to as "Happy Eyeballs". This document obsoletes the origina
l algorithm description in RFC 6555.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8305"/>
<seriesInfo name="DOI" value="10.17487/RFC8305"/>
</reference>
<reference anchor="DoT">
<front>
<title>Specification for DNS over Transport Layer Security (TLS)</ti
tle>
<author fullname="Z. Hu" initials="Z." surname="Hu">
<organization/>
</author>
<author fullname="L. Zhu" initials="L." surname="Zhu">
<organization/>
</author>
<author fullname="J. Heidemann" initials="J." surname="Heidemann">
<organization/>
</author>
<author fullname="A. Mankin" initials="A." surname="Mankin">
<organization/>
</author>
<author fullname="D. Wessels" initials="D." surname="Wessels">
<organization/>
</author>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author>
<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 opportunit
ies for eavesdropping and on-path tampering with DNS queries in the network, suc
h as discussed in RFC 7626. In addition, this document specifies two usage prof
iles for DNS over TLS and provides advice on performance considerations to minim
ize 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 applic
ations 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="DoH">
<front>
<title>DNS Queries over HTTPS (DoH)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author>
<author fullname="P. McManus" initials="P." surname="McManus">
<organization/>
</author>
<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="RFC7231">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="
Fielding">
<organization/>
</author>
<author fullname="J. Reschke" initials="J." role="editor" surname="R
eschke">
<organization/>
</author>
<date month="June" year="2014"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless \%applica
tion- level protocol for distributed, collaborative, hypertext information syste
ms. This document defines the semantics of HTTP/1.1 messages, as expressed by r
equest methods, request header fields, response status codes, and response heade
r fields, along with the payload of messages (metadata and body content) and mec
hanisms for content negotiation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7231"/>
<seriesInfo name="DOI" value="10.17487/RFC7231"/>
</reference>
<reference anchor="RFC1928">
<front>
<title>SOCKS Protocol Version 5</title>
<author fullname="M. Leech" initials="M." surname="Leech">
<organization/>
</author>
<author fullname="M. Ganis" initials="M." surname="Ganis">
<organization/>
</author>
<author fullname="Y. Lee" initials="Y." surname="Lee">
<organization/>
</author>
<author fullname="R. Kuris" initials="R." surname="Kuris">
<organization/>
</author>
<author fullname="D. Koblas" initials="D." surname="Koblas">
<organization/>
</author>
<author fullname="L. Jones" initials="L." surname="Jones">
<organization/>
</author>
<date month="March" year="1996"/>
<abstract>
<t>This memo describes a protocol that is an evolution of the prev
ious version of the protocol, version 4 [1]. This new protocol stems from active
discussions and prototype implementations. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1928"/>
<seriesInfo name="DOI" value="10.17487/RFC1928"/>
</reference>
<reference anchor="RFC3597">
<front>
<title>Handling of Unknown DNS Resource Record (RR) Types</title>
<author fullname="A. Gustafsson" initials="A." surname="Gustafsson">
<organization/>
</author>
<date month="September" year="2003"/>
<abstract>
<t>Extending the Domain Name System (DNS) with new Resource Record
(RR) types currently requires changes to name server software. This document s
pecifies the changes necessary to allow future DNS implementations to handle new
RR types transparently. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3597"/>
<seriesInfo name="DOI" value="10.17487/RFC3597"/>
</reference>
<reference anchor="RFC6147">
<front>
<title>DNS64: DNS Extensions for Network Address Translation from IP
v6 Clients to IPv4 Servers</title>
<author fullname="M. Bagnulo" initials="M." surname="Bagnulo">
<organization/>
</author>
<author fullname="A. Sullivan" initials="A." surname="Sullivan">
<organization/>
</author>
<author fullname="P. Matthews" initials="P." surname="Matthews">
<organization/>
</author>
<author fullname="I. van Beijnum" initials="I." surname="van Beijnum
">
<organization/>
</author>
<date month="April" year="2011"/>
<abstract>
<t>DNS64 is a mechanism for synthesizing AAAA records from A recor
ds. DNS64 is used with an IPv6/IPv4 translator to enable client-server communica
tion between an IPv6-only client and an IPv4-only server, without requiring any
changes to either the IPv6 or the IPv4 node, for the class of applications that
work through NATs. This document specifies DNS64, and provides suggestions on h
ow it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6147"/>
<seriesInfo name="DOI" value="10.17487/RFC6147"/>
</reference>
<reference anchor="RFC3225">
<front>
<title>Indicating Resolver Support of DNSSEC</title>
<author fullname="D. Conrad" initials="D." surname="Conrad">
<organization/>
</author>
<date month="December" year="2001"/>
<abstract>
<t>In order to deploy DNSSEC (Domain Name System Security Extensio
ns) operationally, DNSSEC aware servers should only perform automatic inclusion
of DNSSEC RRs when there is an explicit indication that the resolver can underst
and those RRs. This document proposes the use of a bit in the EDNS0 header to p
rovide that explicit indication and describes the necessary protocol changes to
implement that notification. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3225"/>
<seriesInfo name="DOI" value="10.17487/RFC3225"/>
</reference>
<reference anchor="RFC2181">
<front>
<title>Clarifications to the DNS Specification</title>
<author fullname="R. Elz" initials="R." surname="Elz">
<organization/>
</author>
<author fullname="R. Bush" initials="R." surname="Bush">
<organization/>
</author>
<date month="July" year="1997"/>
<abstract>
<t>This document considers some areas that have been identified as
problems with the specification of the Domain Name System, and proposes remedie
s for the defects identified. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2181"/>
<seriesInfo name="DOI" value="10.17487/RFC2181"/>
</reference>
<reference anchor="RFC7871">
<front>
<title>Client Subnet in DNS Queries</title>
<author fullname="C. Contavalli" initials="C." surname="Contavalli">
<organization/>
</author>
<author fullname="W. van der Gaast" initials="W." surname="van der G
aast">
<organization/>
</author>
<author fullname="D. Lawrence" initials="D." surname="Lawrence">
<organization/>
</author>
<author fullname="W. Kumari" initials="W." surname="Kumari">
<organization/>
</author>
<date month="May" year="2016"/>
<abstract>
<t>This document describes an Extension Mechanisms for DNS (EDNS0)
option that is in active use to carry information about the network that origin
ated a DNS query and the network for which the subsequent response can be cached
. Since it has some known operational and privacy shortcomings, a revision will
be worked through the IETF for improvement.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7871"/>
<seriesInfo name="DOI" value="10.17487/RFC7871"/>
</reference>
<reference anchor="ALPN">
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Neg
otiation Extension</title>
<author fullname="S. Friedl" initials="S." surname="Friedl">
<organization/>
</author>
<author fullname="A. Popov" initials="A." surname="Popov">
<organization/>
</author>
<author fullname="A. Langley" initials="A." surname="Langley">
<organization/>
</author>
<author fullname="E. Stephan" initials="E." surname="Stephan">
<organization/>
</author>
<date month="July" year="2014"/>
<abstract>
<t>This document describes a Transport Layer Security (TLS) extens
ion for application-layer protocol negotiation within the TLS handshake. For ins
tances in which multiple application protocols are supported on the same TCP or
UDP port, this extension allows the application layer to negotiate which protoco
l will be used within the TLS connection.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7301"/>
<seriesInfo name="DOI" value="10.17487/RFC7301"/>
</reference>
<reference anchor="RFC5952">
<front>
<title>A Recommendation for IPv6 Address Text Representation</title>
<author fullname="S. Kawamura" initials="S." surname="Kawamura">
<organization/>
</author>
<author fullname="M. Kawashima" initials="M." surname="Kawashima">
<organization/>
</author>
<date month="August" year="2010"/>
<abstract>
<t>As IPv6 deployment increases, there will be a dramatic increase
in the need to use IPv6 addresses in text. While the IPv6 address architecture
in Section 2.2 of RFC 4291 describes a flexible model for text representation o
f an IPv6 address, this flexibility has been causing problems for operators, sys
tem engineers, and users. This document defines a canonical textual representat
ion format. It does not define a format for internal storage, such as within an
application or database. It is expected that the canonical format will be foll
owed by humans and systems when representing IPv6 addresses as text, but all imp
lementations must accept and be able to handle any legitimate RFC 4291 format.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5952"/>
<seriesInfo name="DOI" value="10.17487/RFC5952"/>
</reference>
<reference anchor="RFC4001">
<front>
<title>Textual Conventions for Internet Network Addresses</title>
<author fullname="M. Daniele" initials="M." surname="Daniele">
<organization/>
</author>
<author fullname="B. Haberman" initials="B." surname="Haberman">
<organization/>
</author>
<author fullname="S. Routhier" initials="S." surname="Routhier">
<organization/>
</author>
<author fullname="J. Schoenwaelder" initials="J." surname="Schoenwae
lder">
<organization/>
</author>
<date month="February" year="2005"/>
<abstract>
<t>This MIB module defines textual conventions to represent common
ly used Internet network layer addressing information. The intent is that these
textual conventions will be imported and used in MIB modules that would otherwi
se define their own representations. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4001"/>
<seriesInfo name="DOI" value="10.17487/RFC4001"/>
</reference>
<reference anchor="RFC7050">
<front>
<title>Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis<
/title>
<author fullname="T. Savolainen" initials="T." surname="Savolainen">
<organization/>
</author>
<author fullname="J. Korhonen" initials="J." surname="Korhonen">
<organization/>
</author>
<author fullname="D. Wing" initials="D." surname="Wing">
<organization/>
</author>
<date month="November" year="2013"/>
<abstract>
<t>This document describes a method for detecting the presence of
DNS64 and for learning the IPv6 prefix used for protocol translation on an acces
s network. The method depends on the existence of a well-known IPv4-only fully
qualified domain name "ipv4only.arpa.". The information learned enables nodes t
o perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-st
ack and multi-interface deployments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7050"/>
<seriesInfo name="DOI" value="10.17487/RFC7050"/>
</reference>
<reference anchor="WebSocket">
<front>
<title>The WebSocket Protocol</title>
<author fullname="I. Fette" initials="I." surname="Fette">
<organization/>
</author>
<author fullname="A. Melnikov" initials="A." surname="Melnikov">
<organization/>
</author>
<date month="December" year="2011"/>
<abstract>
<t>The WebSocket Protocol enables two-way communication between a
client running untrusted code in a controlled environment to a remote host that
has opted-in to communications from that code. The security model used for this
is the origin-based security model commonly used by web browsers. The protocol
consists of an opening handshake followed by basic message framing, layered ove
r TCP. The goal of this technology is to provide a mechanism for browser-based
applications that need two-way communication with servers that does not rely on
opening multiple HTTP connections (e.g., using XMLHttpRequest or &lt;iframe&gt;s
and long polling). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6455"/>
<seriesInfo name="DOI" value="10.17487/RFC6455"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over
the Internet in a way that is designed to prevent eavesdropping, tampering, and
message forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 i
mplementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC6066">
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definiti
ons</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd">
<organization/>
</author>
<date month="January" year="2011"/>
<abstract>
<t>This document provides specifications for existing TLS extensio
ns. It is a companion document for RFC 5246, "The Transport Layer Security (TLS
) Protocol Version 1.2". The extensions specified are server_name, max_fragment
_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_req
uest. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6066"/>
<seriesInfo name="DOI" value="10.17487/RFC6066"/>
</reference>
<reference anchor="RFC7595">
<front>
<title>Guidelines and Registration Procedures for URI Schemes</title
>
<author fullname="D. Thaler" initials="D." role="editor" surname="Th
aler">
<organization/>
</author>
<author fullname="T. Hansen" initials="T." surname="Hansen">
<organization/>
</author>
<author fullname="T. Hardie" initials="T." surname="Hardie">
<organization/>
</author>
<date month="June" year="2015"/>
<abstract>
<t>This document updates the guidelines and recommendations, as we
ll as the IANA registration processes, for the definition of Uniform Resource Id
entifier (URI) schemes. It obsoletes RFC 4395.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="35"/>
<seriesInfo name="RFC" value="7595"/>
<seriesInfo name="DOI" value="10.17487/RFC7595"/>
</reference>
<reference anchor="RFC8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton">
<organization/>
</author>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/>
</author>
<author fullname="T. Narten" initials="T." surname="Narten">
<organization/>
</author>
<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 th
ese fields do not have conflicting uses and to promote interoperability, their a
llocations 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 documen
t defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Considerati
ons is clear and addresses the various issues that are likely in the operation o
f 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> <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="2020" month="May"/> <date year="2023" month="October"/>
</front> </front>
</reference> </reference>
<reference anchor="ECH">
<front>
<title>TLS Encrypted Client Hello</title>
<author fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>RTFM, Inc.</organization>
</author>
<author fullname="Kazuho Oku" initials="K." surname="Oku">
<organization>Fastly</organization>
</author>
<author fullname="Nick Sullivan" initials="N." surname="Sullivan">
<organization>Cloudflare</organization>
</author>
<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
d">
<organization>Cloudflare</organization>
</author>
<date day="3" month="October" year="2022"/>
<abstract>
<t> This document describes a mechanism in Transport Layer Secur
ity (TLS)
for encrypting a ClientHello message under a server public key.
Discussion Venues <reference anchor="FETCH-WEBSOCKETS" target="https://websockets.spec.wha
twg.org/">
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/tlswg/draft-ietf-tls-esni
(https://github.com/tlswg/draft-ietf-tls-esni).
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-15"/>
</reference>
<reference anchor="HTTP3">
<front>
<title>HTTP/3</title>
<author fullname="Mike Bishop" initials="M." surname="Bishop">
<organization>Akamai</organization>
</author>
<date day="2" month="February" year="2021"/>
<abstract>
<t>The QUIC transport protocol has several features that are desir
able in a transport for HTTP, such as stream multiplexing, per-stream flow contr
ol, and low-latency connection establishment. This document describes a mapping
of HTTP semantics over QUIC. This document also identifies HTTP/2 features tha
t are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP
/3.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
</reference>
<reference anchor="SRV">
<front>
<title>A DNS RR for specifying the location of services (DNS SRV)</t
itle>
<author fullname="A. Gulbrandsen" initials="A." surname="Gulbrandsen
">
<organization/>
</author>
<author fullname="P. Vixie" initials="P." surname="Vixie">
<organization/>
</author>
<author fullname="L. Esibov" initials="L." surname="Esibov">
<organization/>
</author>
<date month="February" year="2000"/>
<abstract>
<t>This document describes a DNS RR which specifies the location o
f the server(s) for a specific protocol and domain. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2782"/>
<seriesInfo name="DOI" value="10.17487/RFC2782"/>
</reference>
<reference anchor="HSTS">
<front>
<title>HTTP Strict Transport Security (HSTS)</title>
<author fullname="J. Hodges" initials="J." surname="Hodges">
<organization/>
</author>
<author fullname="C. Jackson" initials="C." surname="Jackson">
<organization/>
</author>
<author fullname="A. Barth" initials="A." surname="Barth">
<organization/>
</author>
<date month="November" year="2012"/>
<abstract>
<t>This specification defines a mechanism enabling web sites to de
clare themselves accessible only via secure connections and/or for users to be a
ble to direct their user agent(s) to interact with given sites only over secure
connections. This overall policy is referred to as HTTP Strict Transport Securi
ty (HSTS). The policy is declared by web sites via the Strict-Transport-Securit
y HTTP response header field and/or by other means, such as user agent configura
tion, for example. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6797"/>
<seriesInfo name="DOI" value="10.17487/RFC6797"/>
</reference>
<reference anchor="AltSvc">
<front>
<title>HTTP Alternative Services</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham">
<organization/>
</author>
<author fullname="P. McManus" initials="P." surname="McManus">
<organization/>
</author>
<author fullname="J. Reschke" initials="J." surname="Reschke">
<organization/>
</author>
<date month="April" year="2016"/>
<abstract>
<t>This document specifies "Alternative Services" for HTTP, which
allow an origin's resources to be authoritatively available at a separate networ
k location, possibly accessed with a different protocol configuration.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7838"/>
<seriesInfo name="DOI" value="10.17487/RFC7838"/>
</reference>
<reference anchor="RFC6454">
<front>
<title>The Web Origin Concept</title>
<author fullname="A. Barth" initials="A." surname="Barth">
<organization/>
</author>
<date month="December" year="2011"/>
<abstract>
<t>This document defines the concept of an "origin", which is ofte
n used as the scope of authority or privilege by user agents. Typically, user a
gents isolate content retrieved from different origins to prevent malicious web
site operators from interfering with the operation of benign web sites. In addi
tion to outlining the principles that underlie the concept of origin, this docum
ent details how to determine the origin of a URI and how to serialize an origin
into a string. It also defines an HTTP header field, named "Origin", that indic
ates which origins are associated with an HTTP request. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6454"/>
<seriesInfo name="DOI" value="10.17487/RFC6454"/>
</reference>
<reference anchor="DNSTerm">
<front>
<title>DNS Terminology</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman">
<organization/>
</author>
<author fullname="A. Sullivan" initials="A." surname="Sullivan">
<organization/>
</author>
<author fullname="K. Fujiwara" initials="K." surname="Fujiwara">
<organization/>
</author>
<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 prot
ocols, and by operators of DNS systems, has sometimes changed in the decades sin
ce 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="BCP" value="219"/>
<seriesInfo name="RFC" value="8499"/>
<seriesInfo name="DOI" value="10.17487/RFC8499"/>
</reference>
<reference anchor="URI">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee
">
<organization/>
</author>
<author fullname="R. Fielding" initials="R." surname="Fielding">
<organization/>
</author>
<author fullname="L. Masinter" initials="L." surname="Masinter">
<organization/>
</author>
<date month="January" year="2005"/>
<abstract>
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch
aracters that identifies an abstract or physical resource. This specification d
efines the generic URI syntax and a process for resolving URI references that mi
ght be in relative form, along with guidelines and security considerations for t
he use of URIs on the Internet. The URI syntax defines a grammar that is a supe
rset of all valid URIs, allowing an implementation to parse the common component
s of a URI reference without knowing the scheme-specific requirements of every p
ossible identifier. This specification does not define a generative grammar for
URIs; that task is performed by the individual specifications of each URI schem
e. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="RFC1912">
<front> <front>
<title>Common DNS Operational and Configuration Errors</title> <title>WebSockets Living Standard</title>
<author fullname="D. Barr" initials="D." surname="Barr"> <author>
<organization/> <organization>WHATWG</organization>
</author> </author>
<date month="February" year="1996"/> <date year="2023" month="September"/>
<abstract>
<t>This memo describes errors often found in both the operation of
Domain Name System (DNS) servers, and in the data that these DNS servers contai
n. This memo provides information for the Internet community. This memo does no
t specify an Internet standard of any kind.</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="1912"/>
<seriesInfo name="DOI" value="10.17487/RFC1912"/>
</reference> </reference>
<reference anchor="DNAME">
<reference anchor="BIND-CHECK-NAMES" target="https://bind9.readthedocs.i
o/en/v9.19.11/reference.html#namedconf-statement-check-names">
<front> <front>
<title>DNAME Redirection in the DNS</title> <title>BIND v9.19.11 Configuration Reference: "check-names"</title>
<author fullname="S. Rose" initials="S." surname="Rose"> <author>
<organization/> <organization>Internet Systems Consortium</organization>
</author>
<author fullname="W. Wijngaards" initials="W." surname="Wijngaards">
<organization/>
</author> </author>
<date month="June" year="2012"/> <date year="2023" month="September"/>
<abstract>
<t>The DNAME record provides redirection for a subtree of the doma
in name tree in the DNS. That is, all names that end with a particular suffix a
re redirected to another part of the DNS. This document obsoletes the original
specification in RFC 2672 as well as updates the document on representing IPv6 a
ddresses in DNS (RFC 3363). [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="RFC" value="6672"/>
<seriesInfo name="DOI" value="10.17487/RFC6672"/>
</reference> </reference>
<reference anchor="I-D.bellis-dnsop-http-record">
<front>
<title>A DNS Resource Record for HTTP</title>
<author fullname="Ray Bellis" initials="R." surname="Bellis">
<organization>Internet Systems Consortium, Inc.</organization>
</author>
<date day="3" month="November" year="2018"/>
<abstract>
<t> This document specifies an "HTTP" resource record type for t
he DNS to
facilitate the lookup of the server hostname of HTTP(s) URIs. It is
intended to replace the use of CNAME records for this purpose, and in
the process provides a solution for the inability of the DNS to allow
a CNAME to be placed at the apex of a domain name.
</t> <!-- draft-ietf-tls-esni (I-D Exists) -->
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tls
</front> -esni.xml"/>
<seriesInfo name="Internet-Draft" value="draft-bellis-dnsop-http-recor
d-00"/> <!-- draft-ietf-quic-http (RFC 9114) -->
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9114.xml"
<reference anchor="I-D.ietf-dnsop-aname"> />
<front>
<title>Address-specific DNS aliases (ANAME)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2782.xml"
<author fullname="Tony Finch" initials="T." surname="Finch"> />
<organization>University of Cambridge</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6797.xml"
</author> />
<author fullname="Evan Hunt" initials="E." surname="Hunt"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7838.xml"
<organization>ISC</organization> />
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6454.xml"
<author fullname="Peter van Dijk" initials="P." surname="van Dijk"> />
<organization>PowerDNS</organization> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"
</author> />
<author fullname="Anthony Eden" initials="A." surname="Eden"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"
<organization>DNSimple</organization> />
</author> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1912.xml"
<author fullname="Matthijs Mekking" initials="W. M." surname="Mekkin />
g"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6672.xml"
<organization>ISC</organization> />
</author>
<date day="8" month="July" year="2019"/> <!-- draft-bellis-dnsop-http-record (Expired) -->
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.bellis-d
<t> This document defines the "ANAME" DNS RR type, to provide si nsop-http-record.xml"/>
milar
functionality to CNAME, but only for address queries. Unlike CNAME, <!-- draft-ietf-dnsop-aname (Expired) ("long way" to fix author initials) -->
an ANAME can coexist with other record types. The ANAME RR allows <reference anchor="I-D.ietf-dnsop-aname">
zone owners to make an apex domain name into an alias in a standards <front>
compliant manner. <title>Address-specific DNS aliases (ANAME)</title>
<author initials="T." surname="Finch" fullname="Tony Finch">
<organization>University of Cambridge</organization>
</author>
<author initials="E." surname="Hunt" fullname="Evan Hunt">
<organization>ISC</organization>
</author>
<author initials="P." surname="van Dijk" fullname="Peter van Dijk">
<organization>PowerDNS</organization>
</author>
<author initials="A." surname="Eden" fullname="Anthony Eden">
<organization>DNSimple</organization>
</author>
<author initials="W." surname="Mekking" fullname="Matthijs Mekking">
<organization>ISC</organization>
</author>
<date month="July" day="8" year="2019" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-aname-04" />
</reference>
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-aname-04"/>
</reference>
</references> </references>
</references> </references>
<section anchor="decoding"> <section anchor="decoding">
<name>Decoding text in zone files</name> <name>Decoding Text in Zone Files</name>
<t>DNS zone files are capable of representing arbitrary octet sequences in <t>DNS zone files are capable of representing arbitrary octet sequences in
basic ASCII text, using various delimiters and encodings. The algorithm basic ASCII text, using various delimiters and encodings, according to an algori
for decoding these character-strings is defined in <xref section="5.1" sectionFo thm
rmat="of" target="RFC1035"/>. defined in <xref section="5.1" sectionFormat="of" target="RFC1035"/>.
Here we summarize the allowed input to that algorithm, using ABNF:</t> The following summarizes some allowed inputs to that algorithm, using ABNF:</t>
<artwork><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\". ; non-special is VCHAR minus DQUOTE, ";", "(", ")", and "\".
non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E non-special = %x21 / %x23-27 / %x2A-3A / %x3C-5B / %x5D-7E
; non-digit is VCHAR minus DIGIT ; non-digit is VCHAR minus DIGIT.
non-digit = %x21-2F / %x3A-7E non-digit = %x21-2F / %x3A-7E
; dec-octet is a number 0-255 as a three-digit decimal number. ; dec-octet is a number 0-255 as a three-digit decimal number.
dec-octet = ( "0" / "1" ) 2DIGIT / dec-octet = ( "0" / "1" ) 2DIGIT /
"2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) ) "2" ( ( %x30-34 DIGIT ) / ( "5" %x30-35 ) )
escaped = "\" ( non-digit / dec-octet ) escaped = "\" ( non-digit / dec-octet )
contiguous = 1*( non-special / escaped ) contiguous = 1*( non-special / escaped )
quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE quoted = DQUOTE *( contiguous / ( ["\"] WSP ) ) DQUOTE
char-string = contiguous / quoted char-string = contiguous / quoted
]]></artwork> ]]></sourcecode>
<t>The decoding algorithm allows <tt>char-string</tt> to represent any <tt >*OCTET</tt>, <t>The decoding algorithm allows <tt>char-string</tt> to represent any <tt >*OCTET</tt>,
using quoting to group values (e.g., those with internal whitespace), and using quoting to group values (e.g., those with internal whitespace), and
escaping to represent each non-printable octet as a single <tt>escaped</tt> sequ ence. escaping to represent each non-printable octet as a single <tt>escaped</tt> sequ ence.
In this document, this algorithm is referred to as "character-string decoding". In this document, this algorithm is referred to as "character-string decoding",
The algorithm is the same as used by <tt>&lt;character-string&gt;</tt> in RFC 10 because
35, <xref target="RFC1035" sectionFormat="of" section="5.1"/> uses this
although the output length in this document is not limited to 255 octets.</t> algorithm to produce a <tt>&lt;character-string&gt;</tt>. Note that while
the length of a <tt>&lt;character-string&gt;</tt> is limited to 255 octets, the
character-string decoding algorithm can produce output of any length.</t>
<section anchor="value-list"> <section anchor="value-list">
<name>Decoding a comma-separated list</name> <name>Decoding a Comma-Separated List</name>
<t>In order to represent lists of items in zone files, this specificatio n uses <t>In order to represent lists of items in zone files, this specificatio n uses
comma-separated lists. When the allowed items in the list cannot contain "," comma-separated lists. When the allowed items in the list cannot contain ","
or "\", this is trivial. (For simplicity, empty items are not allowed.) or "\", this is trivial. (For simplicity, empty items are not allowed.)
A value-list parser that splits on "," and prohibits items containing "\" A value-list parser that splits on "," and prohibits items containing "\"
is sufficient to comply with all requirements in this document. This is sufficient to comply with all requirements in this document. This
corresponds to the <tt>simple-comma-separated</tt> syntax:</t> corresponds to the <tt>simple-comma-separated</tt> syntax:</t>
<artwork><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
; item-allowed is OCTET minus "," and "\". ; item-allowed is OCTET minus "," and "\".
item-allowed = %x00-2B / %x2D-5B / %x5D-FF item-allowed = %x00-2B / %x2D-5B / %x5D-FF
simple-item = 1*item-allowed simple-item = 1*item-allowed
simple-comma-separated = [simple-item *("," simple-item)] simple-comma-separated = [simple-item *("," simple-item)]
]]></artwork> ]]></sourcecode>
<t>For implementations that allow "," and "\" in item values, the follow ing <t>For implementations that allow "," and "\" in item values, the follow ing
escaping syntax applies:</t> escaping syntax applies:</t>
<artwork><![CDATA[ <sourcecode name="" type="abnf"><![CDATA[
item = 1*OCTET item = 1*OCTET
escaped-item = 1*(item-allowed / "\," / "\\") escaped-item = 1*(item-allowed / "\," / "\\")
comma-separated = [escaped-item *("," escaped-item)] comma-separated = [escaped-item *("," escaped-item)]
]]></artwork> ]]></sourcecode>
<t>Decoding of value-lists happens after character-string decoding. <t>Decoding of value-lists happens after character-string decoding.
For example, consider these <tt>char-string</tt> SvcParamValues:</t> For example, consider these <tt>char-string</tt> SvcParamValues:</t>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
"part1,part2,part3\\,part4\\\\" "part1,part2,part3\\,part4\\\\"
part1\,\p\a\r\t2\044part3\092,part4\092\\ part1\,\p\a\r\t2\044part3\092,part4\092\\
]]></artwork> ]]></sourcecode>
<t>These inputs are equivalent: character-string decoding either of them would <t>These inputs are equivalent: character-string decoding either of them would
produce the same <tt>value</tt>:</t> produce the same <tt>value</tt>:</t>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
part1,part2,part3\,part4\\ part1,part2,part3\,part4\\
]]></artwork> ]]></sourcecode>
<t>Applying comma-separated list decoding to this <tt>value</tt> would p roduce a list <t>Applying comma-separated list decoding to this <tt>value</tt> would p roduce a list
of three <tt>item</tt>s:</t> of three <tt>item</tt>s:</t>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
part1 part1
part2 part2
part3,part4\ part3,part4\
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="http-mapping-summary"> <section anchor="http-mapping-summary">
<name>HTTP Mapping Summary</name> <name>HTTP Mapping Summary</name>
<t>This table serves as a non-normative summary of the HTTP mapping for SV CB <t>This table serves as a non-normative summary of the HTTP mapping for SV CB
(<xref target="https"/>). Future protocol mappings may provide a similar summar y table.</t> (<xref target="https"/>). Future protocol mappings may provide a similar summar y table.</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">"https"</td> <td align="left">"https"</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<strong>Other affected schemes</strong></td> <strong>Other affected schemes</strong></td>
<td align="left">"http", "wss", "ws", (other HTTP-based)</td> <td align="left">"http", "wss", "ws", (other HTTP-based)</td>
skipping to change at line 2465 skipping to change at line 1839
<strong>RR type</strong></td> <strong>RR type</strong></td>
<td align="left">HTTPS (65)</td> <td align="left">HTTPS (65)</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<strong>Name prefix</strong></td> <strong>Name prefix</strong></td>
<td align="left">None for port 443, else <tt>_$PORT._https</tt></td> <td align="left">None for port 443, else <tt>_$PORT._https</tt></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>, <tt>no-default-alpn</tt></td> <tt>port</tt>, <tt>no-default-alpn</tt></td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<strong>SvcParam defaults</strong></td> <strong>SvcParam defaults</strong></td>
<td align="left"> <td align="left">
<tt>alpn</tt>: ["http/1.1"]</td> <tt>alpn</tt>: ["http/1.1"]</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<strong>Special behaviors</strong></td> <strong>Special behaviors</strong></td>
<td align="left">HTTP to HTTPS upgrade</td> <td align="left">Upgrade from HTTP to HTTPS</td>
</tr> </tr>
<tr> <tr>
<td align="left"> <td align="left">
<strong>Keys that records must include</strong></td> <strong>Keys that records must include</strong></td>
<td align="left">None</td> <td align="left">None</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="comparison-with-alternatives"> <section anchor="comparison-with-alternatives">
<name>Comparison with alternatives</name> <name>Comparison with Alternatives</name>
<t>The SVCB and HTTPS RR types closely resemble, <t>The SVCB and HTTPS RR types closely resemble,
and are inspired by, some existing and are inspired by, some existing
record types and proposals. A complaint with all of the alternatives record types and proposals. One complaint regarding all of the alternatives
is that web clients have seemed unenthusiastic about implementing is that web clients have seemed unenthusiastic about implementing
them. The hope here is that by providing an extensible solution that them. The hope here is that an extensible solution that
solves multiple problems we will overcome the inertia and have a path solves multiple problems will overcome this inertia and have a path
to achieve client implementation.</t> to achieve client implementation.</t>
<section anchor="differences-from-the-srv-rr-type"> <section anchor="differences-from-the-srv-rr-type">
<name>Differences from the SRV RR type</name> <name>Differences from the SRV RR Type</name>
<t>An SRV record <xref target="SRV"/> can perform a similar function to <t>An SRV record <xref target="RFC2782"/> can perform a function similar
the SVCB record, to that of the SVCB record,
informing a client to look in a different location for a service. informing a client to look in a different location for a service.
However, there are several differences:</t> However, there are several differences:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>SRV records are typically mandatory, whereas SVCB is intended to b e optional <li>SRV records are typically mandatory, whereas SVCB is intended to b e optional
when used with pre-existing protocols.</li> when used with pre-existing protocols.</li>
<li>SRV records cannot instruct the client to switch or upgrade <li>SRV records cannot instruct the client to switch or upgrade
protocols, whereas SVCB can signal such an upgrade (e.g. to protocols, whereas SVCB can signal such an upgrade (e.g., to
HTTP/2).</li> HTTP/2).</li>
<li>SRV records are not extensible, whereas SVCB and HTTPS RRs <li>SRV records are not extensible, whereas SVCB and HTTPS RRs
can be extended with new parameters.</li> can be extended with new parameters.</li>
<li>SRV records specify a "weight" for unbalanced randomized load-bala <li>SRV records specify a "weight" for unbalanced randomized load bala
ncing. ncing.
SVCB only supports balanced randomized load-balancing, although weights SVCB only supports balanced randomized load balancing, although weights
could be added via a future SvcParam.</li> could be added via a future SvcParam.</li>
</ul> </ul>
</section> </section>
<section anchor="differences-from-the-proposed-http-record"> <section anchor="differences-from-the-proposed-http-record">
<name>Differences from the proposed HTTP record</name> <name>Differences from the Proposed HTTP Record</name>
<t>Unlike <xref target="I-D.bellis-dnsop-http-record"/>, this approach i s <t>Unlike <xref target="I-D.bellis-dnsop-http-record"/>, this approach i s
extensible to cover Alt-Svc and Encrypted ClientHello use-cases. Like that extensible to cover Alt-Svc and Encrypted ClientHello use cases. Like that
proposal, this addresses the zone apex CNAME challenge.</t> proposal, this addresses the zone-apex CNAME challenge.</t>
<t>Like that proposal, it remains necessary to continue to include <t>Like that proposal, it remains necessary to continue to include
address records at the zone apex for legacy clients.</t> address records at the zone apex for legacy clients.</t>
</section> </section>
<section anchor="differences-from-the-proposed-aname-record"> <section anchor="differences-from-the-proposed-aname-record">
<name>Differences from the proposed ANAME record</name> <name>Differences from the Proposed ANAME Record</name>
<t>Unlike <xref target="I-D.ietf-dnsop-aname"/>, this approach is extens ible to <t>Unlike <xref target="I-D.ietf-dnsop-aname"/>, this approach is extens ible to
cover Alt-Svc and ECH use-cases. This approach also does not cover Alt-Svc and Encrypted ClientHello use cases. This approach also does not
require any changes or special handling on either authoritative or require any changes or special handling on either authoritative or
primary servers, beyond optionally returning in-bailiwick additional records.</t > primary servers, beyond optionally returning in-bailiwick additional records.</t >
<t>Like that proposal, this addresses the zone apex CNAME challenge <t>Like that proposal, this addresses the zone-apex CNAME challenge
for clients that implement this.</t> for clients that implement this.</t>
<t>However, with this SVCB proposal, it remains necessary to continue <t>However, with this SVCB proposal, it remains necessary to continue
to include address records at the zone apex for legacy clients. to include address records at the zone apex for legacy clients.
If deployment of this standard is successful, the number of legacy clients If deployment of this standard is successful, the number of legacy clients
will fall over time. As the number of legacy clients declines, the operational will fall over time. As the number of legacy clients declines, the operational
effort required to serve these users without the benefit of SVCB indirection effort required to serve these users without the benefit of SVCB indirection
should fall. Server operators can easily observe how much traffic reaches this should fall. Server operators can easily observe how much traffic reaches this
legacy endpoint, and may remove the apex's address records if the observed legac y legacy endpoint and may remove the apex's address records if the observed legacy
traffic has fallen to negligible levels.</t> traffic has fallen to negligible levels.</t>
</section> </section>
<section anchor="comparison-with-separate-rr-types-for-aliasmode-and-servi cemode"> <section anchor="comparison-with-separate-rr-types-for-aliasmode-and-servi cemode">
<name>Comparison with separate RR types for AliasMode and ServiceMode</n ame> <name>Comparison with Separate RR Types for AliasMode and ServiceMode</n ame>
<t>Abstractly, functions of AliasMode and ServiceMode are independent, <t>Abstractly, functions of AliasMode and ServiceMode are independent,
so it might be tempting to specify them as separate RR types. However, so it might be tempting to specify them as separate RR types. However,
this would result in a serious performance impairment, because clients this would result in serious performance impairment, because clients
cannot rely on their recursive resolver to follow SVCB aliases (unlike cannot rely on their recursive resolver to follow SVCB aliases (unlike
CNAME). Thus, clients would have to issue queries for both RR types CNAME). Thus, clients would have to issue queries for both RR types
in parallel, potentially at each step of the alias chain. Recursive in parallel, potentially at each step of the alias chain. Recursive
resolvers that implement the specification would, upon receipt of a resolvers that implement the specification would, upon receipt of a
ServiceMode query, emit both a ServiceMode and an AliasMode query to ServiceMode query, emit both a ServiceMode query and an AliasMode query to
the authoritative. Thus, splitting the RR type would double, or in the authoritative DNS server. Thus, splitting the RR type would double, or in
some cases triple, the load on clients and servers, and would not some cases triple, the load on clients and servers, and would not
reduce implementation complexity.</t> reduce implementation complexity.</t>
</section> </section>
</section> </section>
<section anchor="test-vectors"> <section anchor="test-vectors">
<name>Test vectors</name> <name>Test Vectors</name>
<t>These test vectors only contain the RDATA portion of SVCB/HTTPS records in <t>These test vectors only contain the RDATA portion of SVCB/HTTPS records in
presentation format, generic format (<xref target="RFC3597"/>) and wire format. presentation format, generic format <xref target="RFC3597"/>, and wire format. T
The wire he wire
format uses hexadecimal (\xNN) for each non-ascii byte. As the wireformat is format uses hexadecimal (\xNN) for each non-ASCII byte. As the wire format is
long, it is broken into several lines.</t> long, it is broken into several lines.</t>
<section anchor="aliasmode"> <section anchor="aliasmode">
<name>AliasMode</name> <name>AliasMode</name>
<figure> <figure>
<name>AliasMode</name> <name>AliasMode</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
example.com. HTTPS 0 foo.example.com. example.com. HTTPS 0 foo.example.com.
\# 19 ( \# 19 (
00 00 ; priority 00 00 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
) )
\x00\x00 # priority \x00\x00 # priority
\x03foo\x07example\x03com\x00 # target \x03foo\x07example\x03com\x00 # target
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="servicemode-1"> <section anchor="servicemode-1">
<name>ServiceMode</name> <name>ServiceMode</name>
<figure> <figure>
<name>TargetName is "."</name> <name>TargetName Is "."</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
example.com. SVCB 1 . example.com. SVCB 1 .
\# 3 ( \# 3 (
00 01 ; priority 00 01 ; priority
00 ; target (root label) 00 ; target (root label)
) )
\x00\x01 # priority \x00\x01 # priority
\x00 # target, root label \x00 # target (root label)
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>Specifies a port</name> <name>Specifies a Port</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
example.com. SVCB 16 foo.example.com. port=53 example.com. SVCB 16 foo.example.com. port=53
\# 25 ( \# 25 (
00 10 ; priority 00 10 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
00 03 ; key 3 00 03 ; key 3
00 02 ; length 2 00 02 ; length 2
00 35 ; value 00 35 ; value
) )
\x00\x10 # priority \x00\x10 # priority
\x03foo\x07example\x03com\x00 # target \x03foo\x07example\x03com\x00 # target
\x00\x03 # key 3 \x00\x03 # key 3
\x00\x02 # length: 2 bytes \x00\x02 # length 2
\x00\x35 # value \x00\x35 # value
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>A generic key and unquoted value</name> <name>A Generic Key and Unquoted Value</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
example.com. SVCB 1 foo.example.com. key667=hello example.com. SVCB 1 foo.example.com. key667=hello
\# 28 ( \# 28 (
00 01 ; priority 00 01 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b ; key 667 02 9b ; key 667
00 05 ; length 5 00 05 ; length 5
68 65 6c 6c 6f ; value 68 65 6c 6c 6f ; value
) )
\x00\x01 # priority \x00\x01 # priority
\x03foo\x07example\x03com\x00 # target \x03foo\x07example\x03com\x00 # target
\x02\x9b # key 667 \x02\x9b # key 667
\x00\x05 # length 5 \x00\x05 # length 5
hello # value hello # value
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>A generic key and quoted value with a decimal escape</name> <name>A Generic Key and Quoted Value with a Decimal Escape</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
example.com. SVCB 1 foo.example.com. key667="hello\210qoo" example.com. SVCB 1 foo.example.com. key667="hello\210qoo"
\# 32 ( \# 32 (
00 01 ; priority 00 01 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
02 9b ; key 667 02 9b ; key 667
00 09 ; length 9 00 09 ; length 9
68 65 6c 6c 6f d2 71 6f 6f ; value 68 65 6c 6c 6f d2 71 6f 6f ; value
) )
\x00\x01 # priority \x00\x01 # priority
\x03foo\x07example\x03com\x00 # target \x03foo\x07example\x03com\x00 # target
\x02\x9b # key 667 \x02\x9b # key 667
\x00\x09 # length 9 \x00\x09 # length 9
hello\xd2qoo # value hello\xd2qoo # value
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>Two quoted IPv6 hints</name> <name>Two Quoted IPv6 Hints</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
example.com. SVCB 1 foo.example.com. ( example.com. SVCB 1 foo.example.com. (
ipv6hint="2001:db8::1,2001:db8::53:1" ipv6hint="2001:db8::1,2001:db8::53:1"
) )
\# 55 ( \# 55 (
00 01 ; priority 00 01 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
00 06 ; key 6 00 06 ; key 6
00 20 ; length 32 00 20 ; length 32
20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 ; first address 20 01 0d b8 00 00 00 00 00 00 00 00 00 00 00 01 ; first address
skipping to change at line 2678 skipping to change at line 2053
) )
\x00\x01 # priority \x00\x01 # priority
\x03foo\x07example\x03com\x00 # target \x03foo\x07example\x03com\x00 # target
\x00\x06 # key 6 \x00\x06 # key 6
\x00\x20 # length 32 \x00\x20 # length 32
\x20\x01\x0d\xb8\x00\x00\x00\x00 \x20\x01\x0d\xb8\x00\x00\x00\x00
\x00\x00\x00\x00\x00\x00\x00\x01 # first address \x00\x00\x00\x00\x00\x00\x00\x01 # first address
\x20\x01\x0d\xb8\x00\x00\x00\x00 \x20\x01\x0d\xb8\x00\x00\x00\x00
\x00\x00\x00\x00\x00\x53\x00\x01 # second address \x00\x00\x00\x00\x00\x53\x00\x01 # second address
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>An IPv6 hint using the embedded IPv4 syntax</name> <name>An IPv6 Hint Using the Embedded IPv4 Syntax</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
example.com. SVCB 1 example.com. ipv6hint="2001:db8:122:344::192.0.2.33" example.com. SVCB 1 example.com. (
ipv6hint="2001:db8:122:344::192.0.2.33"
)
\# 35 ( \# 35 (
00 01 ; priority 00 01 ; priority
07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 ; target
00 06 ; key 6 00 06 ; key 6
00 10 ; length 16 00 10 ; length 16
20 01 0d b8 01 22 03 44 00 00 00 00 c0 00 02 21 ; address 20 01 0d b8 01 22 03 44 00 00 00 00 c0 00 02 21 ; address
) )
\x00\x01 # priority \x00\x01 # priority
\x07example\x03com\x00 # target \x07example\x03com\x00 # target
\x00\x06 # key 6 \x00\x06 # key 6
\x00\x10 # length 16 \x00\x10 # length 16
\x20\x01\x0d\xb8\x01\x22\x03\x44 \x20\x01\x0d\xb8\x01\x22\x03\x44
\x00\x00\x00\x00\xc0\x00\x02\x21 # address \x00\x00\x00\x00\xc0\x00\x02\x21 # address
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>SvcParamKey ordering is arbitrary in presentation format but sor <name>SvcParamKey Ordering Is Arbitrary in Presentation Format but Sor
ted in wire format</name> ted in Wire Format</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
example.com. SVCB 16 foo.example.org. ( example.com. SVCB 16 foo.example.org. (
alpn=h2,h3-19 mandatory=ipv4hint,alpn alpn=h2,h3-19 mandatory=ipv4hint,alpn
ipv4hint=192.0.2.1 ipv4hint=192.0.2.1
) )
\# 48 ( \# 48 (
00 10 ; priority 00 10 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
00 00 ; key 0 00 00 ; key 0
00 04 ; param length 4 00 04 ; param length 4
skipping to change at line 2742 skipping to change at line 2118
\x00\x04 # value: key 4 \x00\x04 # value: key 4
\x00\x01 # key 1 \x00\x01 # key 1
\x00\x09 # param length 9 \x00\x09 # param length 9
\x02 # alpn length 2 \x02 # alpn length 2
h2 # alpn value h2 # alpn value
\x05 # alpn length 5 \x05 # alpn length 5
h3-19 # alpn value h3-19 # alpn value
\x00\x04 # key 4 \x00\x04 # key 4
\x00\x04 # param length 4 \x00\x04 # param length 4
\xc0\x00\x02\x01 # param value \xc0\x00\x02\x01 # param value
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>An alpn value with an escaped comma and an escaped backslash in <name>An &quot;alpn&quot; Value with an Escaped Comma and an Escaped B
two presentation formats</name> ackslash in Two Presentation Formats</name>
<artwork><![CDATA[ <sourcecode type="test-vectors"><![CDATA[
example.com. SVCB 16 foo.example.org. alpn="f\\\\oo\\,bar,h2" example.com. SVCB 16 foo.example.org. alpn="f\\\\oo\\,bar,h2"
example.com. SVCB 16 foo.example.org. alpn=f\\\092oo\092,bar,h2 example.com. SVCB 16 foo.example.org. alpn=f\\\092oo\092,bar,h2
\# 35 ( \# 35 (
00 10 ; priority 00 10 ; priority
03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target 03 66 6f 6f 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 ; target
00 01 ; key 1 00 01 ; key 1
00 0c ; param length 12 00 0c ; param length 12
08 ; alpn length 8 08 ; alpn length 8
66 5c 6f 6f 2c 62 61 72 ; alpn value 66 5c 6f 6f 2c 62 61 72 ; alpn value
skipping to change at line 2769 skipping to change at line 2145
) )
\x00\x10 # priority \x00\x10 # priority
\x03foo\x07example\x03org\x00 # target \x03foo\x07example\x03org\x00 # target
\x00\x01 # key 1 \x00\x01 # key 1
\x00\x0c # param length 12 \x00\x0c # param length 12
\x08 # alpn length 8 \x08 # alpn length 8
f\oo,bar # alpn value f\oo,bar # alpn value
\x02 # alpn length 2 \x02 # alpn length 2
h2 # alpn value h2 # alpn value
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="failure-cases"> <section anchor="failure-cases">
<name>Failure cases</name> <name>Failure Cases</name>
<t>This subsection contains test vectors which are not <t>This subsection contains test vectors that are not
compliant with this document. The various reasons for non-compliance compliant with this document. The various reasons for non-compliance
are explained with each example.</t> are explained with each example.</t>
<figure> <figure>
<name>Multiple instances of the same SvcParamKey</name> <name>Multiple Instances of the Same SvcParamKey</name>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
example.com. SVCB 1 foo.example.com. ( example.com. SVCB 1 foo.example.com. (
key123=abc key123=def key123=abc key123=def
) )
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>Missing SvcParamValues that must be nonempty</name> <name>Missing SvcParamValues That Must Be Non-Empty</name>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
example.com. SVCB 1 foo.example.com. mandatory example.com. SVCB 1 foo.example.com. mandatory
example.com. SVCB 1 foo.example.com. alpn example.com. SVCB 1 foo.example.com. alpn
example.com. SVCB 1 foo.example.com. port example.com. SVCB 1 foo.example.com. port
example.com. SVCB 1 foo.example.com. ipv4hint example.com. SVCB 1 foo.example.com. ipv4hint
example.com. SVCB 1 foo.example.com. ipv6hint example.com. SVCB 1 foo.example.com. ipv6hint
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>The "no-default-alpn" SvcParamKey value must be empty</name> <name>The "no-default-alpn" SvcParamKey Value Must Be Empty</name>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
example.com. SVCB 1 foo.example.com. no-default-alpn=abc example.com. SVCB 1 foo.example.com. no-default-alpn=abc
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>A mandatory SvcParam is missing</name> <name>A Mandatory SvcParam Is Missing</name>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
example.com. SVCB 1 foo.example.com. mandatory=key123 example.com. SVCB 1 foo.example.com. mandatory=key123
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>The "mandatory" SvcParamKey must not be included in the mandator <name>The "mandatory" SvcParamKey Must Not Be Included in the Mandator
y list</name> y List</name>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
example.com. SVCB 1 foo.example.com. mandatory=mandatory example.com. SVCB 1 foo.example.com. mandatory=mandatory
]]></artwork> ]]></sourcecode>
</figure> </figure>
<figure> <figure>
<name>Multiple instances of the same SvcParamKey in the mandatory list <name>Multiple Instances of the Same SvcParamKey in the Mandatory List
</name> </name>
<artwork><![CDATA[ <sourcecode type="dns-rr"><![CDATA[
example.com. SVCB 1 foo.example.com. ( example.com. SVCB 1 foo.example.com. (
mandatory=key123,key123 key123=abc mandatory=key123,key123 key123=abc
) )
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="change-history"> <section anchor="acknowledgments-and-related-proposals" numbered="false">
<name>Change history</name> <name>Acknowledgments and Related Proposals</name>
<t>(This section to be removed by the RFC editor.)</t> <t>Over the years, IETF participants have proposed a wide range of solutio
<ul spacing="normal"> ns to
<li> the "CNAME at the zone apex" challenge, including
<t>draft-ietf-dnsop-svcb-https-12 <xref target="I-D.bellis-dnsop-http-record"/>,
</t> <xref target="I-D.ietf-dnsop-aname"/>, and others. The authors are grateful
<ul spacing="normal"> for their work to elucidate the problem and identify promising strategies to
<li>Split out Encrypted Client Hello (ECH) to a separate draft address it, some of which are reflected in this document.</t>
and convert all remaining references to informative.</li> <t>Thank you to <contact fullname="Ian Swett"/>, <contact fullname="Ralf W
</ul> eber"/>, <contact fullname="Jon Reed"/>,
</li> <contact fullname="Martin Thomson"/>, <contact fullname="Lucas Pardue"/>, <conta
<li> ct fullname="Ilari Liusvaara"/>,
<t>draft-ietf-dnsop-svcb-https-11 <contact fullname="Tim Wicinski"/>, <contact fullname="Tommy Pauly"/>, <contact
</t> fullname="Chris Wood"/>, <contact fullname="David Benjamin"/>,
<ul spacing="normal"> <contact fullname="Mark Andrews"/>, <contact fullname="Emily Stark"/>, <contact
<li> fullname="Eric Orth"/>, <contact fullname="Kyle Rose"/>,
<t>Narrow set of post-IESG clarifications: <contact fullname="Craig Taylor"/>, <contact fullname="Dan McArdle"/>, <contact
</t> fullname="Brian Dickson"/>,
<ul spacing="normal"> <contact fullname="Willem Toorop"/>, <contact fullname="Pieter Lexis"/>, <contac
<li>Clarify that that the fallback addition of the t fullname="Puneet Sood"/>,
QNAME was for the AliasMode case</li> <contact fullname="Olivier Poitrey"/>, <contact fullname="Mashooq Muhaimen"/>,
<li>Note that some implementations may not allow A/AAAA <contact fullname="Tom Carpay"/>, and many others for their feedback
records on names starting with an underscore</li> and suggestions on this document.</t>
</ul>
</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-https-10
</t>
<ul spacing="normal">
<li>Clarify rationale for two recommendations</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-https-09
</t>
<ul spacing="normal">
<li>
<t>Extensive adjustments based on IESG reviews, including:
</t>
<ul spacing="normal">
<li>IANA registry changed to Expert Review policy</li>
<li>Adjustments to the use of normative language</li>
<li>Revised and expanded description of HSTS behavior</li>
<li>Expanded discussion of CNAME handling</li>
<li>Discussion of SvcParams in AliasMode records</li>
<li>Restructured ABNF for comma-separated lists</li>
<li>Additional references and many other minor clarifications</l
i>
</ul>
</li>
<li>
<t>Other changes include:
</t>
<ul spacing="normal">
<li>New section on interaction with DNS64</li>
<li>New text on the interpretation of wildcard owner names</li>
<li>Adjusted guidance on default ALPN enforcement</li>
<li>Removed mention of IPv4-mapped IPv6</li>
</ul>
</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-https-08
</t>
<ul spacing="normal">
<li>
<t>Extensive structural and editorial adjustments based on area re
views,
including:
</t>
<ul spacing="normal">
<li>A new section on SVCB-compatible record types</li>
<li>Reorganized description of client behavior</li>
<li>Test vectors are now in titled figures</li>
<li>Adjusted mapping summary</li>
<li>Improve description of rules for resolver handling of invali
d
SvcParamValues.</li>
</ul>
</li>
<li>New text on cross-transport fallback (e.g. QUIC vs. TCP)</li>
<li>Improved explanation of use with domain-oriented transport proxi
es</li>
<li>HTTP terminology adjusted to match draft-ietf-httpbis-semantics<
/li>
<li>Improved and corrected IANA instructions</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-https-07
</t>
<ul spacing="normal">
<li>Editorial improvements following AD review.</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-https-06
</t>
<ul spacing="normal">
<li>Add requirements for HTTPS origins that also use Alt-Svc</li>
<li>Remove requirement for comma-escaping related to unusual ALPN va
lues</li>
<li>Allow resolvers to reject invalid SvcParamValues, with additiona
l
guidance</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-https-05
</t>
<ul spacing="normal">
<li>Specify interaction with EDNS Client Subnet and Additional secti
on caching</li>
<li>Rename "echconfig" to "ech"</li>
<li>Add a suite of test vectors (both valid and invalid) and more ex
amples</li>
<li>Clarify requirements for resolvers' (non-)use of SvcParams</li>
<li>Clarify guidance regarding default ALPN values</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-https-04
</t>
<ul spacing="normal">
<li>Simplify the IANA instructions (pure First Come First Served)</l
i>
<li>Recommend against publishing chains of &gt;8 aliases</li>
<li>Clarify requirements for using SVCB with a transport proxy</li>
<li>Adjust guidance for Port Prefix Naming</li>
<li>Minor editorial updates</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-https-03
</t>
<ul spacing="normal">
<li>Simplified escaping of comma-separated values</li>
<li>Reorganized client requirements</li>
<li>Added a warning about port filtering for cross-protocol attacks<
/li>
<li>Clarified self-consistency rules for SvcParams</li>
<li>Added a non-normative mapping summary table for HTTPS</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-https-02
</t>
<ul spacing="normal">
<li>Added a Privacy Considerations section</li>
<li>Adjusted resolution fallback description</li>
<li>Clarified status of SvcParams in AliasMode</li>
<li>Improved advice on zone structuring and use with Alt-Svc</li>
<li>Improved examples, including a new Multi-CDN example</li>
<li>Reorganized text on value-list parsing and SvcPriority</li>
<li>Improved phrasing and other editorial improvements throughout</l
i>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-https-01
</t>
<ul spacing="normal">
<li>Added a "mandatory" SvcParamKey</li>
<li>Added the ability to indicate that a service does not exist</li>
<li>Adjusted resolution and ALPN algorithms</li>
<li>Major terminology revisions for "origin" and CamelCase names</li
>
<li>Revised ABNF</li>
<li>Include allocated RR type numbers</li>
<li>Various corrections, explanations, and recommendations</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-https-00
</t>
<ul spacing="normal">
<li>Rename HTTPSSVC RR to HTTPS RR</li>
<li>Rename "an SVCB" to "a SVCB"</li>
<li>Removed "design considerations and open issues" section and some
other "to be removed" text</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-httpssvc-03
</t>
<ul spacing="normal">
<li>Revised chain length limit requirements</li>
<li>Revised IANA registry rules for SvcParamKeys</li>
<li>Require HTTPS clients to implement SNI</li>
<li>Update terminology for Encrypted ClientHello</li>
<li>Clarifications: non-default ports, transport proxies, HSTS proce
dure, WebSocket behavior, wire format, IP hints, inner/outer ClientHello with EC
H</li>
<li>Various textual and ABNF corrections</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-httpssvc-02
</t>
<ul spacing="normal">
<li>All changes to Alt-Svc have been removed</li>
<li>Expanded and reorganized examples</li>
<li>Priority zero is now the definition of AliasForm</li>
<li>Repeated SvcParamKeys are no longer allowed</li>
<li>The "=" sign may be omitted in a key=value pair if the value is
also empty</li>
<li>In the wire format, SvcParamKeys must be in sorted order</li>
<li>New text regarding how to handle resolution timeouts</li>
<li>Expanded description of recursive resolver behavior</li>
<li>Much more precise description of the intended ALPN behavior</li>
<li>Match the HSTS specification's language on HTTPS enforcement</li
>
<li>Removed 'esniconfig=""' mechanism and simplified ESNI connection
logic</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-httpssvc-01
</t>
<ul spacing="normal">
<li>Reduce the emphasis on conversion between HTTPSSVC and Alt-Svc</
li>
<li>Make the "untrusted channel" concept more precise.</li>
<li>Make SvcFieldPriority = 0 the definition of AliasForm, instead o
f a requirement.</li>
</ul>
</li>
<li>
<t>draft-ietf-dnsop-svcb-httpssvc-00
</t>
<ul spacing="normal">
<li>Document an optimization for optimistic pre-connection. (Chris W
ood)</li>
<li>Relax IP hint handling requirements. (Eric Rescorla)</li>
</ul>
</li>
<li>
<t>draft-nygren-dnsop-svcb-httpssvc-00
</t>
<ul spacing="normal">
<li>Generalize to an SVCB record, with special-case
handling for Alt-Svc and HTTPS separated out
to dedicated sections.</li>
<li>Split out a separate HTTPSSVC record for
the HTTPS use-case.</li>
<li>Remove the explicit SvcRecordType=0/1 and instead
make the AliasForm vs ServiceForm be implicit.
This was based on feedback recommending against
subtyping RR type.</li>
<li>Remove one optimization.</li>
</ul>
</li>
<li>
<t>draft-nygren-httpbis-httpssvc-03
</t>
<ul spacing="normal">
<li>Change redirect type for HSTS-style behavior
from 302 to 307 to reduce ambiguities.</li>
</ul>
</li>
<li>
<t>draft-nygren-httpbis-httpssvc-02
</t>
<ul spacing="normal">
<li>Remove the redundant length fields from the wire format.</li>
<li>Define a SvcDomainName of "." for SvcRecordType=1
as being the HTTPSSVC RRNAME.</li>
<li>Replace "hq" with "h3".</li>
</ul>
</li>
<li>
<t>draft-nygren-httpbis-httpssvc-01
</t>
<ul spacing="normal">
<li>Fixes of record name. Replace references to "HTTPSVC" with "HTT
PSSVC".</li>
</ul>
</li>
<li>
<t>draft-nygren-httpbis-httpssvc-00
</t>
<ul spacing="normal">
<li>Initial version</li>
</ul>
</li>
</ul>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA9y9e3fbVpYn+v/5FLh0z4qUS9ISJfmhjKdbkeVEtx3bJSnJ
7SnXKoMkKKFNAiyAlMy43J/97uc5+wCgbaUyc2uNVlUskcB5n/3evz0YDNwq
X82z4+Qyq27zSZaM82KaF9dJWkyTZVqli2yVVUm9zCb5LJ+kq7wskts8TVY3
WfL81WWyg/+5/OX0e3rjx6urN5fJxUW969LxuMpujzu+S2Zlhe+6aTkpoIPj
ZFqls9Ugz1azwbSoy+Wgvp2MBzer1bIezNNVVq/cFP45Tj4+P7k6++RgHNl1
WW2Ok3o1dS5fVsfJqlrXq9He3tO9kUurLD1OfsiKrErn7q6s3l9X5Xp5jL2+
fpP8Ch/gHH/AD937bANPTI+T8wKmWmSrwXMcjnP1Cob913ReFtDzJqvdMj9O
/rwqJ/2kLqtVlc1q+G2zwF/+4ly6Xt2U1bFLBi6Bn7yoj5Pvh8nl5OYurVa/
0Yc83e+zIv64rK7TIv+NVhfGXZbX84y+yBZpPj9OcGX+bQx/1JMhDDDq4qdh
8n1e35RL08FP+fvMfgrtHycn71NoLbnKJjdFOS+vc5iR6WMxpuf/LbvN/rbO
ZuV6OM6ijs6GyavNdZUVpqOzKn9vP/2ajjJ45/+mGRX04hBecq4oqwXM/zY7
hv0sZuGvJHlxdnX64zE1IYe19yJbTW6Sl/ktbuMl7lNaTXv0CB+Un9JNMtob
7fFbaXWdreA1OlHHDx/O8PUhHurh3U26urvGMTzsucFgkKTjelWlE9j/q5u8
TuCMrhdZsdIrkNV09Ht4rHt0rnt0sHt0G6qsLtcVXKMqm8CZSnYuLnbdarPE
t8pklk7yeb6CAVIb87J8v14m5SzxE4bLVWTZNJvi44sUdnFSFkU2wW9qB5/B
7uNxTmq+rngA17ASKV8qHAnsQX4NGzZM+OrxSGqXzuflXZLqm9jBOEuWVXmb
Y3+zqlwki/V8lS/nWZLO8SrQDiRZMV2WebGq+y5Loa+7fIUd1uUkh5kYKlEn
OzoYWMGiXsIlwQ7gxpRzBxOZ5dfrima526elg3uaZB9WWVHn4zkNqV4v6bXZ
erWGL9c1nB3fKtxUnmdWTKrNcoWbjwt59fIyOZ3nsEs/ZjDLXZj61U22gVnU
pcuKdEwzytMaX4DlTpfZB9hYOI4FLODdTQ7Nw1YXJQy3rHksNMvTVyc/nQ3h
IGSeeuGDaXKbVjlvFzRHy4zDgtHye7QPHz/+X/jvs/PB8yGRNjx9cMkGNVyE
YpVP6k+fhu77jewBjm1RwpztYYAVwQlOaHKwXzN6YJWkq1W2WK7wVDmgjjBD
uLwwrnBa+vhirQexhnHOgI4vS1jsVZ7Ooa0im+XcwriEMS+zivot4GwQ8a/y
23SyGcI9eJ18f5ZcnP30+pez58dJfC3g93GGY4c9nqfjsqIzAUPPi+QHWIv1
GAZ77P6sV++aPhtOysVDpFJMpB4C1R/AmUO6/5edr350l7dmUdYrnCcO505I
+y0cR9keXEAdbj8pl0B887pe490BMjBMoNX1HM7iHBfFpbdApOjEwHtVxkcp
YdoOB/wa5zdbz+eb3SSdTLIlHBn4C7oHolmvalguJCKLfDoFEu4eIFOpyuma
9sTRcOm47PSU4X7PDLe322CScjNl72s+WLAWcD1XeEiASq2FLuDZw8HURGX8
Faexw/7YA8W3AT5bYPvZ1G3Z9mQM1+e25GNJt5lOoKFG0tV6XMJFXACbnWaz
FOgH9Z5VfSBV1+UKbwlKE9BuBgewQnohFKEv/enhr7J5dgsXwy3XcJwndNth
OV/gff+Q4rz7fLF0RSZraK9YzTdEdudAqsoC/jjBdh/CWyfw488/TNLhSWDq
mNzAmUEW1k/mWVoVRBjwZbwR52+SdDqFNoH4wBqeA8EobM/8Su3otsKRX68S
07JcUl2p4rqPF3YB/GiMTzOZWy/hIMHmEkfqJT9fvCTqzgyq15dtok4fHkDL
yRlTPFg+Q+iAxPzr2emPgcKs5vUgq4v806e+g5dqODNA2nCjCgcHn2kvHPSN
bAd1ovQdp0r3+Sa/voFHplmdVzrgRV7ki/w3uhWuWC/GQEzgboEAVUwHqypf
1rSbzNJqug55RWzM0WrBe0g4p9Och2AP5dDci/gOIAFPbrL5Eoh0VvAq0zRK
6t2fdHcHtIF57BRO0TVyWDNf3Ay4hXP8HoQ5XE/auxKveGAE2fB66OR9ZS2y
qV5ykJOIRKkXXTbnB6brCXQv6QGVGuo7wLt7sMi/3uREXWA9JilQ6AmcrroE
DpovgNnBIbmBRZjD2uEVZBaExBxam5YZc6kJXN2KKBawnAG2ggeVHiX+hHwv
L+CA/W2NS+EXT3m/HysKG7RsSm3SZIxb6pCa80XHhYb1q/N6JRQgsHHL+1c3
cBiub1QxCFxbRZZ5yepDv0EB4J7japsDsTtsCl+zvAIaDydyUuVjEcHovABD
TpEhX7OsP1iuK2DhmRfEnAhitH640ngJl0u4Q9NkCid0guQDR5HNQL3JmZzQ
vt7hcgDhu4atnXl5K9n5+BGVk0+fdvm+0BGNB1atkcIiUQaSmDNtwZPmcMQD
JOEwS7xXMHiWDaVR8x20D6IdCK50Eon2r1QKcfIevkbnkh5mMUb2MRB4P7EJ
zxP27zYr8G+8NSqrRNQe+sFzQTOAFTtZrSq4w7ME2GI2R7FGP3l28eL0ydHR
6NMnp0NBmorjsXcahnuDMuEdkJESxnac7O8mvRMUyH6Cv3s69hrGTHSHb3Bt
r7DTK0yD8tv7XTKCpoSVRo2hHosnGwR/XPr42FqOyA3qzfDE0JlGw6oaAgbH
9tltOl9n5hLQigK5IDn5AnTVE2gY2nIPHoBWB0dF5RFZF16ka/im8QXeYjyF
JLMrv4MPlNHBgGGrQMIwA0L9A98s8PACu8EjD8rUt8kbP/ouqZ6vBkriLOSg
foIP4LoYmtEHTQpVYTmM5uIbVYC+osnzdGrTzxBG8lwJGLwDF1u6BjLWPbKb
9JY1pRr6ssuMiibc5mU6Rn0qR1EOdxG1iVvSRPnkMA31DaDku9p4qYjuCOga
KYqFcD5x/ZTCQhOeIhYbXk4QxfPMn6igK11cXGarOqwXdoXXYIiqqxVe8lly
d3c3NCyElQmm26Sg8Iow3yateQzEMwPqTWwL17TKsuT0+asaJ4xCDN7YrLjN
q7JASskKIYqCuJQgk1asffPooG0cGUkjVQYaVuHlIyaQJUhUoLcVpH9Oc9QZ
kPzaDnAfz0SKpJEP5mhtmK2LCR9EWGNkfWnyGw6adC3lBTCQnuWguzSuJVK5
Sb5krqvMoWbuIIR9voF3VXhVHs3MyTJ6PcIbJV7Cv+VeovCS0EaTTOSPnW6Y
OwnX6Zruqxq+8AUjl+ACCTkOLBiu3mS+nmZ06U5Z/gtMRhoAcW7nTz+fnwYV
eZduVtf5B/EOXzkIAh5IVRPSI4HkfptcirJclMVApe+r0zc0vJ+fv0nwy9pv
V3J58Qvvldf9dlDkEXXYryldBtxq+B1uEAi4t9muNy8gHbhDzQibwxHCP8gH
Ro+fAB8gQo8XfIyHFlkostdpiZJroEQkT19eXfJoUP8RwyJOGD7H9h49fvoY
2qvzazxSxJZSlrNFSIZx1HBJ4DSLAjcmc8GUVKMsneLREPGazgJQGdou1dRY
t0ZxF9VHUkVwLXfqDM8IsDN4hhiZXz/SxJF9bkhbgva3SeUglMPYyVwRqCMu
HJlOis7tZi7x+hbJbXbXwShgqKBt1SKVjeFiz1hK75CJqCOY9l0Ksg+J+sjw
SdnHx1CBBboEklKut4ioNsofsOmkC+yctE5BX6T4+dyxDFUnKGHO+XSvrJVE
OPoN0OTaGQo8KaekEjH/5SuO+sYAdD8QLrxpZLj7WQHCCw8oAxHlHOA3RhCi
D5Hn0dV2dN9Z3me1Dzu2LB5FMP6z2ZJn/kH5dVaAIIE50gWCCsC6Bazmm3k6
wVNMphZ8t2ZGLWxcJTpi+LXh+I5MlSxWin4cSS98oqQZovcbL01+QRbzOtos
z+ZTJmrEZpZCAelzMYDoMxVSt/1hcnk7eVPlTGqhv2UFOufuMT261M/pCOe1
t4XCBPjIoxqGW1EjMeEpwLRha0ieqoOtAGXsE/4UW9tTWgHP+BMwdKNhckUW
3ldkk74iew+uOzM7PNw57TyuorBZej7ZQasADME3tpuU+lj7htLj9tDAyh7w
UqBoAuRUlw5W4iSZg8aEnVtBMSfhRS+tStudnaUohJiJQetooBASF51d2jmc
IajBQE+vi5LWDt9/LuSB3sF9ApmsWNHZQeujOy2FfcJQ2IA9WVckO4ioWaHl
CaiF2ImYBME5K1ayr44eXNNp5AWCc9ZPTviKWRsMW7hE7oDhLhJhyYbrXgal
k888SiM1XU8/tME4A8kQDhkrYadyWWST13V4rXbCkqfSlRXglZLygIKs2F4C
tKXo/IECgHCVwjXbNs8kLAhpdnyZG4NGDTmWt9lsVpOSmq5WSI7zYjBOQcK9
yyfvQ3fYFXdK4pdTCU5m2LGYrDjwioi+Q8TAk4toJNFInTuPzlqf2Yw/8g02
FYRma9efpquUKPdctGJ/+s3Jd1+lkXga2zfaiPtqbaRbzoIVQF7N832hfhQv
1/Vj1ma0bi+RLlBLkLXw0hX8fTJfDWCxHAg28Cv8hqLN4ycHT0B+w+Gh7fAu
zen68fSINbOx0bMb2Np8Jf6GHa93kO2NTG+7ToyOwZbJQwlGVzPxvsOzo73r
ec7JjHqbqbBFwlT1Dd4g2Ee8QbBtME7vl0CBijSqnDTL0lsO2NoD0vwNrCbK
NFdZtcjJE7hx7vUaCGz4gPwHac0uAxawFgv4lSxjLGf68yXXC94gIgjMUYze
wR6QwOGDMc1yNZ/9fHEOzaBF6J3XDd4xNyOrIFr+4DG8jmoSJv8V9PkOP3g3
RGEeWUpPDl6PdPOb2E/T2Ts1YnqFZQeS/I6l1ne6RzDCPuuyc+JVwSAeTPpC
CqmTIWuVQQqGBuSIhiEGRa4WVafHmlAPZWwUrw+PDpEBxHMjhuknyAtAYrEh
yX5C/uWgdOmV8k34r76pk7C+6PljaVssyWj4yUlCVn2dJfvSRx4ECg7TxZ5P
YEpdt7nHOnWw75t++oFTxnK59aY0fG4l+grumIQiKUkLelo1AHW1RKojKZj2
jNMVqsXlGoypbICDDYEX8JKQPe3w6VPizHTkaS5k+ko9X/SbJaEaPRHRhAb3
PaXiiy6eVG9rZAsDCub0xje1yOK1cOdrGBtwBfjeG4FvUYt7X5R3Bd6NbVZM
GYYdrXjJ1SQt15YVEq9/1RtYjAWbceGqzjORV4EkozsP1q3308+XV70+/5u8
ek2/X5yBGn1x9hx/v/zx5OVL/4uTJy5/fP3zy+fht/Dm6euffjp79Zxfhk+T
6CPX++nkP3p8WHqv31ydv3518rLH588apXEJeUtxgysgtsh10tpNrdD1PSjk
+4doNkUteX8fdlf+eLL/GO4gWeflZKKAx3/CCdygkgUEnRQFILZAI4ATkl2k
Rp0XdoM8lA6pbDgBavBGdeLjA7JVG/l/W5CCGJRVD3l0uOsCnWXT/TbuGbFl
2bt0fo3X/mZB37IcRaEaJiKB6UC4huJz81/ndXz5OyQp6O013ebmmWxOkQ6o
I9EK7fWwZWSap+0aSMQFav5JlyEeDf2FWKnW87Si3XFBHvCLdrQblEUaOtAC
cubA1J3aB4mzqW2i7mm4Bm7qNBbWRcpQWkCGpzhgglic6hleKPMqcCUqh5Ic
DX9w+ui/ZxuhxvrJL6ioDJMzJHX2qRu6nlZ9SAItd0w1MhQ0mNIOk19YlUsp
oAHlGiIykT3NSpLQBywzdusHJ32GMxD1Lu3tqD5ExsZZDsIYqRlAWqtgb3Bk
6OpbtRBWCegnyvEonZL9GIaeVTA01kJh26+Iy+cUL2EGWjux/+VVoJ1VOFK0
eSxQslHnf+rYOqfw8UGklfEF6nrw3X8nl8L/eBe0I76/TE729w6O+l7mPxru
o4AKa8gWH2gCNHeMhrKqu1Ev/fEx1CJIXDo3HwiIRh+2qlL7GjuX7PTOX/V2
QSmDm909soPhaHjIsrYdCrE6lQeY1ZP3LdkbPDo6ggacGSw9/O6/836SoQNW
5TPr0NctM6oLKRh4VVYgKaWTbFBnqEcgDccr1Tf6g77kGhfJnopn0RWii5cw
ZaTwNIwijE67vYQ8GFCt/xNNxnA1zk9enXivNdtzSMdR9szL17qlxP4SYRtw
YigypkRRRVbUz36Iel3HIesnrWGRaYY0ISCeS6Bnck1gHLAO0BL2TFdKJepk
f/DoIJmAjAFyACplFFzmdxQYetob9H5D5rsHvzxVXjvo0bBOvn/1Qljk0ejg
EIMZ6OBS74P5JKGfZ8l/+/Bof/D4BH7/Dr4c/OZPty4HPrT/7aODHf/mw+T5
+Q/nV/AvdLYbvaCt2gb+3HvWi0njX6J3eKuf0VQHvB4wlkvgIyewByCdfUhO
6AW2/+jPs+Tb16dXZ1fwLLcg6hvQjIEnkLDfaNWT2xh1CKcfv4WDuq5FW3N+
tXUc04xpn+HFcJD0U7JvLikyieNz3tEQ33FElfwhUnyBw8+ndDO8C7laEaWD
s4qUdiAkikg9KMNFVjlL6ukWvcdT734NkRwiLuMikzk2miQevXKRr6Af1m7C
oFwsbyUYCodNn1TjHGRPoOlkehd3f5XJObfrlawLEmgHKGV23APXgy9e4U9P
1FD6Q/UauQPOmyZXIrCSIKC6NajjtAO/ZVUJ9+QknDWVJcmkxLd2nOmmplbw
EcM7sjQKZMP9g491Mfy7a3kzp1CxKlOmoSxQLBsYaBJd8Xhtm3qjCBcVurFh
mg5o5QIF/TftFWNBkBx9tPoic6M5LiWtPm0QWIwZoG4H+FdgCEyd807ylIBk
nhixGK0u1RQ1uzGsN/WrOgIG88HWZ9gfs2F2yJvF4bvFH6t4plZyofRoxSF/
XpqMBiXcr5UYD8jSadgXyioFKQLXzMDEEEI6LYYj4TBRceXDhwImRZjB4aZw
wgE6UnjLA5/rR4eX/KcoaaP5ldXPeVZcr24GaOfJP+C6YogGyZIkhASWu49P
K3dkxT/iB32a8Hqh16PCYO1iylFeQdaAAeyA/FwvgP+TQR3mTNw5obWplT5g
CHVubKq0xjh6+BpVkAXanIC31/lvKGkZqtCSZjkytxjQJadYOmO3qcm/jSfz
85y4bq5k555Kw7oGkZSMUyNLQXOD7fbC6lySEpGnRTpgEdCfLBWhWLwc7n55
ALy73sZqZ4VrGZ04DRTYozXmPekeJPZb8H4JD/eeGumQDWY4GDKsp2qEi5kQ
XD8OLMB7Oc3Y4BG2PJJ1YmEnElNynMOkyjg6W4ULGapT4z7darqTeCZh/HBF
4RBi78iH+I5it1kx1QXji11O0JyvEQBBZMN1aMk66LqGp3BZyGm/fWTfdiyJ
xBzYc+ND9nwsS/YBaPuKw6tg5WCOr8pVFtzbNVw0vkRsTxLjWO2fqDIZajJd
wzeomUfLizb7GZFG1Rj9QvWtZYuWtMpY5Lzh8JhKwlmI38woJDqdvEdWgFeQ
aKMxS/vIczSHiLHXOBZYJmQbhDgj5aLT9/6aqd0q+E9zySCYp17KSJM/UZjM
mNg1CVcgHJkAJdZHxR/KoWoaWSAdsVGxn3hqqe74NRK6Guhb1kdvFhrYKSAR
GrKORIpW6P1VAli4tWG6zG1Ez7An8UWg77Mvl3wyGkIH7VCMC8bvV0ih9RsQ
coE3W9snbQ/xMK9bw42pyiVmHmSifbGiIJYLMmwOasmGEXfGGwmngUOwXJJc
KOarmngpCxob6xcLq9HkK05zRmj9s6mYonnAalnUBiWcwjKh0fAAYyn/9eeL
czR1Hjx98ojkUFSN8JqVHGfBORj5XLRCik6lHsXszi5gjtfQWOQctTEbBxOZ
l41AhQG4GVlnmeSpMcn13uAbb2jGySvaJ9FLUITJV6pC6fZrwCuHfxu7IFI7
2g8bEOm5gDcbacfK/FJ2nEs0mPhRVQMnUwhFNLDfw37Zl3DDiyAMepcm7SXJ
hGguhP+H+AcUERy8zkYQ7hWOF4WOwTEJyvShVd0fDUdsEXtBjjzgVmiQxJgZ
FRIWsAbTlE3pcHbTSpQQDsfAZdDohk7faN+pI1QiMuBI269pR9DYQw/gLwO2
3a8rDXYI9LTwYXPo/OOwCzJisgLCsWFItKOwMdF2MM5DwomBpkaRfJhwNGlw
JqAZa7IHq7LET4GixImTWe1NgNwxuaAD6UL9pWbHqfRCj9KWYQiDiRqcULwT
pUnUNzbGQiw8f31yeHgw/OusLFvkKXk82ttLzl/xAdpLgDYf2gB1GAVMQe8Y
r2IPGjp++LDR1DF2IrZ9PZgU734YB7yTjN2aBnzVpxsF57T/xQm1RpnwPPxE
Djoe2XGqb4P6XzzrjdOqR2ThWe/J3t5hL9ntmCufFB/tTWYZPITkn7Q0BZvo
Owlz4ji8WnyuQnC5QzyueP+MXzokx8ENVMKrBlGlX+0MOjqbshewrG4HOD6c
QBwwD1St9RwAQsobHP8xUNb3uNQod//WaYl0akz9+HGL/QzDsR48YCsf6t38
Gnz0IFKC0JSZK5NvGPf2uhy5MKztoVxDNu5jUAvJ/fz854O2kJp6SY8FCxBn
+pj9SOKQaKVxZDGHEXGeD4s/RsXQwZqR9lUjypdBkuJVdyh32SE2ojM4HFxC
htmajzJcjsLmuiDZMpsmIfuiVrEgspWytmAcNBjJXGcc8ApNcDqTLgCZHlRl
i3bFR1N56VPkHb6vnpxTR6olaEoF5aDYqeL6evmrum50RmqPMjvM1uPk3eaS
UxqkhjhE7iJNgnC1mqujpvueIsseY4giyiFwkWBWSX2zns0ksZN0Fx+nxqGH
3s3OvYlJzhuMFn2yY4GOjJ8WOV4ZNy/T6WCcztNiwiYWuhHhRH98YA40hdI0
zpC9DiFi0aTopsbqrRm9cnpkmuQ0pPPswwCbyS/27HJCW0j0rTwpCAtILjsJ
gnIhDkw6XGI0EoV2r2Rth+qzyBcoS2gODsW/6FLYhAafiyuHDqmSwyjkvtja
fCYT5QrgO+qfo4BlDmHYf7o/CnRKfQrtNTZuA4xkwwwrMuFJbKCX8ekOyGxp
sBRx5Xy4FaUU6vkIqn7LXyjhxiHdeKvDfNf9XJBSIUleYbX0FE5LXoLZTLU0
E22Hse/k/by44BxzSaqmc0/HgoNS1Q7rI6eoyUIVPqPiyEaGcVj/kPeho4RJ
cb9O7kxDriT+fUcsnbUpVqXmZbls7o+nobUloqS8BgOQDweTgzp06FAbMBtD
k2nFuky2wMzo5E5ioHKi5801JVHauEGuONKpYXJqv0d2qJBxiksoBh22PaZO
Ai1iqAyWbMhlO+1ok+QPilC0Y4qFTbaVh6xHlgAiSWzvyR735Dh21Ma4p42s
P7l30EojN9Ghas0iGDzjRUlom0XJSIw8eBSJke3WYBY/0wUIk8ZjFgx3ZAoO
+YUgKCPIhJV5XbtVjo6cTplELYAFRRyoxS9AOXMc58xejmDfppT1G3IwIl23
c0uCApF3DgIkskVeZ0LR7tJN7WXXhmZGV8GvgNLj4JiYp5Mo0VMpIrE4e61Y
0ORLhSRjvnGS4WcT91GHsBQ3kygEjhuerVmG3JqGKEmmlAAl0eGxeURMJwF0
ItJosZFhnPPkmoe3I49Wpf8tJzerHJoVGlsQnVWrMVieQpktcpA7Ty8Pfa/Z
essmZ/b0m9rsC5Ed4SewqWWBjnFOOCDOwnuqh0Fd0Iaomve9ipRGcb1DH9/M
4Vnt8GwinGxt4jfJ/k94KnMk6CWndsI2UqZCJpIGnn5Ke558TfsqYLp5jlRW
gjVX5Qrn69PBOYVb5BgMYeLYcRkcIXegqSLwMCf7rUl53Lpx4ZDvDKT/IZws
NIRmC1VaarWQaVK9WNzwAMyzlBzfWYvkSpAabDbwU+O9074dWcFnKxGqbX+w
lv+T7A4iKPD94E4jqbVN5oULFPAvalBOLx/buCj3yMAwMDoF2wMwKWuyMSAQ
sJzIe9B5SUACdWZPf7+Vji7vMM3gvF6KwCM/PVp4ycBL4esUx27wYsriGs3t
3H5E1tI5ktbrG2bsJmSX7rskV9jQcLmbi/z6ZiVQJOMMbaB24t7LWbHsfadp
XQaswNqP/P54EhDxXsfLE9FEj4aC0hELSvCUpEmGFE6VmJSoxQw5ovF471lK
pbySUrEiLnWxENkoIRUVb1M6FK3ZcK2PDyIltjvk3hAN6yv3jg1/sUzYm/NG
h21JZ80sX1ay0F5hkp1CdL3GnHiThNiq6UYgVg+vDF1Mlo7IrNmwQOPTDvVe
kgUwurYRlCP5+bTXBnCEDhTyAra8o/CM8YLBVx5yYNgH5Zpd92OrXYe06Wk+
um4cbiwu5XWR/4YH6dJ6z2slikIK2KiOAg2HJFppktxRF5jN5GKNmaRK1Myn
GNc7nw1CdHAPJVjcCrM6GAZaUpY85T1wcgN2900dDcOkxVg3DzuFxL/nJzZ1
8frjrBtjYeaF3GqLwwjpaukIquM3TiJT8sPMh+Eu1KfVp4dYgm9SddYzXIbR
9ZOsMZAJeWLvsvmcXfqXjShLCqwcUqyuuTAfH0zL1Sdyi5lPb0R+YS6Ab+1Y
H7Hsmo2lQCO8Q4Y0EEcpuUUQqEGGwcgPRFeGW2wBPBKkJ+ErtdMgaTED9HNp
WWmUyKuG7DGL0CivHsfsQx4Yq0myJRyW27xG/Dyn98HzJk9LzRu473JXck6V
FfwppHdyQ306y8ooVDCvNr3j2bfEdpp//vkd6nM4El5tI4Q18gxVLNCIGDqq
pEAj5TPmFDwPJoySw02BW04nmDVrOpCj4I2nDfufY78Ls+KQfPYNhraTfRbv
mG3vs4OKeY10HaQM+YYs7aPI0u7y7c12CcH0483oW0Vhsb9vM7+ziNscjH8t
/rTZ3X4yZIv8k7290ZZXDvANfOWEBrz/dDTcG46GX34cRZoE+ts/no6fHB+P
OE7+VKHU2KUE17Lpg3KuJ/xdpVSfziL+MXJkUDxAcC6rNXGgNlwfIO+aeWu1
Cj0hWILHECD7vI0nN2IOH2fxK3Ma7kuQs/5FHONZxMjpoC3n69p6jdX17UUd
XETh4Tb83WQOj4bJOcqjcc4gvs79wiMHQ8HIalC0YOb3/sjwXrKTzlD+Cyeb
dRcckVdfkLSGGaJIDqTKpsSqjo8vBQ+2znJXMamWPowBmMgyGVHesQm3JVVI
o19ID6jDqxjawjbGm2xdYfTvpFaYgJCUMAMSHFyQh7QkFmuqFxTuHvotFuil
BwaJobydDgPkxLpuNN6V4PkJi6Ld7szIgP6PhonxnTQPFVI6HG9mlFKfrUxp
PiG7I6cd0QhL4iV0C6ZrMh0Kr6kyMjmSgBF0SONZ5SGiC4p1etTXjCTTIb4T
wAmZtaHN9A59XXL1hK2caCCLEaHItKGBpSJAkblFuFTS5lKuY/ElHplag6nl
KUpjXro0whXBl1TZgHgtBqR49BLB1kA6tyuOeX+Rk2iYgRbtZB8IUTCtUfJs
ZL2EA4YrQ5BeoC74ZMMu6yNF1sV9NXwkpGpSrGWKICvZnEMqSYDFzVLNiCQP
0t7QfC4JM7F8HkcD4dJ3+PvSMXsacnFURdBy02yebpxa4jngHJG5AvoGQQ0K
Tm6dTPN6sq5rXafoS84NQm266/CjvZHSwsnhQLMV1By0kWEqSLnqOzQgf86W
kNyltbIEvKPbVlqD3RglwjILvnVp4XOfG5k6xPopUsCbKpgWsgTiwxb8+yBz
tPIdi9LYlpNkh+6w75CsA4h7yRIdHibWvtE2QIgVnwkAIzQOFTHZN8ZnZcta
UGcEaysSYpeBnrWTWAx03aCOaHgvysjsq8AhQhtoe7Kph8/cclpDXLjYvaZK
EENaurn2cnswTxLBS7Jq4HfUUOSaYes4kcR5Wwvl091te8f0omBfapyh6ft0
/6C5zzme0IYNq7Y2uSlxMTU4FP2YMlc4dCQYpBS/wNbcH+GTTXK2ycYw1poA
bPET/eCXESWoHuxRALFKz4EIR3ve11BgQcH0S0yWNuY1FukLxCThSKbRgsx5
HuqWTs32cyj6uUf1apALStH6LMkglBhSV40wgTGIqHfmBaneKUgAHK3hY6dw
fx6eKPYlK6Y/qkJqKI9S8CBzeppOqym5mYLTgMMldKHyukqXN5JyhfyFt5v5
C68qvHl5dgojchhzBPv2vLxipIGjJ58+0d8/cnLxk0MfRNUkjDiY2k05iAnt
RWtUtlbKjrOqKoGiXJ5d/PLi5PylH2nfhKrIMwi1mi8y4LPRbqpffoxO44Kj
YoIeyenVRoTtM5hb/tljBtfFCDo4alZ9CEHjPZla0Yi4QOWWXL13BSOv8gPI
OadZ4WNREfOgkXdv/XInYfo0VRItKMBY+Z04U/Na9mSAAFZ6qttOdfOgRp2h
lUqFMp0Foyz7O9zVkH9li8BFSDqNnSKwG94onInzM2mvY9S97IV22XYaoNTI
dIlzx6eggCx9/q8KFZwZzMe9H6FA5BVlBuBBYlmkHOMsODqUY2frFgUSi5Eu
qAnjw1bhhjLn8B3meiKdGILV72ZeXJbzfLLRYID2YdPVYefrNJtlYqGR7uS6
EkwUaU3XJgtabzq73QgnjnQymY+iJMV4xFsoBaHCbqcWxvAJXGEFd41ZdAd5
Ih0zRb8OyUEF/d5F7teFggN7VOpmk0JMyJ5sVCx2IrWD0aOA80jA8ayCA1dn
bAKiMMpvIt8ErOPUWL+IFis/FcaHKHQfNiG1QD+WZFJolXXtKALvw4bDvwmZ
5fT1q1dnp1dOYmQfjw72QyDK4fBgiGHNFML7+vTfL498LO3T0RPOyb0N4izx
EkeMLV3EKCs1ycns+SVp2KyX17zElEBxZyeJCkjWo2FxWwTrmIOA4u1UhNRs
6pTT4oCcHZCGd/GCxJjECv1jrAQeoXPDCdiJYgTj1ZnN4BuKh1RMAqQcu9Gp
YA8Qr1fpp9o8ZZpWNt/01c+FfH5eeqEumgNyN2MrwLR+voRF8p/reqWGng+g
7+oR0XS9GEVW+VnFecpq5uHBNO+CC1ozL2JklWHMdfwko+HoBuV1szDBNjWD
fS55zUiPjRViSz2ujzJ+VWtd9D4RBt6AaKYULE5ksUUIaP/xtHj47q5z3JYC
2O7DCRySsdAatuhWfZFxfR4HhTLWhKykMYBO7xJFbdSJCW/w4MkNtsV7jHjc
WWEEVaf0IPJ4RsukRz2oZw3vHFENpmGOuvEBHBZKjY0lAsJ3EmDEgiBJepWc
L9JTUHmtQSyqTAUHgRtF0TQT3FY8BcposHDKgJGqfT5K4DBqtDaJgPksRAR6
IAmu7sIAdKlfVRNcFoUpXtkWEW1WqshwpFNU4OKGclRvUoKntF5wwSadL4vd
uB5FezomXtLDvxP7CHU+hs1FCjBL/iz4fKDAcLsWT4hfKafSS0bnb24PaaTw
y6PAsa2pVY1fIGGWnBeh3NFeNz9Fq1Gbrjl4ltGopQ8vPGFjIfM0Sa6zMuCu
Ix0J2/9NbTpiGLNZWpNNVlVVHDoCyrZ5QAgg1THwCZkFMWqWLnL2gxGFv+Sp
fx8M783sDmLWJ52geB8fbIGo8/HEIMHJelpDdX+rPOyVeLaxughYL4oj246r
x/l+FkUDwTYkWNE4jQK7JRcSWjqNViBnQrkJY/fzTWGAVrakFgTPy3NA8TZG
9FtFxV5aQ3YCduhzk7KJJiWxzVECXDBLuiME6OODDvBFWvqV4mp2KgFst/WR
QWJYo+fZwO9n4ThpmDG4vJ9lh+J+JFVfozEsh+D8JhavDo4QMXjXMWL0ShBx
T4oakUUV7LGBKzl0XdMN+IPR8DV3AJ3cERV12QdoRYhO4PPdmEVyf9DouV5Q
ED3i6aqVYUw5p2W1LDVU0yTmcQifJZ+UGrmKITS3TLXlOzr3/Xi/JVxqb2E3
yxzOb3uXv6GLjzRm3uFGSXaYg0j5k4Ao7hFBlBbx8wxYkySMH00mAbomlFsM
AxWHFKe3hgmyxS4Gl+INMLHGYgsLKWELchtpEHtfAuDY5rYVxJTuDFDZGJx1
yP7VgQ6tNRQdZD+5Lr0fat+/ZhNdtm/LiR2Nbk5fcAWp0JlZp4MhTH7+5RUy
7g/Y5wu1OfqusGmrTpCZJoKlrbwt0vrMrScf2wBq0Bv2duMJpmGEOEmxfJhZ
nIvk7W9VP+nJdHrJIkuL2s4Qw2C8Wa5hJDEiJbfDiqRJeUyNc5NIAEe2OAmg
IJJcG4clOaZ8sGO6ikYiuouMBhihhieyXCMR/8/JsUkIgPAL4Z4/eiwZlmdo
oiErSVqADEM54JiyOdY0GUMadE/J5pv6oEClo0gkdFEpXN35EEu8ByDIoDih
L5pJkJRDAGFqHQiUUziJTdlijmhIUTrLrtepXpuO6FJn4yzZG7TKSYBD32vt
e8kLNTIMdATSna/YFlt7NSjEb7gEogD3fHToHP1jSH6I1LCGmbKtTXNSO203
isNOXJQ+cNJmPB8N94ePFXjj0f7hY95Y0r+YtfBoWik2DYOUDg6IZHkNsvYd
izwKqke3tOkWMDeUKBYe31p0ucAsgMVekkccT9YWiOXgTUA4nqYsFDJi2ovq
D1n2YVWly3KuNI1WtTkrsfmcv3E3uVe6rR5hcLAQWmOQL+lBXtSf0Bfq7bgg
wdN3TmJIKQeybReMQF80fhzBcektAoPgIPuoTJovp0TYPEmc9NyI2JDaL1zE
IgrRc52iRyOmWeoNdCTCrYuO+D0G9NHtCtq8ROqFpWxguurUa1Cj07+txfSu
Nu0ICETtAAia7r1WaFnoyhjjgEHShlPxIHhnk7eke6cLS+JE2fyMGFhDtXrp
PNaf7CH5phFEwJG7TDo+iBOVcx3Yy5hHCa0Sn8xSilO9rhmg6OMSwiVg57vT
TDWBsYcHvJ8GQXrxzR4qtMgFAwWUO8/ykjmcSHt9aKvH1KHwDtF5fCILaT3M
vHiplFnh2sixf/3vyThfqS3yYDQ6omx78T4oAHEg0RTmt1V5onOK2wAadbFx
gkCAeZxtdUkFUm+IIaImHVNRgGzqw85D/C1fQmI/dOOsxq7MWUBwRMjnpYYv
zn/oJ6+g9b7D/x5gGMSJPTKWRB8GbKTR/pN9BOLo/VwY5xcMDjNbReueEpLg
hARTlmKHwyFTgzBjAjzXaeP3UqKEK6Po20By+TL4ck124mjlibAcaKo4T0mO
0QHxxlMm20YF7eilzqJ7kmlpzJDD3jZtSAPyWbqY3ARF04vx7e2msDeCzkA3
ynI9Z32m41wYn4z3W1MvJKNjM1IEiJub8SopPnzYJdCd+FAx0T3D8yrhfpfr
MYFTnp1e7oI2i9ovhwl0PCSWRHy2L6rl4yePCU1TrEBdpG7FBTWyehX5a4Iu
Wa/zlU9hSA2crKhADl4jQ1+jcC9tqQIrRk3voKNxefstcrpA23ep9KO4k9a1
Py41zW7QYbCjFPMu2UyDhMQa4a8urIyuUl7EPj1GHhPvl3y4/fY9HhpkMl5k
uH0nHEQWDtjbP3eruG//EqUKrfJM6rCIBQyxeHzPwKOc0pEg8XvtmPnBn67+
482ZdzIHI3K/LaMxd03NWLdTvpRqmaFx+fL1zxenZ8mbi7MX5//v4OXZqx+u
fqQcJ7Y7nb5+0/zSogE66SJsAM6w02JGC0MCG9EYP8Zweyi7ITqVa86cwDnV
q/W4aRHBUMzO8a9KiorXQCAycncrE970LWrUYL20fAud0ELWxBmCYjBoHljQ
BGft45fIhrbI8fqICLAmQDk4SxyRTDE3uE6NkA89acFh93g4QowLDBzqXkoW
9nEpT9oaFyWkSopDxizfG3Moma85UfIDqwrJ7zDmFY6O0iKMrMkIwskbI33G
as7HB3EMC4ePS0ne2J5OtjS1O5ngGdhWGBzGAex6P4e/+l41S+WrAaWEIdUk
Go0sQ9Wl7eefsXKt11tvEWZ3URIsHm2m+hJ/JmNXRTteRqIqv/rAUdVWfNCR
vmlElr44dmgY3muJucS+QKlsW0hq8MvDeZQdGbcsmqjLCGOTTO9tmtpeYArA
xAu+luJIcaSb0lUbomlwiWEuTgzd3gVAMN3TnIKEfNigNdhwoHf7qJGYREHZ
aQPXg+S6IAI1owk2HOJMLtRQQcqZMQfOTrl8WNLqpNu05h0LxqgupdHooGP4
NYXcmi2ykWYkTwDpERA8ZZfGDFpV5DyRY8YKjs0Kj85p30ZkUB4Ml2LJomLr
ISjBur+9EPbqNSIRNg0vGF5AiAXFpu0Sm2juI8UGGlRFOzi3BtlnTjk5PKlG
9rUGBUcwh75lxaOkeM2AioURZKaaXcBgdO18S0t79EZjORvayaM9oDbzec6A
hrrgzhe1Lbftp6ZI0HCu16APMYK1+/ixEY9I5PGkGWRsqhWLl9JWbou81yxq
axQa6qigoMOlyaJa5xJtnb7nOEaKGpckYM4pPp/F/uLOUfiYKjLHDICUXOPJ
dKaf0zgmRq+LmCONgQIHcapwv6GBRqIq4VLFcSPedxiSevl6i1Qq4esuZHTi
eSCon6vTNwoKsT86OBz+dZxWDVAIgwmxj7k5+9sQuUBsfYRi67OQn7PPmUDY
dLLrH/zMD3Uz6kgB+mw3o6ibRjDDjWKq+t0h96fZIeAN7/5sWvvLMbb0ru9y
3S+KN+Ytp6XzFzocb4prlAxqMpuTFy2A9eBnvCs4II4w9jHjHIFhkO3aVv1m
hRkyVHedPTsqHwkSTWFrxHSjXIXrrs7hbV/syyoUgTuYc4259eODLiuvWDti
manhZOuyW263SHlTeKOpLK2kGDgDo2ekH7AlViTA2hGAtpZCCphujMlkagtr
eZpgLWx7xxzxVDYGbClwJ46iXQaZYfuUljAxurvzvSzSDyTgeX5HNu3QUd9n
jxiWpyH/CESNSPI1A8gTymcxQfmDCWUX5IgE0BBUO4GqZBWqqoJx1u8QggKS
FB9pGmBckdsJXJkN8TGG5pNW8kfr8DVCdoxJlcWPYBVxLeab+2TqqcbINMKB
OLFIQrO0xqBqZ1oyxLtKQEej6ilbpHhqzp4rEusaWqXfTwGPoexWzWYyEDdx
FSoRHxmHpYutlCFqALcK4Trnkma1ojhc3SOWwpp6MWxF8Ms387Bsxhsv2BJv
3oppbGRV1XV3XEENnckSc0v40BLkxIDOXWj933aAu3/L4Li+ohWtmMK2+1Iu
33bqz13RHsFugN3FpzqKV6OvpVar1EEh3atZIyWUK8GwBQn2YgtTbHiNkVms
GRatHeQr8uvmjHlDqvRtxR9DZIy5cB+9OZasp5LLbg3tAo9PNIi+dF/oJVkz
TIMBOgRGsrJwDcMmie9KC2qiQ+IR1ZP3L1cJC+rcRDAqlE1fGNuthYCS+4ff
12A7X9yLpeOa9JktU0t2Sgl/ScUKBgc1m892j+m6RbhItmqkD6tDs0EdwKEZ
tNqn6GLNSPmKcjeOjrDAts2cU+dUDCdDfFvT2DmPlVNrbV0oKc3tqQiNFr2t
ih4tR7BW07XHXodWM2IUPnVOSKSG+Cjwhyuyu21LF3DiJjclWj8ERQWx1udi
wcYDjocQNVIHzGhebgReGYFI21WZQH4gxH3UCGbQdVflpqhOE1VPo2DFOpNi
3YyiqkBZeKK0TJeCh+NyUlkdAe/kZBwGxva16hnCZKIch46JU5jsAGBBWCq4
Sl7sboJ083lVTG3ePj9S0wmOCp3tiWLeNGG/WfIJWl7D8WXQ72iZUNhQTTXo
hsQODPFFSSIQXFHT2cPFCbRFqXjcA/4UQTCWVHRF7O+ffToa0qq8puPmDGBv
JnVJsNzOXBOVXqYbGK5fgFfZdemLp568fPNqN8DC+HqdFWW74beUNnWwt//p
k4vr03Ug8taK/Kv6OVolmyXAd+gU0eXA9nHEvV2WYejiSYlYxIKnCrEoupBx
h57uGKotgCqfbiTcNSyCf68xCbT3EjjZ1jk0hp70AtgPvotjv7pRLMaJz+Lc
Otgi8A2dfxvShPKF4oXrG0Y03jQjrIPaZGr/kv/P9XA2vV2GmQob4r2P8Xxa
BYMZsg9HGmZhClHMcn+H9OzFzxJThusw6eqNUdGcLLkmepFnm9HJyZKNQY3C
ddso0LT1O2jUd0BJQMk4HaB6Pvj5+Ru8kKBz8t+guFL59C0bE6H9IaAtcEwE
FdQDlTbXSeKxi+Rc2pCTdqnlaMiO1JROueA9KsJU+gV+2Q35Sq0YfTgGzdKE
1sHTLOYdHSqJ77nIImRrh19L5EKzOG9eJaa4Qm/LvHpu5x0RrXz6zrPuvG4U
4tkfjI60CM7QlyvDl6gGGXxJFb/YPM9Ery/nwxDUZlUn1105KWlWTsILbcEm
/IBRIw3VB1sAesASMFmA4tKITPWFFL9927P127DibZZSYZWGEVBLR9FI3iVw
Y9Ol4CBonB0mngggNd1aijChYlkKO04n6x18sv/s7d7e6Gb0ble22KGpZOV9
43VmR0XniKAIBLfWYjXd+ooswmJMQacord/5xQqFQTAKd+XL4XAZSoZWph32
CZq11ugZUHeOq22KCQYJXJGKdEBeLxupIoU2RfrgF+msEzQhhgvmEhsZvfFd
kJr77W/xXPpiLwIl1GKrHeeOC4I3Fs9rzo7RP0TRb7PpZqFWgvTuO1n3BeZU
qcQdPcdyrMZgIYgxPdPGQeuEeSfhqYU/x2ZNW4BH5Pg06Sm0PnJgJdwmYD/i
g4UYg+Yhw4pkLPElCRmAC4R4GLo+V2Wog9QmUJFtl6zgAdPcow2EmxtiK3ot
aUiAnqdTZhhmYqpt0W3+nEBFRQQVT5ko58/oNIEpeDtf7OIQXSqwZ2tf8WBE
JO/jjAek7aoDcBxJa0H26CLkPgTIr5WUVxhi7Dd2YpseXCmLrBu9rMIXTGGA
+fSJBfWJbe46KTuuck80rO6JDDGs+oVGQdtCDtsG1U98ZgOnnlIXKMe8xBp4
jYpfW3gQEy2hBz5iPhxYHKeBnvEBzH6AfWMqQhtPpM4bDhpjj83az+Cxeftn
Uooe7g/3sYTnzUHv7V9CzrpEs/iaGKhY4qNcl/zhiJ+k3w+iKzGJfDHBCcsm
Y2f9EOrXaS4nLlNzdCM/OukAE2y8x8eecDZN49Hof6kDnLICzDT8B367UXe1
nrR+kKgKo5MI3o1DCMP6BrFRPGZJ2qqATSoKaghf2E7H23lq3LTWle8TvAyb
Vh82ko8B2wcrq/Wg52yhRaEa3zGclNkzNYT7jjzGEYh4t+t5IXCuJCoXOUeH
cZK8j94J2fV3N8AY5uXkPZO7eBRuZe4a6q35SqPgYCRYZ1BC+jusJArbpF3W
Uj4kiUPHyfuOUQpx0j8OC+VdgmGi2DPOf5X0OxjXDAOt8JFlxYJManGGAvmw
zqExgzGggOxZPRc8xdQZ0RkjoV6yYykYqAHQRXw3AuYhwtU61j5gNAI8CpVn
lBU16UUDEAfldL1aMetI24oxR1yRrdtTFx+XoQFvFIvk6ZwncRyPwRNzXlTg
kJsQDGKjFNq4pcb5iduGR9Up+MA4rXHnPgNuhdS41PhoY97ywJkd/DeEVZuW
JyHHnc4GQWvJZXS2ohk2IRjUBl5VVl4Kk7AwY/cQIWaLxMTn2mJFrlVtyKA5
cUpox60htzxGv2Gwowf/Vv+hWIFICefifyFiHz9Uww8/0CWqkcn2lLRZVGqJ
+HAA2o3GLmjdGwWNyetOKDyB+IRv37PEw0AFjXInMXxnG3NCQLWk1Nywo0C7
6m1dlTpFV2T1YQrUfEGBuFS1022p2nlyeXp+jsq7B2PTHrwWTjInC+q7jrvY
wHA+cJQ9C6OCnFYT6a+0onQ/FpKDhi13zpESl3n1tu7QrjpLkgpIZhxNM5JK
o1o+81aLh3ZVJqWYHVps9P9SEU5sYwY93+GF4wpQRIp92jU5zhqp/YqPa4RV
LPXgvcemjhe7VDVaER31Pjd+Toj3CgZka01SxGy4g3Iusw9ZNcnJRbcOYSMG
98ocduej+zcdhQvlDuXL20MMXxClXKMZWtdKE2HkZm19jatic0ZJO0jZUkta
jdK1MJk4E3RL6JY10VHdeAKhcR6duAsGQmCFWZe+EZg1kw3ZCJfT+NHuILnm
IOotgQkiDsa8S+9/WBgWzeAQuDjXWqKqDDR5KNJAaVIsvoYwA8yQsEDmAW0u
bAH0xWlPVDBO7C010FvcAM7xjR72/uC2j4vzAZIXkrEn7hldMhfhIJkRMCPS
NHP0KQLlB5aJRa4SX+QKqTL7M66zUrLYEPWIJAy5f1VGsFoMtKVAfFGVkq0U
1Jew/J2Wr+hYa5iGiZNgUAKu8SuoI6vsw2qdzpW0sVf26Cl62/j3wz10B3yW
pLrofjPdb9LV5Cvoqk+w9VbttqkxmqIpNB4IabKjRpWKKsCwE5nfGfAK7A7d
S8QzosxFvUdcK8/aI0xPHniWKmF31arrvFZULcxQmlJzQnxhNqH9J8rT2l3n
Fn6GjFABEOZL6BvcYWD2qBpQQMfvwT/EmCaOdkEkFENogzGln7w6uXp0GPUX
kktdY3QdGh76n/aO9hjmNZBH29t7to07H2rZSAnvrqzKwYFjFNqiohsS8dAS
KTXtA46I4SH+YFLIESUpoUuj+fRh42k+62Tp9O4aTidcUSnhCAjWBLEYQVnC
sznUKd0COKF+BQI3CuJqVKKBmEKrtKwgf0RVzoLDYcZOX28L1NKALnTWEeik
NlNDnEVIktqzwF1WXC6olUC/o8BfZD27A4l0lVGgMWfRN3fNmZGbhB3lqqBX
Zj4lg5On1oWAZYU0U2RUNkpJIIZEHPGQ1Q0BZBCwrDVd26Bbc9hQXPSiXf/G
v8BCyscHts3zohWR3jeV3MWaqREK6MsxQxUrFpa9kOI5brYuVPeqME1qvonq
ynAskt68WG7DvHwfed+qbCJ7EAQ7MUXSnLyhuQfiYYnxZiwfhbFKnaOwFjbX
TWG/1cDegFlCmTKatikOqg5zVKYbC82MAuMVLwhtzpSjJUi5aKjNl9uF+TAY
u13fxGyMjQkjY48C0Nk4XOdTm2tv9Yy79ubGvFJnRVzHN5hZ3HYtvvbgAQHh
xFgFtAgsaOENHT8GqcNjZUI/JiuTDuBzJwKC+u+TfFxT8kkakg/xx0YmeJZz
bFeHu5MrZ3j/vGDsDIJbDju0A+U0ewrFoFCS5TJLq0RMNMTD+1HYiD6Bg3OS
GjLR+nCtqi5tF0+fpg0jpaPm47Zc6NhqoN4itF3jdfcXz1p1GEOIGollnI2u
Aosfi4TJ++hzzACGWTw6Ojg4eJZ92Oc/Dg8P4Y9RONnP9OO+vkmkz8iHPAgf
AGTL1fg9jhRtYnZtTbsf+ydJGkZlmyTjSZVxALC2pMr5VdO3RlYXKn+4hUz0
Yxd+2DqMpEZIp3CiVe37PMWxdkZ7DhztAR93zBE8Jw6opXsRqB1jL+olGg5w
SKFS1A0Vm5CiKVTmOuG6lULHku9zMmTUIUwOuBOH8mGJSwmA2QRjKT0n0cIk
ddQmmCLk3wrPcDFegVjf1G+mwqEYvoXNqHRPjg7R8jlMzf18cZ5ooBnKrzBc
YsHmbjRLJmFrNC3gFwPEGZVw4Th+EWMjJW6O/OHbAvv8fFQx1QA6P0qNpWsV
qcJYM1Xwm0DBaIZZrprIueTel5nrr6H5DmIbm698so5cWBLQrq5ehgI1Nvzc
1sLVm84RtKubRo6VrhRJ9BSU+In5JMU/ryQOmRUhp+tcC0e33lwNLzp/Xqvk
KJZEqYnkXV1DCafrvj1i+2nWHSFphAyxrjMCD6/SSZzoEQt3Rq9aA48SfmMA
fUJsZdBmpAqZx7ZlEYeuM1zAUyuFqRVQ3NwByFa9rnq6EF/DWUh0OnrjlLE4
4QEiEOTH+PjxxdnV6Y9Ud6UBt8Olxb3pMXi9G9bq6Gj5GDh/YRgXUGV88sH4
iDcX2dpCcC15OmtUITJJQlGDVCsCtXaN5IebGlFwlHZICLk/ViFIHGQ6W6wk
vi+whC85sGGesTvBQ20YYYeCLFLHA/UYIQGDweai0Rr5RdFUUDUSF3iha/Rs
cbKNj+oiWmTAZZQSk18L89mm3nbjQtCkISYmUENkeX8ew6JoArxN9AjPSVAm
Kz5/olhyBn5SYsmNCCPgckmN+dJKvcFj+obCipC64IruNGos9TlHC0U5rufC
nOBYJUjZHYRPM5TUm7Hh88PDA6LYFpydgNDw+AGl/5NUU3dUtFuPdFQoihMU
gmL6Te1VUxkgOpuZzdFkKFYdSez3mJezKG/1zsXR7MiE9JNPn9xajiyj6ymk
csB9VKdTOZvNMYZGoGsQLZMrojhfnk2QrG1MO9chbUe1J8LR6YLbWUsdtmYp
uSwu4Ol97RqZ33ec/RAgYbniKdcF08vFMARcZFco0+nzV7Ss9S5DAKbVyoAe
+ZMT+Fu7hLXQFJm9qO6M2y16dK6OU5viJLC4fC1feCEWxsu9hmwLuhuaMuDh
7QjunctlC+qNFGHyd47lQLIjwKyEsiBJwTHqye1K7ff8T3I2AvlW9LoG+2Fq
Ry4YqbZAG1iH1Gotxh0uqsctp8OLhRX/SiOMKj2bnMqaJe7aRMxzY7L+prLV
ppF0G6WdoW6RF4yCL9BOnGGNWXJ81zOnN62OaiBIVwJhHyqP2KBx596EItix
icSvKowWIxPIhsq2Nomzs/gZkou+8sk3HJMOkufcgwhgJW5sVYEyMZFYng+d
1ZFFL+rFhVdouZuN62X9sbzLCCphxQhFGJpXLjKn4KGTADXh+zL+PzGMqWFP
63CiFEUQIQ7rxqLpWyf5gsZBSmHdN2dGyobRbQq1nUUaY1nNIQJlyGw1p0cE
tgajXteC6IHhdsD41qTg4r0qsrlzluzUGpqthaap0hjjjpNhpgYOnarwoTw4
pzjEHaabTukmjg7WxPOWuJy8tipWcGm2Twv/+s3V+etXJy9BLkPm5pH6o3w3
ijotkcQISBXQisbcklBADANKcVmrklIFCW/Gx9TgrXa6McZUrOgwAqCFqS5z
D4Q99fj8NIqgTDBMW8MhrbJ5bNRravpVxtbkKB49bkj4qI62B1QNzRnG6O2N
ruweinw6BL4jGTui3JRcx6W9enJiTgkeZZ7PMgRrIXFDh5l8/TAXaS/ZWaQf
ErgLu9ZAf85Oxw6HABaHFfyn7MMyl6IAOAi9iHgwQHESmc/WNkB1iu+47n4X
CjCNimOofZqmjLgvicgmhBwYAolsGcZX5VwVuJi69JrsyYifVS4MRk3NkLNi
6c0+rDJf85CXEq8QPO1TbsfZptRIAk5VhFkQw2ktjZxJqX8YdDleKB1zTqj4
lzcYxeRjPXFlpHgKiNvknGSgTh4qjV0sTcjULs5OX//009mr52fPQ/bcEmPh
CT1owSHkKONEecYza+QWuzelafPKIGnwQVcI1ZoCSUU3KQHBm92mrYoHx2Uq
tp0adUh4iaQz/m5JG6kLz3gmpA9yxZ+M1SUbjW386HS/4VhVGmWPy4r5dA04
fbo9P8DUEG4Ni0W4SzlQeis8/2mWFeD0RoagsvfIGa4RICfnc59z6iu6/moA
ggKn7LvrqlwvSWSMquNpzGIe6BsPJrI7DPnyozTVj5WapAvVy2vTxEocmxAG
wjSvw8KwsEGRzKnBbPTSRqSbB21JQsqoN8r30WXVSN/A1OieVpmCqUTxtwbB
SBAStZ0GahRcVFDQM6kNGncwi/cJBbiBF9VYdDGxco5tphbJR8vNxUAaJpnJ
th5YFGcLFoYpBQuSll48N5U1mmrGN7awrfNFRCQj9QvFNncYdm+717cDEgYm
z2L58cOHBsWlR4ib9VYpcHbs3H/913/R2JVTHyc3o2c9WGnFYTkGlbTX109H
zY8PnvWOn+Dv2FJUrpElEr+9sck92uhjTbLynQ5jeJioyDRas57djPo3B9Be
iQZ5fXvU/bp5Gx8ah6e4qbidv+JshqRS1DEkTtzOQWgmgNQQHs1TaKBjlAhR
871RCshiuFyv6qY7ousEC7gRa2ZjD09LUAoci09wNo19e6ffHui3ftTHT+X7
F6aWZWRzwEA2PTb2Zst55L3+mlGLoNca8kHnkJMdiRmObqsMZBcxHopNE8Un
2lZqgYX7rXee9hF2zcAwmR5EPdQEBSqhuOE7jE4+u4xfGq67NJc06cFR6LG7
yQp5QtAxVTSq6WOLOw0byy09DMhIsn3tw7pznEs+s/AhXlpQqk8DFJEk26go
1KhxrIkATo9CxykcfeYYmktFpOOdI+KjlB29BCJvTNKq2nSwTG/tYQ2e86Rc
CsLkrWZi1DEn56ojosaCqD7EnG1TmFmBQUbDQzLU+/RtG0np8yupQJswUrv2
DShr4EbY6wQmBRpb2k/IcqStmF2MIgrpNMzxRlperHXFfHxeKGyiMZkotJpV
CYHTXApGzU5SvIecH+dsyqbs2qb/RkKr2rYsm5fWSOsie0h3B8nO5atzKv/k
bMq4Hy5XmmCloIFb5yuPqM4JagLWR0RQxDzFHJiOgtk+Euzs9MddKfxg4+Xp
zmIhSgVNaJRmDLYkHRGMH7hzwWlHwbzd+7FETRF9VsdeOuntsgjoEwjCTEPt
pqjmCBaaxeYu2Unis84Qs2ZNTquPD8hcRjg9flMYHLhZCgzNp+uCYyhCJjwa
p5gMsHqqpn+TWmYMSV8azccfL68u0QRCXjVO/3kvonHsjRAw5a6Y4QAiy5XS
3MrmXeYzIxWyJkauH82JE7MaZ2uCRldG4EhKREzOXqxOB4fTy1ZFnYuMQ9ON
b1ZmQ+spr/oaNuYxbM0C5Hi3L63fk72+jymiD1DaoAovz9lGxFbKULo9pahP
tWZD4+q9j6ztGJUS4A4jYOYnwwMyDtNu9RNO2DkaKqhmw2Trg4js4rBhuxa6
p+Zlvy2EUp0SW/Y+5C77Za14pdZxaU+F80iybO6pBWsKHfteFpcxJwd7j5Od
qwwrRGNa2EXGV2GX9Pw1rs80c+Hw2/kImem9lHJqPZaL0dx2gd0sV+IGZBC7
jinhzRPm6eCKXF/70lmC1u1tlrvue4nWi3U7Px81FZUzkB8GeSGXUq1taADc
7ce1HckwPucACAVsRTOTN56htTAlS51WfsDqJlOziNuXz5N5GthkDvo6hlUr
qpC1UpvTcyMseVmiFJSzb4p2cV14aB0pDUTHBVMySNNRS0ZKtgSCDiZ/CVnE
zL1CY+W6Qn8Pu6adrrUv76xbHJ6kQjXe0uwFCYPKoc9qNHIa/NCGs1M97STU
0+byFz7eyrfGe+csQRUuZF8yDgNTJKJv019qBw2hXQ2JNZrYMOmdKlqjyLqu
6qwnEkCwcdDXKOJslqmw51qpNfdtwHXx5IAyITHQDcpdN0m3TFtYtWKgBgOI
BAvwfuCQK+LMOCotrMLf6YJYADvyOWZ+Ck5nGGDRX1O/IvO0PUKrUNVAbwdK
ro7ygM2SsTOfggnFTExXx2AGoukri2gnBaI7/Xt/xBj3yvoc59oH5xsnDSqc
jaY4cmgJUa1I0iulwGop8yMcqjn8Lvm0EdUQrFEKmaamNCw0JXO0kKy4Z4Z1
Uo+vZ0us8SMvaVjLbdispn1bulVM44AQD2n8aza+LCfvM8q58H9QEazDo6NP
n1y5ZGtpSI32BuNfD06TFwTkGAtwPrjDpvX4wTi1Dr2TMwrTeae3OFofSlCg
wjcfVkJWyJlJxEFJiJrbAhCXOHobG6bch8p37sYrhgVkpy0pQ0fchcPu7+d6
yRk2Prc65uYkPRYx5obzwSKoZWKeiQcNIGWFoduCGkLxVgoh1kC98PjRaB+l
tHVgFFOOh1FzKsc1YVAdpa1ekuyBqgjdAv0TZ4xw5JJeNQeJTcpGM8pHG4x8
kkoOBtloQ34lUyAJpAqREypRT51APRiXv0ZTSACbnG78hGJ684nHPGTgOnY0
SeU5Tag27fmhjY3lrnuAxATqSckR1LP8A8YDmlSFVqxIsyIsQ83CKmbe7qmo
d4wK7yQhPvdl8pBNqw0eLj8VJGX/OekAXCPRFDmr4V7VMwY3c6EKUYR7z0EC
fck7CMEPbCKJcRx9+aLg5+9aZ+EX+DIF8NpxqozOY6VnHEdg2IHHMHFyFIi4
K+DQDN6/nVjs6HeEPYtfHD98+E4DCXejwhZc/lNrVqGngeuqcVqK0FLpryAY
h1WJ14WrQanBLHJQiJPAO5lNfqov00hJTB7awOEoCEMAc6CXWucrCs5RUYMW
KDELJDhp7wTGG2Y7bK7D7vAzF9T6lz4+aNURoGBTXh20rszTOLvC1Er4fKkE
F0V36K77JCFh/Wx5aZwxm8vj5JzYxFBrc/HlEsgcQgEsRQQFTGYgF1k6yRcY
BfLhredaDl+Tmuoo0+KW63Kw9BCX8aBY+5/ZZBJilT0ll6oEYax5zaUaV3aa
XYFeEpooVMJZyqrhTqyX94a9gHKsINVkOSn4RAnK2b+8vjj/4fxVElm9vxPp
i56A89UGbz94xFjxTCjaN1Ht6ntP9viEhla+7tVxWnVgxgtCPW2NQXHnzp7u
Pd1jVPvwsnYmmPb4hQ/eR+t/5xoQCv13PoJcAiwqukK6JDDoLUsiXZmUAXUz
dL62ZU777uNxsspX8+xZj+kZrmJkRoW15bBuLpkuOGXN5eSsDpg4NNFA/D/G
FUsE9BLzVDjje9gDGvC86/IyVVAKYI+q3DWgW2gq5bqoFOqqTE5y1dZFAHXh
eLf3WSjuASNBuzUrLXNsHhNL53UpDKT28kfkEDUm8lDI5InyNbcDmgDj3Ylz
U6lNiJMTusMR1Q1vvVYvyZjac1IjJUTxZbdmQ9LmmjB9SPLZyoOLE9J11eVZ
siG0DqU1VNkyAsZUg9CqvFzXDfxXckOD3F0P1UykfoBCHPo8cKZwHmvebKDm
SkkwjwkB7TsBvEWdw/vBzasYjQfExrdqZamtrUqJNz6LNXv4PeRrVtwgaZUy
m6eKXJxKXpAIEzNxoVWL4/ga81PBVQc3md+TT8I9/jd/+fCv/aej4R4Wk4qr
V7QuJnllLHNTZKqpgIHyxsqo/i15POJOmu7MA+dsdh8dIPXoxnMIRmxEt3Jx
np9H6BLvlcXZIgRYgklDDVByAwQBVvxgAVXL552yDGRh9VniQu+gT7vH8Yh3
unvQ5Ofpi9xKXal7SsuQGK/r5xbpivymPgJhTtXuNC8eIzYyg/LHApU343bY
b+mkOkRFIN0UPmuvt0yqe04akrjMPngJNzqmdD6VJPKVMeG48GfjwDKhmtoT
e9LVSErWfLY5MUAKtvIdFj6U4ygtsVyEhUesZKcBMcuynNObd3d30UnXPeDB
4mORYCm90bz1+BcJI26ev6l9hvKpxKsHoocGC7EdwMtyLbawweQzV9H+KMuM
r+avGjV+GfI8+Y4SAl+0zv7o52LHxMEl4w0CdXDkV5TK3rjV8U98fPc6Fs8A
k4VKMYJKRm8NLi4EjyMKKNI0EjRiOrODLAo2ZkRAoHd3w9aJwrJ7WJoUWuTo
dzU+9OScN954CDJLz4R+D3eT5BVc/3ikLhrpf5I1OiAeYCSXVFhy7jI4maR2
ejAxkcm4KBWwJIqfJkYiFks1y6BCGfVsw7RD1eSoCIPz9jZ1C8CkO5bKpuO1
l6VHhSQ96ekL8ioMIYoOl20yNt86KC3zjRCQNz6edMw5io3IAXN8EMKqyhco
NdkjEIM0Hih+Xk04aOtl9Ky6LlQZFmCC7MOS3J8+fSfIUl2s1ZxoolJKkFRG
ZiJBHW4l6Rgg03Gv+bFRImOXZzm8BsmuaTkmFoZejDraZSqRJC2FQTra1lbX
GDvaOgiuuWASIN8cwdTNIw+ZB7ToRdyj562xzhdlCD7NaJf5xmAhe9rKuP4V
7bE87gwVbAZe0olF+xYTgalKEZcxBAxRCzXAPjzwcAZwdKDrNzESSG8MUvaU
aAaZ1MzZo6jw5od0AOnmI1QzGivVltm3BpR+kq0mcmF+QgPLALNwPj4gY8tk
WjTTthoZDLE9u9ZMNBaKKXzdebMNXEIpmbSizcOolODMCVHPp1xPPXmezYEK
VBv3StAnkx0YGygRVL9Xn27ekFBkSjAb2X2dUg1bSpjwGj8aKjU6liznFjqQ
DdMkqkUieqM1a0HA9mSyhJLN0DthAUJYdMNMhCDgU9hd+H2jG8Iogyqf3qBD
St089iYIFCtS2gnwB9CPvArquKauWSvJTxBdEMMC/FdaCUkxEUjEpTh6XG0m
/fPyOp9Qf2o621L/XKgaUDCaBYlaqqs8VMe32XCrI+qb6co8QQ72epAXA4kV
vyKLdC2F+Xow/R5Vx5WXycBM4DseKFMtzNTZ0A8QQ+GxTd5YGulNWh/z10qW
mys7JDnN3Bd9QOQ2fhvFv6dW4oPrtD+Myv75Yfik+4QHkwd4jS+NZVtn+lxU
ADDqcJOt/uhOp8UBdnjQ7vBXJc2BAVbZQrCdyXCeSoaSRGQquNAfshffJVcq
gOai4xhZHufhq1JIychwxbiFf+uUQ+FN7SCIb7GUiQQeNTscG4jxXRL3CbO8
A+CL+/sHwyddbLahJ8PTyGe18wufdVQncSnA1qHTV4Bn3qj0Wxv3g725OGZO
aTaX0SKJKunTvN+HB8N4u6Ljju2KZoMvYOuigeAoWTp4Egs1NwfEzFRZ7ViX
JIg2XgLa8lxkhtj6ULTO8PTx8SE/KmPxAs12SabdxmOSZL68W1239it3zEbX
yd6xDzCSYkftDRpZmVM1z8DBqSVZLX+5DrbIns2leGTtP0+GR/vD/b29bWvf
fGzLfjcfO9zyWGMTQJh8/NVP7n/l3YrJ3e/fKcFZiWL42zt18BU7deBv1EFr
CwyN+aqV2Aci88QaYJXxUwBKBP1j2DkIaSx5+s9cRFAlrcq/MEmXKblcSQAh
gO+mhh5CFAhdhWThgZa8wvI8GJIb29QDGjLjza7ruBj5InCMWKCissEBeAH7
8yjODJ6XfeCQarQAzTGA1hS4UksWxm+D9kA0LlzB1Cfn2XASCUBm7YBum1cn
2ZWVeBywOong4eGbKcxXAh0idPgpAjygRos47EBucSbGiofeTu4qOJ6/ZeO9
R19FdokmVETi8DYwstgF0J3ffPkc3Dh2Q8CoBCeJnQ+aECsQhSBkCsoOV8mL
C8QbHsrZBA3HJ+E+R0zIh+WvSmNtEis0TcIHUZHhjmznIHin15JgiwtB00ch
4aRPtyDUYbA5vepvDpoMx9jW5PIMFVwXKS6CJOkxfjpRjqbU25DC8ergrde4
cXRtrG7WNUfB+MjpCGBYxXnJhw6BMoqLm0T4igFEJOgCxs6CLnl80QcRB5CE
xHtryQhscpA06zEO98bkRw14UMQuDncS/EvuEVUfsSYblQiPkJirBKIcla6h
3CqxfDKpiYPXvIs7oiG1ivl8pChtkMvOG8gSnR6mi3F15yZ9Z8K324dWiExJ
Oha3d/IwhnxGjTKNN9egsJDyn3TV86BtE7aggWa4OoI2SVWm1Frh821q0eFV
CiWxjRHaQgyTqcfJSAXYrC9ZSgl6zXKbET6Jt2ugya6ZFK5o8xQTx6vlg0bL
meuN09/Q4LfMYy/r40dHvWa2linwGy63wjXyDc9pnXqwOYcDaDlycPecVCED
dRFUTb9N9Afu0cOwSxKM0CwpbBz/3psCI0X392/DxhyGXiugpdxLOgflTPLz
ug7AD01AGIG1Eeusx1jsBkFv56JKfI0vU/rxAX3i/UqMw4M+aXU0NSw6ch3b
wLKcZiIVrikGVPJnMHW7mffdKINm+tOQPfaI+bg9NOvuDw8E4ffJ4eEjxASD
I/n69BJTJtIlgrE5/vrR3qNHGHdP/ma4DgIFC2wc574eky6JUV7WO8OFy2nE
Tq6SlwjYPAt7OVYALYtSp/frio74XKNrfI0HzSPSViUIjuGY0nm0whhAtdZA
8FRfHVDea0XmGjSjhNInO4TFgZ+p9xHW4Hl5xfjH/nM+W/jNj5TU6kFC7ArI
5pHfl0k++dMRFcLMInqKkpEVBTSiRh7OA+3p/nQhxGmxaQSdKpgbYkDiinq0
GZGAKMKYsxMwxWolKRNUTp79i+Soj6gVg+4xM6M61rgUPwd//g/zcozFbSdw
JqfJGTbqLrTUtSVqcTBkx1BsJwgfeMlRb7Y1AqU+enqkKMmmFR8G2rkkzh8z
WDgGApbg1dNGDAQ+8zBQEEbKw7w3YMNjlq7oIHhwDCfJDnVsc8b9vDj708/n
F2fPKeABcU82QbToKhNC9TMiU59GU6r6v2NynGzi375N/NuNsvIb2FWEweLj
9iNwFbaW+hQJx2AyyieMmMaxtFHOna37wmG7HvYiYciRFYk3EodKDIzCdBQV
lOK9ZvN1fcNJxipeM9hTTXwvVC+iV43oTS7czCOMMkgE0LyUCWOKnaIQyoZZ
4neNDIQFldaoMHURaS65Jm5yvQ5Rbn7NtaDZhwCH+1Zxm7h3uprt6kw6eIWO
VFkdvwMBd2Pq+21MMdiQBqFUD+VytsYT52+hj08oMo5Me9Sunh2Yn0WzZAVQ
V4zicBbZNE9JMptoTo8fthmxGOn7VBQzxMsY7KOOUXm/opxHRSpKW3knvhhl
ULh4MetoHW3SjDqBxTdB7pAgfQMV29F4892+6MS11KvemHwH3d5JSR7OVJI0
PfZOzdl6OgI/PlhLD3kw42oX0BWJOYsFoRhEMZrpGAsOFBqA28h+5gVlF4Qe
IwTNw8xCTEQicGvdfkLUClu3kTRTOu0mQAzjmlTo0vr105LQm1MUee5S0tio
tpkfJsvVlHFCfh+8whME6PDuJxRIdJx6FZ0GIwDTnm6kSXYherS4MfEdKoOD
uT1FhjYDr2DxwaQ470WG1z+vF42LqlHEZkxG+K4Ya1MdKKn0O4xhQzwMEMgx
/ynqAK+6HLa4Mky0mC7IKp/ZC6xQItJlWqhYbEUdjZliuoy1cLS2SuKBN9R7
GGLaG3U3kHvRUWKa6M0SIETG8ds1sgBFYifmM7c7KR5YT7cokrgAiixFlTVI
Al346YaKsfhyltBOXTMWE+XRTNizWMtto5biHt0NV7NdC3QS2gzm6QdCyqbp
crUrkYcC1/Sjo1N2jX6HdeGFPp8ftXOl6XIE8En5nwI9mlxe/BKUVwX5JIQn
pywu5NZgvMgJjhSkgPxaDFc2GwUO12TN9Rx8vQpJm/bAC2LVMniuNgXegFR5
du8rzZmCaCi2vBHZsSW1qJKh50dVbCRV6VwFyeobkZBXCvdVEyi0v0YS6x5c
uyF0Di1iea3ZXRIN14yV5yyWEmsJbEJddLLhEVkDjpxzLlMsfUu6ExIUy6Ic
CeU2dt1snvHleaxnEVhRFvP2lPnGfW4VmAl1UBK/CJwpW+BKzCnVB9aepLMo
+U4yXIw1NJQb4JwMisZiHqzufCJPghSFy8K6JkrAzR3GLAgWya9ggqJb6tkz
1YWxMVxbnyfEGKdc5JCxcx4dohUcdDMc1BzJhthVqeOAhXahVoULlph2Li52
k6v/eHNWIwEUoVz4WE9swgxLvQHBeMHZvya8AhHprtlgi3M4ZmPAtwxedQzD
gt9/YiDD4+QHLmSQvFlXFEnUgEGHRy80OfY4iRbDwxFc3n+xevRer7FeR/8k
68WWqLBgR3bBGgvEiptqhB6E9kvr9opi3WSsdOGkWRMlE4qu6JNYGwXXgmIC
KaGR+cyENHdZaH24z0Epc5Bte63WubDDjkUx3+3pTfQDsxUaKeQcAfUpqTIA
YVmWiXSX/OAWhJ0JiBQXiPAVuWRBq1c0rtyklWL6Mulp4M+7QIE04MYKoigw
nKK2daxrs7Jd9Bl1DFcLt94sFJ7SViWAHex8t2e09q86Vg4P8HVZ+fg9LdOK
0owMhWk+qXamio8NqkPQgZoO5ytib8dRATGt2ZBLIWksBlahJpfsDai8JGIV
4SiP0akERybGx6daROZwp0hXq5VA8FJqNcI/cV/mQJMazZnksR0AiSu8cUra
JEU+Ee4njPoNLElJSLq02hsJ9CGD4GQVs8CZ5dYCMgkSKhoG8WKIBcNUN6F9
kPL1CaWEUGUDdOLCSHxdi6Q36HXXObmSEx6ywxmumQPB32cbBm+RsmSEIwyH
Bw0qucLT2iPM9eW9vAuC2dmHJQIlX2S3ebijHI6xLOc5l0QhU+H+6FE/UZPD
4fAoDBBdbdesLmXcXNMmQNpYc7sStlaOJd6XLA8ThFcMhRpT9cYgZ1UwEndT
3vliURULhlFNlW/qpKvaAgaghCMqyLmtQWH+8Zg1Q7xnoE+u0zm0SBZgkK4H
zytQ/8lckQaeglzABaFHGAHtkppsPKQtZbngxEPZKZky44ZSCToyieFYQhGn
1lBLBsQi/1HvUpDEd3gEWEAHT9+ups8J/KKIxdH6sFOqIgoKPdSK+aAQ4tCW
BsqlFd1iC7fIrU5BxJqXS/oCpsckzLOMDjR/5x2aPoZ3gTo8XWAycI/nmVCo
c0kmVr0CWFCeFumASlpItdEm/2PiaDiL2hF7SMUJ3oganaOVGggH1f5W2h6u
sXrSKSMMyN3fhdyxG//vfMPNz9+VaHW6/fmJ1kZuf7RFsJK/wxAG4SfRv+xb
g86fLz/R8U7HozSEvWiYoTyOX4W4YI5SImCP+sROJH3sxtA68Sqcn129aKwM
DGE/egbjYuK3TkLOQ0fp7u4hYCt4rOIRbB3CKHqmUbYET0cZAaF5t5Ja5P+A
IRxEz1BX0SdvtPMui/OWjWgXy/70uSEcRh16r3MYONXEFM2Uq8s2pvaFIWhh
4U9bh3AUNZeB5BV3cHF2eXbxy9nzZMf6VmldEGMNt+rhSfJVP9uG8Ki5Co9a
q/Dof/EqPDoaPWH56rBjRn9n8wEInQj70j215hDuvwpUO1yfaQ/hIpMk3Z3e
OQstSCB6u+GJf3AIlORKLNBLPevllEreOJD1Ip9UP1lihfpMUh6tfMsMWCwd
sc/Ldfi8PHchFgFUDvU+GuNfX71+fpZQ1G4Xb/h7iw1EBD6iv93EuPkZNcAK
B3cgmYn8h6ABoykBRdvOFf87uchOJog4ANrH9SLTcjYXGTPJN+JyrRX9nZxw
rCEDB8UsfuJb5cwUy/GhPaVUa002WVr5muY9yS1kgY5wWjC5pIcSNnA+bE7b
8i4C0U3cx4//ej54PgQmPc/rwbSoy+UAZz1gWxHstD6SZ6uZPJCiYK2uRJKa
uFZXWrxPNuUaN/8cBJPLu2wF8t5FOp8hVBBauf4fEJousmzadz9RpjOMplzU
aAV6uQb5HoWO6RrE13OEs05e5uv6NoVr3HdX+SL5NZ/kRf0+7ydX5WKxgYfX
mIF1elPBJvxaltN+8jwFsTP5Piv+E2v1UC/vk5MCSMcdKJZnVDr6EvSA9/AH
ahCvq9VNP/n3DdY/g/Xpu9Mqza+TK7TTVtgcqHKTk2qKIvX3oLwUyfN88h4H
7H4FcghK4lVZwtr2kzc5yUovUfaDv9ZFlq2SSxyUez0HYRi+e1PmqyqDEf+U
glJW/i35aX2T5nBGYHrlIjlNq2UqGWXBDOgBsXOMwsumhMFKnvH19TXW06Jz
IULCFCVsdNTiaaYn4Tg+h51kwwaaD2HNjfz48cFUvsWMf7is5jsKEcfAxzkd
R28DIKN7NYa5kK0eNLhVqLmIEEXjtIalPbk8PT+nPvviDNXU9Wk2B8me84YI
zZtHoOXT0vk1+nFvFo45v46ezq1XGgdsmqhtXbsI1PWIfbuggO3vHRwhYNKP
eN/uUI9bLGAoEiSh+akEy8x0i/ybMggd/Mn3r15IoM13nActZfig/19Ofzy5
QGATmNzzP/38+uqsn/S+68F/dvA/uz3e1N7bHgfM2tefJf/tw2g/eYj/HAxG
j/m3k8HBCf12cDo4+p5+O3o+eHxm+p/m14ztEfV+/sP5le+DH0mkj8HoBTd5
EhqC1R3wDuYminRvMDo64iqBq5sqy6QheDhfoKeEnuKphAawm52kt9eDTnr7
vWQ3GdFokocdgby9UQ8e3sHR7A2A5/KTu/AqNHHUk8+P4JNdeptLe07p3We4
kPBcmOFDMwx+nvJBr9d42uD5/W93ojV/6Nvjp/+2JkxgaZ13MIF3TCs4sD9D
v39Jfr18g8OSx7g3OJRyHuH96C1uWhAD9Cj7w6XeuXemhXeSwS7VgpEQvPv2
9enV2dW7vuOziI0K+A0VIdBSoeRW6kvEC6lj3nsEeuSKrX3sWnK0AtJI6I3C
C3CplhUWfaCrT8vKTidOUHonq/fOX3usPSIUSHihRBiFmZIxBfi1VGrDJNzm
XfYLJLUQo5e9Ap4KwNsY1uW/N5v4H++QCMCdT/DSY50vjAe6Zr20XK/wiiNH
pKWJR6z56kybaJB4C2j6HLsYKGl3hV+gpqbAL5V+pcqr8RLjlzWHSGaLOqbH
smqxBY7iJLv689XJIzKmrZJnE0clFU40z6zX51Kbb9/2pDtCIAMWlaLnZoeq
+ypiBNqcse6xNOvx8riz4a47MRVgxQcpucvQwIo4E3QooW3lTT7GD7kxGRBh
8sJgHEE1q1dTC6vMNwokNk8aNeDj7ROjswvRxR4h9B1DOAwaawjHdwMj+OCp
Og5r4NexTujSCWHVSXgaHj0cfpDU7gH9ZJo9em6o94sX9KIMBt9Pohf3v7Vt
2mebm/8s+bNt5dsdHJ35ZPcvHFfbxKEJkTtmPkBLqZ4vNHQrJbQigT5QCl4u
BkvMfI3kjnnQwlm67WdLtDhaOmAWb/vEM2AkSrxb043a4fnaj3DC/nLC1Qpn
EvM8llieR0KPttKcZhE4BfNgsSMm0JHNVBeih57Q/T7+d0T/PXj7lv49fPsW
jzc+Q4+87b9dvk3fVm9Xo7d7h4f86N7TkTwMv719q5gnXCuCIUI9NuTx9ln4
5NgZR3xQbDKWufcR7ERDpWS5jLw9cB23cyfo/OcEyA6CF4QziQjXWui+MBn1
m3IBdBoUiBPJO9yzd7Xt3v828r8dyChQhqXYgp8kcOCS5LeNGFaZS5FuzPZX
4l8F+x5uVdrb2MqQUR1m8qVimBNVhCbT/AtGlvfGJsXPpGwHX8PN26e1h5UY
Xv/elne2/dznUfePGR+3Pgrtfvstri2qmhQ6+u2328erkWNfNd5vv5WS4FSc
27dftzqQdlFavqtr/gf+KyZ53LMBFRfa1XbFW7h9pNouq+07j44+Yw8x430l
Nv5Z/uFzbaOBsmAvseK5A6ecI6X467+8eX1xJahG77Tdk6isc7Dxop/WdPT3
5B22966fvGvYRN91j1dJkVpI20ur7VIjx8nbP4eS02//snUdLkVUVmjare3S
fVL0CB9PuLVd8lILdBsHoywYwpzMEb4TWd+v+UHDVau8pjHZsqWlHYnL3uZk
MgdhmUp11dkCXWdcB4pyqGoubjbeCEq3+nU084NbENmGzToUY0qCC4Osquwi
1CcaVy4rcZeNfewgmYPqLEOA6HUBH92AyJ9CrxPM7FmvorwFtP4sRGu+KZfw
H6knSM2OlVYJYhvVzeM4JB+RypDPGIJUG/TSqoSHFhisyrlJaHaalAtmIKBp
VyuCkZxqBDkmkzqKi7qhjCtNBYzEDxGhTQ1QHwCCsUmyIRQCHGKVUJ+/+OXT
Jw5g9WUjlPIqirxKeiZGsO9yj02amiIZmA3H0UMh72lemqB3j75hchRWoZAp
fgD3wtQyJVd+FF6FvtvNslnCvc+AHMCi2IjYqrSqtXaAA4asDzpBUdFv74gZ
NvoVQT/Xyhcmthjd+tASAh1XekmhG99UY2y42lJNQONp9WZz6CLldXK29m5z
GKokhPPWaD2Kh8fMUQUiktWgKcd+0GYfwbfbu8swHrXHETvFOJ2jp3iKZtRp
iTiziGqZTgf8BQl6EisXp55/+UVE0RFtkvuksXugRUIHjirTmGLz206+t/FK
8CTOzte3/bJtVpRsDK1AxR0rhIdLThoUGoxtMb8zX0THltqBk0bhFUi+XmLX
RBeUqGk3PnbWZ9VS6qqvk822ZpitbyIJTeQrQdOokwAAyrEIHrlLjdLq6/En
atXoEvcaMU8nPvgfjZ5fXOQTA+PSXOUu83ZzdZNodV3H6p7+GK3lVdQAJZT5
AiIKXUolVDhXAy+n2qgQMn/OIHQq1McZLmXlYkQwjP/muqdKSIitaXXyvICj
nM/zu3zyvo1qV2/ZtvvsvLMo0Y0Kk9gOZhgqRQ0lWugufv05ceGcJL/rnJzP
sB7tvNxoxEWU/EehNWuK752t56wKh9z6uC3ONp2lwiG1SuxJ/dm3UGmaYxCe
YBMGdFaXzWZl5UFtGb6K0rNZCeX0mi0Jt+KY4uhrDEKSeFocXlf+IxJdoMjo
ENEkcIwOWiC5X1Up2mEENZor1TqZhTrA1U+xsZU8cNG/qVv7ohmjY4UZpqac
doMR7TM6Q1QcI7vWYhhzDI2puwuoqyYaJDkuOWyhfU2OLMgVY4xJwRz7vpcb
6hh8vPFOM5O+7zAh1CRAUNqJqL/KkUjtTuv2+ExhdMZE1lKZWB2HJRJYHnKQ
NFIi07xik6ria/pqMVHtYnESdaQQESw0mX2Y/zIscrKzJgro6BpzSNrapqXT
+EjEwztHyME2opxyW3V2CEmLE4ZdJPg2qQeEQWliVa5X2TKIwZghDYSDIuYv
dMQuwBO0yEez0BuNrg9iSVlwfruUb4oQ0bmGQpJhJiINN433VxLK/QHgalji
Vo3IrV8dsmuuFIDCFzugtZqWa5J2qOCP48I+tNKrKvcwJJQAgulrPmttGgg4
BZRp/Uwnmc6xHB0APigMNbnC1NhbuPRYspmtRivzUaK1Isn4S2MmUAGUeqQG
nsncDPk1riMQsO8rPUhgoEQ4Hhw9fUwpURIO5wMFUTEx8XEcSneTfUjVlbTz
9sOrV7shsxFNN2k9yXPQXlaw6EJLsQ1pAilRicIYO7/GVfk+oyyZ0svmRF2Z
avitZVNTlBOfeF//XtKAVhdQsLcPkv2nUuh1bw//d6+f7zBjmQoDcgsHyaNH
yaMZ/m/vMQbHP36SPNpPHk2Tx3vJowl+gs8c0DNT7O47ydei93dlUB/29vD/
9xjIg3gg8PYBTBj+eSxzxk9g2tubfaADCZj0fmkRLB6TLCyx7VhsIj0JIjH5
xT0wa7vfvWZhPLoWyU5VopsGwQh2OxZmv3PC2o5OpJ+EVsykLA5JnbztDd/2
cHqfmc6j1tlhwNKjAz/N0VGY5/7/v2cIV/rg8z22R4ARsQf+9dGXXmi+Lv62
kbZwcPSld5otkFG5vdX3Wss/8A6EEdxrLR+YhZTX77OWD2QhjxEhd7PKatPQ
vZb0gaxnOPWXvlplSof3C0e+feKx0MWjx89uUJkMx/5J+3p/7c8ffexHydPx
fUeAuwWz8lO497GVg39ELTx6goPEoU5wkF/XwpaDf6/V/OMP/ujth3ut5oNo
KWUK9zux0VLSMbvH60nXmT/xsgwOjpLqC4kDoUd/7x3o0ejejvb3/laWvcDq
Rv9nXYan921AdvBp12WYjpLH+zKj7S38H3wZ7rOaD+Kl5OP2YTr6W1eVpi0t
fPky2KugcDgqtLPn/d4XZGcLnCn+aND3s54p5tAPvx8dHO/3PvP+rr9oR0f/
PBcNRvDo8z22R0CnQ18f3VtalLNxwNLWiNZgb5qMn4gC87n/7XMTs7wC9VFs
OPdp5ujANlODKllMo3b+me4tjuA+m/PA7Ay/fq/NedDYGXwd1wD+P337YfxE
tTr9fzjrzW8a/99v9tPevn+0r6ODbX019tjoUXelkhDK3qD8iy9RjOjzDoqw
PxodHxweHh97WOMDw2D/wHv/dXc9buEPvff31xLldO0/al/Y/WQ0wrEfHka3
dbIn6txILuz/qpv61VfUt/BH39R7KorxWnbcHvh9NMLpvP1wePi52zPR3+Hp
Uev2tK/NSRGui6mvmi3GGbkXKR+Mw/DuZZYoq+vP899Ql2Ww/zS4rJ9pSlof
H/g8/6bnnn1F3SbDrA+f/G+3jMySx6Pk0eNOZn3vEeBB2/OvH37phdYEKHJH
jtvh76detwxrgaPZ//2jMa38A2OJB3FvNSFakqeqr9z35ztOao0sT6BzHNzb
dkXNBMXjvjaA1lC8LeDgIBlNk4P95ODrlqg9lN+zxfHe/hHn1XORrz8p2s7/
NqseUL/7yYX3G0EgAvL6fdb1Qdei/i622yICv2s0LSLwu8bSGsT9FNwOInBP
Yym30yYCN/enJQ+aN++exqv2UMSKRaz2Hx7K/be4tbd/wHm1gs5XnZUHEREw
pmiDJkTJMxS6UpuEw7zoxCgZrzGQkZAK8sJ6Ie8vKJEw1Jth2D7Qkrf9cVr1
b0a939MKNrL3dATNYIA/N9SpsvwTSD//IKtvlbX+4gTsQdoX99CT+7WSNBks
Vw2BtTiayHKM4JcRrsXjz979NoP95xE7/tn44z/IDO5zUh50HhNo5L4H5UHH
MZnB/e5315n/QjMRCf5nYEyRDhk+94XENeGV0ng08EU+pGKh9TytOSnyruwi
sGS9QT//C8bp5cgWhepfj2tJu/YVv6MgFMa/l8hgRxEsearx8Y08Pgwa0VRx
DBrmqkYVxYbom5OMcN+zDxRnrzHDFEIS13X7Q6zTeIT3RwfP0vFEf51ms8+9
sGs25KdQXhKjDAXGyudiGY53b5O6V9Tv95pX5r/6Daoneq831CJw77fI6meX
L2cY5TjpTqCIMXdkTNXrKE313gvYSLLBHbZWTNijt73GM297SQvy0A/k940i
2Fv4dEWemYAQ5XN9qCworco/0FU4O80J+28aU6VJYsDh2OOHaNFgF0aJqX5/
qG+ouTp9/sdcys/amn7PRcT4N/y8PasHCiwGNIsWzzEGjJI/zuTgkFgpuZVR
Pno2zeH54S4mixBMx8BEnNe3kzGF9tcD4XDfJpcYaIg5662Y/YSD9ncIf4nq
RflgU2pZloOKKgjSH6dPazHLKvNB8hRNPdNkyeEXR7cvo3uVVlV5l2B9U4Sq
KevV4Pzs8odkgsAtGqSpRTrh+VP63JdxkEhtjPpF5uPj0WVD/Ib+iSLM71KP
gmKCNZEB+fZDATgKu2xmPmOcsk9clzpIvhMNehT4zJqRInGhlHuuA4TRlxZo
z8UT1uBuwai+KxOPbq8IxZ9vce+ptHjGyQeYcTXFSuucB09pkTh0Wv6K0Cgt
hGvYAgKa9dBOnHJAMeYxkiWDV/q3TkxfkmUllVJCiu0cmlqn12E3sCkcFsG7
fFimlNZjIEjx9R8vry59eqF/88w/ndeTNWOjw8OcaaA5Ef7p59FDvtoAEqVw
TqKyvTQ4zo9aY4g9wrrQznQCLJhVMPkS/vLESD2IFEAJEPYGyN5xGqymeQjx
DFuD0KNKQf6/yq6tp20sCL/zKyy/ABJJA3TbvrBSFYoWaanYovbdSQx4N4mz
MeHSX9/zze3MOWZJlidAvhzPzJmbPd/XCua750w6/3rz4X1yNGH5CCQyHR5S
NsnXQDfUzGdTTDMQ0yBbdabR8Ih3m2ZG35i3SwPY+/zn9deiXhIbH2EbR6mx
S6PRQ74L3kYMFjw4jNcWWy35U8+SVRPgJIGtkJNsiKHkFRMPKV9lJi4r6xk6
PSKNjzmJZmDDhR/gdOd9q0MtVC1p+CszVxmkywwWJ/kPsCXFfaKwSAjEBRE3
JncxBegYugyQu0MuhcUqW8R6M5eP7+3b/jgndFsImK0Lh2nSNFTn7Qxoum67
bhAB5c0l86DfX98vx8VjF7Ly8fXhXrK4GaffS7M6w8tmLPxB0GQQmcfix5zP
c1PrruDZYRAFLdt5e/ciWmevxFzHzp5gRJOmC3t0AXaaaZcvhwMeEf3BIglX
W2Yhd3K0H9U8zQo905SDuPt8Lla4NV6OPuyZA0nxSyKpH1NdGDpHx8j6Mla2
53efv4JzWgbQsRaQOYDzLzfdJjwB7WfG9dCVUAh0kxaISIRrLOaTGY3MaiU0
i/hR77FVBL9ZQsMTMj3v9gXAY5La3Gwmy5q5cDwKqRaXmDAW/w+hEMBzWU/v
mSC1JMa98GfppA6ujOaBqcD8Tj2ggRB+YuJ85KfnKYZFuzb2WBWcRfRcjSbL
/eIAReqhUolpPMouYH43BONqPWP8Dud+RV3b5Ppe5cp0p5xq9qy+OFihWr+g
r0LGyI34VxoImx2aKCUnKSpQgwDLx+iseE6HcuXfP+nw0DaZOPor+XosdQIv
piHs+CgSnEvAq9eEwQCU4KjwKwqwMUgYPOUWSZ2mkmrgunTPMGNuEvqT7eJD
gsQA/7DR0OCAQqbKw5Y8q88OtcHMv6KNsLs1ZBGhzEmkieV19fx2QBg0HVMb
Rs+fW5XeOkU9yUKLoKSY09kqspPs6q/zp+jGTJRZzzznlcUTj0Dfe9yQumy6
/87hep5+RojVrWBnaRahNG0WiFIn6uIWb2zPdMDkAVdGuez5slMr0MiZAV/p
zfEEvufq7ru6X1d2HOeM9eux5uF+jUHzYERbNXWcaSqW70n1nhxF422Cok4V
IBPvSAgy4jOdVWbgizeUTO4arssg29Q6r6q/Ufa4GI/I2TXa1Cs5+jEY1Ti4
8/kYsLIxY43FBFJ1lagOABupiA7iCWmTHPdD2oiSFeCuRz5rkYm7/1uRjdIA
RDsquDpaRGvQBlmUqjgL5RhV8e9JdJ8VJfMBGPiUY9toV5hywwxmV1o4NIJM
tqUyaT6UTN3w9rOE36J7VEGTv9f2NMHhveby9Oi0rOz7KSC+2Ck88s4SclTf
cdDz5uulHPydnHtiOgQ6/RqAQepQtPnQI6TFyHWeih5xIbpSKo8jQNXetMTG
pcn+kX+feAQeMfqeEe4jlFfvwi4N0vd4CpzWjP/IzBAK2UipQ4Wns8tdFGVO
eT63WjJITxEIIpSwmICVW1JTs61HT5YlOOq2ip/1umU4xCehKLglzH9O88kr
A4nftLqqaQ96jUshVGBWE9AFDtSOSczLs5IgRqg1A/CTYGby8rZCa++MG6sY
ftb5cf4PoUqGJJlareYPbEzUtJSsRvuzYIfnl8T0cjmvh2JCJkwZVF3V3tVh
yD8ovMtlm1dq/SnspHQMnhGT9pRnhtJ92nS9Yk9Le7o8edf8ClQhEagZTDiZ
j97vrCuDWMU7Lq/ro+fZr7tlw0n0WVnuF44/ED4m5k1fwgZNqJfbu2a6i+0e
2x0Nii5o8D7EQ2q8caOSOjmT+uEJRmxulbZLEsmvqn/4EqWxyRbCJlsycd3q
IZHt0J8YrnMBEh6z97Ni9JadH1FCXWNs+7aovC/cVv/Rk2u0OFegUVCEBi0v
mp8RdYj/QThPAPuJEh4WBxHgOqbroPwTPxRbAN5Lh/MI4fpbjb7lvHKN5+XL
3bpevr1YYREjkGSiu/HQSoLAwEglA9eHtZUwFkMERmH7iyk2Ehs+JVw92HfD
UVwCmzUqYg/c9bjNLqSJc2vdmEgYpSAsw8TO2eqeGdoUZsB8Y+AIOxu9O5Yy
kFQtV1yooZkxFI+djjrTnxNuNuOKQzmJXgigZ22NKwXujpkGZYFcaslZ3WYC
0Kjwf8llsrUj0fVmM+wpVBsk/cgu7yyUnDFSnMFxDLoH4J9nnS1CzzkdnUBB
p6OPjni9WkyaUK+Bm3CXNZz0VYALhWRraVi8zIkVEXs8iIDuHsL4BoDD45S5
umhKO+xIcLRKwuH0qR8gQw21fkjtMjU0lKOEQ0Y4BSvuv6UQRN2flrs8nHq1
i+aZ3yaJTSLlI2QLvnD6woW58n6M9V66qp3uOLKQx8w+4jX3fgHuW7J7CoQB
AA==
</rfc> </rfc>
 End of changes. 399 change blocks. 
2676 lines changed or deleted 988 lines changed or added

This html diff was produced by rfcdiff 1.48.