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]