<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.8 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC7858 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml">
<!ENTITY RFC8484 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml">
<!ENTITY I-D.btw-add-home SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.btw-add-home.xml">
<!ENTITY RFC7719 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7719.xml">
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>

<rfc docName="draft-mglt-add-rdp-03" category="info">

  <front>
    <title abbrev="DRDP">DNS Resolving service Discovery Protocol (DRDP)</title>

    <author initials="D." surname="Migault" fullname="Daniel Migault">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>8275 Trans Canada Route</street>
          <city>Saint Laurent, QC</city>
          <code>4S 0B6</code>
          <country>Canada</country>
        </postal>
        <email>daniel.migault@ericsson.com</email>
      </address>
    </author>

    <date year="2020" month="July" day="28"/>

    <area>ART</area>
    <workgroup>add</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document describes the DNS Resolver Discovery Protocol (DRDP) that enables a DNS client to discover various available local and global resolving service. 
The discovery is primarily initiated by a DNS client, but a resolving service may also inform the DNS client other resolving services are available and eventually preferred.</t>



    </abstract>


  </front>

  <middle>


<section anchor="requirements-notation" title="Requirements Notation">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”,
“MAY”, and “OPTIONAL” in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

</section>
<section anchor="sec-intro" title="Introduction">

<t>A DNS client can proceed to DNS resolution using various resolving services. 
These services can be local or global and can use a wide range of DNS transport protocols such as, for example, standard DNS <xref target="RFC1035"/>, DNS over TLS <xref target="RFC7858"/> or DNS over HTTPS <xref target="RFC8484"/>. 
The local scope of these services may take various forms. 
For example, it could be associated to a network perspective ( restricted to the network the DNS client is connected to ) or to an application perspective ( restricted to some domain names ).</t>

<t>The purpose of the DNS Resolving service Discovery Protocol (DRDP) is to discover resolving services available to the DNS client. 
These available resolving services to a given DNS client may highly depend on its location or browsing activity. 
The number of resolving services available to the DNS client is expected to remain quite consequent and evolve over time. 
Similarly, characteristics associated to these resolving services may also evolve over time.
As a result, the DNS client is unlikely willing to synchronize such a huge data base of resolving services.
DRDP proposes an alternative that consists in adaptively discovering the available resolving services based on the DNS client context.</t>

<t>DRDP adopts a hierarchical approach where the DNS client (or  DRDP client) discovers the resolving services from resolving domains (RD) or a pointer to a list of resolving domains (Pointer).</t>

<t>The document does not describe how the DNS client is provisioned with RD or RD_list. 
The DNS client may obtain the contextual resolving domains via various way, including a configuration, via DHCP Options <xref target="I-D.btw-add-home"/> or derived from specific procedures [I-D.mglt-add-drdp-isp].
The DNS client is expected to discover resolving services from all RD or RD_list before proceeding to a selection process. 
The selection process of the resolving service is out of scope of this document.</t>

</section>
<section anchor="terminology" title="Terminology">

<t><list style="hanging">
  <t hangText='DNS client'>
  the client that sends DNS queries fro resolution. In this document the DNS client designates also the end entity that is collecting information about the available Resolving Services and then proceed to the selection of a subset them. The selection is processed according to the DNS client’s policy.</t>
  <t hangText='Resolving Service'>
  designates a service that receives DNS queries from a DNS client and resolves them. A Resolving Service is implemented by one or multiple resolvers.</t>
</list></t>

<t>Resolver: 
A resolver designates the software or hardware handling the DNS exchange. See <xref target="RFC7719"/> for more details.</t>

<t><list style="hanging">
  <t hangText='DNS transport'>
  designates the necessary parameters a DNS client needs to establish a session with a Resolving Service.</t>
  <t hangText='Resolving Domain'>
  a DNS domain that hosts one or multiple resolving services.</t>
</list></t>

</section>
<section anchor="overview" title="Overview">

<t>DRDP is a DNS based protocol that addresses the requirements listed in <xref target="requirements"/>.
The figure below represents provides a high level description of DRDP.</t>

<t><list style="numbers">
  <t>The DRDP client considers the source of resolving domains (RD). This document defines two ways to collect RDs:
RD are directly provisioned - in our case rd.org) , or RD are retrieved from a Pointer - in our case rd_pointer.org. In the later case RD are collected from a DNS request of type PTR. In the case of Pointer being rd_pointer.org, the QNAME of the PTR request would be b._dns.rd_pointer.org.</t>
  <t>The DRDP client collects the resolving services and associated parameters under the umbrella of each RD. 
The resolving services offered by the RD are collected via a DNS request of type SVCB and the associated parameters are provided through SvcParameters. In the case of the RD being rd.org, the QNAME of the SVCB request would be _dns.rd.org.</t>
</list></t>

<figure><artwork><![CDATA[
                     +---------------------------------------------+
   +---------------->| source of Resolving Domains                 |
   |                 +---------------------------------------------+
1. collect           | * resolving domains (rd.org)                |
Resolving Domains    | * list of resolving domains (rd_pointer.net)|
   |                 | * other means: configuration, DHCP,         |
   |                 |                Website co-hosting, derived  |
   |                 +---------------------------------------------+
   |
+-------------+      +---------------------------------------------+
| DRDP client |----->|  Resolving Domain                           |
+-------------+      +---------------------------------------------+
2. collect           | rd.1.com,   ...,  rd.i.com,  ...,  rd.n.com |
Resolving Services   +---------------------|------------------|----+
and associated       |                     |                  | 
parameters           +---------------------|------------------|----+
                     | Resolving Services  |                  |    |
                     +---------------------v------------------v----+
                     | +-------------------+      +--------------+ |
3. Proceed           | | doh.resolver.net  |      | doh.isp.com  | |
Selection            | +-------------------+ ...  +--------------+ |
                     | | dot.resolver.net  |      | do53.isp.com | |
                     | +-------------------+      +--------------+ |
                     | | do53.resolver.net |                       |
                     | +-------------------+                       |
                     +---------------------------------------------+
]]></artwork></figure>

</section>
<section anchor="list" title="Pointer to a list of Resolving Domains">

<t>A Pointer is a FQDN that points to a list of FQDN that designates RD. 
If Pointer is represented by rd_pointer.net, the associated RDs are retrieved by the DNS query of type PTR for b._dns.rd_pointer.org.</t>

<t>The zone file below is inspired from DNS-SD where b indicates a browsing domain, _dns indicates the DNS resolving service, rd_pointer.org the Pointer and rd.1.com, … rd.i.com the associated RDs. 
Note that they do not necessarily need to share a TLD. 
The order of the resolving domains is irrelevant, and the zone administrator SHOULD regularly reorder them. 
The RRsets MUST be signed with DNSSEC.</t>

<figure><artwork><![CDATA[
b._dns.rd_pointer.net  PTR rd.1.com
[...]
b._dns.rd_pointer.net  PTR rd.n.com
]]></artwork></figure>

