DNS Resolver Discovery Protocol (RDP)
draft-mglt-add-rdp-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Daniel Migault | ||
| Last updated | 2020-03-09 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mglt-add-rdp-00
add D. Migault
Internet-Draft Ericsson
Intended status: Informational March 09, 2020
Expires: September 10, 2020
DNS Resolver Discovery Protocol (RDP)
draft-mglt-add-rdp-00
Abstract
This document describes the DNS Resolver Discovery Protocol (RDP)
that enables a DNS client to discover various available DNS resolving
services instantiated as resolvers. These resolvers can be local and
global. The discovery is primarily initiated by a DNS client, but a
resolver may also inform the DNS client with other resolver services.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Migault Expires September 10, 2020 [Page 1]
Internet-Draft RDP March 2020
Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. RDP Requirements . . . . . . . . . . . . . . . . . . . . . . 3
5. RDP outputs . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6
7. Domain Discovery with RDP . . . . . . . . . . . . . . . . . . 6
7.1. Global Domain . . . . . . . . . . . . . . . . . . . . . . 6
7.2. Local Domain . . . . . . . . . . . . . . . . . . . . . . 7
8. Resolvers Discovery . . . . . . . . . . . . . . . . . . . . . 7
8.1. Discovery of all service instances . . . . . . . . . . . 7
8.2. Discovery of specific service instances . . . . . . . . . 8
9. Resolver advertising other service sub type . . . . . . . . . 10
10. Migration to service sub types . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11.1. Use of protected channel is RECOMMENDED . . . . . . . . 10
11.2. DNSSEC is RECOMMENDED . . . . . . . . . . . . . . . . . 11
11.3. TLSA is RECOMMENDED . . . . . . . . . . . . . . . . . . 11
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13.1. Resources using SRV RRsets . . . . . . . . . . . . . . . 13
13.1.1. Discovery mechanism associated to one domain . . . . 13
13.1.2. File example . . . . . . . . . . . . . . . . . . . . 16
13.1.3. Resolver advertising other service sub type . . . . 16
14. Normative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described BCP 14
[RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here.
2. Introduction
A DNS client can proceed to DNS resolution using various resolution
services. These services can be instantiated by local or global
resolver using a wide range of DNS transport protocols such as, for
example, standard DNS [RFC1035], DNS over TLS[RFC7858] or DNS over
HTTPS [RFC8484].
The purpose of the DNS Resolving service Protocol (RDP) is to
discover the various resolving services available to the DNS client
so a selection process can apply. The information returned by RDP
Migault Expires September 10, 2020 [Page 2]
Internet-Draft RDP March 2020
typically includes information related to the IP addresses, the
transport protocols, the TLS parameters or the HTTP version. How the
selection is performed is out of scope of this document.
This document considers the resolver as a DNS resolving service noted
rdns. The motivation for creating a new service is that "domain" is
associated to port 53 as well as TCP and UDP and designates both the
authoritative as well as the resoling service. On the other hand the
service "rdns" is expected to be limited to the DNS resolution
service that can have various transport flavors including using
different ports.
3. Terminology
DNS client the client that sends DNS queries fro resolution. In
this document the DNS client designates also the end entity that
is collecting information about the available Resolving Services
and then proceed to the selection of a subset them. The selection
is processed according to the DNS client's policy.
Resolving Service designates a service that receives DNS queries
from a DNS client and resolves them. Resolving services can be
instantiated in various ways, with different resolvers and
different DNS transport for example. This document use rdn to
designate all instances of resolving services within a domain.
This document also use dns, dot and doh to designates the subset
of instances to respectively implement DNS, DoT and DoH.
Resolving Service Instance represents one way to implement the
Resolving Service and terminate the DNS session with the DNS
client. The resolving service instance is also designated as the
resolver.
DNS transport designates the necessary parameters a DNS client needs
to establish a session with a Resolving Service.
rdns domain a DNS domain that hosts resolving services.
4. RDP Requirements
This section lists the RDP requirements.
REQ 1: RDP MUST be able to list resolving services that are available
to the DNS client. The resolving services can be available globally
or locally and listing MUST be performed dynamically.
The necessary inputs for the resolving service instances may be of
various form. Not all of them are expected to be in the scope of RDP
Migault Expires September 10, 2020 [Page 3]
Internet-Draft RDP March 2020
and RDP limits its scope to parameters that are inherent to the
resolving service instance.
For example, an end user may simply willing to know which DNS
resolver provides the fastest resolution. Such inputs are not
inherent to a specific resolver and are out of scope of RDP.
Another example could be the activation of some services such as
parental protection for example. While such parameter could
potentially be gather toward RDP, discussion are left for future
extensions of RDP, and the current proposal limits its scope on DNS
transport parameters.
REQ 2: RDP MUST be able to return DNS transport parameters associated
to each resolving service instance. RDP MAY be extended in the
future to return additional parameter.
The selection of the resolving service instances MAY take various
form between fully automated to fully manual. This, in particularly
includes interaction with the end user on a subset of the selection
parameters as well as the ability for a resolving service operator to
indicate a preference toward a resolving service instance.
REQ 3: RDP MUST return the parameters used for the selection in a
standard format without room for interpretation to ease automation of
the resolver instance selection.
REQ 4: RDP MUST consider that selection MAY involve interaction from
the end user, and as such provide the ability that user friendly
information MAY be displayed.
REQ 4: RDP MUST provide means from a resolving service to indicate a
preference among the available resolving service instances.
The resolving service instances selection process MAY be performed
over a subset of the available instances. In that case, collecting
parameters of resolving service instances that are known not to match
the policy is useless.
REQ 5: RDP SHOULD be able to narrow narrow down the discovery to a
subset of resolving service instances matching certain criteria.
DNS is the common denominator among the envisioned resolving service
instances.
REQ 6: RDP MUST be based on DNS messages.
Migault Expires September 10, 2020 [Page 4]
Internet-Draft RDP March 2020
Information provided by RDP will be used for a selection and as such
the collected information needs to be reliable.
REQ: RDP MUST provide authenticated information
Finally,
REQ: RDP MUST be deployed without affecting legacy DNS client or
infrastructure.
5. RDP outputs
The identity of the resolving service instance (or resolver)
represents an important parameter. The choice of a resolver
generally reflects the trust the end user which can hardly be
inferred automatically and is likely to require an interaction with
the end user, unless explicitly provided by the end user.
This document considers the resolver's FQDN resolver.example.com as
its identifier. example.com designates the rdns domain and resolver
represents hostname.
a) The rdns domain is expected to be the part that will mostly be
used by the end user as a way to select trust as these are expected
to represent the brand or legal entity of the institution the end
user sends its data to. The rdns domain follows some DNS encoding
rules and as such may not be believed to be so user friendly.
Typically, the rdns domain might be ericsson.com or ericsson which is
different from Ericsson (with appropriated police character and
color) which is probably what would be more meaningful for the end
user. On the other hand, the end user may also be familiar with that
format and the use or a standardize format helps automation in the
selection. As a result, this document will assume that the rdns
domain will reflect the legal entity administrating the resolver to
the user. Note that a user interface may also use the rdns domain to
derive more user friendly and additional specific information that
will be presented to the user. This could include for example
additional RDAP queries, favicons of web sites that are shown to the
end users. What is presented to the end user is out of scope of this
document, but the rdns domain can be used as the key.
b) The hostname part is only meaningful within the rdns domain.
While, it may carry some information that may be interpreted to the
end user, the constraint provided by the DNS format may be too
restricting. As a result, it is expected that a more user friendly
string might be associated with the hostname and that the hostname
remain reserved for networking administrators.
Migault Expires September 10, 2020 [Page 5]
Internet-Draft RDP March 2020
Parameters associated to the DNS transport are the type of transport
that is DNS, DoT or DoH as well as the necessary parameters to
establish the session. This may include specific TLS parameters for
DoT and DoH as well as specific HTTP versions for DoH. These
parameters are expected to be identified in a standard way.
6. Architecture Overview
DNS based Service Discovery (DNS-SD) [RFC6763] is a discovery
protocol for services based on DNS messages. DNS-SD provides the
ability to display user-friendly names in UTF-8 and uses a
combination of DNS RRsets of type PTR, SRV and TXT. The current
document is largely inspired from this long time and already existing
protocol. However, RDP differs from DNS SD in that DNS-SD discovers
services within a specific domain (such as .local or .home.arpa for
example) while RDP needs to discover the rdns domain as well as the
resolving services (i.e. resolvers) associated to this domain. In
addition, RDP is taking advantage of the latests development of SRVCB
RRsets [I-D.ietf-dnsop-svcb-httpssvc] which, among other things,
enables to combine the SRV and TXT Rsets. While nothing prevents RDP
to use SRV and TXT RRsets, RDP uses instead SVCB RRset as web browser
are more likely to implement SVBC. The use of SRV is provided in the
annex in case SVBC does not become standard or that the WG decides to
use SRV RRsets instead. The status of these annex are purely a
documentation and will be removed from teh final version. In any
case, while DNS SD and RDP presents some strong similarities, it is
not expect they are compatible.
The overall procedure is performed as described below: 1. Discovery
of the global and local available rdns domains 2. Discovery of the
resolvers among each rdns domain.
7. Domain Discovery with RDP
7.1. Global Domain
The mechanism involves the creation of a special domain name
rdns.arpa that will list the various rdns domains. This mechanism
remains valid as long as the list of rdns domain name remains
relatively limited. The number of rdns domain that can fit into a
payload will depend on the length of the rnds domain, so rdns domains
are expected to have limited length. However the compactness is not
expected to match the one achieved for the root servers that are
designated by a one character size identity. The reason for it is
that the identity of the resolver is expected to carry some meaning
to the DNS client as opposed to the root servers.
Migault Expires September 10, 2020 [Page 6]
Internet-Draft RDP March 2020
That said, a UDP packet of 4096 bytes is expected to contain a
significant amount of resolvers. The number of open resolver is not
expected to reach that limit and if so the list can be retrieved
through TCP.
The zone file below is inspired from DNS-SD where b indicates a
browsing domain, _rdns indicates the DNS resolving service and
rdns.arpa. indicates the special domain. rdns domain_0, rnds_domain_n
indicates the various rdns domains. The order of the rdns domain is
irrelevant, and the zone administrator SHOULD regularly reorder them.
The RRsets MUST be signed with DNSSEC.
b._rdns.rdns.arpa PTR <rdns_domain_0>
[...]
b._rdns.rdns.arpa PTR <rdns_domain_n>
7.2. Local Domain
An application such as an web browser has a DNS client that MAY be
configured by the application vendor or the end user with an IP
address. Note that the IP address MAY be provided by the system as
well. Similarly, a non negligible part of the systems the resolver
is automatically provided by the network via the DNS Recursive Name
Server option [RFC3646] and designated by an IP address. In such
cases, there is a need to derive the domain associated to that domain
name.
In any of these cases, the IP address is used as a local input to
proceed to a resolving service instances discovery and eventually
select a more appropriated resolving service instance according to
the end user policy. The rdns domain will be derived from the IP
address by:
1. performing a reverse resolution
2. derive the rdns domain assuming the resulting FQDN is composed of
a hostname and the rdns domain. For example, if
resolver.example.com is the resulting FQDN from the reverse
resolution, then the rdns domain will be example.com.
8. Resolvers Discovery
8.1. Discovery of all service instances
Given a rdns domain example.com, a DNS client MAY request all
possible resolving service instances with a query of type SVCB with
the service _rdns.
Migault Expires September 10, 2020 [Page 7]
Internet-Draft RDP March 2020
The example below presents the use of an AliasForm followed by a
ServiceForm which allows an indirection. The Alias form is not
madatory and instead only ServiceForm associated to _rdn.example.com
could have been used instead.
The SvcFieldPriority indicates the preference of the resolving
service instance.
The SvcParamKey alpn MUST be present when TLS is used as its presence
and value indicates the DNS transport. The abscenec of the alpn
SvcParamKey indicates that DNS is served, alpn set to dot indicates
DoT is served while h* indicates DoH is served.
The SvcParamField ux is optional is provides an UTF-8 string that is
expected to be displayed to the end user if needed.
The RRsets MUST be protected with DNSSEC and when alpn is provided a
TLSA RRset MUST be present.
8.2. Discovery of specific service instances
In order to reduce the size of the messages, the DNS client MAY also
prefer to query information of resolvers using a specific transport
(DNS, DoT, DoH) that are designated as sub sets. A DNS client MAY
list the the different subsets of that rdns domain with a PTR query.
In our case the subsets are defined as _dns for DNS, _dot for DoT and
_doh for DoH. All subsets MUST share the same rdns domain.
This redirection with a PTR RRset is mandatory to be specified in the
rdns domain, but the DNS client MAY directly query the subsets if it
has a previous knowledge of these subsets.
The currently defined subsets MAY be extended in the future.
One the DNS client is aware of the available subsets, it MAY select
one or more subsets and proceed to the SRVCB resolution.
The same restriction as defined in section Section 8.1 apply.
Note that while the SvcFieldPriority indicates the priority within a
subservice, this field MUST have a coherence across subservices. The
priority provided SHOULD be coherent with the case of a _rnds SRVCB
query of section Section 8.1.
The figure below illustrates an example of zone file. RRSIG and TLSA
have been omited for the purpose of clarity.
Migault Expires September 10, 2020 [Page 8]
Internet-Draft RDP March 2020
## Discovery of all service instances
_rdns.example.com. 7200 IN SVCB 0 svc.example.com.
svc.example.com. 7200 IN SVCB 12 ( svc0.example.net.
port="53" ux="Legacy Resolver" )
svc.example.com. 7200 IN SVCB 1 ( svc1.example.net. alpn="dot"
port="53" esniconfig="..."
ux="Preferred Example's Choice" )
svc.example.com. 7200 IN SVCB 3 ( svc2.example.net. alpn="h2"
port="53" esniconfig="..." ux= )
svc.example.com. 7200 IN SVCB 2 ( svc3.example.net. alpn="h3"
## Discovery of specific service instances
### Definition of the resolving service subsets
_rdns.example.com PTR _domain.example.com
_rdns.example.com PTR _dot.example.com
_rdns.example.com PTR _doh.example.com
### services instances per service subset
_domain.example.com. 7200 IN SVCB 0 svc0.example.com.
svc0.example.com. 7200 IN SVCB 12 ( svc0.example.net.
port="53" ux="Legacy Resolver" )
_dot.example.com. 7200 IN SVCB 0 svc1.example.com.
svc1.example.com. 7200 IN SVCB 1 ( svc1.example.net. alpn="dot"
port="53" esniconfig="..."
ux="Preferred Example's Choice" )
_doh.example.com. 7200 IN SVCB 0 svc4.example.net.
svc4.example.com. 7200 IN SVCB 3 ( svc2.example.net. alpn="h2"
port="53" esniconfig="..." ux= )
svc4.example.com. 7200 IN SVCB 2 ( svc3.example.net. alpn="h3"
port="443" esniconfig="..."
ux="Testing QUIC")
Some notes:
1. SVCB requires to mention the port. SVCB is a work in progress
and we would like the port to be removed as port is not always
mentioned in the scheme. That said, mentionnig a non necessary
port could be feasible.
2. _domain uses SVCB but does not have TLS. While SVCB has been
created essentially for TLS based service, this does not appear
to be mandatory.
3. _dot and _doh are seen as services even if doh is using HTTPS.
Migault Expires September 10, 2020 [Page 9]
Internet-Draft RDP March 2020
4. Should we have some constraints regarding the SvcDomainName ?
9. Resolver advertising other service sub type
A resolver receiving a DNS request over a service sub type MAY be
willing to advertise the DNS client that other sub service type are
available. This is especially useful, when, for example, a resolver
wants that the DNS resolver switches to other service sub types that
are more secure.
In order to do so the resolver MAY provide in the additional data
field the _rdns SRVCB of ServiceForm.
10. Migration to service sub types
The principle of the discovery mechanism is that the resolver
indicates the available service sub types and let the DNS client
chose which sub type it prefers. On the other hand, the resolver MAY
also indicate a preference using the priority and weight fields
however, there is no mechanisms that could permit an indirection from
one service sub type to another service sub type. Redirection MAY
especially be needed when a DNS client is using the dns53 sub type
and the resolver would liek to upgrade the DNS client session to a
more secure session. The MAY require a specific ERROR code that will
request the DNS client to perform service discovery.
It is expected that domain sub service MUST always be provided to
perform resolver discovery. In other words, resolver discovery MUST
be available though the non confidential channels designated by the
sub service type dns53. However, this does not mean that a resolver
is expected to implement the dns53 sub type service for resolutions.
The availability of the sub service types for resolution. If a
resolver chose not to provide the dns53 sub service type, that
service MUST NOT be pointed by the _domain.example.com search.
11. Security Considerations
11.1. Use of protected channel is RECOMMENDED
When available, it is recommended to chose a protected version of the
rdns service. More specifically, the use of end-to-end protection
ensures that the DNS client is connected to the expected platform and
that its traffic cannot be intercepted on path. Typically, the
selection of resolver on the Internet (and not on your ISP network)
and the use of a non protected channel enables an attacker to monitor
your DNS traffic. The similar observation remains true if you are
connected to the resolver of your ISP. It is commonly believed that
trusting your ISP (that is your first hop) makes encryption
Migault Expires September 10, 2020 [Page 10]
Internet-Draft RDP March 2020
unecessary. Trusting your ISP is mandatory in any case, but the
associated level of trust with an protected channel is restricted to
the operation of the DNS platform. With non protected channel the
trust is extended to any segment between the DNS client and the
resolver, which is consequently larger. The use of a protected
channel is recommended as it will prevent anyone on path to monitor
your traffic.
11.2. DNSSEC is RECOMMENDED
The exchanges SHOULD be protected with DNSSEC to ensure integrity of
the information between the authoritative servers and the DNS client.
Without DNSSEC protection, DNS messages may be tampered typically
when they are transmitted over an unprotected channel either between
the DNS client and the resolver or between the resolver and the
authoritative servers. The messages may be tampered by an online
attacker intercepting the messages or by the intermediary devices.
It is important to realize that protection provided by TLS is limited
to the channel between the DNS client and the resolver. There are a
number of cases were the trust in the resolver is not sufficient
which justify the generalization of the use of DNSSEC. The following
examples are illustrative and are intended to be exhaustive.
First, the discovery exchanges may happen over an unprotected
channel, in which case, the messages exchanged may be tampered by
anyone on-path between the DNS client and the resolver as well as
between the resolver and the authoritative servers - including the
resolver. When TLS is used between the DNS client and the resolver,
this does not necessarily mean the DNS client trusts the resolver.
Typically, the TLS session may be established with a self-signed
certificate in which case the session is basically protected by a
proof-of-ownership. In other cases, the session may be established
based on Certificate Authorities (CA) that have been configured into
the TLS client, but that are not necessarily trusted by the DNS
client. In such cases, the connected resolver may be used to
discover resolvers from another domain. In this case, the resolver
is probably interacting with authoritative servers using untrusted
and unprotected channels. Integrity protection relies on DNSSEC.
11.3. TLSA is RECOMMENDED
When TLS is used to protect the DNS exchanges, certificates or
fingerprint SHOULD be provided to implement trust into the
communication between the DNS client and the resolver. The TLS
session and the association of the private key to a specific identity
can be based on two different trust model. The Web PKI that will
rely on CA provisioned in the TLS library or the TA provided to the
Migault Expires September 10, 2020 [Page 11]
Internet-Draft RDP March 2020
DNS client. A DNS client SHOULD be able to validate the trust of a
TLS session based on the DNSSEC trust model using DANE.
When the DNS client is protecting its session to the resolver via
TLS, the DNS client may initiate an TLS session that is not validated
by a CA or a TLSA RRsets. The DNS client MUST proceed to the
discovery process and validate the certificate match the TLSA RRset.
In case of mismatch the DNS client MUST abort the session.
12. Privacy Considerations
When the discovery protocol is performed using a resolver that
belongs to one domain for another domain, or over an unprotected
channel, the DNS client must be conscious that its is revealing to
the resolver its intention to use another resolver. More
specifically, suppose an resolver is complying some legal
requirements that DNS traffic must be unencrypted. Using this
resolver to perform a resolver discovery reveals the intention of
potentially using alternative resolvers. Alternatively, narrowing
down the discovery over a specific sub type of resolver (DoT, or DoH)
may reveal to that resolver the type of communication. As result,
when performing a discovery over a domain that differs to the domain
the resolver belongs to, it is RECOMMENDED to request the SRV RRsets
associated to all different sub type of proposed services.
The absence of traffic that results from switching completely to a
newly discovered resolver right after the discovery process provides
an indication to the resolver the DNS client is switching to. It is
hard to make that switch unnoticed to the initial resolver and the
DNS resolver MUST assume this will be noticed. The information of
switching may be limited by sharing the traffic between different
resolvers, however, the traffic pattern associated to each resolver
may also reveal the switch. In addition, when the initial resolver
is provided by the ISP, the ISP is also able to monitor the IP
traffic and infer the switch. As a result, the DNS client SHOULD
assume the switch will be detected.
With DoT or DoH, the selection of port 443 will make the traffic
indistinguishable from HTTPS traffic. This means that an observer
will not be able to tell whether the traffic carries web traffic or
DNS traffic. Note that it presents an interest if the server offers
both a web service as well as a resolution service. Note that many
resolvers have a dedicated IP address for the resolution service, in
which case, the information will be inferred from the IP address.
Note also that traffic analysis may infer this as well. Typically
suppose an IP address hosts one or multiple web sites that are not
popular as well as a resolving service. If this IP address is
associated frequent short size exchanges, it is likely that these
Migault Expires September 10, 2020 [Page 12]
Internet-Draft RDP March 2020
exchanges will be DNS exchanges rather than Web traffic. The size of
the packet may also be used as well as many other patterns. As a
result, the use port 443 to hide the DNS traffic over web traffic
should be considered as providing limited privacy.
13. IANA Considerations
This document requests the IANA the creation of a new service name in
the Service Name and Transport Protocol Port Number Registry
https://www.iana.org/assignments/service-names-port-numbers/service-
names-port-numbers.xml
Fields Port Number, Transport Protocol, Assignee, Contact,
Modification Date, Service Unauthorized Use Report, Assignment Notes
are void.
Service | Description | Registration | Reference
Name | | Date |
--------+----------------+--------------+-----------
rdns | DNS resolution | TBD1 | RFC-TBD
This document requests the IANA the creation of the following
underscored node names in the Underscored and Globally Scoped DNS
Node Names registry https://www.iana.org/assignments/dns-parameters/
dns-parameters.xhtml#dns-parameters-14
RR Type | _NODE NAME | Reference
--------+------------+----------
SRVCB | _rdns | RFC-TBD
SRVCB | _dot | RFC-TBD
SRVCB | _doh | RFC-TBD
SRVCB | _dns | RFC-TBD
SvcParamKey | NAME | Meaning | Reference
------------+--------------+-----------------------------+-----------
7 | user-display | User friendly string (UTF8) | RFC-TBD
| | to represent the resolver |
# Appendix
13.1. Resources using SRV RRsets
13.1.1. Discovery mechanism associated to one domain
The discovery mechanism is intended to enable a DNS client to
discover what are the resolvers options available as well as how to
further use these resolvers.
Migault Expires September 10, 2020 [Page 13]
Internet-Draft RDP March 2020
The procedure is based on service discovery [RFC8145] and the overall
procedure consists in finding various instances of the service
"rdns". The resolution service is designated as "rdns" and differs
from the service "domain" defined by IANA.
In this document, the service "rdns" is associated to a domain such
as example.com. This means that the discovery process is performed
over a specific portion of the internet, and resolvers that have no
relation to that domain are not expected to be found. It is expected
that the domain may be provisioned as a configuration parameter in
the DNS client. It is expected that the domain provides a good
meaning of the administrative entity managing the resolver, as it
reflects the trust/mistrust the end user puts in the resolution.
This configuration parameters differs from the one that is currently
provisioned and discussion on how to proceed to resolver discovery
from a legacy provisioning is described in more details in
Section 7.2.
The DNS client then searches for the rdns service associated to the
domain example.com by querying PTR RRsets associated to
_rdns_udp.example.com. This query corresponds to the general case of
DNS service discovery. While tcp is reserved for TCP only and DNS is
not only running on top of TCP we use _udp as a representation of
_srv.
The difference with service discovery is that the response is
expected to return instances of the service type. These instances
may offer completely different services, but the end user is expected
to select them according to their human readable name. In our case,
the rdns service type can be implemented into different sub services
types that are in our cases (DOT, DOH DNS). DOT, DOH and DNS are
only example and any other designation may have been provided.
Possible ways to distinguish these services could have been to adopt
a convention in the service instance names or to have standard value
for the service names. We prefer not to take that path and remove
any constraints on the service name as it usually appears to the end
user and we want to leave it free to contain what is going to be
meaningful for the end user. Typically, DOT, DOH or DNS are unlikely
to be meaningful to the waste majority of the internet users.
Instead we used the DNS-SD capabilities to specify sub services by
prefixing with _dot, _doh and _dns53 the dns._udp service type.
Migault Expires September 10, 2020 [Page 14]
Internet-Draft RDP March 2020
DNS client --> Resolver
_rdns.example.com PTR ?
<--
_rdns_udp.example.com PTR DOT._dot._sub._rdns._udp.example.com
_rdns_udp.example.com PTR DOH._doh_sub._rdns._udp.example.com
_rdns_udp.example.com PTR DNS._dns53_sub._rdns._udp.example.com
Note that "DOT", "DOH" and "DNS" are the strings that may be shown to
the end user. The main difference with DNS-SD is that the sub type
was initially designed so the end user can narrow down its search.
More explicitly its purpose was to enable an end user to narrow down
the search on services providing DNS resolution over HTTPS with
_doh._sub._rdns._udp.example.com. The purpose was not to split a
generic service into multiple sub types of services.
Note that the user interface is expected to interpret and present to
the end user the different services by interpreting the _dot, _doh or
_dns53 sub service types and easing the understanding of the end
user. If the DNS client is implementing a specific configuration, it
will also have to interprete the sub types according to the
configuration of the end user.
Now that the end user has the various services available ("DOH",
"DOT" and "DNS") with there associated types, the selection can
occur, and the DNS client can request additional information about
the service itself to set up a session with the chosen service. In
our case this is mostly the host name, ports, the ip address, the
certificates, .... If the DNS client choses to use DoH, for example,
it will request the SRV RRsets associated to that service.
Note that in our case, the sub service type carries sufficient
information and no additional information is needed. There is no
need to request the TXT reccord. Note also that carrying the sub
type into the TXT RRsets would not be appropriated as this is believe
to be a sufficiently important information to prevent a DNS client to
browse thought all the different service instances.
While the TXT RRset is not necessary now, it MAY contain additional
information that may be usefull to the DNS client as well.
It is expected these exchanges are protected with DNSSEC as these
could be performed over an untrusted channel as well as through semi
trusted resolver. The additional section SHOULD also carry the
necessary information to set up the session between the DNS client
and the resolver. This includes the IP addresses (A and AAAA)
Migault Expires September 10, 2020 [Page 15]
Internet-Draft RDP March 2020
RRsets, for services implemented over TLS the necessary security
credentials (TLSA RRsets).
DNS client --> Resolver
DOH._doh_sub._rdns._udp.example.com SRV ?
<--
DOH._doh_sub_rdns.example.com SRV priority=0, weight=0,
port=443 host=resolver.example.com
DOH._doh_sub_rdns.example.com SRV priority=0, weight=1,
port=443 host=resolver.example.com
DOH._doh_sub_rdns.example.com RRSIG (SRV) <signature>
resolver.example.com AAAA <ip6_address>
resolver.example.com AAAA <ip6_address>
resolver.example.com RRSIG (A) <signature>
resolver.example.com TLSA <certificate>
resolver.example.com RRSIG (TLSA) <signature>
13.1.2. File example
Example of a file.
_rdns_udp.example.com PTR DOT._dot._sub._rdns._udp.example.com
_rdns_udp.example.com PTR DOH._doh_sub._rdns._udp.example.com
_rdns_udp.example.com PTR DNS._dns53_sub._rdns._udp.example.com
_dot_sub_rdns.example.com PTR DOT._dot_sub_rdns._udp.example.com
_doh_sub_rdns.example.com PTR DOH._doh_sub_rdns._udp.example.com
_dns53_sub_rdns.example.com PTR DNS._dns53_sub_rdns._udp.example.com
DOT._dot_sub_rdns.example.com SRV port=443 host=dns.example.com
DOT._dot_sub_rdns.example.com SRV port=53 host=dns.example.com
DOH._dot_sub_rdns.example.com SRV port=443 host=dns-dot.example.com
DNS._dns53_sub_rdns.example.com SRV port=53 host=dns53.example.com
dns.example.com AAAA
dns.example.com TLSA
dns.example.com RRSIG
dns53.example.com AAAA
dns53.example.com RRSIG
13.1.3. Resolver advertising other service sub type
A resolver receiving a DNS request over a service sub type MAY be
willing to advertise the DNS client that other sub service type are
available. This is especially useful, when, for example, a resolver
wants that the DNS resolver switches to other service sub types that
are more secure.
Migault Expires September 10, 2020 [Page 16]
Internet-Draft RDP March 2020
In order to do so the resolver MAY provide in the additional data
field the appropriated SRV RRsets. As an example, if the resolver
wants to advertise the existence of resolver using dot or doh sub
service type, the resolver would add the following RRsets.
Additional RRSets such as A, AAAA or TLSA RRSets MAY also be added.
DOH._doh._sub_rdns.example.com SRV priority=0, weight=0,
port=443 host=resolver.example.com
DOH._doh._sub_rdns.example.com SRV priority=0, weight=1,
port=443 host=resolver.example.com
DOH._doh._sub_rdns.example.com RRSIG (SRV) <signature>
DOT._dot._sub_rdns.example.com SRV priority=0, weight=0,
port=443 host=resolver.example.com
DOT._dot._sub_rdns.example.com SRV priority=0, weight=1,
port=443 host=resolver.example.com
DOT._dot._sub_rdns.example.com RRSIG (SRV) <signature>
14. Normative References
[I-D.ietf-dnsop-svcb-httpssvc]
Schwartz, B., Bishop, M., and E. Nygren, "Service binding
and parameter specification via the DNS (DNS SVCB and
HTTPSSVC)", draft-ietf-dnsop-svcb-httpssvc-01 (work in
progress), November 2019.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
DOI 10.17487/RFC3646, December 2003,
<https://www.rfc-editor.org/info/rfc3646>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <https://www.rfc-editor.org/info/rfc7858>.
Migault Expires September 10, 2020 [Page 17]
Internet-Draft RDP March 2020
[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust
Anchor Knowledge in DNS Security Extensions (DNSSEC)",
RFC 8145, DOI 10.17487/RFC8145, April 2017,
<https://www.rfc-editor.org/info/rfc8145>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS
(DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
<https://www.rfc-editor.org/info/rfc8484>.
Author's Address
Daniel Migault
Ericsson
8275 Trans Canada Route
Saint Laurent, QC 4S 0B6
Canada
EMail: daniel.migault@ericsson.com
Migault Expires September 10, 2020 [Page 18]