Skip to main content

DNS Resolver Discovery Protocol (RDP)
draft-mglt-add-rdp-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Daniel Migault
Last updated 2020-03-09
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-mglt-add-rdp-00
add                                                           D. Migault
Internet-Draft                                                  Ericsson
Intended status: Informational                            March 09, 2020
Expires: September 10, 2020

                 DNS Resolver Discovery Protocol (RDP)
                         draft-mglt-add-rdp-00

Abstract

   This document describes the DNS Resolver Discovery Protocol (RDP)
   that enables a DNS client to discover various available DNS resolving
   services instantiated as resolvers.  These resolvers can be local and
   global.  The discovery is primarily initiated by a DNS client, but a
   resolver may also inform the DNS client with other resolver services.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 10, 2020.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Migault                Expires September 10, 2020               [Page 1]
Internet-Draft                     RDP                        March 2020

Table of Contents

   1.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  RDP Requirements  . . . . . . . . . . . . . . . . . . . . . .   3
   5.  RDP outputs . . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   6
   7.  Domain Discovery with RDP . . . . . . . . . . . . . . . . . .   6
     7.1.  Global Domain . . . . . . . . . . . . . . . . . . . . . .   6
     7.2.  Local Domain  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Resolvers Discovery . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Discovery of all service instances  . . . . . . . . . . .   7
     8.2.  Discovery of specific service instances . . . . . . . . .   8
   9.  Resolver advertising other service sub type . . . . . . . . .  10
   10. Migration to service sub types  . . . . . . . . . . . . . . .  10
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  10
     11.1.  Use of protected channel is RECOMMENDED  . . . . . . . .  10
     11.2.  DNSSEC is RECOMMENDED  . . . . . . . . . . . . . . . . .  11
     11.3.  TLSA is RECOMMENDED  . . . . . . . . . . . . . . . . . .  11
   12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     13.1.  Resources using SRV RRsets . . . . . . . . . . . . . . .  13
       13.1.1.  Discovery mechanism associated to one domain . . . .  13
       13.1.2.  File example . . . . . . . . . . . . . . . . . . . .  16
       13.1.3.  Resolver advertising other service sub type  . . . .  16
   14. Normative References  . . . . . . . . . . . . . . . . . . . .  17
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Requirements Notation

   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 BCP 14
   [RFC2119] [RFC8174] when, and only when, they appear in all capitals,
   as shown here.

2.  Introduction

   A DNS client can proceed to DNS resolution using various resolution
   services.  These services can be instantiated by local or global
   resolver using a wide range of DNS transport protocols such as, for
   example, standard DNS [RFC1035], DNS over TLS[RFC7858] or DNS over
   HTTPS [RFC8484].

   The purpose of the DNS Resolving service Protocol (RDP) is to
   discover the various resolving services available to the DNS client
   so a selection process can apply.  The information returned by RDP

Migault                Expires September 10, 2020               [Page 2]
Internet-Draft                     RDP                        March 2020

   typically includes information related to the IP addresses, the
   transport protocols, the TLS parameters or the HTTP version.  How the
   selection is performed is out of scope of this document.

   This document considers the resolver as a DNS resolving service noted
   rdns.  The motivation for creating a new service is that "domain" is
   associated to port 53 as well as TCP and UDP and designates both the
   authoritative as well as the resoling service.  On the other hand the
   service "rdns" is expected to be limited to the DNS resolution
   service that can have various transport flavors including using
   different ports.

3.  Terminology

   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.

   Resolving Service  designates a service that receives DNS queries
      from a DNS client and resolves them.  Resolving services can be
      instantiated in various ways, with different resolvers and
      different DNS transport for example.  This document use rdn to
      designate all instances of resolving services within a domain.
      This document also use dns, dot and doh to designates the subset
      of instances to respectively implement DNS, DoT and DoH.

   Resolving Service Instance  represents one way to implement the
      Resolving Service and terminate the DNS session with the DNS
      client.  The resolving service instance is also designated as the
      resolver.

   DNS transport  designates the necessary parameters a DNS client needs
      to establish a session with a Resolving Service.

   rdns domain  a DNS domain that hosts resolving services.