<t>Using the DNS provides the advantage to retrieve the resolving domain without requiring other libraries than DNS as well as benefit from the DNS caching infrastructure including the use of the TTL.</t>

<t>An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly all current networks. This is based on an MTU of 1280, which is required by the IPv6 specification, minus 48 bytes for the IPv6 and UDP headers.
This document RECOMMENDS that the number of RDs associated to a Pointer do not generate fragmentation of the DNS UDP packet.
It is believed to address most common needs or expectation from a vast majority of stub DNS client.</t>

<t>When the number of RD exceeds this limit, the DNS client may carry this over TCP which is likely to be supported by DNS client wiling to upgrade to DoH or DoT resolving services. 
However, the transfer of large number of RDs is considered as an application specificity that would benefit benefit from the compression of the transferred data provided by ftp or http. 
In such case, these application may define there own specific mechanism to provision the RDs.</t>

<t>As of July 27 2020, 1232 bytes correspond to the 94 first most popular FQDN listed by <xref target="moz.com"/>. 
The current size of such lists <xref target="curl"/><xref target="dnsprivacy.org"/> have less than 50 resolving domains. 
Other lists such as <xref target="public-dns.info"/> have as much as 11.000 entries, but such lists seems to contain open resolvers which is out side of the scope of a selection process. <vspace />
Web browser (Google Chrome) also have lists over 10.000 entries, but in case a significant number of entries seems to be IP addresses that have a very limited network scope ( e.g. limited to the ISP ).
The length of the list in scope to the DNS client is in fact significant smaller in term of IP addresses and even smaller if resolving domain are able to represent multiple IP addresses. 
Overall, the size of such lists are currently due to the absence of discovery protocols.</t>

</section>
<section anchor="all" title="Discovery of Resolving Services">

<t>The discovery of resolving services is performed by the RDP client with all the available RDs. 
Given a RD rd.org, a DRDP client sends a DNS request of type SVCB for _dns.rd.org.</t>

<t>The example below presents the use of an AliasForm followed by a ServiceForm which allows an indirection. 
The Alias form is not madatory and instead only ServiceForm associated to _dns.rd.org could have been used instead.</t>

<t>The SvcFieldPriority indicates the preference of the RD. It typically enables an operator to indicate that an encrypted DNS is preferred.</t>

<t>The SvcParamKey alpn MUST be present when TLS is used as its presence and value indicates the DNS transport. 
The absence of the alpn SvcParamKey indicates Do53, alpn set to dot indicates DoT is served while h* indicates DoH is served. 
Note that the port value (53, 853, 443) is not used to determine the DNS transport as non standard port MAY be used. The example below uses an non standard port 5353 for illustrative purpose.</t>

<t>Other SvcParam are detailed in <xref target="svcparam"/> and are optional. 
A SvcParam not understood by the DNS client MUST be ignored.</t>

<t>The RRsets MUST be protected with DNSSEC and when alpn is provided a TLSA RRset SHOULD be present. These RRsets have been omitted for clarity.</t>

<figure><artwork><![CDATA[
## Discovery of all service instances
_dns.rd.org. 7200 IN SVCB 0 svc.example.com.
svc.example.com.    7200 IN SVCB 12 ( svc0.example.net.
                                      port="5353" user-display="Legacy Resolver" )
svc.example.com.    7200 IN SVCB 1 ( svc1.example.net.  alpn="dot" 
                                      port="5353" esniconfig="..." 
                                      user-display="Preferred Example's Choice" )      
svc.example.com.    7200 IN SVCB 3 ( svc2.example.net. alpn="h2"
                                       port="5353" esniconfig="..." user-display= )
svc.example.com.    7200 IN SVCB 2 ( svc3.example.net. alpn="h3"
                                       port="5353" esniconfig="..." user-display= )

]]></artwork></figure>

<t>Note that <xref target="variant"/> provides another variant to perform RDP. 
Such variant is left for further discussion and address the need to be able to narrow down the discovery to a subset of resolving services such as DoH-only or DoT-only services.</t>

<t>Some notes:</t>

<t><list style="numbers">
  <t>_domain uses SVCB but does not have TLS. While SVCB has been created
essentially for TLS based service, this does not appear to be mandatory.</t>
  <t>Should we have some constraints regarding the SvcDomainName and QNAME ?</t>
  <t>do we need the service subsets</t>
</list></t>

</section>
<section anchor="ttl" title="TTL">

<t>The DNS client SHOULD perform DRDP at regular intervals as indicated by its policy.</t>

<t>The selection process MAY remove resolving services with short TTL lower than a day as it indicates some source of instalbility. 
Given a subset of selected resolving services, the DNS client may perform DRDP 1 hour before an SVB RRset expires.</t>

</section>
<section anchor="svcparam" title="SvcParamKey">

<t>This section defines a set of SvcParamKey that MAY be use to carry the necessary informations for the selection process.</t>

<t>alpn
:</t>

<t>esniconfig
:</t>

<t>port
:</t>

<t><list style="hanging">
  <t hangText='user-display'>
  indicates a strings in UTF-8 that is expected to be representative to a potential end user. Though there is no restriction in the scope of that string. The string is likely to represent the service within the resolving domain.</t>
  <t hangText='uri_template'>
  designates the URI template for DoH. This key MUST NOT be present on non DoH services and MUST be ignored by the DNS client on non DoH resolving Services.</t>
  <t hangText='auth_domain'>
  indicates the list of authoritative domain name the resolving service has strong relation with. It is expected that a resolving service may prefer to perform DNS resolution over these domains to that specific resolving service as to preserve its privacy. This information MUST be verified and validated.</t>
  <t hangText='scope_domain'>
  indicates the limitation of resolved domains. When present DNS request sent to the resolution service MUST belong to that domain.</t>
  <t hangText='filtering'>
  indicates the presence of a filtering service</t>
  <t hangText='ip_subnet'>
  indicates a subnetwork restriction. This is mostly useful for resolving services that are not globally.</t>
  <t hangText='dnssec'>
  indicates whether dnssec is enabled or not.</t>
</list></t>

</section>
<section anchor="resolver-advertising-other-service-sub-type" title="Resolver advertising other service sub type">

<t>A resolving service receiving a DNS request over a service sub type MAY be willing to advertise the DNS client that other sub service type are available. 
This is especially useful, when, for example, a resolver wants that the DNS resolver switches to other service sub types that are more secure.</t>

<t>In order to do so the resolver MAY provide in the additional data field the _dns  SRVCB of ServiceForm.</t>

</section>
<section anchor="migration-to-service-sub-types" title="Migration to service sub types">

<t>The principle of the discovery mechanism is that the resolver indicates the available service sub types and let the DNS client chose which sub type it prefers. 
On the other hand, the resolver MAY also indicate a preference using the priority and weight fields.
Redirection MAY especially be needed when a DNS client is using the Do53 and the resolver would like to upgrade the DNS client session to a more
secure session. This MAY require a specific ERROR code that will request the DNS client to perform service discovery.</t>

