Internet DRAFT - draft-pauly-dprive-adaptive-dns-privacy
draft-pauly-dprive-adaptive-dns-privacy
Network Working Group E. Kinnear
Internet-Draft T. Pauly
Intended status: Standards Track C. Wood
Expires: May 4, 2020 Apple Inc.
P. McManus
Fastly
November 01, 2019
Adaptive DNS: Improving Privacy of Name Resolution
draft-pauly-dprive-adaptive-dns-privacy-01
Abstract
This document defines an architecture that allows clients to
dynamically discover designated resolvers that offer encrypted DNS
services, and use them in an adaptive way that improves privacy while
co-existing with locally provisioned resolvers. These resolvers can
be used directly when looking up names for which they are designated.
These resolvers also provide the ability to proxy encrypted queries,
thus hiding the identity of the client requesting resolution.
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 May 4, 2020.
Copyright Notice
Copyright (c) 2019 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
Kinnear, et al. Expires May 4, 2020 [Page 1]
Internet-Draft ADNS Privacy November 2019
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Discovering Designated DoH Servers . . . . . . . . . . . 6
3.1.1. Whitelisting Designated DoH Servers . . . . . . . . . 7
3.1.2. Accessing Extended Information . . . . . . . . . . . 8
3.2. Discovering Local Resolvers . . . . . . . . . . . . . . . 9
3.3. Hostname Resolution Algorithm . . . . . . . . . . . . . . 10
3.4. Oblivious Resolution . . . . . . . . . . . . . . . . . . 11
3.5. Handling Network Changes . . . . . . . . . . . . . . . . 12
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 12
4.1. Provide a DoH Server . . . . . . . . . . . . . . . . . . 12
4.1.1. Oblivious DoH Proxy . . . . . . . . . . . . . . . . . 12
4.1.2. Oblivious DoH Target . . . . . . . . . . . . . . . . 13
4.1.3. Keying Material . . . . . . . . . . . . . . . . . . . 13
4.2. Advertise the DoH Server . . . . . . . . . . . . . . . . 13
4.3. Provide Extended Configuration as a Web PvD . . . . . . . 13
5. Server Deployment Considerations . . . . . . . . . . . . . . 15
5.1. Single Content Provider . . . . . . . . . . . . . . . . . 15
5.2. Multiple Content Providers . . . . . . . . . . . . . . . 15
5.3. Avoid Narrow Deployments . . . . . . . . . . . . . . . . 16
6. Local Resolver Deployment Considerations . . . . . . . . . . 16
6.1. Designating Local DoH Servers . . . . . . . . . . . . . . 16
6.2. Local Use Cases . . . . . . . . . . . . . . . . . . . . . 17
6.2.1. Accessing Local-Only Resolvable Content . . . . . . . 17
6.2.2. Accessing Locally Optimized Content . . . . . . . . . 18
6.2.3. Walled-Garden and Captive Network Deployments . . . . 19
6.2.4. Network-Based Filtering . . . . . . . . . . . . . . . 19
7. Performance Considerations . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10.1. DoH Template PvD Key . . . . . . . . . . . . . . . . . . 22
10.2. DNS Filtering PvD Keys . . . . . . . . . . . . . . . . . 22
10.3. DoH URI Template DNS Parameter . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . 24
Kinnear, et al. Expires May 4, 2020 [Page 2]
Internet-Draft ADNS Privacy November 2019
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 [RFC7858],
DNS-over-HTTPS [RFC8484], and encrypted Server Name Indication (ESNI)
[I-D.ietf-tls-esni].
There are several concerns around a client using such privacy-
enhancing mechanisms for generic system traffic. A remote service
that provides encrypted DNS may not provide correct answers for
locally available resources, or private resources (such as domains
only accessible over a private network). Remote services may also be
untrusted from a privacy perspective: while encryption will prevent
on-path observers from seeing hostnames, client systems need to trust
the encrypted DNS service to not store or misuse queries made to it.
Further, extensive use of cloud based recursive resolvers obscures
the network location of the client which may degrade the performance
of the returned server due to lack of proximity at the benefit of
improved privacy.
Client systems are left with choosing between one of the following
stances:
1. Send all application DNS queries to a particular encrypted DNS
service, which requires establishing user trust of the service.
This can lead to resolution failures for local or private
enterprise domains absent heuristics or other workarounds for
detecting managed networks.
2. Allow the user or another entity to configure local policy for
which domains to send to local, private, or encrypted resolvers.
This provides more granularity at the cost of increasing user
burden.
3. Only use locally-provisioned resolvers, and opportunistically use
encrypted DNS to these resolvers when possible. (Clients may
Kinnear, et al. Expires May 4, 2020 [Page 3]
Internet-Draft ADNS Privacy November 2019
learn of encrypted transport support by actively probing such
resolvers.) This provides marginal benefit over not using
encrypted DNS at all, especially if clients have no means of
authenticating or trusting local resolvers.
This document defines an architecture that allows clients to improve
the privacy of their DNS queries without requiring user intervention,
and allowing coexistence with local, private, and enterprise
resolvers.
This architecture is composed of several mechanisms:
o A DNS record that indicates a designated DoH server associated
with a name (Section 3.1);
o an extension to DoH that allows client IP addresses to be
disassociated from queries via proxying
([I-D.pauly-dprive-oblivious-doh]);
o a DoH server that responds to queries directly and supports
proxying (Section 4);
o and client behavior rules for how to resolve names using a
combination of designated DoH resolvers, proxied queries, and
local resolvers (Section 3).
1.1. Specification of Requirements
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. Terminology
This document defines the following terms:
Adaptive DNS: Adaptive DNS is a technique to provide an encrypted
transport for DNS queries that can be sent directly to a
Designated DoH Server, to use Oblivious DoH to hide the client IP
address, or to use Direct Resolvers when required or appropriate.
Designated DoH Server: A DNS resolver that provides connectivity
over HTTPS (DoH) that is designated as a responsible resolver for
a given domain or zone.
Kinnear, et al. Expires May 4, 2020 [Page 4]
Internet-Draft ADNS Privacy November 2019
Direct Resolver: A DNS resolver using any transport that is
provisioned directly by a local router or a VPN.
Exclusive Direct Resolver: A Direct Resolver that requires the
client to use it exclusively for a given set of domains, such as
private domains managed by a VPN. This status is governed by
local system policy.
Oblivious DoH: A technique that uses multiple DoH servers to proxy
queries in a way that disassociates the client's IP address from
query content.
Oblivious Proxy: A resolution server that proxies encrypted client
DNS queries to another resolution server that will be able to
decrypt the query (the Oblivious Target).
Oblivious Target: A resolution server that receives encrypted client
DNS queries via an Oblivious Proxy.
Privacy-Sensitive Connections: Connections made by clients that are
explicitly Privacy-Sensitive are treated differently from
connections made for generic system behavior, such as non-user-
initiated maintenance connections. This distinction is only
relevant on the client, and does not get communicated to other
network entities. Certain applications, such as browsers, can
choose to treat all connections as privacy-sensitive.
Web PvD: A Web Provisioning Domain, or Web PvD, represents the
configuration of resolvers, proxies, and other information that a
server deployment makes available to clients. See Section 4.3.
3. Client Behavior
Adaptive DNS allows client systems and applications to improve the
privacy of their DNS queries and connections, both by requiring
confidentiality via encryption, and by limiting the ability to
correlate client IP addresses with query contents. Specifically, the
goal for client queries is to achieve the following properties:
1. No party other than the client and server can learn or control
the names being queried by the client or the answers being
returned by the server.
2. Only a designated DNS resolver associated with the deployment
that is also hosting content will be able to read both the client
IP address and queried names for Privacy-Sensitive Connections.
For example, a resolver owned and operated by the same provider
that hosts "example.com" would be able to link queries for
Kinnear, et al. Expires May 4, 2020 [Page 5]
Internet-Draft ADNS Privacy November 2019
"example.com" to specific clients (by their IP address), since
the server ultimately has this capability once clients
subsequently establish secure (e.g., TLS) connections to an
address to which "example.com" resolves.
3. Clients will be able to comply with policies required by VPNs and
local networks that are authoritative for private domains.
An algorithm for determining how to resolve a given name in a manner
that satisfies these properties is described in Section 3.3. Note
that this algorithm does not guarantee that responses that are not
signed with DNSSEC are valid, and clients that establish connections
to unsigned addresses may still expose their local IP addresses to
attackers that control their terminal resolver even if hidden during
resolution.
3.1. Discovering Designated DoH Servers
All direct (non-oblivious) queries for names in privacy-sensitive
connections MUST be sent to a server that both provides encryption
and is designated for the domain.
Clients dynamically build and maintain a set of known Designated DoH
Servers. The information that is associated with each server is:
o The URI Template of the DoH server [RFC8484]
o The public HPKE [I-D.irtf-cfrg-hpke] key of the DoH server used
for proxied oblivious queries [I-D.pauly-dprive-oblivious-doh]
o A list of domains for which the DoH server is designated
This information can be retrieved from several different sources.
The primary source for discovering Designated DoH Server
configurations is from properties stored in a SVCB (or a SVCB-
conformant type like HTTPSSVC) DNS Record
[I-D.nygren-dnsop-svcb-httpssvc]. This record provides the URI
Template and the public Oblivious DoH key of a DoH server that is
designated for a specific domain. A specific domain may have more
than one such record.
In order to designate a DoH server for a domain, a SVCB record can
contain the "dohuri" (Section 10). The value stored in the parameter
is a URI, which is the DoH URI template [RFC8484].
The public key of the DoH server is sent as the "odohkey"
[I-D.pauly-dprive-oblivious-doh].
Kinnear, et al. Expires May 4, 2020 [Page 6]
Internet-Draft ADNS Privacy November 2019
The following example shows a record containing a DoH URI, as
returned by a query for the HTTPSSVC variant of the SVCB record type
on "example.com".
example.com. 7200 IN HTTPSSVC 0 svc.example.net.
svc.example.net. 7200 IN HTTPSSVC 2 svc1.example.net. (
dohuri=https://doh.example.net/dns-query
odohkey="..." )
Clients MUST ignore any DoH server URI that was not retrieved from a
DNSSEC-signed record that was validated by the client [RFC4033].
Whenever a client resolves a name for which it does not already have
a Designated DoH Server, it SHOULD try to determine the Designated
DoH Server by sending a query for the an SVCB record for the name.
If there is no DoH server designated for the name or zone, signaled
either by an NXDOMAIN answer or a SVCB record that does not contain a
DoH URI, the client SHOULD suppress queries for the SVCB record for a
given name until the time-to-live of the answer expires.
In order to bootstrap discovery of Designated DoH Servers, client
systems SHOULD have some saved list of at least two names that they
use consistently to perform SVCB record queries on the Direct
Resolvers configured by the local network. Since these queries are
likely not private, they SHOULD NOT be associated with user action or
contain user-identifying content. Rather, the expectation is that
all client systems of the same version and configuration would issue
the same bootstrapping queries when joining a network for the first
time when the list of Designated DoH Servers is empty.
3.1.1. Whitelisting Designated DoH Servers
Prior to using a Designated DoH Server for direct name queries on
privacy-sensitive connections, clients MUST whitelist the server.
The requirements for whitelisting are:
o Support for acting as an Oblivious Proxy. Each Designated DoH
Server is expected to support acting as a proxy for Oblivious DoH.
A client MUST issue at least one query that is proxied through the
server before sending direct queries to the server.
o Support for acting as an Oblivious Target. Each Designated DoH
Server is expected to support acting as a target for Oblivious
DoH. A client MUST issue at least one query that is targeted at
the server through a proxy before sending direct queries to the
server.
Kinnear, et al. Expires May 4, 2020 [Page 7]
Internet-Draft ADNS Privacy November 2019
Designated DoH Servers are expected to act both as Oblivious Proxies
and as Oblivious Targets to ensure that clients have sufficient
options for preserving privacy using Oblivious DoH. Oblivious
Targets are expected to act as Oblivious Proxies to ensure that no
Oblivious DoH server can act as only a target (thus being able to see
patterns in name resolution, which might have value to a resolver)
and require other servers to take on a disproportionate load of
proxying.
Clients MAY further choose to restrict the whitelist by other local
policy. For example, a client system can have a list of trusted
resolver configurations, and it can limit the whitelist of Designated
DoH Servers to configurations that match this list. Alternatively, a
client system can check a server against a list of audited and
approved DoH Servers that have properties that the client approves.
Clients SHOULD NOT whitelist authority mappings for effective top-
level domains (eTLDs), such as ".com".
If a client detects at any point after whitelisting a DoH server that
the server no longer meets the criteria for whitelisting, such as
consistently failing to proxy or receive Oblivious DoH queries, the
client SHOULD remove the DoH server from its whitelist.
3.1.2. Accessing Extended Information
When a Designated DoH Server is discovered, clients SHOULD also check
to see if this server provides an extended configuration in the form
of a Web PvD (Section 4.3). To do this, the client performs a GET
request to the DoH URI, indicating that it accepts a media type of
"application/pvd+json" [I-D.ietf-intarea-provisioning-domains]. When
requesting the PvD information, the query and fragment components of
the requested path are left empty. Note that this is different from
a GET request for the "application/dns-message" type, in which the
query variable "dns" contains an encoded version of a DNS message.
In response, the server will return the JSON content for the PvD, if
present. The content-type MUST be "application/pvd+json".
The following exchange shows an example of a client retrieving a Web
PvD configuration for a DoH server with the URI Template
"https://dnsserver.example.net/dns-query".
The client sends:
Kinnear, et al. Expires May 4, 2020 [Page 8]
Internet-Draft ADNS Privacy November 2019
:method = GET
:scheme = https
:authority = dnsserver.example.net
:path = /dns-query
accept = application/pvd+json
And the server replies:
:status = 200
content-type = application/pvd+json
content-length = 175
cache-control = max-age=86400
<JSON content of the Web PvD>
If the server does not support retrieving any extended PvD
information, it MUST reply with HTTP status code 415 (Unsupported
Media Type, [RFC7231]).
If the retrieved JSON contains a "dnsZones" array
[I-D.ietf-intarea-provisioning-domains], the client SHOULD perform an
SVCB record lookup of each of the listed zones on the DoH server and
validate that the DoH server is a designated server for the domain;
and if it is, add the domain to the local configuration.
3.2. Discovering 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.
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" (Section 10), 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 an SVCB record
from the locally-provisioned DoH server and validate the answer with
DNSSEC [RFC4033] before creating a mapping from the domain to the
server. Once this has been validated, clients can use this server
for resolution as described in step 2 of Section 3.3.
See Section 6 for local deployment considerations.
Kinnear, et al. Expires May 4, 2020 [Page 9]
Internet-Draft ADNS Privacy November 2019
3.3. Hostname Resolution Algorithm
When establishing a secure connection to a certain hostname, clients
need to first determine which resolver configuration ought to be used
for DNS resolution.
Several of the steps outlined in this algorithm take into account the
success or failure of name resolution. Failure can be indicated
either by a DNS response, such as SERVFAIL or NXDOMAIN, or by a
connection-level failure, such as a TCP reset, TLS handshake failure,
or an HTTP response error status. In effect, any unsuccessful
attempt to resolve a name can cause the client to try another
resolver if permitted by the algorithm. This is particularly useful
for cases in which a name may not be resolvable over public DNS but
has a valid answer only on the local network.
Given a specific hostname, the order of preference for which resolver
to use SHOULD be:
1. An Exclusive Direct Resolver, such as a resolver provisioned by a
VPN, with domain rules that include the hostname being resolved.
If the resolution fails, the connection will fail. See
Section 3.2 and Section 6.
2. A Direct Resolver, such as a local router, with domain rules that
are known to be authoritative for the domain containing the
hostname. If the resolution fails, the connection will try the
next resolver configuration based on this list.
3. The most specific Designated DoH Server that has been whitelisted
(Section 3.1.1) for the domain containing the hostname, i.e., the
designated DoH server which is associated with the longest
matching suffix of the hostname. For example, given two
Designated DoH Servers, one for "foo.example.com" and another
"example.com", clients connecting to "bar.foo.example.com" should
use the former. Note that the matching MUST be performed on
entire labels. That is, if "example.com" has a designated DoH
server, it can be used for "foo.example.com", but not for
"badexample.com". If the resolution fails, the connection can
either use an Oblivious DoH resolver (Step 4) or the default
resolver (Step 5). Privacy-Sensitive Connections SHOULD NOT skip
Step 4. Other connections MAY skip Step 4, based on system
policy.
4. Oblivious DoH queries using multiple DoH Servers
([I-D.pauly-dprive-oblivious-doh]). If this resolution fails,
Privacy-Sensitive Connections will fail. All other connections
will use the last resort, the default Direct Resolvers.
Kinnear, et al. Expires May 4, 2020 [Page 10]
Internet-Draft ADNS Privacy November 2019
5. The default Direct Resolver, generally the resolver provisioned
by the local router, is used as the last resort for any
connection that is not explicitly Privacy-Sensitive [RFC2132]
[RFC8106].
If the system allows the user to specify a preferred encrypted
resolver, such as allowing the user to manually configure a DoH
server URI to use by default, the use of this resolver SHOULD come
between steps 2 and 3. This ensures that VPN-managed and locally-
accessible names remain accessible while all other names are resolved
using the user preference.
Resolution on behalf of system traffic, such as interactions required
to detect and access a Captive Network Portal, require the use of the
default Direct Resolver. System traffic SHOULD have an exception to
this algorithm, and only use Steps 2 and 5 (those that use a resolver
provisioned by the local network). Further deployment considerations
for captive networks and walled-garden networks can be found in
Section 6.2.3.
3.4. Oblivious Resolution
For all privacy-sensitive connection queries for names that do not
correspond to a Designated DoH Server, the client SHOULD use
Oblivious DoH to help conceal its IP address from eavesdroppers and
untrusted resolvers.
Disassociation of client IPs from query content is achieved by using
Oblivious DoH [I-D.pauly-dprive-oblivious-doh]. This extension to
DoH allows a client to encrypt a query with a target DoH server's
public key, and proxy the query through another server. The query is
packaged with a unique client-defined symmetric key that is used to
sign the DNS answer, which is sent back to the client via the proxy.
All DoH Servers that are used as Designated DoH Servers by the client
MUST support being both an Oblivious Proxy and an Oblivious Target,
as described in the server requirements (Section 4).
Since each Designated DoH Server can act as one of two roles in an
proxied exchange, there are (N) * (N - 1) / 2 possible pairs of
servers, where N is the number of whitelisted servers. While clients
SHOULD use a variety of server pairs in rotation to decrease the
ability for any given server to track client queries, it is not
expected that all possible combinations will be used. Some
combinations will be able to handle more load than others, and some
will have better latency properties than others. To optimize
performance, clients SHOULD maintain statistics to track the
performance characteristics and success rates of particular pairs.
Kinnear, et al. Expires May 4, 2020 [Page 11]
Internet-Draft ADNS Privacy November 2019
Clients that are performing Oblivious DoH resolution SHOULD fall back
to another pair of servers if a first query times out, with a
locally-determined limit for the number of fallback attempts that
will be performed.
3.5. Handling Network Changes
Whenever a client joins a new network, it SHOULD wait to receive
local configuration for resolvers before using any Designated DoH
servers. The local network might be authoritative for some names, or
might require filtering.
Once the local configuration of the new network has been received,
the client MAY use Designated DoH configuration that it discovered
when associated with another network. These configurations can still
be considered valid since they came from DNSSEC-signed records.
However, it is possible that different resolver IP addresses would be
returned when looking up the designated server on the new network,
which can provide a more optimal route through the Internet, so
clients SHOULD perform new queries to refresh their mappings by
making queries on connection on this new interface.
4. Server Requirements
Any server deployment that provides a set of services within one or
more domains, such as a CDN, can run a server node that allows
clients to run Adaptive DNS. A new server node can be added at any
time, and can be used once it is advertised to clients and can be
validated and whitelisted. The system overall is intended to scale
and provide improved performance as more nodes become available.
The basic requirements to participate as a server node in this
architecture are described below.
4.1. Provide a DoH Server
Each server node is primarily defined by a DoH server [RFC8484] that
is designated for a set of domains, and also provides Oblivious DoH
functionality. As such, the DoH servers MUST be able to act as
recursive resolvers that accept queries for records and domains
beyond those for which the servers are specifically designated.
4.1.1. Oblivious DoH Proxy
The DoH servers MUST be able to act as Oblivious Proxies. In this
function, they will proxy encrypted queries and answers between
clients and Oblivious Target DoH servers.
Kinnear, et al. Expires May 4, 2020 [Page 12]
Internet-Draft ADNS Privacy November 2019
4.1.2. Oblivious DoH Target
The DoH servers MUST be able to act as Oblivious Targets. In this
function, they will accept encrypted proxied queries from clients via
Oblivious Proxy DoH servers, and provide encrypted answers using
client keys.
4.1.3. Keying Material
In order to support acting as an Oblivious Target, a DoH server needs
to provide a public HPKE [I-D.irtf-cfrg-hpke] key that can be used to
encrypt client queries. This key is advertised in the SVCB record
[I-D.pauly-dprive-oblivious-doh].
DoH servers also SHOULD provide an ESNI [I-D.ietf-tls-esni] key to
encrypt the Server Name Indication field in TLS handshakes to the DoH
server.
4.2. Advertise the DoH Server
The primary mechanism for advertising a Designated DoH Server is a
SVCB DNS record (Section 3.1). This record MUST contain both the URI
Template of the DoH Server as well as the Oblivious DoH Public Key.
It MAY contain the ESNI key [I-D.ietf-tls-esni].
Servers MUST ensure that any SVCB records are signed with DNSSEC
[RFC4033].
4.3. Provide Extended Configuration as a Web PvD
Beyond providing basic DoH server functionality, server nodes SHOULD
provide a mechanism that allows clients to look up properties and
configuration for the server deployment. Amongst other information,
this configuration can optionally contain a list of some popular
domains for which this server is designated. Clients can use this
list to optimize lookups for common names.
This set of extended configuration information is referred to as a
Web Provisioning Domain, or a Web PvD. Provisioning Domains are sets
of consistent information that clients can use to access networks,
including rules for resolution and proxying. Generally, these PvDs
are provisioned directly, such as by a local router or a VPN.
[I-D.ietf-intarea-provisioning-domains] defines an extensible
configuration dictionary that can be used to add information to local
PvD configurations. Web PvDs share the same JSON configuration
format, and share the registry of keys defined as "Additional
Information PvD Keys".
Kinnear, et al. Expires May 4, 2020 [Page 13]
Internet-Draft ADNS Privacy November 2019
If present, the PvD JSON configuration MUST be made available to
clients that request the "application/pvd+json" media type in a GET
request to the DoH server's URI
[I-D.ietf-intarea-provisioning-domains]. Clients MUST include this
media type as an Accept header in their GET requests, and servers
MUST mark this media type as their Content-Type header in responses.
If the PvD JSON format is not supported, the server MUST reply with
HTTP status code 415 [RFC7231].
The "identifier" key in the JSON configuration SHOULD be the hostname
of the DoH Server itself.
For Web PvDs, the "prefixes" key within the JSON configuration SHOULD
contain an empty array.
The key "dnsZones", which contains an array of domains as strings
[I-D.ietf-intarea-provisioning-domains], indicates the zones that
belong to the PvD. Any zone that is listed in this array for a Web
PvD MUST have a corresponding SVCB record that defines the DoH server
as designated for the zone. Servers SHOULD include in this array any
names that are considered default or well-known for the deployment,
but is not required or expected to list all zones or domains for
which it is designated. The trade-off here is that zones that are
listed can be fetched and validated automatically by clients, thus
removing a bootstrapping step in discovering mappings from domains to
Designated DoH Servers.
Clients that retrieve the Web PvD JSON dictionary SHOULD perform an
SVCB record query for each of the entries in the "dnsZones" array in
order to populate the mappings of domains. These MAY be performed in
an oblivious fashion, but MAY also be queried directly on the DoH
server (since the information is not user-specific, but in response
to generic server-driven content). Servers can choose to
preemptively transfer the relevant SVCB records if the PvD
information retrieval is done with an HTTP version that supports PUSH
semantics. This allows the server to avoid a round trip in zone
validation even before the client has started requested SVCB records.
Once the client requests an SVCB record for one of the names included
in the "dnsZones" array, the server can also include the SVCB records
for the other names in the array in the Additionals section of the
DNS response.
This document also registers one new key in the Additional
Information PvD Keys registry, to identify the URI Template for the
DoH server Section 10. When included in Web PvDs, this URI MUST
match the template in the SVCB DNS Record.
Kinnear, et al. Expires May 4, 2020 [Page 14]
Internet-Draft ADNS Privacy November 2019
Beyond providing resolution configuration, the Web PvD configuration
can be extended to offer information about proxies and other services
offered by the server deployment. Such keys are not defined in this
document.
5. Server Deployment Considerations
When servers designate DoH servers for their names, the specific
deployment model can impact the effective privacy and performance
characteristics.
5.1. Single Content Provider
If a name always resolves to server IP addresses that are hosted by a
single content provider, the name ought to designate a single DoH
server. This DoH server will be most optimal when it is designated
by many or all names that are hosted by the same content provider.
This ensures that clients can increase connection reuse to reduce
latency in connection setup.
A DoH server that corresponds to the content provider that hosts
content has an opportunity to tune the responses provided to a client
based on the location inferred by the client IP address.
5.2. Multiple Content Providers
Some hostnames may resolve to server IP addresses that are hosted by
multiple content providers. In such scenarios, the deployment may
want to be able to control the percentage of traffic that flows to
each content provider.
In these scenarios, there can either be:
o multiple designated DoH servers that are advertised via SVCB DNS
Records; or,
o a single designated DoH server that can be referenced by one or
more SVCB DNS Records, operated by a party that is aware of both
content providers and can manage splitting the traffic.
If a server deployment wants to easily control the split of traffic
between different content providers, it ought to use the latter model
of using a single designated DoH server that can better control which
IP addresses are provided to clients. Otherwise, if a client is
aware of multiple DoH servers, it might use a single resolver
exclusively, which may lead to inconsistent behavior between clients
that choose different resolvers.
Kinnear, et al. Expires May 4, 2020 [Page 15]
Internet-Draft ADNS Privacy November 2019
5.3. Avoid Narrow Deployments
Using designated DoH servers can improve the privacy of name
resolution whenever a DoH server is designated by many different
names within one or more domains. This limits the amount of
information leaked to an attacker observing traffic between a client
and a DoH server: the attacker only learns that the client might be
resolving one of the many names for which the server is designated
(or might be performing an Oblivious query).
However, if a deployment designates a given DoH server for only one
name, or a very small set of names, then it becomes easier for an
attacker to infer that a specific name is being accessed by a client.
For this reason, deployments are encouraged to avoid deploying a DoH
server that is only designated by a small number of names. Clients
can also choose to only whitelist DoH servers that are associated
with many names.
Beyond the benefits to privacy, having a larger number of names
designate a given DoH server improves the opportunity for DoH
connection reuse, which can improve the performance of name
resolutions.
6. Local Resolver Deployment Considerations
A key goal of Adaptive DNS is that clients will be able to use
Designated DoH Servers to improve the privacy of queries, without
entirely bypassing local network authority and policy. For example,
if a client is attached to an enterprise Wi-Fi network that provides
access and resolution for private names not generally accessible on
the Internet, such names will only be usable when a local resolver is
used.
In order to achieve this, a local network can advertise itself as
authoritative for a domain, allowing it to be used prior to external
servers in the client resolution algorithm Section 3.3.
6.1. Designating Local DoH Servers
If a local network wants to have clients send queries for a set of
private domains to its own resolver, it needs to define an explicit
provisioning domain [I-D.ietf-intarea-provisioning-domains]. The PvD
RA option SHOULD set the H-flag to indicate that Additional
Information is available. This Additional Information JSON object
SHOULD include both the "dohTemplate" and "dnsZones" keys to define
the local DoH server and the domains over which it claims authority.
Kinnear, et al. Expires May 4, 2020 [Page 16]
Internet-Draft ADNS Privacy November 2019
In order to validate that a local resolver is designated for a given
zone, the client SHOULD issue a SVCB record query for the names
specified in the PvD information, using the DoH server specified in
the PvD information. If there is no SVCB record for a name that
points to the DoH server that can be validated using DNSSEC, the
client SHOULD NOT automatically create a designation from the domain
name to DoH server. See specific use cases in Section 6.2 for cases
in which a local resolver may still be used.
Although local Designated DoH Servers MAY support proxying Oblivious
DoH queries, a client SHOULD NOT select one of these servers as an
Oblivious Proxy. Doing so might reveal the client's location to the
Target based on the address of the proxy, which could contribute to
deanonymizing the client. Clients can make an exception to this
behavior if the DoH server designated by the local network is known
to be a non-local service, such as when a local network configures a
centralized public resolver to handle its DNS operations.
6.2. Local Use Cases
The various use cases for selecting locally-provisioned resolvers
require different approaches for deployment and client resolution.
The following list is not exhaustive, but provides guidance on how
these scenarios can be achieved using the Adaptive DNS algorithm.
6.2.1. Accessing Local-Only Resolvable Content
Some names are not resolvable using generic DNS resolvers, but
require using a DNS server that can resolve private names. This is
common in enterprise scenarios, in which an enterprise can have a set
of private names that it allows to be resolved when connected to a
VPN or an enterprise-managed Wi-Fi network. In this case, clients
that do not use the locally-provisioned resolver will fail to resolve
private names.
In these scenarios, the local network SHOULD designate a local DoH
server for the domains that are locally resolvable. For example, an
enterprise that owns "private.example.org" would advertise
"private.example.org" in its PvD information along with a DoH URI
template. Clients could then use that locally-configured resolver
with names under "private.example.org" according to the rules in
Section 6.1.
In general, clients SHOULD only create designated DoH server
associations when they can validate a SVCB record using DNSSEC.
However, some deployments of private names might not want to sign all
private names within a zone. There are thus a few possible
deployment models:
Kinnear, et al. Expires May 4, 2020 [Page 17]
Internet-Draft ADNS Privacy November 2019
o "private.example.org" does have a DNSSEC-signed SVCB record that
points to the local DoH server. The client requests the SVCB
record for "private.example.org" using the local DoH server that
is specified in the PvD information, and from that point on uses
the local DoH server for names under "private.example.org".
o Instead of signing "private.example.org", the deployment provides
a DNSSEC-signed SVCB record for "example.org", thus steering all
resolution under "example.org" to the local resolver.
o No DNSSEC-signed SVCB record designates the local server. In this
case, clients have a hint that the local network can serve names
under "private.example.org", but do not have a way to validate the
designation. Clients can in this case try to resolve names using
external servers (such as via Oblivious DoH), and then MAY fall
back to using locally-provisioned resolvers if the names do not
resolve externally. This approach has the risk of exposing
private names to public resolvers, which can be undesirable for
certain enterprise deployments. Alternatively, if the client
trusts the local network based on specific policy configured on
the client, it can choose to resolve these names locally first.
Note that this approach risks exposing names to a potentially
malicious network that is masquerading as an authority for private
names if the network cannot be validated in some other manner.
Deployments SHOULD use the one of the first two approaches (signing
their records) whenever possible; the case of providing unsigned
names is only described as a possibility for handling legacy
enterprise deployments. Clients SHOULD choose to ignore any locally
designated names that are not signed unless there is a specific
policy configuration on the client.
6.2.2. Accessing Locally Optimized Content
Other names may be resolvable both publicly and on the local
resolver, but have more optimized servers that are accessible only
via the local network. For example, a Wi-Fi provider may provide
access to a cache of video content that provides lower latency than
publicly-accessible caches.
Names that are hosted locally in this way SHOULD use a designation
with a DNSSEC-signed SVCB record for the name. If a client discovers
that a local resolver is designated for a given name, the client
SHOULD prefer using connections to this locally-hosted content rather
than names resolved externally.
Kinnear, et al. Expires May 4, 2020 [Page 18]
Internet-Draft ADNS Privacy November 2019
Note that having a DNSSEC-signed designation to the local resolver
provides a clear indication that the entity that manages a given name
has an explicit relationship with the local network provider.
6.2.3. Walled-Garden and Captive Network Deployments
Some networks do not provide any access to the general Internet, but
host local content that clients can access. For example, a network
on an airplane can give access to flight information and in-flight
media, but will not allow access to any external hosts or DNS
servers. These networks are often described as "walled-gardens".
Captive networks [I-D.ietf-capport-architecture] are similar in that
they block access to external hosts, although they can provide
generic access after some time.
If a walled-garden or captive network defines a PvD with additional
information, it can define zones for names that it hosts, such as
"airplane.example.com". It can also provide a locally-hosted
encrypted DNS server.
However, if such a network does not support explicitly advertising
local names, clients that try to establish connections to DoH servers
will experience connection failures. In these cases, system traffic
that is used for connecting to captive portals SHOULD use local
resolvers. In addition, clients MAY choose to fall back to using
direct resolution without any encryption if they determine that all
connectivity is blocked otherwise. Note that this comes with a risk
of a network blocking connections in order to induce this fallback
behavior, so clients might want to inform users about this possible
attack where appropriate, or prefer to not fall back if there is a
concern about leaking user data.
6.2.4. Network-Based Filtering
Some networks currently rely on manipulating DNS name resolution in
order to apply content filtering rules to clients associated with the
network. Using encrypted DNS resolvers that are not participating in
this filtering can bypass such enforcement. However, simply blocking
connections for filtering is indistinguishable from a malicious
attack from a client's perspective.
In order to indicate the presence of filtering requirements, a
network deployment can add the "requireDNSFiltering" and
"dnsFilteredZones" keys to its PvD information. The
"dnsFilteredZones" entry can contain an array of strings, each of
which is a domain name that the network requires clients to resolve
using the local resolver. If the array contains the string ".", it
Kinnear, et al. Expires May 4, 2020 [Page 19]
Internet-Draft ADNS Privacy November 2019
indicates the network requires filtering for all domains. If
"requireDNSFiltering" is present with a boolean value of true, the
network is indicating that it expects all client systems to send the
names indicated by "dnsFilteredZones" to the local resolver. If
"requireDNSFiltering" is not present or set to false, then the
filtering service is considered to be optional for clients that want
to use it as a service to enforce desired policy.
Clients that receive indication of filtering requirements SHOULD NOT
use any other resolver for the filtered domains, but treat the
network as claiming authority. However, since this filtering cannot
be authenticated, this behavior SHOULD NOT be done silently without
user consent.
Networks that try to interfere with connections to encrypted DNS
resolvers without indicating a requirement for filtering cannot be
distinguished from misconfigurations or network attacks. Clients MAY
choose to avoid sending any user-initiated connections on such
networks to prevent malicious interception.
7. Performance Considerations
One of the challenges of using non-local DNS servers (such as cloud-
based DoH servers) is that recursive queries made by these servers
will originate from an IP address that is not necessarily
geographically related to the client. Many DNS servers make
assumptions about the geographic locality of clients to their
recursive resolvers to optimize answers. To avoid this problem, the
client's subnet can be forwarded to the authoritative server by the
recursive using the EDNS0 Client Subnet feature. Oblivious DoH
discourages this practice for privacy reasons. However, sharing this
subnet, while detrimental to privacy, can result in better targeted
DNS resolutions.
Adaptive DNS splits DoH queries into two sets: those made to
Designated DoH Servers, and those made to Oblivious DoH servers.
Oblivious queries are sensitive for privacy, and can encounter
performance degradation as a result of not using the client subnet.
Queries to designated DoH servers, on the other hand, are sent
directly by clients, so the client IP address is made available to
these servers. Since these servers are designated by the authority
for the names, they can use the IP address subnet information to tune
DNS answers.
Based on these properties, clients SHOULD prefer lookups via
Designated DoH Servers over oblivious mechanisms whenever possible.
Servers can encourage this by setting large TTLs for SVCB records and
using longer TTLs for responses returned by their Designated DoH
Kinnear, et al. Expires May 4, 2020 [Page 20]
Internet-Draft ADNS Privacy November 2019
Server endpoints which can be more confident they have accurate
addressing information.
8. Security Considerations
In order to avoid interception and modification of the information
retrieved by clients using Adaptive DNS, all exchanges between
clients and servers are performed over encrypted connections, e.g.,
TLS.
Malicious adversaries may block client connections to all DoH or
Oblivious DoH services as a Denial-of-Service (DoS) measure. Clients
which cannot connect to any proxy may, by local policy, fall back to
unencrypted DNS if this occurs.
9. Privacy Considerations
Clients must be careful in determining to which DoH servers they send
queries directly without proxying. A malicious DoH server 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 [RFC4033].
Even servers that are officially designated can risk leaking or
logging information about client lookups. Such risk can be mitigated
by further restricting the list of DoH servers that are whitelisted
for direct use based on client policy.
Using Oblivious DoH reduces the risk that a single DoH server can
track or profile a client. However, clients should exercise caution
when using Oblivious DoH responses from resolvers that do not carry
DNSSEC signatures. An adversarial Oblivious Target resolver that
wishes to learn the IP address of clients requesting resolution for
sensitive domains can redirect clients to unique addresses of its
choosing. Clients that use these answers when establishing TLS
connections may then leak their local IP address to chosen server.
Thus, when Oblivious DoH answers are returned without DNSSEC,
Privacy-Sensitive Connections concerned about this attack SHOULD
conceal their IP address via a TLS- or HTTP-layer proxy or some other
tunneling mechanism.
An adversary able to see traffic on each path segment of a DoH or
Oblivious DoH query (e.g., from client to proxy, proxy to target, and
target 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
Kinnear, et al. Expires May 4, 2020 [Page 21]
Internet-Draft ADNS Privacy November 2019
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.
10. IANA Considerations
10.1. DoH Template PvD Key
This document adds a key to the "Additional Information PvD Keys"
registry [I-D.ietf-intarea-provisioning-domains].
+----------+----------+-------+-------------------------------------+
| JSON key | Descript | Type | Example |
| | ion | | |
+----------+----------+-------+-------------------------------------+
| dohTempl | DoH URI | Strin | "https://dnsserver.example.net/dns- |
| ate | Template | g | query{?dns}" |
| | [RFC8484 | | |
| | ] | | |
+----------+----------+-------+-------------------------------------+
10.2. DNS Filtering PvD Keys
This document adds a key to the "Additional Information PvD Keys"
registry [I-D.ietf-intarea-provisioning-domains].
+---------------------+-------------------------+---------+---------+
| JSON key | Description | Type | Example |
+---------------------+-------------------------+---------+---------+
| requireDNSFiltering | A flag to indicate that | Boolean | true |
| | the network requires | | |
| | filtering all DNS | | |
| | traffic using the | | |
| | provisioned resolver. | | |
| | | | |
| dnsFilteredZones | A list of DNS domains | Array | [ "." ] |
| | as strings that | of | |
| | represent domains that | Strings | |
| | can be filtered by the | | |
| | provisioned resolver. | | |
+---------------------+-------------------------+---------+---------+
Any network that sets the "requireDNSFiltering" boolean to false but
provides "dnsFilteredZones" advertises the optional service of
filtering on the provisioned network.
An "." in the "dnsFilteredZones" array represents a wildcard, which
can be used to indicate that the network is requesting to filter all
Kinnear, et al. Expires May 4, 2020 [Page 22]
Internet-Draft ADNS Privacy November 2019
names. Any more specific string represents a domain that requires
filtering on the network.
10.3. DoH URI Template DNS Parameter
If present, this parameters indicates the URI template of a DoH
server that is designated for use with the name being resolved. This
is a string encoded as UTF-8 characters.
Name: dohuri
SvcParamKey: TBD
Meaning: URI template for a designated DoH server
Reference: This document.
11. Acknowledgments
Thanks to Erik Nygren, Lorenzo Colitti, Tommy Jensen, 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.
12. References
12.1. Normative References
[I-D.ietf-intarea-provisioning-domains]
Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data",
draft-ietf-intarea-provisioning-domains-08 (work in
progress), October 2019.
[I-D.ietf-tls-esni]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
"Encrypted Server Name Indication for TLS 1.3", draft-
ietf-tls-esni-04 (work in progress), July 2019.
[I-D.irtf-cfrg-hpke]
Barnes, R. and K. Bhargavan, "Hybrid Public Key
Encryption", draft-irtf-cfrg-hpke-00 (work in progress),
July 2019.
Kinnear, et al. Expires May 4, 2020 [Page 23]
Internet-Draft ADNS Privacy November 2019
[I-D.nygren-dnsop-svcb-httpssvc]
Schwartz, B., Bishop, M., and E. Nygren, "Service binding
and parameter specification via the DNS (DNS SVCB and
HTTPSSVC)", draft-nygren-dnsop-svcb-httpssvc-00 (work in
progress), September 2019.
[I-D.pauly-dprive-oblivious-doh]
Kinnear, E., Pauly, T., Wood, C., and P. McManus,
"Oblivious DNS Over HTTPS", draft-pauly-dprive-oblivious-
doh-00 (work in progress), October 2019.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[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>.
[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>.
12.2. Informative References
[I-D.ietf-capport-architecture]
Larose, K. and D. Dolson, "CAPPORT Architecture", draft-
ietf-capport-architecture-04 (work in progress), June
2019.
[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>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
<https://www.rfc-editor.org/info/rfc2132>.
Kinnear, et al. Expires May 4, 2020 [Page 24]
Internet-Draft ADNS Privacy November 2019
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli,
"IPv6 Router Advertisement Options for DNS Configuration",
RFC 8106, DOI 10.17487/RFC8106, March 2017,
<https://www.rfc-editor.org/info/rfc8106>.
[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>.
Authors' Addresses
Eric Kinnear
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: ekinnear@apple.com
Tommy Pauly
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: tpauly@apple.com
Chris Wood
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: cawood@apple.com
Patrick McManus
Fastly
Email: mcmanus@ducksong.com
Kinnear, et al. Expires May 4, 2020 [Page 25]
