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.


Table of Contents

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

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.

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.

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.

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.

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

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.

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

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)", Internet-Draft draft-ietf-dnsop-svcb-httpssvc-01, November 2019.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, DOI 10.17487/RFC3646, December 2003.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013.
[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.
[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.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
[RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018.

Author's Address

Daniel Migault Ericsson 8275 Trans Canada Route Saint Laurent, QC, 4S 0B6 Canada EMail: daniel.migault@ericsson.com