[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

add                                                           D. Migault
Internet-Draft                                                  Ericsson
Intended status: Informational                            March 24, 2020
Expires: September 25, 2020


                 DNS Resolver Discovery Protocol (DRDP)
                         draft-mglt-add-rdp-01

Abstract

   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 resolver may also inform the DNS client other
   resolving services are available and eventually preferred.

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 25, 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 25, 2020               [Page 1]


Internet-Draft                    DRDP                        March 2020


Table of Contents

   1.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  DRDP Requirements . . . . . . . . . . . . . . . . . . . . . .   3
   5.  DRDP outputs  . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Resolving Service Identity  . . . . . . . . . . . . . . .   4
     5.2.  DNS Transport related information . . . . . . . . . . . .   5
     5.3.  DNS Service related Information . . . . . . . . . . . . .   5
   6.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   5
   7.  Domain Discovery with DRDP  . . . . . . . . . . . . . . . . .   6
     7.1.  Global Domain . . . . . . . . . . . . . . . . . . . . . .   6
     7.2.  Local Domain  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Resolving Service  Discovery  . . . . . . . . . . . . . . . .   8
     8.1.  Discovery of all service instances  . . . . . . . . . . .   8
     8.2.  Discovery of specific service instances . . . . . . . . .   9
   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  . . . . . . . .  11
     11.2.  DNSSEC is RECOMMENDED  . . . . . . . . . . . . . . . . .  11
     11.3.  TLSA is RECOMMENDED  . . . . . . . . . . . . . . . . . .  12
   12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  13
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     15.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

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 in
   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 resolving
   services.  These services can be local, global and can use 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 (DRDP) is to
   discover these resolving services available to the DNS client so a



Migault                Expires September 25, 2020               [Page 2]


Internet-Draft                    DRDP                        March 2020


   selection process can be applied.  The information returned by DRDP
   typically includes information related to the identity of the
   resolving service, the transport ( IP addresses, the transport
   protocols, TLS parameters, HTTP version) as well as to
   characteristics of the resolving service (filtering, associated
   authoritative domains).  The pieces of information can be extended to
   meet future usage.

   How the selection is performed is out of scope of this document.

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.  A Resolving Service is
      implemented by one or multiple resolvers.

   Resolver: A resolver designates the software or hardware handling the
   DNS exchange.  See [RFC7719] for more details.

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

   Resolving Domain  a DNS domain that hosts one or multiple resolving
      services.

4.  DRDP Requirements

   This section lists the DRDP requirements.

   REQ 1: DRDP MAY be used by a DNS client (Do53, DoT, DoH, ...) to
   discover resolving service or by a resolver to advertise other
   resolving services are available.

   REQ 2: DRDP MUST be able to list dynamically locally and globally
   resolving services available to the DNS client.

   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
   DRDP and DRDP limits its scope to parameters that are inherent to the
   resolving service.  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



Migault                Expires September 25, 2020               [Page 3]


Internet-Draft                    DRDP                        March 2020


   DRDP.Another example could be the activation of some services such as
   parental protection.

   REQ 3: DRDP MUST at least return DNS transport parameters associated
   of the resolving services and MAY be extended with additional
   parameters.

   The selection of the resolving service 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 4: DRDP MUST return selection parameters in a standard format to
   ease automation.

   REQ 5: DRDP MUST return selection parameters that can be displayed to
   an end user either as a simple notification of when user interaction
   is involved in the selection process.

   REQ 6: DRDP MUST enable a resolving service provider to indicate a
   preference between multiple provided resolving services.

   The resolving service selection MAY be performed over a subset of the
   available resolvers as opposed as the full set of available
   resolvers.

   REQ 7: DRDP SHOULD be able to narrow down the discovery to a subset
   of resolving services.

   REQ 8: DRDP MUST provide authenticated information

   REQ 9: DRDP deployment MUST NOT be disruptive for the legacy DNS
   client or infrastructure and legacy client SHOULD be able to
   incrementally include DRDP.

5.  DRDP outputs

5.1.  Resolving Service Identity

   The identity of the resolving service is an important selection
   parameter as it usually reflects the trust an end user puts into this
   service.  In addition, trust 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 resolver domain and
   "resolver" represents hostname.



Migault                Expires September 25, 2020               [Page 4]


Internet-Draft                    DRDP                        March 2020


   a) The resolving 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 resolving domain follows some
   DNS encoding rules and as such may not be believed to be so user
   friendly.  Typically, it 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 resolving 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.

