<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.35 (Ruby 3.2.2) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-add-svcb-dns-09" number="9461" category="std" submissionType="IETF" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.17.3 --> <front> <title abbrev="SVCB for DNS">Service Binding Mapping for DNS Servers</title> <seriesInfoname="Internet-Draft" value="draft-ietf-add-svcb-dns-09"/>name="RFC" value="9461"/> <author initials="B." surname="Schwartz" fullname="Benjamin Schwartz"> <organization>Meta Platforms, Inc.</organization> <address> <email>ietf@bemasc.net</email> </address> </author> <date year="2023"month="June" day="26"/> <area>General</area>month="November"/> <area>int</area> <workgroup>add</workgroup><keyword>Internet-Draft</keyword><keyword>DoH</keyword> <keyword>DoT</keyword> <keyword>DoQ</keyword> <keyword>DDR</keyword> <keyword>DNR</keyword> <abstract><?line 32?><t>The SVCB DNS resource record type expresses a bound collection of endpoint metadata, for use when establishing a connection to a named service. DNS itself can be such a service, when the server is identified by a domain name. This document provides the SVCB mapping for named DNS servers, allowing them to indicate support for encrypted transport protocols.</t> </abstract><note removeInRFC="true"> <name>Discussion Venues</name> <t>Discussion of this document takes place on the ADD Working Group mailing list (add@ietf.org), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/add/"/>.</t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/bemasc/svcb-dns"/>.</t> </note></front> <middle><?line 36?><section anchor="introduction"> <name>Introduction</name> <t>The SVCB resource record (RR) type <xref target="SVCB"/> provides clients with information about how to reach alternative endpoints for aservice, whichservice. These endpoints mayhaveoffer improved performance or privacy properties. The service is identified by a "scheme" indicating the service type, a hostname,and optionallyand, optionally, other information such as a port number. A DNS server is often identified only by its IP address (e.g., in DHCP), but in some contexts it can also be identified by a hostname (e.g., "NS" records, manual resolver configuration) and sometimes also a non-default port number.</t><t>Use<t>The use of the SVCBresource recordRR type requires a mapping document for each service type (<xref section="2.4.3" sectionFormat="of" target="SVCB"/>), indicating how a client for that service can interpret the contents of the SVCB SvcParams. This document provides the mapping for the "dns" service type, allowing DNS servers to offer alternative endpoints and transports, including encrypted transports like DNS over TLS (DoT) <xref target="RFC7858"/>, DNS over HTTPS (DoH) <xref target="RFC8484"/>, and DNS over QUIC (DoQ) <xref target="RFC9250"/>.</t> <t>The SVCB mapping described in this document is intended as a general-purpose baseline. Subsequent specifications will adapt this mechanism as needed to support specific configurations (e.g., for communication between stub resolvers and recursive resolvers).</t> </section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> </section> <section anchor="identity"> <name>Identities and Names</name> <t>SVCB record names (i.e., QNAMEs) for DNS services are formed usingPort-PrefixPort Prefix Naming (<xref section="2.3" sectionFormat="of" target="SVCB"/>), with a scheme of "dns". For example, SVCB records for a DNS service identified as <tt>dns1.example.com</tt> would be queried at <tt>_dns.dns1.example.com</tt>.</t> <t>In some use cases, the name used for retrieving these DNS records is different from the server identity used to authenticate the secure transport. To distinguish between these, this document uses the following terms:</t><ul<dl spacing="normal"><li>Binding authority - The<dt>Binding authority:</dt><dd>The service name (<xrefsection="1.4"section="1.3" sectionFormat="of" target="SVCB"/>) and optional port number used as input toPort-Prefix Naming.</li> <li>Authentication name - ThePort Prefix Naming.</dd> <dt>Authentication name:</dt><dd>The name used for secure transport authentication. ThisMUST<bcp14>MUST</bcp14> be a DNS hostname or a literal IP address. Unless otherwise specified, this is the service name from the bindingauthority.</li> </ul>authority.</dd> </dl> <section anchor="special-case-non-default-ports"> <name>Specialcase: non-default ports</name>Case: Non-default Ports</name> <t>Normally, a DNS service is identified by an IP address or a domain name. When connecting to the service using unencrypted DNS over UDP or TCP, clients use the default port number for DNS (53). However, in rare cases, a DNS service might be identified by both a name and a port number. For example, the"<tt>dns:</tt>"DNS URI scheme <xreftarget="DNSURI"/>target="RFC4501"/> optionally includes an authority, comprised of a host and a port number (with a default of 53). DNS URIs normally omit theauthority,authority or specify an IP address, but a hostname and non-default port number are allowed.</t> <t>When the binding authority specifies a non-default port number,Port-PrefixPort Prefix Naming places the port number in an additional prefix on the name. For example, if the binding authority is "<tt>dns1.example.com:9953</tt>", the client would query for SVCB records at <tt>_9953._dns.dns1.example.com</tt>. If two DNS services operating on different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative endpoints.</t> </section> </section> <section anchor="applicable-existing-svcparamkeys"> <name>ApplicableexistingExisting SvcParamKeys</name> <section anchor="alpn"><name>alpn</name><name>"alpn"</name> <t>This key indicates the set of supported protocols (<xref section="7.1" sectionFormat="of" target="SVCB"/>). There is no default protocol, so the "<tt>no-default-alpn</tt>" key does not apply. If the "<tt>alpn</tt>" SvcParamKey is absent, the clientMUST<bcp14>MUST</bcp14> treat the SVCB record as "incompatible"(see(as defined in <xref section="8" sectionFormat="of"target="I-D.draft-ietf-dnsop-svcb-https"/>)target="SVCB"/>) unless some other recognized SvcParam indicates a supported protocol.</t> <t>If the protocol set contains any HTTP versions (e.g., "h2", "h3"), then the record indicates support forDoH,DoH and the "dohpath" keyMUST<bcp14>MUST</bcp14> be present (<xref target="dohpath"/>). All keys specified for use with the HTTPS record are alsopermissible,permissible and apply to the resulting HTTP connection.</t> <t>If the protocol set contains protocols with different defaultports,ports and noport"port" key is specified, then protocols are contacted separately on their default ports. Note that in this configuration,ALPNApplication-Layer Protocol Negotiation (ALPN) negotiation does not defend against cross-protocol downgrade attacks.</t> </section> <section anchor="port"><name>port</name><name>"port"</name> <t>This key is used to indicate the target port for connection (<xref section="7.2" sectionFormat="of" target="SVCB"/>). If omitted, the clientSHALL<bcp14>SHALL</bcp14> use the default port number for each transport protocol (853 for DoT and DoQ, 443 for DoH).</t> <t>This key is automatically mandatory for this binding. This means that a client that does not respect the "<tt>port</tt>" keyMUST<bcp14>MUST</bcp14> ignore any SVCB record that contains this key. (See <xref section="8" sectionFormat="of" target="SVCB"/> for the definition of "automatically mandatory".)</t> <t>Support for the "<tt>port</tt>" key can be unsafe if the client has implicit elevated access to some network service (e.g., a local service that is inaccessible to remote parties) and that service uses a TCP-based protocol other than TLS. A hostile DNS server might be able to manipulate this service by causing the client to send a specially crafted TLSSNIServer Name Indication (SNI) or session ticket that can be misparsed as a command or exploit. To avoid such attacks, clientsSHOULD NOT<bcp14>SHOULD NOT</bcp14> support the "<tt>port</tt>" key unless one of the following conditions applies:</t> <ul spacing="normal"> <li>The client is being used with a DNS server that it trusts not to attempt this attack.</li> <li>The client is being used in a context where implicit elevated access cannot apply.</li> <li>The client restricts the set of allowed TCP port values to exclude any ports where a confusion attack is likely to be possible (e.g., the "bad ports" list fromthe "Port blocking" sectionSection <xref target="FETCH" section="2.9" relative="https://fetch.spec.whatwg.org/#port-blocking" sectionFormat="bare">"Port blocking"</xref> of <xref target="FETCH"/>).</li> </ul> </section> <section anchor="other-applicable-svcparamkeys"> <name>OtherapplicableApplicable SvcParamKeys</name> <t>These SvcParamKeys from <xref target="SVCB"/> apply to the "dns" scheme without modification:</t> <ul spacing="normal"> <li>mandatory</li> <li>ipv4hint</li> <li>ipv6hint</li> </ul> <t>Future SvcParamKeys might also be applicable.</t> </section> </section> <sectionanchor="new-svcparamkeys"> <name>New SvcParamKeys</name> <sectionanchor="dohpath"><name>dohpath</name><name>New SvcParamKey: "dohpath"</name> <t>"<tt>dohpath</tt>" is a single-valued SvcParamKey whose value(both in(in both presentation format and wire format)MUST<bcp14>MUST</bcp14> be a URI Template in relative form (<xref section="1.1" sectionFormat="comma" target="RFC6570"/>) encoded in UTF-8 <xref target="RFC3629"/>. If the "<tt>alpn</tt>" SvcParam indicates support for HTTP, "<tt>dohpath</tt>"MUST<bcp14>MUST</bcp14> be present. The URI TemplateMUST<bcp14>MUST</bcp14> contain a "<tt>dns</tt>" variable, andMUST<bcp14>MUST</bcp14> be chosen such that the result after DoHtemplateURI Template expansion (<xref section="6" sectionFormat="of" target="RFC8484"/>) is always a valid and functional "<tt>:path</tt>" value (<xref section="8.3.1" sectionFormat="comma" target="RFC9113"/>).</t> <t>When using this SVCB record, the clientMUST<bcp14>MUST</bcp14> send any DoH requests to the HTTP origin identified by the "<tt>https</tt>" scheme, the authentication name, and the port from the "<tt>port</tt>" SvcParam (if present). HTTP requestsMUST<bcp14>MUST</bcp14> be directed to the resource resulting from DoHtemplateURI Template expansion of the "<tt>dohpath</tt>" value.</t> <t>ClientsSHOULD NOT<bcp14>SHOULD NOT</bcp14> query for any"HTTPS"HTTPS RRs when using "<tt>dohpath</tt>". Instead, the SvcParams and address records associated with this SVCB recordSHOULD<bcp14>SHOULD</bcp14> be used for the HTTPS connection, with the same semantics as an HTTPS RR. However, for consistency, service operatorsSHOULD<bcp14>SHOULD</bcp14> publish an equivalent HTTPS RR, especially if clients might learn about this DoH service through a different channel.</t> </section></section><section anchor="limitations"> <name>Limitations</name> <t>This document is concerned exclusively with the DNStransport,transport and does not affect or inform the construction or interpretation of DNS messages. For example, nothing in this document indicates whether the service is intended for use as a recursive or authoritative DNS server. Clients need to know the intended use of services based on their context.</t> <t>Not all features of this specification will be applicable or effective in all contexts:</t> <ul spacing="normal"> <li>If the authentication name is received over an insecure channel (e.g., a glue NS record), this specification cannot prevent the client from connecting to an attacker.</li> <li>Different transports might prove to be popular for different purposes (e.g., querying a recursive resolver vs. an authoritative server). Implementors are not obligated to implement all the defined transports, although doing so is beneficial for compatibility.</li> <li>Where resolution speed is a high priority, the SVCB TargetNameSHOULD<bcp14>SHOULD</bcp14> follow the convention described in <xref section="10.2" sectionFormat="of" target="SVCB"/>, and the use of AliasMode records (<xref section="2.4.2" sectionFormat="of" target="SVCB"/>) isNOT RECOMMENDED.</li><bcp14>NOT RECOMMENDED</bcp14>.</li> </ul> </section> <section anchor="examples"> <name>Examples</name> <ul spacing="normal"> <li> <t>A resolver known as <tt>simple.example</tt> that supports DNS over TLS on port 853 (implicitly, as this is its default port): </t><artwork><![CDATA[<sourcecode type="dns-rr"><![CDATA[ _dns.simple.example. 7200 IN SVCB 1 simple.example. alpn=dot]]></artwork>]]></sourcecode> </li> <li> <t>A DoH-only resolver at <tt>https://doh.example/dns-query{?dns}</tt>. (DNS over TLS is not supported.): </t><artwork><![CDATA[<sourcecode type="dns-rr"><![CDATA[ _dns.doh.example. 7200 IN SVCB 1 doh.example. ( alpn=h2 dohpath=/dns-query{?dns} )]]></artwork>]]></sourcecode> </li> <li> <t>A resolver known as <tt>resolver.example</tt> that supports: </t> <ul spacing="normal"> <li>DoT on <tt>resolver.example</tt> ports 853 (implicit in record 1) and 8530 (explicit in record 2), with "<tt>resolver.example</tt>" as the Authentication Domain Name,</li> <li>DoQ on <tt>resolver.example</tt> port 853 (record 1),</li> <li>DoH at <tt>https://resolver.example/q{?dns}</tt> (record 1), and</li> <li> <t>an experimental protocol on <tt>fooexp.resolver.example:5353</tt> (record 3): </t><artwork><![CDATA[<sourcecode type="dns-rr"><![CDATA[ _dns.resolver.example. 7200 IN \ SVCB 1 resolver.example. alpn=dot,doq,h2,h3 dohpath=/q{?dns} SVCB 2 resolver.example. alpn=dot port=8530 SVCB 3 fooexp.resolver.example. port=5353 alpn=foo foo-info=...]]></artwork>]]></sourcecode> </li> </ul> </li> <li> <t>Anameservername server named <tt>ns.example.</tt> whose service configuration is published on a different domain: </t><artwork><![CDATA[<sourcecode type="dns-rr"><![CDATA[ _dns.ns.example. 7200 IN SVCB 0 _dns.ns.nic.example.]]></artwork>]]></sourcecode> </li> </ul> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <section anchor="adversary-on-the-query-path"> <name>Adversary on thequery path</name>Query Path</name> <t>This section considers an adversary who can add or remove responses to the SVCB query.</t> <t>During secure transport establishment, clientsMUST<bcp14>MUST</bcp14> authenticate the server to its authentication name, which is not influenced by the SVCB record contents. Accordingly, thisdraftdocument does not mandate the use of DNSSEC. Thisdraftdocument also does not specify how clients authenticate the name (e.g., selection of roots of trust),whichas this procedure might vary according to the context.</t> <section anchor="downgrade-attacks"> <name>Downgradeattacks</name>Attacks</name> <t>This attacker cannot impersonate the secure endpoint, but it can forge a response indicating that the requested SVCB records do not exist. For a SVCB-reliant client (<xref section="3" sectionFormat="comma"target="SVCB"/>)target="SVCB"/>), this only results in a denial of service. However, SVCB-optional clients will generally fall back to insecure DNS in this case, exposing all DNS traffic to attacks.</t> </section> <section anchor="redirection-attacks"> <name>Redirectionattacks</name>Attacks</name> <t>SVCB-reliant clients always enforce theauthentication domain name,Authentication Domain Name, but they are still subject to attacks using the transport, port number, and "dohpath" value, which are controlled by this adversary. By changing these values in the SVCB answers, the adversary can direct DNS queries for $HOSTNAME to any port on$HOSTNAME,$HOSTNAME and any path on "<tt>https://$HOSTNAME</tt>". If the DNS client uses shared TLS or HTTP state, the client could be correctly authenticated (e.g., using a TLS client certificate or HTTP cookie).</t> <t>This behavior creates a number of possible attacks for certain server configurations. For example, if <tt>https://$HOSTNAME/upload</tt> accepts any POST request as a public file upload, the adversary could forge a SVCB record containing <tt>dohpath=/upload{?dns}</tt>. This would cause the client to upload and publish every query, resulting in unexpected storage costs for the server and privacy loss for the client. Similarly, if two DoH endpoints are available on the sameorigin,origin and the service has designated one of them for use with this specification, this adversary can cause clients to use the other endpoint instead.</t> <t>To mitigate redirection attacks, a client of this SVCB mappingMUST NOT<bcp14>MUST NOT</bcp14> identify or authenticate itself when performing DNS queries, except to servers that it specifically knows are not vulnerable to such attacks. If an endpoint sends an invalid response to a DNS query, the clientSHOULD NOT<bcp14>SHOULD NOT</bcp14> send more queries to that endpoint andMAY<bcp14>MAY</bcp14> log this error. Multiple DNS servicesMUST NOT<bcp14>MUST NOT</bcp14> share a hostname identifier (<xref target="identity"/>) unless they are so similar that it is safe to allow an attacker to choose which one is used.</t> </section> </section> <section anchor="adversary-on-the-transport-path"> <name>Adversary on thetransport path</name>Transport Path</name> <t>This section considers an adversary who can modify network traffic between the client and the alternative service (identified by the TargetName).</t> <t>For a SVCB-reliant client, this adversary can only cause a denial of service. However, because DNS is unencrypted by default, this adversary can execute a downgrade attack against SVCB-optional clients. Accordingly, when the use of this specification is optional, clientsSHOULD<bcp14>SHOULD</bcp14> switch to SVCB-reliant behavior if SVCB resolution succeeds. Specifications makingusinguse of this mappingMAY<bcp14>MAY</bcp14> adjust this fallback behavior to suit their requirements.</t> </section> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>Per <xreftarget="SVCB"/>target="SVCB"/>, IANAis directed to addhas added the following entry to theSVCB Service Parameters"Service Parameter Keys (SvcParamKeys)" registry.</t> <table> <thead> <tr> <th align="left">Number</th> <th align="left">Name</th> <th align="left">Meaning</th> <th align="left">Format Reference</th> <th align="left">Change Controller</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <tdalign="left">7</td>align="center">7</td> <td align="left">dohpath</td> <tdalign="left">DNS over HTTPSalign="left">DNS-over-HTTPS path template</td> <tdalign="left">(This document)</td>align="left">RFC 9461</td> <td align="left">IETF</td> <td align="left">RFC 9461</td> </tr> </tbody> </table> <t>Per <xreftarget="Attrleaf"/>,target="RFC8552"/>, IANAis directed to addhas added the following entry to the DNSUnderscore Global"Underscored and Globally ScopedEntry Registry:</t>DNS Node Names" registry:</t> <table> <thead> <tr> <th align="left">RRTYPE</th>Type</th> <th align="left">_NODE NAME</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">SVCB</td> <td align="left">_dns</td> <tdalign="left">(This document)</td>align="left">RFC 9461</td> </tr> </tbody> </table> </section> </middle> <back> <displayreference target="RFC8552" to="Attrleaf"/> <displayreference target="RFC4501" to="DNSURI"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <!-- draft-ietf-dnsop-svcb-https (companion) (RFC 9460)--> <referenceanchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="SVCB">anchor="SVCB" target="https://www.rfc-editor.org/info/rfc9460"> <front> <title>ServicebindingBinding andparameter specificationParameter Specification via the DNS(DNS SVCB(SVCB and HTTPSRRs)</title>Resource Records)</title> <authorfullname="Benjamin M.fullname="Ben Schwartz"initials="B. M." surname="Schwartz"> <organization>Google</organization> </author> <author fullname="Mike Bishop" initials="M." surname="Bishop"> <organization>Akamai Technologies</organization> </author> <author fullname="Erik Nygren" initials="E." surname="Nygren"> <organization>Akamai Technologies</organization> </author> <date day="11" month="March" year="2023"/> <abstract> <t> This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-12"/> </reference> <reference anchor="RFC8484"> <front> <title>DNS Queries over HTTPS (DoH)</title> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <author fullname="P. McManus" initials="P." surname="McManus"/> <date month="October" year="2018"/> <abstract> <t>This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange.</t> </abstract> </front> <seriesInfo name="RFC" value="8484"/> <seriesInfo name="DOI" value="10.17487/RFC8484"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba"initials="B."surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="I-D.draft-ietf-dnsop-svcb-https"> <front> <title>Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)</title> <author fullname="Benjamin M. Schwartz" initials="B. M." surname="Schwartz"> <organization>Google</organization> </author>surname="Schwartz"></author> <author fullname="Mike Bishop" initials="M." surname="Bishop"><organization>Akamai Technologies</organization></author> <author fullname="Erik Nygren" initials="E." surname="Nygren"><organization>Akamai Technologies</organization></author> <dateday="11" month="March" year="2023"/> <abstract> <t> This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP [HTTP]. By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc (https://github.com/MikeBishop/dns-alt-svc). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-12"/> </reference> <reference anchor="RFC6570"> <front> <title>URI Template</title> <author fullname="J. Gregorio" initials="J." surname="Gregorio"/> <author fullname="R. Fielding" initials="R." surname="Fielding"/> <author fullname="M. Hadley" initials="M." surname="Hadley"/> <author fullname="M. Nottingham" initials="M." surname="Nottingham"/> <author fullname="D. Orchard" initials="D." surname="Orchard"/> <date month="March" year="2012"/> <abstract> <t>A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6570"/> <seriesInfo name="DOI" value="10.17487/RFC6570"/> </reference> <reference anchor="RFC3629"> <front> <title>UTF-8, a transformation format of ISO 10646</title> <author fullname="F. Yergeau" initials="F." surname="Yergeau"/> <datemonth="November"year="2003"/> <abstract> <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t> </abstract> </front> <seriesInfo name="STD" value="63"/> <seriesInfo name="RFC" value="3629"/> <seriesInfo name="DOI" value="10.17487/RFC3629"/> </reference> <reference anchor="RFC9113"> <front> <title>HTTP/2</title> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/> <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"/> <date month="June" year="2022"/> <abstract> <t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t> <t>This document obsoletes RFCs 7540 and 8740.</t> </abstract>year="2023"/> </front> <seriesInfo name="RFC"value="9113"/>value="9460"/> <seriesInfo name="DOI"value="10.17487/RFC9113"/>value="10.17487/RFC9460"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6570.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"/> </references> <references> <name>Informative References</name> <reference anchor="FETCH" target="https://fetch.spec.whatwg.org/"> <front> <title>Fetch Living Standard</title> <author><organization/><organization>WHATWG</organization> </author> <dateyear="2022" month="February"/> </front> </reference> <reference anchor="RFC7858"> <front> <title>Specification for DNS over Transport Layer Security (TLS)</title> <author fullname="Z. Hu" initials="Z." surname="Hu"/> <author fullname="L. Zhu" initials="L." surname="Zhu"/> <author fullname="J. Heidemann" initials="J." surname="Heidemann"/> <author fullname="A. Mankin" initials="A." surname="Mankin"/> <author fullname="D. Wessels" initials="D." surname="Wessels"/> <author fullname="P. Hoffman" initials="P." surname="Hoffman"/> <date month="May" year="2016"/> <abstract> <t>This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS.</t> <t>This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic.</t> </abstract> </front> <seriesInfo name="RFC" value="7858"/> <seriesInfo name="DOI" value="10.17487/RFC7858"/> </reference> <reference anchor="RFC9250"> <front> <title>DNS over Dedicated QUIC Connections</title> <author fullname="C. Huitema" initials="C." surname="Huitema"/> <author fullname="S. Dickinson" initials="S." surname="Dickinson"/> <author fullname="A. Mankin" initials="A." surname="Mankin"/> <date month="May" year="2022"/> <abstract> <t>This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios.</t> </abstract> </front> <seriesInfo name="RFC" value="9250"/> <seriesInfo name="DOI" value="10.17487/RFC9250"/> </reference> <reference anchor="DNSURI"> <front> <title>Domain Name System Uniform Resource Identifiers</title> <author fullname="S. Josefsson" initials="S." surname="Josefsson"/> <date month="May" year="2006"/> <abstract> <t>This document defines Uniform Resource Identifiers for Domain Name System resources. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4501"/> <seriesInfo name="DOI" value="10.17487/RFC4501"/> </reference> <reference anchor="Attrleaf"> <front> <title>Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves</title> <author fullname="D. Crocker" initials="D." surname="Crocker"/> <date month="March" year="2019"/> <abstract> <t>Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the 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 collisions resulting from the use of the same underscored name for different services.</t> </abstract>year="2023" month="October"/> </front><seriesInfo name="BCP" value="222"/> <seriesInfo name="RFC" value="8552"/> <seriesInfo name="DOI" value="10.17487/RFC8552"/></reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4501.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8552.xml"/> </references> </references><?line 188?><section anchor="mapping-summary"> <name>Mapping Summary</name> <t>This table serves as a non-normative summary of the DNS mapping for SVCB.</t> <table><thead> <tr> <th align="left"> </th> <th align="left"> </th> </tr> </thead><tbody> <tr> <td align="left"> <strong>Mapped scheme</strong></td> <td align="left">"dns"</td> </tr> <tr> <td align="left"> <strong>RR type</strong></td> <td align="left">SVCB (64)</td> </tr> <tr> <td align="left"> <strong>Name prefix</strong></td> <td align="left"> <tt>_dns</tt> for port 53, else <tt>_$PORT._dns</tt></td> </tr> <tr> <td align="left"> <strong>Required keys</strong></td> <td align="left"> <tt>alpn</tt> or equivalent</td> </tr> <tr> <td align="left"> <strong>AutomaticallyMandatory Keys</strong></td>mandatory keys</strong></td> <td align="left"> <tt>port</tt></td> </tr> <tr> <td align="left"> <strong>Special behaviors</strong></td> <td align="left">Supports all HTTPS RR SvcParamKeys</td> </tr> <tr><td align="left"> </td><td/> <td align="left">Overrides the HTTPS RR for DoH</td> </tr> <tr><td align="left"> </td><td/> <td align="left">Default port is per-transport</td> </tr> <tr> <td/> <tdalign="left"> </td> <td align="left">No encrypted -> cleartext fallback</td>align="left">Cleartext fallback is discouraged</td> </tr> </tbody> </table> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>Thanks to the many reviewers and contributors, includingAndrew Campling, Peter<contact fullname="Andrew Campling"/>, <contact fullname="Peter vanDijk, Paul Hoffman, Daniel Migault, Matt Norhoff, Eric Rescorla, Andreas Schulze, and Éric Vyncke.</t>Dijk"/>, <contact fullname="Paul Hoffman"/>, <contact fullname="Daniel Migault"/>, <contact fullname="Matt Nordhoff"/>, <contact fullname="Eric Rescorla"/>, <contact fullname="Andreas Schulze"/>, and <contact fullname="Éric Vyncke"/>.</t> </section> </back><!-- ##markdown-source: H4sIAAAAAAAAA51b3XLbuJK+11PgKOfCTkmKf+JJ4qrsrMdOTlwndjy2c6am drfGEAlJHFOEhiDtaBI/wHmufbH9uhsASUlOMpubyCLYaPTv193QcDjsVVmV m0PVvzLlXZYY9VNWpFkxVWd6saD/J7ZUJ+dXip6b0vV7ejwuzR298a/jn8Lj fi+1SaHnoJSWelINM1NNhjpNh+4uGQ/Twg13XvUSXZmpLZeHylVpr5ctykNV lbWr9nZ2Xu3s9XRp9KH6hylMqfPevS1vp6WtF4cKhHq3Zolv0kN1WlSmLEw1 PKGdej1X6SL9Tee2wO5L43qL7FD9V2WTgXK2rEozcfi0nNOH/+n1dF3NbHnY U8Oewr+scIfqp5G6Smb3uqz+5C/lJD+Z4nc9z4ruM1tOdZH9qavMFofqzFRa XeS6giDm2Oe0SEa8zMx1lh8qksN/jvGHS0bgudcrsA7v3hlwoC7fHu/t7r46 hCyKSfvB2zfXx+8OmVBQ0FtTJTP1PrsjrVzRmXWZ9nlJCrkeqt1d9daMy1qX S7W3s7cnb+tyaiq8PquqhTt89mxCZEZuYZLR/UxX99MRDvSs3+v1hsOh0mNX lToBn9czo1jDpPzSOFuXsI7SJNCBqpYLo8ynBb53ximtxrYuUpXYPDcJCUbZ iTJFurBZUak5ZAQW9YCtpXZG3c9MoQwUN84zN6MDabxcFP7lyuJv0kGqnJjl SDEfWeVMPlGJLtTYKFdDIDosGQjVCnw7tlWVOZWlpqiySQZK4yXWphZqKZg2 SF7PsASGW8+xSi1Ke4f1jknw0ectHxB2iAmhDl3rPLf39BwvzIlpch2ycXC2 WMD0+EVTJOVyUeFlSLZw/D22gn3a3I1E7PMsTXPT6z0h4y5tWrMcWkrYqIDP n/9GD1+fDk9GLa+Ds9mF+B0r/eGhOVqSZziqU/dZNVPR5iByDQ1Wambv6Rxw Q5JsTn7GJhl16fhIHZlnWDrXSzXTWJfNaSucdWFKJl6AZ7yxKLM7nSyJETyp MuNY/CYQ2qSrvksgV9MPYvWSjq+QDKAEMO0q0g4+wwbtgs4D1SyVxeqyc0qx GDJYVkNRz8emBCdHLcUSK3ZSwZRaDNkC9MAVDFCdXlA8ItNXW2Y0HQ2whTp5 d3yxPVBjCBF/OTs3ZNCV+YQXsootVufOktmunjPwH6j1EU69nmFkEGGtczaA nLgD1Uk2rUs+0DYfmXarsjk5Im0B17HFMDUTXedV56C93kc4H1yz+qpdleaP OivZr4MHRCdhiybraGtBbX3+fOV9d2/0fLRPe7BtPjxsD9r6IwPT3gqZVoUY FGmRlDKK7ggsFTPJMiSzazN9dZdc6FLP3ddduO299HcfjtFftZ7gwi3HJg+w kwlkvdkDSOTRlR0dL8lrzpkbXN2pPLs1TN6S+q7fX6mtE3u9De/9EeH/xcuD lw8Pg2bBu+vrC17yjpb8DUtePn/5nJbQvnHZzx9Pj2nVz4HQq72DnYeHUStm RN0Zl5TZGFxlFB7b8iKvIwGneMhuMZXcO1zU5cLCVsYaATcrKFhe1WMHw6DX KHvAgBO2QQomeQ6X0ItKyM9NMkOKdHOiWRhD1CHTEBTD211Tjs5E6krsfF4X fgP4THVv4I+uqscsBRhrXTrSSnALtz2i6HlsiztyLiLH4jKTrMj4bxEMQIQi FOFU/+zj1XV/IP+r8w/8+fIN5Hr55oQ+X707ev8+fggrrt59+Pgez3v+U/Pm 8YezszfnJ/IyvlUrX50d/doXJfY/XFyffjg/et8PGulFjQACkawoTARHEN10 tPjT8YXafQ7NewCBEO9tZfcFbKVHmdCHQwpc8id8AOFmsTCagiKZPhxukVUI GgPawcE5C4WQaViWpxymKFQzoXNNAebzE4le1fKh1/MRhANHwY+3spGBCn8+ Pzp747YjdvQ+5/h0FI1xitqRbV7AIIYXQGbZJ9qBvurEEo4kMZBw1kLy4bxA T9ilYZtvKSp90vNFDp9usRXSVYuJdvjFoW9AYXfk3x3B7m5gH3WekgZg7CUv q9TNb1g3WlsLQZ36aE+wJoG3OBY0y4O+S5kDaBGU7nwGc8aDKmGRHDKjeMMx sbTzDobx4hZaBIwAX+krxhmyEM5gmohDQdGCoqOAWwNeRf/hrQcrIaB2PlxO bIQzBlAWmFQ9jdWAgGbiY9hJ25K3Go3tjp63NNZJyO1MJKfRFH0WyJg41roh jGj/o+a0RJ63Ew66Al4VQltMeDEkCvZ1aFYsIiZetpE8qyj0tdI73vpY5JTn GUncZ1CcD14m9XLMXAeTMLmow/Gq9MixnqgroqFzNpfDtWSNSHVOgAUIZrBq umsgqWijET5GF+H+QpA4IGtSre2wK05YF03iignm48kFEbw+vhhE1Eg2Tq9v wBbR17cO9rex8Tt7b0CGsVFJbu99o3ugeTadVeuYaGzZz1mYZEKrcK3j7pza yY0Pb/rq4+VpCA9Ii9gKX7xGXHx+sLOLINkCh5K1Obg1+hlQ5gFWJbOCGQs2 W2dBbflIFASBtXJsOhy2RNrzKlR2ngmUaW1CBst2tKJBwY8tREg7PwLmOJYy fDEpzOqXUPus2Vw0Wfc4MhxsCsSLXCc+NrT3pdRREMdZ8Gt5yxYx8K2qKJs8 whoMur8WgQ9fvTrYv+mLZj1UlJhMAXnJltaJ8Ryf6aXRI1FaqVNwcG+7yYgq EUGlYL2JwK2zugAoW4/HBoVOZkvnA4AuEXOmRpI3qcPFcpDKY4ri4jMckCVK cqHqLYAFsglnchI+WixyxLBxTuW2hPQIf/9plo7jic4XXCuCG8I3oQoNkYnN 04MvqsxC7dmO2y9Gu624LbVZyQGnsI27+zepr+LdrrDBnIbEBTyQOEitoRcr Qhv50ouf1/tFrSPQHhrIsqg6CudIXaEQrdrFCkMNpI0+JAlHhcQgmb7acob8 PRzmJZcf36yKtxH4OLpz/pZikbaYFtmfkFPgsSVPvUGMBAHkdOEbFjkVLojD FF6WjOkVodQ2zu3P9ggWzvb723xycR9/xmbPdisBRYGgOiln7AwSmInIQ2Zj m4P8oFv/XPR5BLSHda5JYE0zhmIZUZTSI0iZwwsUDS+ZZ86RpGVzVmrIJNgO yiez5EM2TZxvyaUxQ96/cbBOLhz4ECheeSvm0snBkFtDihMN7ZBU3DtaQIGV oSjM0s3KLnXI5dwyjNJVLI46VclAHb2/OEcRM7VVJhgkGjdIGRLHlM6Dk5XW uWE8bAowPS01YoeuwM+tk9xP+7Z91UVgF5tHJDNp26mo+VZzrOO1e12vhcQp 31ReNMGZpIL5Vvbmsn69R6W2Xh7se/O7lqrK/jxQz5+HL99tj7onQny31HBJ OAHOqVNZWR+4WcQ+EQRUNjfYU5QQewP8VxQ1rAw6r3wQIfZuWmafTZFtDXta O04wiWhvlWcQm25drYcLkWHsFaSxcOQy45ET9UfbqIJaDrrGn+9U1oXTExPy oD/ijPDvnOI7EILJzZ3mUi9JKCZRvUxhqQB2t+VtREw+eACuWjDTdDPYgglP y/vkrdLJm5OBww+okNv2waPVcqmlfwuYN6Rav4lrPiBicUFNC26SES7JctNu lkUEp/2OEE62qHMxZHJWv9GYhCF4syUDOiY7kTg1izehoA1OqFVydX7KaImO RD6cJbfGG4cXLWITTudCA4M6B1x1EPxY5Dbz9ZC+s1nq+3/ijw2sbSr5GG3X FOlThS1i/6ypl2BjAoYcx0YIGsXTU65S/DHJ5g1DbWLUg8eWFEV9lQxDxOSp 1IMjz0NTRbgefY0uIbPQdSSMUZrH7QvSaxJ0lyicDdVqUnXwg0eaZCgSOO50 Xhu2U/OJkTT7n7S8ZG/mZVKz4oR74pfaYZI+KFtZb6rerFnsY50KnT4Wu1ZJ 3CeQqsaw/FucmVp5cdbw+TNPTCgKcpj9wMarG/TUBU3XXIS3v5NdEBQkDnRy nG8cSllByqNW+dymsQXG6o5RAZ+zxd3zGUCcfPyBP/be1hXVqJ1dxX1CZ7jh l8HfublfB3s+q6vPT0J+7/WAoeUzjDVjmAL55GbIOko7aOt+Rm09fqC2uM7K igAa/CSgIAv1jRpdbbeKZqqurmGS7N1U2JlcQCstpcRELagfDl7sDFTTENgl pIUC06Zioh+v3w5f+nbV/g97rx4evgIQHwFChDUGqn3sFfzjpwsdhnmJzwc0 XqDCA2/e6TLTEdwEOgnJyQ8M2DsbsKMoPHHiU1WgjViDHLaSnn9gHBo7uNus m/xeL0lFUAECEm05qaUsQDjv3xz683gNiZhe7e7uNyJ9OdpnoYaqLwRVUG+l v3U0LYEWTkqcU4/fUKzxNs7oDUXZNCtWinHRC2Pmm+AFg1jRrjRnGngquoqu G2JpVOwWkqFXFvcLaP/IVNBCCjtkKNegzTCuCLCTt3hEFzZYVWMnLFdI7ng9 9jfVJQmpz2i4ry4vndRrIuYWLTJbAD+jvazjWEJQsm/KxCLVOYsEV4X4v6qv wMm41dVqQHmD/wYNXnfUInAGgQc6cJz/Cr/+8rLdg/EI0iGawhGXg5iUpQRG MRt2X9Q8kSVCNASCtMh8As2BMk2ahv5CApUolhtdhkEin4600gCU0tZT7plE pE9TgsLkHOveZ8CtOnbqV4YUYD6hmX8qyYZa/9TWDoKgTBqBq5hgU4JiNyBH GwaBYayEHFf79FE2vXYdEgqRnEN/esqjyk47A2R5Zr0+TonBChbj4VN3xBmG LaH2YszSjDPI9nxzRAJrgxHARLBZGqmQR9wWNK6dmYZsLeO92OIQSBeLH48N RtRh5G6FmqDArmnUx67S1FbepXmy00lMDKxYpMReGCP4Saf0jH0s3xAdSAQ4 rMloQsxdRh74+eatN4cG4k4pBMZG+fZgE4cex0B3d1I2xJjHgaHb+tQBiNAs FJyeRFNszevEmHmMHVEKAVopklp9IhmRxXqew4dcZVifT6k7WFGr0yjaFc1y 4UaWRTZEvkhVLB3Kwhen2oe/LKxgiccaxXRnkTondAI/Sy2xAljBELHAUm45 ++Ead06ynDvSkMMvjNeY11rm5AsyMYYSM4iDxve+dRmbMddcodJUKMQOAcTB v/wcrju3ag0KdqR29VPiJm94Ez7KM+3OgBliAF2ZMbff5sy6MnLjqPJGXNYR PjtqlEGOU/D0x7FYQ7fwxtdGgjRcd2qLfTmnUTW8FXA19+hdHAXQ9YB2eb1N HsH/uDPZ3W2kXuzt7KjTcxHorlp9TFjodWor4R7RdMjTvHgM6nuGaz3ISuHF Z3Tbiq3x84/4+HAzUludk2QSGWMva7TCZovWGo+dZ1v+LfnH7M72AkJ9vcqH 2n5UDeGrRxTB7D3l/gO0sGG1qKujGcGnnFl3pe7F4x0466e153thtNhfJ90X 9ZrVSdSJjFnI/geeuZ+/wpzwFvkJr7zr6HD11Wd/eAW236Sj8NuUoj8hf2cU FLgNHwp3cDGxFg9HqxQPD/YP9hty+43ivepXX0BoCgbw3y1le2NYXx1MdpDa PwazvcFsvzEHf5pVMntfIcOye02KW32Lmk8bjziSd+igQgbraO2Q0v/r0Wgk Rsjzaim+5WbXDU4fSNz4MineS2m3BMl9PEyS3NqGNDJ967pTi3DXm3bi8yJL 4hqKW1eUQGhAckyoLTVlQEYoAI9S6iTTJT8/cRHcSjL2yCnUxYl/WWZc8TWc Te4jpdwmoRaRZKoF1ptYETCLTBssnYAdyierY9Z4h2/ODfwACBm/b5hUS7PD cpzcWD3IdTIfoKAxIAAgv1iHtPFyuBpEnamEvqGadxnG29RDakCg1OamnWAQ Ea/eHMcbRLye6/D4UhjR0Z2lcLC1M7UvbjnTuv1YWuuvLVFPZzvelGN0cUd6 0IHrIPEGnj2Bnk9WG8heuwHBBOiDgAfFonzs3gcIcyR/J036ZUj/U8MARZTd vVoXq1yuwqhx0J6ypZalwmMoj4g1rxiWBsma8LwAry3pojQF6z5laFZLyF/I j07aVSg1CZc0oLVdtzD1eH+gubsIAOQvKoHchPDQmLpL3ET3x+fboqGjr+na A4KFdTJty0PFMKFrSNJpiy36J+rSSN3ZNK6cXHZZOWms5g1VFonZBHtb43jR hNzCAYfUSs2R4sa/c2c7MqGaJmmrpukMa/kSURz/cEkb7CtMQEq6iuv9howm eD/E+9OSofa0uY3ie3lZ0TgZNr43pb/M0sQOMiIRDotQbsjILZu/v/twdU0X fwRpSy+QYlR84MdHhQQretSPuS8ukrp6Eus6b1Tcp3YzHE8aw74JBCnC7ju9 jiRc34HZEqMwkbbXpsFbRcyaqYVX6WrqRJw7bJBYe5uZOOII41+V0GxSZuoy QoEJx3ZmUCXDbRAlE/DRr3vpbcOkfF0kz+pFbnV6w73bRSUzxQs8DK7qr7RS UkrUhDr08saa9lg0IQisBlMwSRK5iQlbiEQQKZFSJvHUyjcrjXxZzjoObQRy 46UkkUGrZwNp1AWBFxnToehBmQ0enL9f3EoWTM1fHs4h3vhc9qV7idk8Q3VG oT/zU37gqtZ1TWpF32ms4fK1aFon0u5qSo+Q7mdy3S6bFmwvTc9/vjozXS1H Byvexv4isgohgwTlRScTlnhNPpNmElmaRZ6ouPaD1NaC0aAZk4WyvXPhM9xo DI28ZegrxMzl79FzX8vf1A6XYL1LU7wkY5MJjb8X66cU8cgUfgnENyXrXZ1T XPazoPa4RbyaQGs4L/UjnXQApBkasxLf/w/MLFdGmc2shvqZc5r8hTDEeRQ8 xi24o3v0KyzHN0hNWVpqpZyRJS5aoyxul0TBcaBpX8SJLdGS0lu8A9ncIWjC uqU6jiwyyoushMZ/dCwukVt9CPoymVnLP4qgAE7W5qfCo814rzWi/cuYj6cW yzhVDCmwdUMwCDo4RftuShxCrneIm3YAhcpHwcFGB2FUIF7yDUAwNrKMs7vr XFwDH77y3riH+QRcUPEGK7gqDvA3oo1VdOlbweaRhhlhHE9hbb7oEDRommC7 gokZJZs0d/JDH6ZGxDcpcXHVvXM917cy9+P7S56XGABg8jr9HbhTvieIxAgp 7sXOKRfTsjJc+J+bcO3o9Oj8aK32uIC1xgEZr+Cbq02HngqK7mQUBMtlp6AI PzPjTrmpyFBLMwWk5DLjizqXZKq+cGlNNdQXdWY0Z6aN/74ArnHxlZjwDcgM 5Z/a8Gnjv/XHTOZF3CSM3b6s3tTnb+Ps4Yva6jSvt0HGC+7Ho6oqc6MndB/x 5cHBHnW9/h9i5CuGBbl4QrHvH7kdw1yvErvA62945aWX6CFJ9PJSXf968Qas /Xb+4eSNYoj2nVJ7XDKsTJYM1bBRTBtOzz9wIusjwwq/Kryq53O4pg9eFScM TjMyxuB7ivGXcjBVXh3mOdybb/24g3hh4/nmv+9YsiaNv2Azjy4EtadP6ewE d3iC9vTpOm8yZ/4u3p4+hVrpJyzrdAI11tDWD8+3v4caO5tc5NxE8YtcgL9h cXPqOdgHQsgRB29++/vFh8vrkTz3vEk8SfnG2aaTypiXZwnNlOkx3o46l2/O 4nWifwpxUOPZ4nfKLVy+jvc4u/xBbqH7S3VimHx1p/aB2re3VB8QKcr4k6RI zt+c6vD2HdRO2le3qA9lymEDB/4qtXPb+sXS8D+Qr4wu+fJITBhCjS6iJgT0 UFJOOUv0Ph9K2WPS132sdqb/QM6si9vYQJpTmVKau8zcCx6RMqPMUAbz/dnm h1NHRVqae3VMVRD+HqgLSg2oSwt1kv1+i79xbMCAyQREB+oE+cDk6gwImfP9 GTI5TlPOsGCg3pRANJeGwmOuB0IbQeUqmdX5n35C/b//pkX/WhbAYKPe/wFy CaSeCD0AAA== --></rfc>