4.  RDP Requirements

   This section lists the RDP requirements.

   REQ 1: RDP MUST be able to list resolving services that are available
   to the DNS client.  The resolving services can be available globally
   or locally and listing MUST be performed dynamically.

   The necessary inputs for the resolving service instances may be of
   various form.  Not all of them are expected to be in the scope of RDP

Migault                Expires September 10, 2020               [Page 3]
Internet-Draft                     RDP                        March 2020

   and RDP limits its scope to parameters that are inherent to the
   resolving service instance.

   For example, an end user may simply willing to know which DNS
   resolver provides the fastest resolution.  Such inputs are not
   inherent to a specific resolver and are out of scope of RDP.

   Another example could be the activation of some services such as
   parental protection for example.  While such parameter could
   potentially be gather toward RDP, discussion are left for future
   extensions of RDP, and the current proposal limits its scope on DNS
   transport parameters.

   REQ 2: RDP MUST be able to return DNS transport parameters associated
   to each resolving service instance.  RDP MAY be extended in the
   future to return additional parameter.

   The selection of the resolving service instances MAY take various
   form between fully automated to fully manual.  This, in particularly
   includes interaction with the end user on a subset of the selection
   parameters as well as the ability for a resolving service operator to
   indicate a preference toward a resolving service instance.

   REQ 3: RDP MUST return the parameters used for the selection in a
   standard format without room for interpretation to ease automation of
   the resolver instance selection.

   REQ 4: RDP MUST consider that selection MAY involve interaction from
   the end user, and as such provide the ability that user friendly
   information MAY be displayed.

   REQ 4: RDP MUST provide means from a resolving service to indicate a
   preference among the available resolving service instances.

   The resolving service instances selection process MAY be performed
   over a subset of the available instances.  In that case, collecting
   parameters of resolving service instances that are known not to match
   the policy is useless.

   REQ 5: RDP SHOULD be able to narrow narrow down the discovery to a
   subset of resolving service instances matching certain criteria.

   DNS is the common denominator among the envisioned resolving service
   instances.

   REQ 6: RDP MUST be based on DNS messages.

Migault                Expires September 10, 2020               [Page 4]
Internet-Draft                     RDP                        March 2020

   Information provided by RDP will be used for a selection and as such
   the collected information needs to be reliable.

   REQ: RDP MUST provide authenticated information

   Finally,

   REQ: RDP MUST be deployed without affecting legacy DNS client or
   infrastructure.

5.  RDP outputs

   The identity of the resolving service instance (or resolver)
   represents an important parameter.  The choice of a resolver
   generally reflects the trust the end user which can hardly be
   inferred automatically and is likely to require an interaction with
   the end user, unless explicitly provided by the end user.
   This document considers the resolver's FQDN resolver.example.com as
   its identifier. example.com designates the rdns domain and resolver
   represents hostname.

   a) The rdns domain is expected to be the part that will mostly be
   used by the end user as a way to select trust as these are expected
   to represent the brand or legal entity of the institution the end
   user sends its data to.  The rdns domain follows some DNS encoding
   rules and as such may not be believed to be so user friendly.
   Typically, the rdns domain might be ericsson.com or ericsson which is
   different from Ericsson (with appropriated police character and
   color) which is probably what would be more meaningful for the end
   user.  On the other hand, the end user may also be familiar with that
   format and the use or a standardize format helps automation in the
   selection.  As a result, this document will assume that the rdns
   domain will reflect the legal entity administrating the resolver to
   the user.  Note that a user interface may also use the rdns domain to
   derive more user friendly and additional specific information that
   will be presented to the user.  This could include for example
   additional RDAP queries, favicons of web sites that are shown to the
   end users.  What is presented to the end user is out of scope of this
   document, but the rdns domain can be used as the key.

   b) The hostname part is only meaningful within the rdns domain.
   While, it may carry some information that may be interpreted to the
   end user, the constraint provided by the DNS format may be too
   restricting.  As a result, it is expected that a more user friendly
   string might be associated with the hostname and that the hostname
   remain reserved for networking administrators.