5.2.  DNS Transport related information

   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 and URI template for
   DoH.  These parameters are expected to be identified in a standard
   way.

5.3.  DNS Service related Information

   Parameters associated to the resolving service include for example,
   the presence of filtering services, the associated authoritative
   domains.

6.  Architecture Overview

   DRDP can be used by a resolver or a DNS client (REQ1), which share
   DNS as a common protocol.  In addition, the ability to deploy
   incrementally DRDP over legacy DNS client (REQ9) makes DNS a good
   candidate for DRDP.




Migault                Expires September 25, 2020               [Page 5]


Internet-Draft                    DRDP                        March 2020


   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, DRDP differs from DNS SD in that DNS-SD
   discovers services within a specific domain (such as .local or
   .home.arpa for example) while DRDP needs to discover the resolving
   domain as well as the resolving services associated to this domain.
   In addition, DRDP 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 DRDP to use SRV and TXT RRsets, DRDP uses instead SVCB RRset
   as web browser are more likely to implement SVBC.

   The overall procedure is performed as described below: 1.  Discovery
   of the global and local available resolving domains 2.  Discovery of
   the resolving services within a resolving domain.

7.  Domain Discovery with DRDP

7.1.  Global Domain

   The mechanism involves the creation of a special domain name
   rdns.arpa that lists the various resolving domains.  This mechanism
   remains valid as long as the list of resolving domain name remains
   relatively limited.  The number of resolving domain that can fit into
   a payload will depend on the length of the various resolving domain.
   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, _dns indicates the DNS resolving service and
   rdns.arpa. indicates the special domain. dns domain_0, nds_domain_n
   indicates the various resolving domains.  The order of the resolving
   domains is irrelevant, and the zone administrator SHOULD regularly
   reorder them.  The RRsets MUST be signed with DNSSEC.

   b._dns.rdns.arpa  PTR <resolving_domain_0>
   [...]
   b._dns.rdns.arpa  PTR <resolving_domain_n>







Migault                Expires September 25, 2020               [Page 6]


Internet-Draft                    DRDP                        March 2020


7.2.  Local Domain

   The resolving domains that are local needs to be provisioned or
   advertised by the network.  With that resolving domain the DNS client
   could proceed to its resolving service selection.

   Resolving service are currently configured or advertised via IP
   addresses rather than a FQDN as a DNS resolution would be needed to
   resolve the IP address.  More specifically, networks usually
   advertise the resolving service via a Recursive Name Server option
   [RFC3646] that contains an IP address.  Similarly application usually
   configures their resolving services with IP addresses (8.8.8.8,
   1.1.1.1, 9.9.9.9,...).  As a result, this section indicates a
   mechanism that would enable a DNS client to derive a resolving domain
   of a resolver from an IP address of an advertised resolver.  The
   mechanism described here is expected to be used as an hint.

   The resolving domain will be derived from the IP address by:

   1.  performing a reverse resolution

   2.  assume the resulting FQDN is composed of a hostname appended to
       the resolving domain.  For example, if resolver.example.com is
       the resulting FQDN from the reverse resolution, then the rdns
       domain will be example.com.

   In most cases local resolving services uses global IP address which
   does not limit the reverse resolution to an associated local
   resolver.  However the zone associated to the resolving domain might
   not be available globally and instead be restricted to the local
   network.  As a result, DNS client SHOULD perform DNS resolution
   associated to the local resolving domain using the local resolver,
   and resolver operator SHOULD publish the resolving domain zone to the
   global Internet.

   Legacy DNS client will not be impacted.  Upon receiving the IP
   address they will send their DNS queries to that IP address.  DRDP
   aware DNS client will derive the resolving domain and attempt to
   perform a discovery within the resolving domain.

   If other mechanisms as used to advertise the resolving domains such
   as those described in [I-D.btw-add-home], and the resolving domain
   are different, the DNS client should perform DRDP with both resolving
   domains.







