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

Versions: 00

dnsop                                                         D. Migault
Internet-Draft                                                  Ericsson
Intended status: Informational                          January 23, 2020
Expires: July 26, 2020


                    DNS over Foo Discovery Mechanism
                draft-mglt-dprive-add-dofoo-discovery-00

Abstract

   This document describes a mechanism that enables a DNS client to
   discover other DNS alternatives such as DoT or DoH for one specific
   domain.  This document also extends this discovery mechanism to an
   Internet wide of open resolvers search - though this is expected to
   be described further in a separate document.  While search are always
   initiated by the DNS client, this document also indicates how a
   resolver MAY indicate a DNS client its preference for using
   alternative flavors of transport layer.

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 July 26, 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



Migault                   Expires July 26, 2020                 [Page 1]


Internet-Draft          DoFoo Discovery Mechanism           January 2020


   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.

Table of Contents

   1.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Discovery mechanism associated to one domain  . . . . . . . .   2
     3.1.  Infering domain from resolvers IP address . . . . . . . .   5
   4.  Resolver advertising other service sub type . . . . . . . . .   5
   5.  Migration to service sub types  . . . . . . . . . . . . . . .   6
   6.  Service discovery over the Internet . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     7.1.  Use of protected channel is RECOMMENDED . . . . . . . . .   7
     7.2.  DNSSEC is RECOMMENDED . . . . . . . . . . . . . . . . . .   8
     7.3.  TLSA is RECOMMENDED . . . . . . . . . . . . . . . . . . .   8
   8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   10. Appendix  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

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

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

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



Migault                   Expires July 26, 2020                 [Page 2]


Internet-Draft          DoFoo Discovery Mechanism           January 2020


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

   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.

   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



Migault                   Expires July 26, 2020                 [Page 3]


Internet-Draft          DoFoo Discovery Mechanism           January 2020


   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)
   RRsets, for services implemented over TLS the necessary security
   credentials (TLSA RRsets).













Migault                   Expires July 26, 2020                 [Page 4]


Internet-Draft          DoFoo Discovery Mechanism           January 2020


   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>

3.1.  Infering domain from resolvers IP address

   When an application such as an web browser has a DNS client as part
   of its components, the configuration of that DNS client can be part
   of the application configuration.  In such case, the domain may be
   provisioned in the configuration either by the software vendor or
   manually by the end user.  On the other hand, a non negligible part
   of the systems the resolver is automatically provided by the network
   and designated by an IP address [RFC3646].  In such cases, there is a
   need to derive the domain associated to that domain name.

   This section describes a procedure performed by the DNS client to
   derive the domain from the IP address.  It is also expected that
   resolver adapt their naming convention so that the procedure works.
   More precisely, the domain will be derived from the IP address by:

   1.  performing a reverse resolution

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

4.  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 appropriated SRV RRsets.  As an example, if the resolver
   wants to advertise the existence of resolver using dot or doh sub



Migault                   Expires July 26, 2020                 [Page 5]


Internet-Draft          DoFoo Discovery Mechanism           January 2020


   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>

5.  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 dns53 sub type 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 _rdns.example.com search.

6.  Service discovery over the Internet

   THIS SECTION NEEDS PROBABLY TO THE TOPIC OF A DEDICATED DRAFT.

   The current document describes a search mechanism over a single
   domain.  This is mostly useful for one resolver to anounce
   availability of other sub service types as well as for resolver to
   discover available alternatives.  However, this requires the
   knowledge of a domain.  The domain can be provisionned out-of band
   and results from a configuration setting.  In the case of local scope
   resolver, it can also be derived from a provisioned IP address.  This
   section aims at extending the ability for one DNS client to learn



Migault                   Expires July 26, 2020                 [Page 6]


Internet-Draft          DoFoo Discovery Mechanism           January 2020


   about the different available domain associated to a resolver on the
   Internet.  This section will list open resolvers that are available.

   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.

   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 traffic associated to that domain is expected to be limited as
   most applications are expected to be provisioned with that RRset.

   b._rdns.rdns.arpa  PTR <rdns domain0>
   b._rdns.rdns.arpa  PTR <rdns domain1>
   [...]

   TBD: * IANA procedure to register * criterias that needs to be met to
   appear in the list

   QUESTION: * Do we need to add some criteria for the search ?

7.  Security Considerations

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



Migault                   Expires July 26, 2020                 [Page 7]


Internet-Draft          DoFoo Discovery Mechanism           January 2020


   resolver, which is consequently larger.  The use of a protected
   channel is recommended as it will prevent anyone on path to monitor
   your traffic.

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

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



Migault                   Expires July 26, 2020                 [Page 8]


Internet-Draft          DoFoo Discovery Mechanism           January 2020


   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.

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




Migault                   Expires July 26, 2020                 [Page 9]


Internet-Draft          DoFoo Discovery Mechanism           January 2020


9.  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
   --------+------------+----------
   SRV     | _rdn       | RFC-TBD
   SRV     | _dot       | RFC-TBD
   SRV     | _doh       | RFC-TBD
   SRV     | _dns53     | RFC-TBD

10.  Appendix

   Example of a file.



















Migault                   Expires July 26, 2020                [Page 10]


Internet-Draft          DoFoo Discovery Mechanism           January 2020


   _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

11.  Normative References

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

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

Author's Address









Migault                   Expires July 26, 2020                [Page 11]


Internet-Draft          DoFoo Discovery Mechanism           January 2020


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

   EMail: daniel.migault@ericsson.com












































Migault                   Expires July 26, 2020                [Page 12]


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