Adaptive DNS Resolver Discovery

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 21 November 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. Introduction

When clients need to resolve names into addresses in order to establish networking connections, they traditionally use by default the DNS resolver that is provisioned by the local network along with their IP address [RFC2132] [RFC8106]. Alternatively, they can use a resolver indicated by a tunneling service such as a VPN.¶

However, privacy-sensitive clients might prefer to use an encrypted DNS service other than the one locally provisioned in order to prevent interception, profiling, or modification by entities other than the operator of the name service for the name being resolved. Protocols that can improve the transport security of a client when using DNS or creating TLS connections include DNS-over-TLS (DoT) [RFC7858], DNS-over-HTTPS (DoH) [RFC8484], and Encrypted TLS Client Hellos [I-D.ietf-tls-esni].¶

This document defines a method for dynamically discovering resolvers that support encrypted transports, and introduces the concept of a designating a resolver to be used for a subset of client queries based on domain. This method is intended to work both for locally-hosted resolvers and resolvers accessible over the broader Internet.¶

2. Terminology

This document defines the following terms:¶

Direct Resolver:

A DNS resolver using any transport, encrypted or unencrypted, that is provisioned directly by a local router or a VPN.¶

Designated Resolver:

A DNS resolver that is designated as a responsible resolver for a given domain or zone. Designated resolvers use encrypted transports.¶

Companion DoH Server:

A DNS resolver that provides connectivity over HTTPS (DoH) that is designated as equivalent to querying a particular Direct Resolver.¶

3. Designated Resolvers

An encrypted DNS resolver, such as a DoH or DoT server, can be designated for use in resolving names within one or more zones. This means that clients can learn about an explicit mapping from a given domain or zone to one or more Designated Resolvers, and use that mapping to select the best resolver for a given query.¶

Designating a resolver MUST rely on mutual agreement between the entity managing a zone (the Domain Owner) and the entity operating the resolver. These entities can be one and the same, or a Domain Owner can choose to designate a third-party resolver to handle its traffic. Proof of this mutual agreement asserts to clients that sending any query to the designated resolver exposes no more information than sending that query to the entity managing the corresponding zone.¶

As an example with only one entity, a company that runs many sites within "enterprise.example.com" can provide its own DoH resolver, "doh.enterprise.example.com", and designate only that resolver for all names that fall within "enterprise.example.com". This means that no other resolver would be designated for those names, and clients would only resolve names with the same entity that would service TLS connections.¶

As an example with several entities, the organization that operates sites within "example.org" may work with two different Content Delivery Networks (CDNs) to serve its sites. It might designate names under "example.com" to two different entities, "doh.cdn-a.net" and "doh.cdn-b.net". These are CDNs that have an existing relationship with the organization that runs "example.org", and have agreements with that organization about how data with information on names and users is handled.¶

There are several methods that can be used to designate a resolver:¶

• Based on SVCB DNS records issued to another resolver (Section 3.1)¶
• Based on information from Designated DoH Resolver that is confirmed via SVCB DNS records (Section 3.2)¶
• Based on mutual agreement through confirmation of domains over HTTPS (Section 3.3)¶