<t>It is expected that DRDP MUST always be available via Do53. However, this does not mean that a resolver is expected to implement the Do53 sub type service for a resolving service.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<section anchor="use-of-protected-channel-is-recommended" title="Use of protected channel is RECOMMENDED">

<t>When available, it is recommended to chose a protected version of the rdns
service. More specifically, the use of end-to-end protection ensures that the
DNS client is connected to the expected platform and that its traffic cannot be
intercepted on path. Typically, the selection of resolver on the Internet (and
not on your ISP network) and the use of a non protected channel enables an
attacker to monitor your DNS traffic.  The similar observation remains true if
you are connected to the resolver of your ISP. It is commonly believed that
trusting your ISP (that is your first hop) makes encryption unecessary.
Trusting your ISP is mandatory in any case, but the associated level of trust
with an protected channel is restricted to the operation of the DNS platform.
With non protected channel the trust is extended to any segment between the DNS
client and the resolver, which is consequently larger.   The use of a protected
channel is recommended as it will prevent anyone on path to monitor your
traffic.</t>

</section>
<section anchor="dnssec-is-recommended" title="DNSSEC is RECOMMENDED">

<t>The exchanges SHOULD be protected with DNSSEC to ensure integrity of the
information between the authoritative servers and the DNS client. Without
DNSSEC protection, DNS messages may be tampered typically when they are
transmitted over an unprotected channel either between the DNS client and the
resolver or between the resolver and the authoritative servers. The messages
may be tampered by an online attacker intercepting the messages or by the
intermediary devices. It is important to realize that protection provided by
TLS is limited to the channel between the DNS client and the resolver. There
are a number of cases were the trust in the resolver is not sufficient which
justify the generalization of the use of DNSSEC. The following examples are
illustrative and are intended to be exhaustive.</t>

<t>First, the discovery exchanges may happen over an unprotected channel, in which
case, the messages exchanged may be tampered by anyone on-path between the DNS
client and the resolver as well as between the resolver and the authoritative
servers - including the resolver. When TLS is used between the DNS client and
the resolver, this does not necessarily mean the DNS client trusts the
resolver. Typically, the TLS session may be established with a self-signed
certificate in which case the session is basically protected by a
proof-of-ownership. In other cases, the session may be established based on
Certificate Authorities (CA) that have been configured into the TLS client, but
that are not necessarily trusted by the DNS client. In such cases, the
connected resolver may be used to discover resolvers from another domain. In
this case, the resolver is probably interacting with authoritative servers
using untrusted and unprotected channels. Integrity protection relies on
DNSSEC.</t>

</section>
<section anchor="tlsa-is-recommended" title="TLSA is RECOMMENDED">

<t>When TLS is used to protect the DNS exchanges, certificates or fingerprint
SHOULD be provided to implement trust into the communication between the DNS
client and the resolver. The TLS session and the association of the private key
to a specific identity can be based on two different trust model. The Web PKI
that will rely on CA provisioned in the TLS library or the TA provided to the
DNS client. A DNS client SHOULD be able to validate the trust of a TLS session
based on the DNSSEC trust model using DANE.</t>

<t>When the DNS client is protecting its session to the resolver via TLS, the DNS
client may initiate an TLS session that is not validated by a CA or a TLSA
RRsets. The DNS client MUST proceed to the discovery process and validate the
certificate match the TLSA RRset. In case of mismatch the DNS client MUST abort
the session.</t>

</section>
</section>
<section anchor="privacy-considerations" title="Privacy Considerations">

<t>When the discovery protocol is performed using a resolver that belongs to one
domain for another domain, or over an unprotected channel, the DNS client must
be conscious that its is revealing to the resolver its intention to use another
resolver. More specifically, suppose an resolver is complying some legal
requirements that DNS traffic must be unencrypted. Using this resolver to
perform a resolver discovery reveals the intention of potentially using
alternative resolvers. Alternatively, narrowing down the discovery over a
specific sub type of resolver (DoT, or DoH) may reveal to that resolver the
type of communication. As result, when performing a discovery over a domain
that differs to the domain the resolver belongs to, it is RECOMMENDED to
request the SRV RRsets associated to all different sub type of proposed
services.</t>

<t>The absence of traffic that results from switching completely to a newly
discovered resolver right after the discovery process provides an indication to
the resolver the DNS client is switching to. It is hard to make that switch
unnoticed to the initial resolver and the DNS resolver MUST assume this will be
noticed. The information of switching may be limited by sharing the traffic
between different resolvers, however, the traffic pattern associated to each
resolver may also reveal the switch. In addition, when the initial resolver is
provided by the ISP, the ISP is also able to monitor the IP traffic and infer
the switch. As a result, the DNS client SHOULD assume the switch will be
detected.</t>

<t>With DoT or DoH, the selection of port 443 will make the traffic
indistinguishable from HTTPS traffic. This means that an observer will not be
able to tell whether the traffic carries web traffic or DNS traffic. Note that
it presents an interest if the server offers both a web service as well as a
resolution service. Note that many resolvers have a dedicated IP address for
the resolution service, in which case, the information will be inferred from
the IP address. Note also that traffic analysis may infer this as well.
Typically suppose an IP address hosts one or multiple web sites that are not
popular as well as a resolving service. If this IP address is associated
frequent short size exchanges, it is likely that these exchanges will be DNS
exchanges rather than Web traffic. The size of the packet may also be used as
well as many other patterns. As a result, the use port 443 to hide the DNS
traffic over web traffic should be considered as providing limited privacy.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document requests the IANA the creation of the following underscored node names in the 
Underscored and Globally Scoped DNS Node Names registry
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-14</t>

<figure><artwork><![CDATA[
RR Type | _NODE NAME | Reference 
--------+------------+----------
SRVCB   | _dns       | RFC-TBD
]]></artwork></figure>

<figure><artwork><![CDATA[
SvcParamKey | NAME         | Meaning                     | Reference 
------------+--------------+-----------------------------+-----------
7           | user-display | User friendly string (UTF8) | RFC-TBD
            |              | to represent the resolver   | 
            | uri_template | URI template                |  
            | auth_domain  | Domains the resolving       |
            |              | service is authoritative    |
            | filetring    | Filetring services provided |
            | ip_subnet    | ip ranges accepted.         |
            | dnssec       | DNSSEC validation enabled   | 
]]></artwork></figure>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>We would like thank Mirja Kühlewind as well as the GSMA IG for their comments.
We also thank Ted Hardie and Paul Hoffman for their feed backs regarding the dns schemes for DoT and DoH. <vspace />
We thank Ben Schwartz for the comments on the list size. 
We thank Harald Alvestrand for its recommendation on having a model that enable multiple third party providers to provide their own list of resolving domains. 
We thank Stephan Bortzmeyer, Ralf Weber, Chris Box for its clarifications.</t>