Migault                Expires September 10, 2020               [Page 5]
Internet-Draft                     RDP                        March 2020

   Parameters associated to the DNS transport are the type of transport
   that is DNS, DoT or DoH as well as the necessary parameters to
   establish the session.  This may include specific TLS parameters for
   DoT and DoH as well as specific HTTP versions for DoH.  These
   parameters are expected to be identified in a standard way.

6.  Architecture Overview

   DNS based Service Discovery (DNS-SD) [RFC6763] is a discovery
   protocol for services based on DNS messages.  DNS-SD provides the
   ability to display user-friendly names in UTF-8 and uses a
   combination of DNS RRsets of type PTR, SRV and TXT.  The current
   document is largely inspired from this long time and already existing
   protocol.  However, RDP differs from DNS SD in that DNS-SD discovers
   services within a specific domain (such as .local or .home.arpa for
   example) while RDP needs to discover the rdns domain as well as the
   resolving services (i.e. resolvers) associated to this domain.  In
   addition, RDP is taking advantage of the latests development of SRVCB
   RRsets [I-D.ietf-dnsop-svcb-httpssvc] which, among other things,
   enables to combine the SRV and TXT Rsets.  While nothing prevents RDP
   to use SRV and TXT RRsets, RDP uses instead SVCB RRset as web browser
   are more likely to implement SVBC.  The use of SRV is provided in the
   annex in case SVBC does not become standard or that the WG decides to
   use SRV RRsets instead.  The status of these annex are purely a
   documentation and will be removed from teh final version.  In any
   case, while DNS SD and RDP presents some strong similarities, it is
   not expect they are compatible.

   The overall procedure is performed as described below: 1.  Discovery
   of the global and local available rdns domains 2.  Discovery of the
   resolvers among each rdns domain.

7.  Domain Discovery with RDP

7.1.  Global Domain

   The mechanism involves the creation of a special domain name
   rdns.arpa that will list the various rdns domains.  This mechanism
   remains valid as long as the list of rdns domain name remains
   relatively limited.  The number of rdns domain that can fit into a
   payload will depend on the length of the rnds domain, so rdns domains
   are expected to have limited length.  However the compactness is not
   expected to match the one achieved for the root servers that are
   designated by a one character size identity.  The reason for it is
   that the identity of the resolver is expected to carry some meaning
   to the DNS client as opposed to the root servers.

Migault                Expires September 10, 2020               [Page 6]
Internet-Draft                     RDP                        March 2020

   That said, a UDP packet of 4096 bytes is expected to contain a
   significant amount of resolvers.  The number of open resolver is not
   expected to reach that limit and if so the list can be retrieved
   through TCP.

   The zone file below is inspired from DNS-SD where b indicates a
   browsing domain, _rdns indicates the DNS resolving service and
   rdns.arpa. indicates the special domain. rdns domain_0, rnds_domain_n
   indicates the various rdns domains.  The order of the rdns domain is
   irrelevant, and the zone administrator SHOULD regularly reorder them.
   The RRsets MUST be signed with DNSSEC.

   b._rdns.rdns.arpa  PTR <rdns_domain_0>
   [...]
   b._rdns.rdns.arpa  PTR <rdns_domain_n>

7.2.  Local Domain

   An application such as an web browser has a DNS client that MAY be
   configured by the application vendor or the end user with an IP
   address.  Note that the IP address MAY be provided by the system as
   well.  Similarly, a non negligible part of the systems the resolver
   is automatically provided by the network via the DNS Recursive Name
   Server option [RFC3646] and designated by an IP address.  In such
   cases, there is a need to derive the domain associated to that domain
   name.

   In any of these cases, the IP address is used as a local input to
   proceed to a resolving service instances discovery and eventually
   select a more appropriated resolving service instance according to
   the end user policy.  The rdns domain will be derived from the IP
   address by:

   1.  performing a reverse resolution

   2.  derive the rdns domain assuming the resulting FQDN is composed of
       a hostname and the rdns domain.  For example, if
       resolver.example.com is the resulting FQDN from the reverse
       resolution, then the rdns domain will be example.com.