Note that clients MUST NOT accept designations for effective top-level domains (eTLDs), such as ".com".¶

   foo.example.com.  7200  IN HTTPSSVC 1 example.com. (
                           dohuri=https://doh.example.net/dns-query )

   {
     "identifier": "doh.example.net.",
     "dohTemplate": "https://doh.example.net/dns-query",
     "dnsZones": ["example.com"],
     "trustedNames": ["example.com"]
   }

   {
     "identifier": "example.com.",
     "dohTemplate": "https://doh.example.net/dns-query",
   }

   {
     "identifier": "example.com.",
     "dohTemplate": "https://not-the-doh-youre-looking-for.example.net/dns-query",
   }

   {
     "identifier": "doh.example.net.",
     "dohTemplate": "https://doh.example.net/dns-query",
     "dnsZones": ["foo.example.com", "bar.example.com"],
     "trustedNames": ["example.com"]
   }

4. Explicit Discovery of Local Resolvers

If the local network provides configuration with an Explicit Provisioning Domain (PvD), as defined by [I-D.ietf-intarea-provisioning-domains], clients can learn about domains for which the local network's resolver is authoritative. The keys for DoH resolvers described in Section 3.2 also allow this local PvD to be used for resolver discovery.¶

If an RA provided by the router on the network defines an Explicit PvD that has additional information, and this additional information JSON dictionary contains the key "dohTemplate", then the client SHOULD add this DoH server to its list of known DoH configurations. The domains that the DoH server claims authority for are listed in the "dnsZones" key. Clients MUST use one of the methods for validating a designation described in Section 3.1 or Section 3.3.¶

Local deployments that want to designate a resolver for a private name that is not easily signed with DNSSEC MUST provide an alternate method of validating a designation, particularly the one described in Section 3.3.¶

5. Discovery of DoH Capabilities for Direct Resolvers

Direct Resolvers can advertise a Companion DoH server that offers equivalent services and is controlled by the same entity. To do this, a DNS server returns an SVCB record for the "resolver.arpa" domain with "ipv4hint" and/or "ipv6hint" set to a valid IP address and the "dohuri" key set to a valid DoH URI template as with the Designated DoH Server SVCB record. The TLS certificate used with the DoH URI MUST have the IP addresses for each of its DNS endpoints, classic or DoH, within the SubjectAlternativeName field to allow the client to verify ownership.¶

Once a client is configured to query a Direct Resolver, it SHOULD query the resolver for SVCB records for the "resolver.arpa" domain before making other queries. This will help the client avoid leaking queries that could go over DoH once the Companion DoH Server is discovered. If an SVCB record is returned, its "dohip" field designates an IP address the client can send DoH queries to in lieu of sending classic DNS queries to the Direct Resolver. The "dohuri" field contains the DoH URI similarly to the SVCB record for a Designated DoH Server.¶

To validate the Companion DoH Server and the resolver that advertised it are related, the client MUST check the SubjectAlternativeName field of the Companion DoH Server's TLS certificate for the original resolver's IP address and the advertised IP address for the Companion DoH server. If both are present, the discovered Companion DoH Server MUST be used whenever the original Direct Resolver would be used. Otherwise, the client SHOULD suppress queries for Companion DoH Servers against this resolver for the TTL of the negative or invalid response and continue to use the original Direct Resolver.¶

The following example shows a record containing a Companion DoH URI, as returned by a query for the HTTPSSVC variant of the SVCB record type on the "resolver.arpa" domain.¶

   resolver.arpa  7200  IN HTTPSSVC 1 doh.example.net (
                        ipv4hint=x.y.z.w
                        dohuri=https://doh.example.net/dns-query )

A DNS resolver MAY return more than one SVCB record of this form to advertise multiple Companion DoH Servers that are valid as a replacement for itself. Any or all of these servers may have the same IP address as the DNS resolver itself. In this case, clients will only have one IP address to check for when verifying ownership of the Companion DoH server.¶

6. Server Deployment Considerations

When servers designate DoH servers for their names, the specific deployment model can impact the effective privacy and performance characteristics.¶

7. Security Considerations

In order to avoid interception and modification of the information sent between clients and Designated Resolvers, all exchanges between clients and servers are performed over encrypted connections, e.g., TLS.¶

Malicious adversaries may block client connections to a Designated Resolver as a Denial-of-Service (DoS) measure. Clients which cannot connect these resolvers may be forced to, if local policy allows, fall back to unencrypted DNS if this occurs.¶

8. Privacy Considerations

Clients must be careful in determining to which DoH servers they send queries directly. A malicious resolver that can direct queries to itself can track or profile client activity. In order to avoid the possibility of a spoofed SVCB record designating a malicious DoH server for a name, clients MUST ensure that such records validate using DNSSEC (Section 3.1) or using mutual confirmation (Section 3.3).¶

Even servers that are validly designated can risk leaking or logging information about client lookups. Such risk can be mitigated by further restricting the list of resolvers that are whitelisted for direct use based on client policy.¶

An adversary able to see traffic on each path segment of a DoH query (e.g., from client to a Designated Resolver, and the Designated Resolver to an authoritative DNS server) can link queries to specific clients with high probability. Failure to observe traffic on any one of these path segments makes this linkability increasingly difficult. For example, if an adversary can only observe traffic between a client and proxy and egress traffic from a target, then it may be difficult identify a specific client's query among the recursive queries generated by the target.¶

9. IANA Considerations

10. Acknowledgments

Thanks to Erik Nygren, Lorenzo Colitti, Mikael Abrahamsson, Ben Schwartz, Ask Hansen, Leif Hedstrom, Tim McCoy, Stuart Cheshire, Miguel Vega, Joey Deng, Ted Lemon, and Elliot Briggs for their feedback and input on this document.¶

Authors' Addresses