</section>
<section anchor="appendices" title="Appendices">

<section anchor="requirements" title="DRDP Requirements">

<t>This section lists the DRDP requirements.</t>

<t>REQ 1: 
DRDP MUST enable a DNS client to discover the available resolving services with their associated characteristics in order to proceeds to a selection process. 
The selection process takes resolving services identities and associated parameters and proceed to the selection.<vspace />
Any sort of resolving service selection is outside the scope of DRDP.</t>

<t>REQ 2: 
While the discovery process is triggered by the DNS client, a third party MUST be able to provide necessary input information so a resolving service discovery process can be triggered within a specific context.<vspace />
Provisioning protocols to provide this information is not as per say in scope of DRDP.
DRDP defines the format of the format for such input as well as a set of such inputs.</t>

<t>REQ 3:
Any information used in DRDP MUST be authenticated by its owner. 
In particular, the characteristics associated to the resolving service MUST be certified by the resolving service operator / owner and MUST be associated a validity period. 
In addition, a third party providing a set of inputs MUST authenticate that set.</t>

<t>REQ 4: 
Information associated to the resolving services is intended to enable the selection process that is assumed to match the end user or application policy. 
The selection process is out of scope of DRDP.
Information may carry some characteristics of a resolving service or hints that will help the selection. In particular an operator of multiple resolving service MUST be able to associate a preference to the proposed resolving services. 
To ease automation of the selection as well as to make multiple applications benefit from DRDP the information MUST be carried over a standardized format.</t>

<t>REQ 5: DRDP MUST be designed to be used indifferently by a DNS client using any DNS transport protocol (Do53, DoT, DoH, …). However, DRDP SHOULD be able to restrict the information retrieved to a certain type of resolving service, i.e. Do53, DoT, DoH.</t>

<t>REQ 6: DRDP deployment MUST NOT be disruptive for the legacy DNS client or infrastructure and legacy client SHOULD be able to incrementally include DRDP.</t>

</section>
<section anchor="variant" title="Discovery of specific service instance">

<t>To reduce the size of the messages, the DNS client MAY also prefer to query information of resolving services using a specific transport (DNS, DoT, DoH) that are designated as sub sets. 
A DNS client MAY list the different subsets of that resolving domain with a PTR query. 
This document defines the following subsets _53._dns for DNS, _853._dns for DoT and _443.__dns for DoH. Other subsets MAY be defined in the future. 
A DNS client that does not understand a subset SHOULD ignore it and maybe proceed to the discovery as defined in <xref target="all"/>.</t>

<t>All subsets MUST share the same resolving domain and be listed with a PTR RRsets. 
The DNS client MAY NOT performed a DNS query of type PTR, for example, if it has a previous knowledge of the existence of the subset or if indicated by its policy. In this it MAY directly proceed to the SRVCB resolution.</t>

<t>The same restrictions as defined in section <xref target="all"/> apply.</t>

<t>Note that while the SvcFieldPriority indicates the priority within a subservice, this field MUST have a coherence across subservices. 
The priority provided SHOULD be coherent with the case of a _dns SRVCB query of section <xref target="all"/>.</t>

<t>The figure below illustrates  an example of zone file. RRSIG and TLSA have been omitted for the purpose of clarity.</t>

<figure><artwork><![CDATA[
### Definition of the resolving service subsets
_dns.example.com PTR _53._dns.example.com
_dns.example.com PTR _853._dns.example.com
_dns.example.com PTR _443._dns.example.com

### services instances per service subset
_53._dns.example.com. 7200 IN SVCB 0 svc0.example.com.
svc0.example.com.    7200 IN SVCB 12 ( svc0.example.net.
                                       port="5353" user-display="Legacy Resolver" )
_853._dns.example.com.    7200 IN SVCB 0 svc1.example.com.
svc1.example.com.    7200 IN SVCB 1 ( svc1.example.net.  alpn="dot" 
                                      port="5353" esniconfig="..." 
                                      user-display="Preferred Example's Choice" )
                    
_443_dns.example.com.    7200 IN SVCB 0 svc4.example.net.
svc4.example.com.    7200 IN SVCB 3 ( svc2.example.net. alpn="h2"
                                       port="5353" esniconfig="..." user-display= )
svc4.example.com.    7200 IN SVCB 2 ( svc3.example.net. alpn="h3"
                                      port="5353" esniconfig="..."  
                                      user-display="Testing QUIC")
]]></artwork></figure>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC2119;
&RFC8174;
&RFC1035;
&RFC7858;
&RFC8484;


    </references>

    <references title='Informative References'>

<reference anchor="public-dns.info" target="https://public-dns.info/">
  <front>
    <title>Public DNS Server List</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="curl" target="https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers">
  <front>
    <title>Publicly available servers</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="dnsprivacy.org" target="https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers#DNSPrivacyTestServers-Publicresolvers">
  <front>
    <title>DNS Privacy Test Servers</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="moz.com" target="https://moz.com/top500">
  <front>
    <title>The Moz Top 500 Websites</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
&I-D.btw-add-home;
&RFC7719;


    </references>



  </back>