8.  Resolvers Discovery

8.1.  Discovery of all service instances

   Given a rdns domain example.com, a DNS client MAY request all
   possible resolving service instances with a query of type SVCB with
   the service _rdns.

Migault                Expires September 10, 2020               [Page 7]
Internet-Draft                     RDP                        March 2020

   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 _rdn.example.com
   could have been used instead.

   The SvcFieldPriority indicates the preference of the resolving
   service instance.

   The SvcParamKey alpn MUST be present when TLS is used as its presence
   and value indicates the DNS transport.  The abscenec of the alpn
   SvcParamKey indicates that DNS is served, alpn set to dot indicates
   DoT is served while h* indicates DoH is served.

   The SvcParamField ux is optional is provides an UTF-8 string that is
   expected to be displayed to the end user if needed.

   The RRsets MUST be protected with DNSSEC and when alpn is provided a
   TLSA RRset MUST be present.

8.2.  Discovery of specific service instances

   In order to reduce the size of the messages, the DNS client MAY also
   prefer to query information of resolvers using a specific transport
   (DNS, DoT, DoH) that are designated as sub sets.  A DNS client MAY
   list the the different subsets of that rdns domain with a PTR query.
   In our case the subsets are defined as _dns for DNS, _dot for DoT and
   _doh for DoH.  All subsets MUST share the same rdns domain.

   This redirection with a PTR RRset is mandatory to be specified in the
   rdns domain, but the DNS client MAY directly query the subsets if it
   has a previous knowledge of these subsets.

   The currently defined subsets MAY be extended in the future.

   One the DNS client is aware of the available subsets, it MAY select
   one or more subsets and proceed to the SRVCB resolution.

   The same restriction as defined in section Section 8.1 apply.

   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 _rnds SRVCB
   query of section Section 8.1.

   The figure below illustrates an example of zone file.  RRSIG and TLSA
   have been omited for the purpose of clarity.

