add D. Migault
Internet-Draft Ericsson
Intended status: Informational May 29, 2020
Expires: November 30, 2020
DNS Resolver Discovery Protocol (DRDP)
draft-mglt-add-rdp-02
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 resolving service 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 November 30, 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 November 30, 2020 [Page 1]
Internet-Draft DRDP May 2020
Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. DRDP Requirements . . . . . . . . . . . . . . . . . . . . . . 4
5. Resolving Domains . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Resolving Domain and Resolving Service Identity . . . . . 5
5.2. List of Resolving Domains . . . . . . . . . . . . . . . . 6
5.3. Local Network Resolving Domain . . . . . . . . . . . . . 7
6. Resolving Service Discovery . . . . . . . . . . . . . . . . . 8
6.1. Discovery of all service instances . . . . . . . . . . . 8
6.2. Discovery of specific service instances . . . . . . . . . 9
6.3. TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.4. SvcParamKey . . . . . . . . . . . . . . . . . . . . . . . 10
7. Resolver advertising other service sub type . . . . . . . . . 11
8. Migration to service sub types . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9.1. Use of protected channel is RECOMMENDED . . . . . . . . . 11
9.2. DNSSEC is RECOMMENDED . . . . . . . . . . . . . . . . . . 12
9.3. TLSA is RECOMMENDED . . . . . . . . . . . . . . . . . . . 12
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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 or 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
local scope of these services may take various forms. For example,
it could be associated to a network perspective ( restricted to the
network the DNS client is connected to ) or to an application
perspective ( restricted to some domain names ).
Migault Expires November 30, 2020 [Page 2]
Internet-Draft DRDP May 2020
The purpose of the DNS Resolving service Protocol (DRDP) is to
discover resolving services available to the DNS client. These
available resolving services to a given DNS client may highly depend
on its location or browsing activity. The number of resolving
services available to the DNS client is expected to remain quite
consequent and evolve over time. Similarly, characteristics
associated to these resolving services may also evolve over time. As
a result, the DNS client is unlikely willing to synchronize such a
huge data base of resolving services. DRDP proposes an alternative
that consists in adaptively discovering the available resolving
services based on the DNS client context.
DRDP adopts a hierarchical approach where the DNS client gets
_resolving domains_ from the context. These _resolving domains_ are
entry points for resolving services ( associated to each of these
resolving domains ).
The DNS client may obtain the contextual resolving domains via
various way, including a configuration or via DHCP Options
[I-D.btw-add-home].
This document describes two mechanisms for a DNS client to retrieve
resolving domains. Firstly, it is envisioned that these resolving
domains will be provided by multiple third party providers which
could designate a set of resolving domains. This set is designated
by a pointer used by the DNS client to retrieve the resolving
domains.
Secondly, resolving domain may be derived from the IP address of the
legacy resolving service provided via the Recursive Name Server
option [RFC3646]. Such a resolving domain can be seen as a network
local scope resolving domain. This resolving domain may then be used
by the DNS client to discover he various flavors of resolving
services provided by the ISP (DoH, DoT for example), while the legacy
IP address provided is reserved to the legacy resolving service.
The discovery process is expected to be followed by a selection
process by which the DNS client selects the resolving service it is
willing to use for the DNS resolution of the end user or application.
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.
Migault Expires November 30, 2020 [Page 3]
Internet-Draft DRDP May 2020
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 MUST enable a DNS client to discover the available
resolving services with their associated characteristics in order to
proceeds to a selection process. The selection process takes
resolving services identities and associated parameters and proceed
to the selection.
Any sort of resolving service selection is outside the scope of DRDP.
REQ 2: While the discovery process is triggered by the DNS client, a
third party MUST be able to provide necessary input information so a
resolving service discovery process can be triggered within a
specific context.
Provisioning protocols to provide this information is not as per say
in scope of DRDP. DRDP defines the format of the format for such
input as well as a set of such inputs.
REQ 3: Any information used in DRDP MUST be authenticated by its
owner. In particular, the characteristics associated to the
resolving service MUST be certified by the resolving service operator
/ owner and MUST be associated a validity period. In addition, a
third party providing a set of inputs MUST authenticate that set.
REQ 4: Information associated to the resolving services is intended
to enable the selection process that is assumed to match the end user
or application policy. The selection process is out of scope of
DRDP. Information may carry some characteristics of a resolving
service or hints that will help the selection. In particular an
operator of multiple resolving service MUST be able to associate a
preference to the proposed resolving services. To ease automation of
the selection as well as to make multiple applications benefit from
DRDP the information MUST be carried over a standardized format.
Migault Expires November 30, 2020 [Page 4]
Internet-Draft DRDP May 2020
REQ 5: DRDP MUST be designed to be used indifferently by a DNS client
using any DNS transport protocol (Do53, DoT, DoH, ...). However,
DRDP SHOULD be able to restrict the information retrieved to a
certain type of resolving service, i.e. Do53, DoT, DoH.
REQ 6: DRDP deployment MUST NOT be disruptive for the legacy DNS
client or infrastructure and legacy client SHOULD be able to
incrementally include DRDP.
5. Resolving Domains
The resolving domain is the input of a discovery process.
Section Section 5.1 defines the format resolving domain and exposes
why resolving domains seem convenient pointers to resolving service
as well as how the relates to resolving service identities.
Section Section 5.2 defines the format of a pointer to a set of
resolving domains as well as how to retrieve how to handle such set.
Such pointer are expected to be used by third party providers to
indicate a subset of resolving domains that match a certain context.
The use of a pointer is expected to ease the management of the set as
opposed to a explicit list. The definition of such a format is
expected to favor interoperability with third party providers.
Finally, section Section 5.3 defines a procedure to derive a
resolving domain from the IP address provided by Recursive Name
Server option [RFC3646]. Such procedure is expected to leverage from
the existing and legacy infrastructure.
5.1. Resolving Domain and Resolving Service Identity
A resolving service is identified by a FQDN - such as
resolver.example.com - and the domain part ( example.com ) is
designated as the resolving domain. Note that the hostname
(resolver) is only considered as a way to distinguish different
resolving services but it is not expected to carry any specific
information that will be useful for the selection process.
The resolving domain is expected to be representative to the end user
of the brand or legal entity of the institution the end user sends
its data to. The end user is likely to select a given resolving
domain based on the trust he puts into the associated legal entity.
The resolving domain follows some DNS encoding rules and as such may
not be believed to be so user friendly. 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. Typically, it
might be ericsson.com or ericsson which is different from Ericsson
(with appropriated police character and color) which would be more
meaningful for the end user. Note that a user interface may also use
Migault Expires November 30, 2020 [Page 5]
Internet-Draft DRDP May 2020
the resolving 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 resolving domain can be
used as the key.
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. List of Resolving Domains
A resolving domain list is designated by a FQDN example.com and the
resolving domains contained in that list are retrieved by sending a
query of type PTR for b._dns.example.com.
The zone file below is inspired from DNS-SD where b indicates a
browsing domain, _dns indicates the DNS resolving service,
example.com designates the list of the resolving domains.
resolving domain_0, resolving_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.example.com PTR <resolving_domain_0>
[...]
b._dns.example.com PTR <resolving_domain_n>
Using the DNS provides the advantage to retrieve the resolving domain
without requiring other libraries than DNS as well as benefit from
the DNS caching infrastructure including the use of the TTL.
An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly
all current networks. This is based on an MTU of 1280, which is
required by the IPv6 specification, minus 48 bytes for the IPv6 and
UDP headers. Such size makes lists of a 100 names viable over UDP
without fragmentation. Larger lists will require the DNS exchange to
be performed over TCP. While there is no hard limits, downloading
the full list every TTL may not be appropriated for very large lists
where the synchronization mechanisms may be needed.
The current size of such lists [curl][dnsprivacy.org] have less than
50 resolving domains. Other lists such as [public-dns.info] have as
Migault Expires November 30, 2020 [Page 6]
Internet-Draft DRDP May 2020
much as 11.000 entries, but such lists seems to contain open
resolvers which is out side of the scope of a selection process.
Web browser (Google Chrome) also have lists over 10.000 entries, but
in case a significant number of entries seems to be IP addresses that
have a very limited network scope ( e.g. limited to the ISP ). The
length of the list in scope to the DNS client is in fact significant
smaller in term of IP addresses and even smaller if resolving domain
are able to represent multiple IP addresses. Overall, the size of
such lists are currently due to the absence of discovery protocols.
5.3. Local Network Resolving Domain
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 resolving service 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
Migault Expires November 30, 2020 [Page 7]
Internet-Draft DRDP May 2020
are different, the DNS client should perform DRDP with both resolving
domains.
6. Resolving Service Discovery
6.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 _dns.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 the DNS transport as non standard port
MAY be used. The example below uses an non standard port 5353 for
illustrative purpose.
Other SvcParam are detailed in Section 6.4 and are optional. A
SvcParam not understood by the DNS client MUST be ignored.
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" user-display="Legacy Resolver" )
svc.example.com. 7200 IN SVCB 1 ( svc1.example.net. alpn="dot"
port="5353" esniconfig="..."
user-display="Preferred Example's Choice" )
svc.example.com. 7200 IN SVCB 3 ( svc2.example.net. alpn="h2"
port="5353" esniconfig="..." user-display= )
svc.example.com. 7200 IN SVCB 2 ( svc3.example.net. alpn="h3"
port="5353" esniconfig="..." user-display= )
Migault Expires November 30, 2020 [Page 8]
Internet-Draft DRDP May 2020
6.2. Discovery of specific service instances
To reduce the size of the messages, the DNS client MAY also prefer to
query information of resolving services using a specific transport
(DNS, DoT, DoH) that are designated as sub sets. A DNS client MAY
list the different subsets of that resolving domain with a PTR query.
This document defines the following subsets _53._dns for DNS,
_853._dns for DoT and _443.__dns for DoH. Other subsets MAY be
defined in the future. A DNS client that does not understand a
subset SHOULD ignore it and maybe proceed to the discovery as defined
in Section 6.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 6.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 6.1.
The figure below illustrates an example of zone file. RRSIG and TLSA
have been omitted 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" user-display="Legacy Resolver" )
_853._dns.example.com. 7200 IN SVCB 0 svc1.example.com.
svc1.example.com. 7200 IN SVCB 1 ( svc1.example.net. alpn="dot"
port="5353" esniconfig="..."
user-display="Preferred Example's Choice" )
_443_dns.example.com. 7200 IN SVCB 0 svc4.example.net.
svc4.example.com. 7200 IN SVCB 3 ( svc2.example.net. alpn="h2"
port="5353" esniconfig="..." user-display= )
svc4.example.com. 7200 IN SVCB 2 ( svc3.example.net. alpn="h3"
port="5353" esniconfig="..."
user-display="Testing QUIC")
Migault Expires November 30, 2020 [Page 9]
Internet-Draft DRDP May 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 ?
3. do we need the service subsets
6.3. TTL
The DNS client SHOULD perform DRDP at regular intervals as indicated
by its policy.
The selection process MAY remove resolving services with short TTL
lower than a day as it indicates some source of instalbility. Given
a subset of selected resolving services, the DNS client may perform
DRDP 1 hour before an SVB RRset expires.
6.4. SvcParamKey
This section defines a set of SvcParamKey that MAY be use to carry
the necessary informations for the selection process.
alpn :
esniconfig :
port :
user-display indicates a strings in UTF-8 that is expected to be
representative to a potential end user. Though there is no
restriction in the scope of that string. The string is likely to
represent the service within the resolving domain.
uri_template designates the URI template for DoH. This key MUST NOT
be present on non DoH services and MUST be ignored by the DNS
client on non DoH resolving Services.
auth_domain indicates the list of authoritative domain name the
resolving service has strong relation with. It is expected that a
resolving service may prefer to perform DNS resolution over these
domains to that specific resolving service as to preserve its
privacy. This information MUST be verified and validated.
filtering indicates the presence of a filtering service
Migault Expires November 30, 2020 [Page 10]
Internet-Draft DRDP May 2020
ip_subnet indicates a subnetwork restriction. This is mostly useful
for resolving services that are not globally.
dnssec indicates whether dnssec is enabled or not.
7. Resolver advertising other service sub type
A resolving service receiving a DNS request over a service sub type
MAY be willing to advertise the DNS client that other sub service
type are available. This is especially useful, when, for example, a
resolver wants that the DNS resolver switches to other service sub
types that are more secure.
In order to do so the resolver MAY provide in the additional data
field the _dns SRVCB of ServiceForm.
8. 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.
9. Security Considerations
9.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
Migault Expires November 30, 2020 [Page 11]
Internet-Draft DRDP May 2020
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.
9.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.
9.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
Migault Expires November 30, 2020 [Page 12]
Internet-Draft DRDP May 2020
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.
10. 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
Migault Expires November 30, 2020 [Page 13]
Internet-Draft DRDP May 2020
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.
11. 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 |
| ip_subnet | ip ranges accepted. |
| dnssec | DNSSEC validation enabled |
12. 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.
We thank Ben Schwartz for the comments on the list size. We thank
Harald Alvestrand for its recommendation on having a model that
enable multiple third party providers to provide their own list of
resolving domains.
13. References
13.1. Normative References
[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>.
Migault Expires November 30, 2020 [Page 14]
Internet-Draft DRDP May 2020
[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>.
[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>.
13.2. Informative References
[curl] "Publicly available servers", n.d.,
<https://github.com/curl/curl/wiki/DNS-over-
HTTPS#publicly-available-servers>.
[dnsprivacy.org]
"DNS Privacy Test Servers", n.d.,
<https://dnsprivacy.org/wiki/display/DP/
DNS+Privacy+Test+Servers#DNSPrivacyTestServers-
Publicresolvers>.
[I-D.btw-add-home]
Boucadair, M., Reddy.K, T., Wing, D., and N. Cook,
"Encrypted DNS Discovery and Deployment Considerations for
Home Networks", draft-btw-add-home-06 (work in progress),
May 2020.
[public-dns.info]
"Public DNS Server List", n.d.,
<https://public-dns.info/>.
[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>.
Migault Expires November 30, 2020 [Page 15]
Internet-Draft DRDP May 2020
Author's Address
Daniel Migault
Ericsson
8275 Trans Canada Route
Saint Laurent, QC 4S 0B6
Canada
EMail: daniel.migault@ericsson.com
Migault Expires November 30, 2020 [Page 16]