<!-- ##markdown-source:
H4sIAKPZIF8AA91d63LcynH+P08xkX5YtLgrUhcfmVVOwkNKR4x14SEpq1wu
lwoLzHJhYYENgOVqRcnPkgfJr+TF0l/3zGAGwEo6jl2Viirlw8Vl0NPT1697
JpPJRLV5W5gjffr6Ul+Ypipu8vJaN6a+yVOjT/MmrW5MvdXnddVWaVXoe6cX
p+d7KpnNanND79EvlVVpmSxplKxO5u1keV20kyTLJnW2mhw8UkoltUmO9PHF
ldpcH2m6pT5sjvRZ2Zq6NO3kFK+pNGmPdF7OK6XSKiMyjvS6nU+eqlV+pLSu
56nJmnYLaremoStEUPBnXmambN2Fpqrb2swb/3u7jH62dZ76h9NquaR3/d28
LPLSf4Zmt0xWKyYIV1SybhdVDZrwb2L/i9dohNOpfpVfJ+ui9deFN6dJmZti
cLOqadhnRE3TVKW/SvQZQ/Q9ffjDE31VJ2WjT5IyyRJ9Ua1b459L83Z7pC+T
vGz1y2Rd0yz29c8n3f0qo08/vtQHP/4muLgu25rekyH9dbNM8oIWkQmdLoXQ
fzWWtilxSSmsT71M2vzGgAGr9azI00lWNlPcEZ5YkTrneyxZlyRPptYv80Ym
3ib1Naa3aNtVc/TgQW+YB1iTdV2MDFdsdXJDZCazwrCYmroZHfI6bxfrGYh+
gKHkfzb5h/wBETSBUE9eXF2dX95d2XEnftxJNy5RtKrzmyTdTrFQIT2Y17nc
01emae0kGx2Qozt64pGEkixvVkWyfXB6DqLu29HuY7T7drS7dMNex2V7dSLM
qFlhhdJl9QmTDUikj18tjH5VfdJX1Uo/OTjQ78ysyVvTjJNoh3jQVit6WKnJ
ZKKTGYlikrZKXS3yBrqwhqrozDRpnc9Mo1v6Rmc9aJV3Gg16NGm1KcHjRif8
VlrkGK6tdGZf0zdJnVfrJljnokqTQidlpq+LakZ/1n1LNdUKc838p4lWYveS
hiKJycu8zZPWZHq2jb67r2frlq4MxtPLhJ4smkqLwPtZWnor+l0PXyOiaxMQ
DpLNDb2wTgqiY0UmyNS1yYhc5u4yz7LCKHWXuPfv67w2bIb066olDSNzwJP6
YLZ6U9VZo++8ent5dWdf/qtfv+G/L579/Pbs4tkp/r58cfzypf9D2ScuX7x5
+/K0+6t78+TNq1fPXp/Ky3RVR5fUnVfHf6Q7mMWdN+dXZ29eH7+8QxwhboSy
gDnTAs4M3SKLTrMEq5NGOSHJ8M6PJ+f/9R+Hj/Xt7T9dPD95eHj42y9f7I+n
hz88ph+bhSnla1VJ3JKfxOitIvNrkhqjEB91mqzylhaHnm10s6g2pabVMFMF
RpJTqatsnYJ/+vZuY9JJjktflDoOVzBNSlqPKjVEHRGPO7yca35x3WBVnSQO
11nkrTHdwmO8mRPVqnaSitng1pqeTfQmz4wma35tdDXnb7aw7StyViCGlYWm
tE4XNLV9TZKnzcdkuSrMPrkEGiupM35N+HZ48OjJly/7fIVV5+qlu/XD0ydP
iaU0gL/J5s5x/PFT4rjVGqGZNGfFZLXxxKAJbfLBeG5AH8CA5yF1eQu3UmTg
QULuIhV9I84mmlw8ye8HvSJLtTIpfIe+B6ayE5anoF/uuZ6ukailVVka9+ge
ZoWBSRpWKzKDrCtfHb2plmQcKvJvJXvjRu9NRblW63pVNW7evzQMAm2h6Roz
CN4Y2Fl2M/NC1D0zMgCz8JpmVYZMwaos8usF6UlmVoZ1hhah4cVkfhCTZnW1
YUFOwBYKFeyCl+vljKilOf8ygjFd83HlV6I2zFGyXK3BGjVkxNggsNmDNxDJ
a/MlLPRlvqSR62K7r9NFAq9CsUXTUnjRExmRwBHavFUejK6OG7HjFLLsj5C9
ppDug4FVyYsCY0IqtmW6qKsy/2SszunFmlQzS9pEzxKRihHdV1h76Cskp2E5
LBDJclQkTg7MoKk1bLKyZIU7WCorKEzA4hsLDwp4WXuzobFb8xHSI4QkWbVq
MftFbuqkThc5e8sVEZjQpDawjf0x7pF0cOxuL+x50sShj5Azr6tlcF20qdH3
Lk5ZIRO9qtj8i8AWNPuYff6Fc3luDxNgp+1jioo+U1ZdcKHJto+sJU3sJm9I
xok9Gwrz9MUpKLg4fY+vWhnv6Uo1a5NcWGn5t47iCEfdTZ54Q7dJSFLzMi3W
GSsR3pzn1+uaFWyfnz19cXKu36xwoSHb+i9nk9PprN1w+rMgqyM2OKMlvyFq
mYewUvmcImN2PxkF7Y3+E97zeVOGxIliwz9P+1PpKeDXDA9/C+4y4g7ZZ7Lf
xrk+qwkJvVYY8Zl8p7EebnjdWcphyES0UW6C+4ErCeIErPddCpXrZV5WRXW9
Jfn1M1NHsjY2HIQONWTVGp48WZU6lykFTnpKvr4XifRkheQovya1hJLCauA2
TCXdI2MoX2HvUvAkaS4+vaEJJzNMJ1bTzjdcentJA9JDUTTRRpwjRhCD17PG
8HDLqY45KyIN5iJsSlOK9ey6xPP5FT1Xkb+DGVcDSoiD4Xz9svAsa5MaksAB
O5dxGI652KSisaQeD+cMgnO4ffBcgmrSRQjZkqxvvvLmjKxJR6qpjzSFYO5O
SCyzq5q3G0SSNAw5h4z/XhBBhTOWoNN8JM9B4dOUaDHQN4Q6P3AoiWBpCdHO
DKl6wV+OIqyYQRJwgOkJ+fUVuaMlha11Ly8paUHZBVM4QQKQNwvmbAPrI7Yn
GfInXp5Ttiz0cRnYRiG8KosKLmKcd71oE6rz5ga/zcba/dzRKo7CxY8yNJmR
GgLlzHmQXcAMSEh+exveoHiQVZ5NnCFDUZD1rQ2F8w2/x2Y3M+Jprhe6oMym
sLZ65QQdlIHcQxHywMWIT8ych2mqdZ2aHS6CfArejxPOeV5iOpsKhpkXxSou
2bbmSJGZg8hkNJ205WSr8xITzJY+SKE4AosMKfie3he7yK9RzkI64W10oq2X
Grz63ro5DGEtEEXQCR7lJ+x4lrRuPEkwSPXEL7ZbspDnVxd+iNTGG+67MwOO
xN+TwObn18evnjkzTEP4YTcuAJ9N3wNK6ROr1MOxVWFCd7p9mIQgOgsUZV1m
8Pb0GoWTtSmKBEQZxBwXp9Z9jAxYzSkHFquBdwf8glcdZ9flH05+dOZ2B02J
uDbIKR6rqzUJ6uVNeu4fGTDcEuH4vYPP/O0Boy2bhb0aWvrXv/7V42nRv/uT
X/Lvvhp75Z8/B2rTtzDN4JOfMcjn/zUlpMpO0YKx9a/HFNep1oCSUWoxyFcC
xUB+KTXc2zEdDCJwzNIkQGB7URoitP1v8WRwxSJlNNgEVpro2vdR3N+LsUxO
/NL9v22kz5FKf+arJCwDGRmQHC7R34WSh+PCQnJxCGwRCzGdTuk/dCW3V/wF
xpgjYfFR1i5KPu+4dF/1DNeOdd519bNWgVn51hrvpmLH98ZmOEqFttI2/DdO
yc2OSzspGRtmfO3vEyWPpoBAOMwNB/lMSruYutAO2uqnI7comeG1xbPq0ke+
30EJCccoJTumg8+1uyl58siT8nn3IL+MJ1+hhD4XkTIufjuX+KuUfO8gv1SD
4cEUx5vnYwn90JDf3sU9xlfdGxyaPv/59LUEo2zFm3ic7m4QlHPccDYPx/EB
qIQMsU/Y74cCFAn2wjkbZri8ZxsGX5wz7AiWLDjxCdH5PC9cPIzUh9KJvHaR
HapJl6cWZZnRzQyAJEfJHn4Tj7bP4ULwhKNrECTt9+I+ifQsTzhH8+YU6uFM
6QgziJ2vq9YmgYDSiRaGWFzqg/JIabPWZsHVC3310oVvlIkKThgHh85Dgxk1
RX7mJkEtxYVmzLMkozQ/R/GoJSbbwkNtrteMANJfMrYkmfyxiwtKkBvNtQ2K
rSAUDuAhLl0+O5lKeDVcMNZyjoQtX9SfiC9//saTUtFkcX/bhEmmT3SYnxkm
l1wbATxFrEb5waQCMpCkCjckLinyWZ1wxk3LIChu0ugNRcz478yUlNq0Ik0+
4aco2uIRdUJMXKctcrIOjOKwuwtgr65ecpJ4XOpnnBKuEWUTDz/xI4cPHz0k
TYDQAf/UyU2VQ36Ta+RWFi8uSRB4bbjGsq5rSYAZk29sOpYHsCRN5dXVWxn+
6cE+qUBOoT+rLCeVXvfOzm9+41EvG5WRcKwb/fippQqK6B+FHL2lcGZhEqSL
017p0deoLr1YB4g2W4BeAcKpjpX9a+I4iaXpM6ArAeDrqyT9YNqpOmOMiLRf
7AkGlNxaLykw5N4BZh2AAq6IAJ6TEW3qd0MrqJfJX6oaqBPwsXY9i+sA6h0Q
pP5MAHcIAAEGFPkyH2LbADfTpK638pCUgU7Ou9WwuLcU6Jr1ClCIrE0wCkmF
hZzWq+ua2M41seoFF5Cqq3FM4kW1IZbUQhLDLHOhvEBlubcmUsVhAICLg/3y
jZMPD8y5JEu0Y6AlxHc4hiZYOUcCPsAYvs8EabLzdsXQUtuu4GNKQfyRBO7b
ekNIDbgqiANuApXadCRSogEUKm+W4JLHGWwmSfKKYgTR9G9r4vvDH/TDg4ek
HoEOphXR2Kyq0oOFv31MTqaGmECmVtUKZlJ8pIVraAq3t7ZC7yt3TkudnvOc
Ci483N6i4+HLl9vbuPPgyxe9SMiCFZBgtkdPDoamncZ/Y20XBrMVSRq016nh
RqN7S/vM4eH04OAAGCtMnlTYA7oaY5YWvCkZkq9WJPkeL+zkFpYU4uJW14PK
o2A1+WtK2cTlEtn3fqqqa3LaJwuSF7Mn8K/Mm6lgNTk8GFJKBDEwkLD/YYMF
K+hF2T7cTWMGoxXBbQD2mCeaS4astrSArrop87inzZSiDHfTisHZ5Tkqk1yU
NeU1eT47eY6aiDZ5ebQwR3fnSdpGdDdLsuWGC+dk/5YYLSLW9Sd0Dw4TcWlp
sPVAH411cGU4IMSGJk1jiVEYkUsGe0RsURBb+9kkMxpXoI2ujcMXxacISLs6
bBSI+hTq9i59+YvqtYKMlzkBupsaaH+IRZ13BhHYblH08X8OqX7iamwCC+0A
oyTKwKV08RUUC/4uAo+EaFtOt7GmR14DZ0/6elzkSfMcTSlzyrTJBtu2FssG
viNalOA2W1oEnbXojDUdPArX8sEKuMVlkiFW27JUkA1oyf1KJ0Y4cuxbgznY
+j+L/swYbnnw47gJXt6kz3NTZOd1Lt4wjoalQcaJgSzJVJMHJs6hqkm0+PYh
thwSXbaVH8ei3yU9l9bbFcjEInCJJWi+sbQwLPh7g5BnVfrI04k4GlC4pQL1
40a8Vs5AuBFRBaNukmJtRoJ6X3aw/A7Em0UKHwwp6EY4pbRxXx7gilGFlDa6
fwWKuEktw0qTwCx+HT3wonugnwFobjYRqu/hQ0/xP48fP9pzcsBTxVeBfSyt
C+w1qyR4tOx6Uvjiq+M/gn14X3DmWJzXtlg+fPHJoyePWCUoNl1zyoBCum3N
IM0XV+S4JTA/F3lcGaO5SRmtIXfEsA8cNpckkmKKopN/lecH3LppqypKDq3m
OhkgI1oFstLLTWCWBK0O0hP+NMsMr13edPEHcqrLYxnF5UKdoDGzGv+RToMq
cg5cQiDWpBQQSAcHpyx3e9YQpsoXYkuwl4ycikzMDw/J2Z29FgN0oIlnU7tA
iCmmqn8B4EH0zuFDclv01IF/rESAvAOO6P3DQv/uDlb6DiShntjmx9/deWmu
0UPpqoR39N53kCKUHEaUaGb87+6QutzRfwNZpilzAY9/d4fyx+8eI57OubMz
+pnQ9quGwpCKFoZmJi98e36PZH4P4/nJ9BYP73wnYV+fXUT29zDdLv+jUaIe
/WOIkvy8s2C3t+jOoNiGVL0rSJaSaNtbHJWLb9dSjrxE/OHuIicy85a1ar6u
+U1EC2tJJtiA2AxPisRiDmddFFRSvkUGLUNS0EaxhvRSSKl/PO5woTQZ6Qk7
V8mw5O+w4HuJnjWamGmOuJz63oZjbEZ5PRCv+p4ZthpkZab6HXsEfmLB+AJZ
krQ2cNkKUVrZ5uxJMX94N0noPfRkOyrssLbzUua/hNFGiED0PZzqywV7/I2R
j3OTHXI8MuCM99Wk2LVHK8gGC2L4OlmK65QC278AVKbMfONYvfDNh5aTjTSO
XL1U/XYYa0rdYks7VOtgJmlHJVfXsOe2/pGtPrtx30sx3ugCd1abJS3s2Dqy
4W8WcF9EmUYcVks+lVDyuZVYIXDKzJ2uesc2uphR2s023UWUnegIPSYb+fYo
BhDx4FAvULK2vT5E0+UffrTex3wEeNlIM04YgNze9V5U227vxnLE1d4TbYkL
32O17Fw/p3YWjwg7LILOmg7uGes6UjAoimS+sw34JR0cSoUGQh1FeCs6Pstr
zoTeXj2fPPUNPmHL1Mx0SYxt2Ku4ea0VxeAGIXwEXpnLxwIAcHDk20q5baeM
81JpWmIabIcP/x1jMF0CFco5hMkO10+/Yv+q1nX+vjVkfWnOw4aWtxdn2t1l
JpOVscgdushd23gY5FYSkCFmjGr+vUBoJFQK3qwHuRgv5LpdWKsVrZRPaBG3
8F6a3C5F0KK7o8kMFo34WqFWbwoBa8A9zhKipeY8YEdnv+QCoZ/o9X9LYylH
ZQ7s5jQVK+xQoOHQSSOAkOHQ2+YKgrxY+DRoL3MMRjvoPEeQKNlEnsFITWW5
FUvXbiYu8w68tBhK1mE476QtTRY6zEUbu+fC81hm7eZhSSsq14WGKo1II5E0
z9HtSvMe0OMTI0Zp/HNuXKXy1XuycAzC677y8nVGSAIl62BnAGOkQqSZ83XB
sj3WK82LXhuBebkDv9hSAkFhMNmy6IsUqIvn51ssOpxZZnDI9PpUdmXYZrUk
o/9t86YD9QMXxXm98r1toURI3510j0ZgAA86GMTZ0aBJ2X150MLLc7W00Ou+
3Q/DRLtQOAEVJhoWXvb+wsh9u8si2mmQeDhObxLBH5Kut9Lfa0jv0oV0qI/z
JFgQ7swjRq9rbo87K21tibNb3QSiiKHBBhvdOTNLIVkuGZ1gu3PACHyHq2r6
8gIBD3xTB1bwGr7Kr6UVhEtcfQrtLgAS05TRLJuedxFdh/XmASM8pbECxFvT
YlZAvQsz6FFNF9h+IHiNF4O8tSaKETVhgLAYHZH7Q2bZrUoWA0lCIGXta1sr
B7pwomry60UrbGym6sJ4gIgHDCRlJoGZccltv7O+q51VlMa7ImAnQhwkwgNG
5YWYC66lkn0xZEWJrLgb1g5ISMbVJWiPs8TPLi7eXPBeR1s6QI3LqVpfbTqb
79bILzZXfcf8CAdVbBWTgpsPZ+Facx84av06qIiEQTQak2KHJLXtMC7xDbUd
K704OELn3Gc/tvkNsRwYhtU9sWUWibUUoIK3Ah52sAVkujQFiAi2fNkylJ8Z
b+vhgp7skM2EVBHZJBgOyH1QiKlJI5Un7hWrviv/Fdj+EQCaNOqkrSaIuux4
GMiUDffFO4VTscxF+4FaRposJxH68OKKHCL+gwGrkzkEJaVZVygmKU4NUsMA
IcLPBCHElUMZ93vRaedda7chw21e1vfoSwqj0o0tom6A+NaV7Xl1cPAth0zD
dehQTZW0LSqPbBqXVZkD4ORxLQKHiZCgcoApG2p0NQOzxcjJnhxMGbDkXNGr
tsGyx7JuQnNPt4uipKjJuu/KnsRKRWNyK1w3z3suxOYrUsJaVKs9irI+mMaB
sLyjzqcCU3U1GAcO3iWXvGem3Nra3Mz14He4szQeQ9YwjhKofoyrLLr9XWaC
GvcKvk5spuodRhtfJKkxrhtrIFqvEKC2MVxKJo61G2P8ph0VdNaHXA/K5d3G
KWI4l05rRH9XodR4YlQ0t04tJd1kw0e2/0Y+ueXWcpHuvjgpJ0qKLYSFMPv2
QFBc6blvIuRyDABFnzwrLmfe167cDf0NI9+QRXH8bzdee26FNfJ30l2h7Lc6
YyH7H5cQrmu7R4wobCmY4VJzVzrY2Br7FgqhGMy2AKuEYxDSEdXM2fH21lXH
66o6bYof9dd93/LYhCVfdFNQ/SmgvIMGDZxKoL198CbM+V/PAtCwtWwHhk++
HSl4ZmxqJkpOHodyaouX1YYyj0/WfwaGOCihK1sK6dUsHZ++ziDPCJ4qsV9a
jbrCKrQdTTF2r5rVsx4TbYWiWUNypU4HLVJ/gT2ZS4Yq3R00mUjJrSbZRiJm
t1TPwDwb+XJxUkU1CFdNAB+dts+gEosEn7wxHDI8h93b7wWOndrwXk0AaeXX
BA1bzex0fFdCt6RutGwg3ywcVtMnrOnfaYLiJqTvFVnldHTS60bqFvhdv262
WzRUbBPjsCnsUbMhVBzKQUaaSP0GPhxkuODScs5v5XHWixsK5hNpOFMp0q25
BNJuRaQnQGICGUsaoaxh6dYSi6HoZzWf4P82JIrNIl/xpgMJ4FnO96OxRuhy
TVbqJKDm2K4D+g/unRzvBb0GAvLaxneuilntxPyDsw5UlCGHDGZmjuE8TLtv
lhHSVRdNeGmxs/DVw3hrIiRG2qEsVu/whLNS8ap3Mh9qO7FyRkzZirFLZJOe
LNqYHVWSjOB4E5kNRHhE13gXiPNQgbWrEe5gR5ZyhoJBGPKPXL8bjZZDQZd2
IIzmmejNwL4OJItt9JxoxXEJNDcVuVa7fSVKCqw9dEaXHP+6dN1K36nwYvZC
jehvpgkMJgNXLZ8+oaSq4bKtPLP7J+2RB90+5Q2Wnbf3eIqXlJQV8mH055z/
/kyFKRrqH6U+OY52a1mrD0KldZKLJHzpOGJPnBhgr+KwNhCUbRy4FjgYDq4C
jqj+pmsOa7qZ2Gz39Pj1s6hrb7BBuXUbSrnlySe3kXwjb6Rv7/fXDZrkjiyB
swhXzMXbUF8PFkr/B3GR80OIqpJast3u1Stv9zaqRt02XPkIkUhR98AKURCX
LtwC2Zo22wi3oWqZN90z/W8nM+D4gfUTFWMt88fp9DNYz+ZhY1DcxyOrEyTZ
zC5BMgWnKo2yIDMn05Ex4v2AX/XQ/boL0o+ZFL1S3jLuM04Oz28QVHU7eTvD
xgcDcMFBxIJPBxFaAlc2kjhz/yY/HJlJNEMWW4YEUGYqzHVSqGjTp8AYXQbJ
tLO9Ln2nzFS7Pui8CVhYKQeYBIztVkKmKfhXNymgDa6kwmgj8OLwmIRgh/Bx
dxlzlOqqVEAGBVZZHuWNkcdIwhT93ml1tS+F1Rd7rE5CpAezA/mgRMC+HtlU
oqrxx0lw4mCZIALWJ8hKkNg2sYGN1y+34zeQgE4kHcYSOBawPESvLi/+4HpD
ep3NZEM7gxuywh5OkTkUpnFlzrANyUqC4whN1fpoQXYxUxYs09riFY5y2RRb
5WYfuv+a4cRk3to9oUOrEpTrHVQp4h8FgSPmtCOnrVzygi3inNLiZBqpy/BT
ag2Eh2bszZtY0mIY1kZgthinpllz5Sm3ffIzo+xoYknDLBY1Wk+YDX5cakT2
GJspXGhsOa2cn+7WzGvBPs66iLqpeW0onodu9NYde2xVFHgx/uuEHMaVKWOz
7IDzfZ//DlmSNyrslWZ86/J83/3B+3nwBedJHZDA9889tdI4SFNTIQ1fO5nF
OmnPePeWZz+a0NJWGrEYmkH3m2j2CEjH3WSPHz+S161sdPyH1DHwtKYom+fC
4i4HI3lojZFm3kuqXTOhAGwAszGuhRD9GTnIoVw5KVw8lMFzTmpn/lrVw/F8
Z4sSzF8aPllDaOFhAXLb/iwEVGJaZhXnLRg5KD66bC5Rw6Je8ClAbdsgLrfd
yrT4tkGia+mFl+zUMxpwP86O9q1kdQpil1Akwu2XUlZk7PiWKns6B7BeL0pJ
sW3yxgZDXK3FuthZTpXP80KfGBA+frYCMyxve6VC5RruQx6O4exn9kiT4Dt5
aJTVvLZHIElnCPc/BxmAmHrXDWCx7SaE2BzTEA52VykSWrj2knedNNk2A9tk
zVE7b1rpTIJLyJJGuYnx4kvYY61LM6KjiEi8NpGQL/KuaKO8MLNKBNLdLNzO
+HivhxgXsNJZSF8X5zPbjl8fD4K+eNOP9YcSZvDznAahrSlIWjpIR5o8U25d
KFEYkmO/rB9Wb4PbsFo/2VqxvkS9XXqGX+O11/xaba6xlW2r3FGJm81mmpOM
8lmOtP75dclxFo55nHQbh3s/px8X7bK4G1+cHD6WLreLC4AXRn/W71+/OX2m
uTsKW4VdJU/5TZrRjs3uTyVFUGwclaIo/6Mhnp9Mrn48tVs78b9hA89n+ZL2
j78i2wcejv0bpWdA0+Bnf5dp8Lf6IRo+7O+hn2+xm2NOZrTMoOrSUXPv7dXz
p3vBxGIKewQPum682+Nt3vHDYX8NPh821AxY0X85aHjBT7dBtvtmx9XPX6c5
OFMpBjpGXsXuVOEL/3zuf/q2CO/b+6+G/Rj8Uw4nbHAKkVn5NpSxr9q+CffT
pso2a5QSnrRTMJNF8u7q4/RDWW3oMhdLSMvVOxNViMnCfdCv8vovif79f//n
ojCkzVlol8HMny5fHeuzn1wbWV77E3ynGM95Exrpigh4gSZEgXLPk3WhX5AP
JSMYvD03DLmlH/o9i1CiJl2Ypd2iiOAD43BbFW85st/5kSKry3SxSer2k+9u
c0Q5OIF7nmCtp8GbRF1Csz/GkUsoSUi3d94G5R2/P5MctaQfgkUEx6l2Ho78
U81HorRbt+514/epiRGnKSOz2nn0RkjfZWtWcDs/kjP4tDRbRKgXSTGHH8Lf
J4uahPTH6qOnmzvV3U7Pxp6LgrUHAp5BIKXihJp6dOzp7d3oOKJeE6JsH2IX
hDfDR6dKXTz7WR8eadVV6i1jdh4z20b9Grs6PIVbQfjdP7kwDzpZLLDS/NIj
1Voulo5tUhKoLf/qOTyJlM5Hzx5DeeIY1Um48rGG5PgYsmrdNs7R+75Gd6QT
WPyQWCz9xeM5HnpkKBO8NqMtg2gtCuXTtcC5SNqJaNg1uuJNeV1UiSxkZBpD
Uiw62ZFjmywDJNOfpKjVucMfMWh3FGukN70GPovCJQxA6Ybj1B7XRBz90VUc
oeD1Ll7hX9AcRthlulEU6tqB/e3GrcWjI17akCS75SroV5lJ+QZiFDU/c2lC
NsJiLfIU8e++K+h9/WzOEfa7b1mgsFv84aN+19YDISLqNg2+lYgzYYSeaKky
obZLZ5MRWyfm0fJM2GVT+4AJFi8wrePk4yMMHZz89+0Zy+EHQVXQmpt2XMEt
ait5rgUuHETqGo4ZvQ0PtHX96eNGY+S4RZG5cCbd7nDpzu8tLcPfI0tUU7zv
UUNOSRamWPVNSyQ70YY8oMA7j7MbqL1nd9y4ZlnvoKzxPehXQEMaFvJqGeUC
HcfC6MEiRp66gOG9oxhYh/o5rZdzTu0z38dpt7ORb8+sUovfg3Q9OYr1UXq2
fS3Z6qzHhNB1E59S7mDtcrvjyGgAntjFx7AnIyPT6XQvaEfj7w8LIq45ZjDN
7vgU9mTQaoYwI6A1OrAkn1JUE1NBq6OZAb+xDMjMqqi2S18LsJ3oZLrrNZ+Q
6yOnQraEhc3mdf8sDOmn5Od2VnzyMpUQgXM7qVcb79D6e+g6ULm3kY4iE7fr
SEHiyJusU6vrQfLtivUDlMt3aHZ953IWTQ9PHLEyrqLhaetW/x59oeP2Xodo
+E0BHDhLczC7jeM+URwBiicPUGRGmt2GhtFTTnCmxtWFTMK1Fw9PaowScjfu
+yeP+FQWiacxg/dPo0s2xH7/+DFdDS6TPMk+UDeS7ZWWz/mq4XzdSo9xNFnb
wm4bC+wOUA6p3JYbKzyy3QFADe6S+ZyZ3fUy4m7w9dtb7D7H0QzqGLsxHZkQ
dTlahwUGexuGe+zLTPDjxvdUCYtdHa+/8wmTh/50ta9k/IyjXm93PsfcFhxa
oFGMq1YuJ/OSbD6CkGC7stuXxCcE7NxJ5c7jzYW+8CjOkIGCUnSIot+CZVnj
mv+bHoNdJmAZzbabEaQO2dz42PSbO83t5S4qXM/iPXDSYc7LZxHStFpY35Sk
ddU0wTtuify4PufurJJ9vfWZhS+ZJoLXCGP8Evbmy/YU34gOaPXtSjhCDvve
7Z5ret+fXTUlMbqkfBlSxkXb8S3GzJfuPHy349htOCZribXIQyc7kk+I2MvW
42A7KUuzU/7wxo4nn37/o2wp+o8ywV2w5rZES6we0arGqBrbLn0w2C998A/c
MP3LdkyP8mtI0UG8a9rN4/D/527r0REV5OU7OfU4Xrjoyv+lfdvfoOrvs3H7
q0T9bauH/5dGMB4/vz07ubPnjh78H6Bk/cSXbAAA

-->

</rfc>