Migault                Expires September 10, 2020               [Page 8]
Internet-Draft                     RDP                        March 2020

 ## Discovery of all service instances
 _rdns.example.com. 7200 IN SVCB 0 svc.example.com.
 svc.example.com.    7200 IN SVCB 12 ( svc0.example.net.
                                       port="53" ux="Legacy Resolver" )
 svc.example.com.    7200 IN SVCB 1 ( svc1.example.net.  alpn="dot"
                                       port="53" esniconfig="..."
                                       ux="Preferred Example's Choice" )

 svc.example.com.    7200 IN SVCB 3 ( svc2.example.net. alpn="h2"
                                        port="53" esniconfig="..." ux= )
 svc.example.com.    7200 IN SVCB 2 ( svc3.example.net. alpn="h3"

 ## Discovery of specific service instances

 ### Definition of the resolving service subsets
 _rdns.example.com PTR _domain.example.com
 _rdns.example.com PTR _dot.example.com
 _rdns.example.com PTR _doh.example.com

 ### services instances per service subset
 _domain.example.com. 7200 IN SVCB 0 svc0.example.com.
 svc0.example.com.    7200 IN SVCB 12 ( svc0.example.net.
                                       port="53" ux="Legacy Resolver" )
 _dot.example.com.    7200 IN SVCB 0 svc1.example.com.
 svc1.example.com.    7200 IN SVCB 1 ( svc1.example.net.  alpn="dot"
                                       port="53" esniconfig="..."
                                       ux="Preferred Example's Choice" )

 _doh.example.com.    7200 IN SVCB 0 svc4.example.net.
 svc4.example.com.    7200 IN SVCB 3 ( svc2.example.net. alpn="h2"
                                        port="53" esniconfig="..." ux= )
 svc4.example.com.    7200 IN SVCB 2 ( svc3.example.net. alpn="h3"
                                       port="443" esniconfig="..."
                                       ux="Testing QUIC")

   Some notes:

   1.  SVCB requires to mention the port.  SVCB is a work in progress
       and we would like the port to be removed as port is not always
       mentioned in the scheme.  That said, mentionnig a non necessary
       port could be feasible.

   2.  _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.

   3.  _dot and _doh are seen as services even if doh is using HTTPS.

Migault                Expires September 10, 2020               [Page 9]
Internet-Draft                     RDP                        March 2020

   4.  Should we have some constraints regarding the SvcDomainName ?

9.  Resolver advertising other service sub type

   A resolver 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.

   In order to do so the resolver MAY provide in the additional data
   field the _rdns SRVCB of ServiceForm.

10.  Migration to service sub types

   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
   however, there is no mechanisms that could permit an indirection from
   one service sub type to another service sub type.  Redirection MAY
   especially be needed when a DNS client is using the dns53 sub type
   and the resolver would liek to upgrade the DNS client session to a
   more secure session.  The MAY require a specific ERROR code that will
   request the DNS client to perform service discovery.

   It is expected that domain sub service MUST always be provided to
   perform resolver discovery.  In other words, resolver discovery MUST
   be available though the non confidential channels designated by the
   sub service type dns53.  However, this does not mean that a resolver
   is expected to implement the dns53 sub type service for resolutions.
   The availability of the sub service types for resolution.  If a
   resolver chose not to provide the dns53 sub service type, that
   service MUST NOT be pointed by the _domain.example.com search.

11.  Security Considerations

11.1.  Use of protected channel is RECOMMENDED

   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

Migault                Expires September 10, 2020              [Page 10]
Internet-Draft                     RDP                        March 2020

   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.

11.2.  DNSSEC is RECOMMENDED

   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.

   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.

11.3.  TLSA is RECOMMENDED

   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

Migault                Expires September 10, 2020              [Page 11]
Internet-Draft                     RDP                        March 2020

   DNS client.  A DNS client SHOULD be able to validate the trust of a
   TLS session based on the DNSSEC trust model using DANE.

   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.

12.  Privacy Considerations

   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.

   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.

   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

Migault                Expires September 10, 2020              [Page 12]
Internet-Draft                     RDP                        March 2020

   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.

13.  IANA Considerations

   This document requests the IANA the creation of a new service name in
   the Service Name and Transport Protocol Port Number Registry
   https://www.iana.org/assignments/service-names-port-numbers/service-
   names-port-numbers.xml

   Fields Port Number, Transport Protocol, Assignee, Contact,
   Modification Date, Service Unauthorized Use Report, Assignment Notes
   are void.

   Service | Description    | Registration | Reference
   Name    |                | Date         |
   --------+----------------+--------------+-----------
   rdns    | DNS resolution |  TBD1        | RFC-TBD

   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

   RR Type | _NODE NAME | Reference
   --------+------------+----------
   SRVCB   | _rdns      | RFC-TBD
   SRVCB   | _dot       | RFC-TBD
   SRVCB   | _doh       | RFC-TBD
   SRVCB   | _dns       | RFC-TBD

   SvcParamKey | NAME         | Meaning                     | Reference
   ------------+--------------+-----------------------------+-----------
   7           | user-display | User friendly string (UTF8) | RFC-TBD
               |              | to represent the resolver   |

   # Appendix

13.1.  Resources using SRV RRsets

13.1.1.  Discovery mechanism associated to one domain

   The discovery mechanism is intended to enable a DNS client to
   discover what are the resolvers options available as well as how to
   further use these resolvers.

Migault                Expires September 10, 2020              [Page 13]
Internet-Draft                     RDP                        March 2020

   The procedure is based on service discovery [RFC8145] and the overall
   procedure consists in finding various instances of the service
   "rdns".  The resolution service is designated as "rdns" and differs
   from the service "domain" defined by IANA.

   In this document, the service "rdns" is associated to a domain such
   as example.com.  This means that the discovery process is performed
   over a specific portion of the internet, and resolvers that have no
   relation to that domain are not expected to be found.  It is expected
   that the domain may be provisioned as a configuration parameter in
   the DNS client.  It is expected that the domain provides a good
   meaning of the administrative entity managing the resolver, as it
   reflects the trust/mistrust the end user puts in the resolution.
   This configuration parameters differs from the one that is currently
   provisioned and discussion on how to proceed to resolver discovery
   from a legacy provisioning is described in more details in
   Section 7.2.

   The DNS client then searches for the rdns service associated to the
   domain example.com by querying PTR RRsets associated to
   _rdns_udp.example.com.  This query corresponds to the general case of
   DNS service discovery.  While tcp is reserved for TCP only and DNS is
   not only running on top of TCP we use _udp as a representation of
   _srv.

   The difference with service discovery is that the response is
   expected to return instances of the service type.  These instances
   may offer completely different services, but the end user is expected
   to select them according to their human readable name.  In our case,
   the rdns service type can be implemented into different sub services
   types that are in our cases (DOT, DOH DNS).  DOT, DOH and DNS are
   only example and any other designation may have been provided.
   Possible ways to distinguish these services could have been to adopt
   a convention in the service instance names or to have standard value
   for the service names.  We prefer not to take that path and remove
   any constraints on the service name as it usually appears to the end
   user and we want to leave it free to contain what is going to be
   meaningful for the end user.  Typically, DOT, DOH or DNS are unlikely
   to be meaningful to the waste majority of the internet users.
   Instead we used the DNS-SD capabilities to specify sub services by
   prefixing with _dot, _doh and _dns53 the dns._udp service type.

Migault                Expires September 10, 2020              [Page 14]
Internet-Draft                     RDP                        March 2020

   DNS client  -->    Resolver
   _rdns.example.com PTR ?

               <--
   _rdns_udp.example.com PTR DOT._dot._sub._rdns._udp.example.com
   _rdns_udp.example.com PTR DOH._doh_sub._rdns._udp.example.com
   _rdns_udp.example.com PTR DNS._dns53_sub._rdns._udp.example.com

   Note that "DOT", "DOH" and "DNS" are the strings that may be shown to
   the end user.  The main difference with DNS-SD is that the sub type
   was initially designed so the end user can narrow down its search.
   More explicitly its purpose was to enable an end user to narrow down
   the search on services providing DNS resolution over HTTPS with
   _doh._sub._rdns._udp.example.com.  The purpose was not to split a
   generic service into multiple sub types of services.

   Note that the user interface is expected to interpret and present to
   the end user the different services by interpreting the _dot, _doh or
   _dns53 sub service types and easing the understanding of the end
   user.  If the DNS client is implementing a specific configuration, it
   will also have to interprete the sub types according to the
   configuration of the end user.

   Now that the end user has the various services available ("DOH",
   "DOT" and "DNS") with there associated types, the selection can
   occur, and the DNS client can request additional information about
   the service itself to set up a session with the chosen service.  In
   our case this is mostly the host name, ports, the ip address, the
   certificates, .... If the DNS client choses to use DoH, for example,
   it will request the SRV RRsets associated to that service.

   Note that in our case, the sub service type carries sufficient
   information and no additional information is needed.  There is no
   need to request the TXT reccord.  Note also that carrying the sub
   type into the TXT RRsets would not be appropriated as this is believe
   to be a sufficiently important information to prevent a DNS client to
   browse thought all the different service instances.

   While the TXT RRset is not necessary now, it MAY contain additional
   information that may be usefull to the DNS client as well.

   It is expected these exchanges are protected with DNSSEC as these
   could be performed over an untrusted channel as well as through semi
   trusted resolver.  The additional section SHOULD also carry the
   necessary information to set up the session between the DNS client
   and the resolver.  This includes the IP addresses (A and AAAA)

Migault                Expires September 10, 2020              [Page 15]
Internet-Draft                     RDP                        March 2020

   RRsets, for services implemented over TLS the necessary security
   credentials (TLSA RRsets).

   DNS client  -->    Resolver
   DOH._doh_sub._rdns._udp.example.com SRV ?
               <--
   DOH._doh_sub_rdns.example.com SRV priority=0, weight=0,
                              port=443 host=resolver.example.com
   DOH._doh_sub_rdns.example.com SRV priority=0, weight=1,
                              port=443 host=resolver.example.com
   DOH._doh_sub_rdns.example.com RRSIG (SRV) <signature>
   resolver.example.com AAAA <ip6_address>
   resolver.example.com AAAA <ip6_address>
   resolver.example.com RRSIG (A) <signature>
   resolver.example.com TLSA <certificate>
   resolver.example.com RRSIG (TLSA) <signature>

13.1.2.  File example

   Example of a file.

   _rdns_udp.example.com PTR DOT._dot._sub._rdns._udp.example.com
   _rdns_udp.example.com PTR DOH._doh_sub._rdns._udp.example.com
   _rdns_udp.example.com PTR DNS._dns53_sub._rdns._udp.example.com

   _dot_sub_rdns.example.com PTR DOT._dot_sub_rdns._udp.example.com
   _doh_sub_rdns.example.com PTR DOH._doh_sub_rdns._udp.example.com
   _dns53_sub_rdns.example.com PTR DNS._dns53_sub_rdns._udp.example.com

   DOT._dot_sub_rdns.example.com SRV port=443 host=dns.example.com
   DOT._dot_sub_rdns.example.com SRV port=53 host=dns.example.com
   DOH._dot_sub_rdns.example.com SRV port=443 host=dns-dot.example.com
   DNS._dns53_sub_rdns.example.com SRV port=53 host=dns53.example.com

   dns.example.com AAAA
   dns.example.com TLSA
   dns.example.com RRSIG

   dns53.example.com AAAA
   dns53.example.com RRSIG

13.1.3.  Resolver advertising other service sub type

   A resolver 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.

Migault                Expires September 10, 2020              [Page 16]
Internet-Draft                     RDP                        March 2020

   In order to do so the resolver MAY provide in the additional data
   field the appropriated SRV RRsets.  As an example, if the resolver
   wants to advertise the existence of resolver using dot or doh sub
   service type, the resolver would add the following RRsets.
   Additional RRSets such as A, AAAA or TLSA RRSets MAY also be added.

   DOH._doh._sub_rdns.example.com SRV priority=0, weight=0,
                                    port=443 host=resolver.example.com
   DOH._doh._sub_rdns.example.com SRV priority=0, weight=1,
                                    port=443 host=resolver.example.com
   DOH._doh._sub_rdns.example.com RRSIG (SRV) <signature>
   DOT._dot._sub_rdns.example.com SRV priority=0, weight=0,
                                    port=443 host=resolver.example.com
   DOT._dot._sub_rdns.example.com SRV priority=0, weight=1,
                                    port=443 host=resolver.example.com
   DOT._dot._sub_rdns.example.com RRSIG (SRV) <signature>

14.  Normative References

   [I-D.ietf-dnsop-svcb-httpssvc]
              Schwartz, B., Bishop, M., and E. Nygren, "Service binding
              and parameter specification via the DNS (DNS SVCB and
              HTTPSSVC)", draft-ietf-dnsop-svcb-httpssvc-01 (work in
              progress), November 2019.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3646]  Droms, R., Ed., "DNS Configuration options for Dynamic
              Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
              DOI 10.17487/RFC3646, December 2003,
              <https://www.rfc-editor.org/info/rfc3646>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

Migault                Expires September 10, 2020              [Page 17]
Internet-Draft                     RDP                        March 2020

   [RFC8145]  Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
              Anchor Knowledge in DNS Security Extensions (DNSSEC)",
              RFC 8145, DOI 10.17487/RFC8145, April 2017,
              <https://www.rfc-editor.org/info/rfc8145>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

Author's Address

   Daniel Migault
   Ericsson
   8275 Trans Canada Route
   Saint Laurent, QC  4S 0B6
   Canada

   EMail: daniel.migault@ericsson.com

Migault                Expires September 10, 2020              [Page 18]