Migault                Expires September 25, 2020               [Page 7]


Internet-Draft                    DRDP                        March 2020


8.  Resolving Service Discovery

8.1.  Discovery of all service instances

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

   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 _dn.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 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 teh DNS transport as non standard port
   MAY be used.  The example below uses an non standard port 5353 for
   illustrative purpose.

   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 SHOULD be present.  These RRsets have been omitted for
   clarity.

## Discovery of all service instances
_dns.example.com. 7200 IN SVCB 0 svc.example.com.
svc.example.com.    7200 IN SVCB 12 ( svc0.example.net.
                                      port="5353" ux="Legacy Resolver" )
svc.example.com.    7200 IN SVCB 1 ( svc1.example.net.  alpn="dot"
                                      port="5353" esniconfig="..."
                                      ux="Preferred Example's Choice" )
svc.example.com.    7200 IN SVCB 3 ( svc2.example.net. alpn="h2"
                                       port="5353" esniconfig="..." ux= )
svc.example.com.    7200 IN SVCB 2 ( svc3.example.net. alpn="h3"
                                       port="5353" esniconfig="..." ux= )









Migault                Expires September 25, 2020               [Page 8]


Internet-Draft                    DRDP                        March 2020


8.2.  Discovery of specific service instances

   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 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 Section 8.1.

   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.

   The same restrictions 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 _dns 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.

### 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" ux="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="..."
                                      ux="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="..." ux= )
svc4.example.com.    7200 IN SVCB 2 ( svc3.example.net. alpn="h3"
                                      port="5353" esniconfig="..."
                                      ux="Testing QUIC")




Migault                Expires September 25, 2020               [Page 9]


Internet-Draft                    DRDP                        March 2020


   Some notes:

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

   2.  Should we have some constraints regarding the SvcDomainName and
       QNAME ?

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 _dns 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.  This document
   specifies that weight needs to be considered across sub types.
   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.

   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.  If a resolving service
   provider chooses not to provide a resolving service using Do53, that
   service MUST NOT be pointed by the _53._dns.example.com search and
   MUST NOT provide _dns.example.com SRVCB RRsets with no SvcParamKey
   alpn.

11.  Security Considerations








Migault                Expires September 25, 2020              [Page 10]


Internet-Draft                    DRDP                        March 2020


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
   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




Migault                Expires September 25, 2020              [Page 11]


Internet-Draft                    DRDP                        March 2020


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




Migault                Expires September 25, 2020              [Page 12]


Internet-Draft                    DRDP                        March 2020


   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.

13.  IANA Considerations

   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   | _dns       | RFC-TBD

   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 |



   SvcParamValue for filetring



14.  Acknowledgments

   We would like thank Mirja Kuehlewind 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.




Migault                Expires September 25, 2020              [Page 13]


Internet-Draft                    DRDP                        March 2020


15.  References

15.1.  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-02 (work in
              progress), March 2020.

   [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>.

   [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>.

15.2.  Informative References

   [I-D.btw-add-home]
              Boucadair, M., Reddy.K, T., Wing, D., and N. Cook, "DNS-
              over-HTTPS and DNS-over-TLS Server Discovery and
              Deployment Considerations for Home and Mobile Networks",
              draft-btw-add-home-04 (work in progress), March 2020.



Migault                Expires September 25, 2020              [Page 14]


Internet-Draft                    DRDP                        March 2020


   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
              2015, <https://www.rfc-editor.org/info/rfc7719>.

Author's Address

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

   EMail: daniel.migault@ericsson.com






































Migault                Expires September 25, 2020              [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/