idnits 2.17.1 draft-pauly-dprive-adaptive-dns-privacy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 01, 2019) is 1610 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-intarea-provisioning-domains-08 == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-04 == Outdated reference: A later version (-12) exists of draft-irtf-cfrg-hpke-00 ** Downref: Normative reference to an Informational draft: draft-irtf-cfrg-hpke (ref. 'I-D.irtf-cfrg-hpke') == Outdated reference: A later version (-11) exists of draft-pauly-dprive-oblivious-doh-00 ** Downref: Normative reference to an Experimental draft: draft-pauly-dprive-oblivious-doh (ref. 'I-D.pauly-dprive-oblivious-doh') ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-10) exists of draft-ietf-capport-architecture-04 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Kinnear 3 Internet-Draft T. Pauly 4 Intended status: Standards Track C. Wood 5 Expires: May 4, 2020 Apple Inc. 6 P. McManus 7 Fastly 8 November 01, 2019 10 Adaptive DNS: Improving Privacy of Name Resolution 11 draft-pauly-dprive-adaptive-dns-privacy-01 13 Abstract 15 This document defines an architecture that allows clients to 16 dynamically discover designated resolvers that offer encrypted DNS 17 services, and use them in an adaptive way that improves privacy while 18 co-existing with locally provisioned resolvers. These resolvers can 19 be used directly when looking up names for which they are designated. 20 These resolvers also provide the ability to proxy encrypted queries, 21 thus hiding the identity of the client requesting resolution. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 4, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Specification of Requirements . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Discovering Designated DoH Servers . . . . . . . . . . . 6 62 3.1.1. Whitelisting Designated DoH Servers . . . . . . . . . 7 63 3.1.2. Accessing Extended Information . . . . . . . . . . . 8 64 3.2. Discovering Local Resolvers . . . . . . . . . . . . . . . 9 65 3.3. Hostname Resolution Algorithm . . . . . . . . . . . . . . 10 66 3.4. Oblivious Resolution . . . . . . . . . . . . . . . . . . 11 67 3.5. Handling Network Changes . . . . . . . . . . . . . . . . 12 68 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 12 69 4.1. Provide a DoH Server . . . . . . . . . . . . . . . . . . 12 70 4.1.1. Oblivious DoH Proxy . . . . . . . . . . . . . . . . . 12 71 4.1.2. Oblivious DoH Target . . . . . . . . . . . . . . . . 13 72 4.1.3. Keying Material . . . . . . . . . . . . . . . . . . . 13 73 4.2. Advertise the DoH Server . . . . . . . . . . . . . . . . 13 74 4.3. Provide Extended Configuration as a Web PvD . . . . . . . 13 75 5. Server Deployment Considerations . . . . . . . . . . . . . . 15 76 5.1. Single Content Provider . . . . . . . . . . . . . . . . . 15 77 5.2. Multiple Content Providers . . . . . . . . . . . . . . . 15 78 5.3. Avoid Narrow Deployments . . . . . . . . . . . . . . . . 16 79 6. Local Resolver Deployment Considerations . . . . . . . . . . 16 80 6.1. Designating Local DoH Servers . . . . . . . . . . . . . . 16 81 6.2. Local Use Cases . . . . . . . . . . . . . . . . . . . . . 17 82 6.2.1. Accessing Local-Only Resolvable Content . . . . . . . 17 83 6.2.2. Accessing Locally Optimized Content . . . . . . . . . 18 84 6.2.3. Walled-Garden and Captive Network Deployments . . . . 19 85 6.2.4. Network-Based Filtering . . . . . . . . . . . . . . . 19 86 7. Performance Considerations . . . . . . . . . . . . . . . . . 20 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 90 10.1. DoH Template PvD Key . . . . . . . . . . . . . . . . . . 22 91 10.2. DNS Filtering PvD Keys . . . . . . . . . . . . . . . . . 22 92 10.3. DoH URI Template DNS Parameter . . . . . . . . . . . . . 23 93 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 94 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 96 12.2. Informative References . . . . . . . . . . . . . . . . . 24 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 100 1. Introduction 102 When clients need to resolve names into addresses in order to 103 establish networking connections, they traditionally use by default 104 the DNS resolver that is provisioned by the local network along with 105 their IP address [RFC2132] [RFC8106]. Alternatively, they can use a 106 resolver indicated by a tunneling service such as a VPN. 108 However, privacy-sensitive clients might prefer to use an encrypted 109 DNS service other than the one locally provisioned in order to 110 prevent interception, profiling, or modification by entities other 111 than the operator of the name service for the name being resolved. 112 Protocols that can improve the transport security of a client when 113 using DNS or creating TLS connections include DNS-over-TLS [RFC7858], 114 DNS-over-HTTPS [RFC8484], and encrypted Server Name Indication (ESNI) 115 [I-D.ietf-tls-esni]. 117 There are several concerns around a client using such privacy- 118 enhancing mechanisms for generic system traffic. A remote service 119 that provides encrypted DNS may not provide correct answers for 120 locally available resources, or private resources (such as domains 121 only accessible over a private network). Remote services may also be 122 untrusted from a privacy perspective: while encryption will prevent 123 on-path observers from seeing hostnames, client systems need to trust 124 the encrypted DNS service to not store or misuse queries made to it. 125 Further, extensive use of cloud based recursive resolvers obscures 126 the network location of the client which may degrade the performance 127 of the returned server due to lack of proximity at the benefit of 128 improved privacy. 130 Client systems are left with choosing between one of the following 131 stances: 133 1. Send all application DNS queries to a particular encrypted DNS 134 service, which requires establishing user trust of the service. 135 This can lead to resolution failures for local or private 136 enterprise domains absent heuristics or other workarounds for 137 detecting managed networks. 139 2. Allow the user or another entity to configure local policy for 140 which domains to send to local, private, or encrypted resolvers. 141 This provides more granularity at the cost of increasing user 142 burden. 144 3. Only use locally-provisioned resolvers, and opportunistically use 145 encrypted DNS to these resolvers when possible. (Clients may 146 learn of encrypted transport support by actively probing such 147 resolvers.) This provides marginal benefit over not using 148 encrypted DNS at all, especially if clients have no means of 149 authenticating or trusting local resolvers. 151 This document defines an architecture that allows clients to improve 152 the privacy of their DNS queries without requiring user intervention, 153 and allowing coexistence with local, private, and enterprise 154 resolvers. 156 This architecture is composed of several mechanisms: 158 o A DNS record that indicates a designated DoH server associated 159 with a name (Section 3.1); 161 o an extension to DoH that allows client IP addresses to be 162 disassociated from queries via proxying 163 ([I-D.pauly-dprive-oblivious-doh]); 165 o a DoH server that responds to queries directly and supports 166 proxying (Section 4); 168 o and client behavior rules for how to resolve names using a 169 combination of designated DoH resolvers, proxied queries, and 170 local resolvers (Section 3). 172 1.1. Specification of Requirements 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in BCP 177 14 [RFC2119] [RFC8174] when, and only when, they appear in all 178 capitals, as shown here. 180 2. Terminology 182 This document defines the following terms: 184 Adaptive DNS: Adaptive DNS is a technique to provide an encrypted 185 transport for DNS queries that can be sent directly to a 186 Designated DoH Server, to use Oblivious DoH to hide the client IP 187 address, or to use Direct Resolvers when required or appropriate. 189 Designated DoH Server: A DNS resolver that provides connectivity 190 over HTTPS (DoH) that is designated as a responsible resolver for 191 a given domain or zone. 193 Direct Resolver: A DNS resolver using any transport that is 194 provisioned directly by a local router or a VPN. 196 Exclusive Direct Resolver: A Direct Resolver that requires the 197 client to use it exclusively for a given set of domains, such as 198 private domains managed by a VPN. This status is governed by 199 local system policy. 201 Oblivious DoH: A technique that uses multiple DoH servers to proxy 202 queries in a way that disassociates the client's IP address from 203 query content. 205 Oblivious Proxy: A resolution server that proxies encrypted client 206 DNS queries to another resolution server that will be able to 207 decrypt the query (the Oblivious Target). 209 Oblivious Target: A resolution server that receives encrypted client 210 DNS queries via an Oblivious Proxy. 212 Privacy-Sensitive Connections: Connections made by clients that are 213 explicitly Privacy-Sensitive are treated differently from 214 connections made for generic system behavior, such as non-user- 215 initiated maintenance connections. This distinction is only 216 relevant on the client, and does not get communicated to other 217 network entities. Certain applications, such as browsers, can 218 choose to treat all connections as privacy-sensitive. 220 Web PvD: A Web Provisioning Domain, or Web PvD, represents the 221 configuration of resolvers, proxies, and other information that a 222 server deployment makes available to clients. See Section 4.3. 224 3. Client Behavior 226 Adaptive DNS allows client systems and applications to improve the 227 privacy of their DNS queries and connections, both by requiring 228 confidentiality via encryption, and by limiting the ability to 229 correlate client IP addresses with query contents. Specifically, the 230 goal for client queries is to achieve the following properties: 232 1. No party other than the client and server can learn or control 233 the names being queried by the client or the answers being 234 returned by the server. 236 2. Only a designated DNS resolver associated with the deployment 237 that is also hosting content will be able to read both the client 238 IP address and queried names for Privacy-Sensitive Connections. 239 For example, a resolver owned and operated by the same provider 240 that hosts "example.com" would be able to link queries for 241 "example.com" to specific clients (by their IP address), since 242 the server ultimately has this capability once clients 243 subsequently establish secure (e.g., TLS) connections to an 244 address to which "example.com" resolves. 246 3. Clients will be able to comply with policies required by VPNs and 247 local networks that are authoritative for private domains. 249 An algorithm for determining how to resolve a given name in a manner 250 that satisfies these properties is described in Section 3.3. Note 251 that this algorithm does not guarantee that responses that are not 252 signed with DNSSEC are valid, and clients that establish connections 253 to unsigned addresses may still expose their local IP addresses to 254 attackers that control their terminal resolver even if hidden during 255 resolution. 257 3.1. Discovering Designated DoH Servers 259 All direct (non-oblivious) queries for names in privacy-sensitive 260 connections MUST be sent to a server that both provides encryption 261 and is designated for the domain. 263 Clients dynamically build and maintain a set of known Designated DoH 264 Servers. The information that is associated with each server is: 266 o The URI Template of the DoH server [RFC8484] 268 o The public HPKE [I-D.irtf-cfrg-hpke] key of the DoH server used 269 for proxied oblivious queries [I-D.pauly-dprive-oblivious-doh] 271 o A list of domains for which the DoH server is designated 273 This information can be retrieved from several different sources. 274 The primary source for discovering Designated DoH Server 275 configurations is from properties stored in a SVCB (or a SVCB- 276 conformant type like HTTPSSVC) DNS Record 277 [I-D.nygren-dnsop-svcb-httpssvc]. This record provides the URI 278 Template and the public Oblivious DoH key of a DoH server that is 279 designated for a specific domain. A specific domain may have more 280 than one such record. 282 In order to designate a DoH server for a domain, a SVCB record can 283 contain the "dohuri" (Section 10). The value stored in the parameter 284 is a URI, which is the DoH URI template [RFC8484]. 286 The public key of the DoH server is sent as the "odohkey" 287 [I-D.pauly-dprive-oblivious-doh]. 289 The following example shows a record containing a DoH URI, as 290 returned by a query for the HTTPSSVC variant of the SVCB record type 291 on "example.com". 293 example.com. 7200 IN HTTPSSVC 0 svc.example.net. 294 svc.example.net. 7200 IN HTTPSSVC 2 svc1.example.net. ( 295 dohuri=https://doh.example.net/dns-query 296 odohkey="..." ) 298 Clients MUST ignore any DoH server URI that was not retrieved from a 299 DNSSEC-signed record that was validated by the client [RFC4033]. 301 Whenever a client resolves a name for which it does not already have 302 a Designated DoH Server, it SHOULD try to determine the Designated 303 DoH Server by sending a query for the an SVCB record for the name. 304 If there is no DoH server designated for the name or zone, signaled 305 either by an NXDOMAIN answer or a SVCB record that does not contain a 306 DoH URI, the client SHOULD suppress queries for the SVCB record for a 307 given name until the time-to-live of the answer expires. 309 In order to bootstrap discovery of Designated DoH Servers, client 310 systems SHOULD have some saved list of at least two names that they 311 use consistently to perform SVCB record queries on the Direct 312 Resolvers configured by the local network. Since these queries are 313 likely not private, they SHOULD NOT be associated with user action or 314 contain user-identifying content. Rather, the expectation is that 315 all client systems of the same version and configuration would issue 316 the same bootstrapping queries when joining a network for the first 317 time when the list of Designated DoH Servers is empty. 319 3.1.1. Whitelisting Designated DoH Servers 321 Prior to using a Designated DoH Server for direct name queries on 322 privacy-sensitive connections, clients MUST whitelist the server. 324 The requirements for whitelisting are: 326 o Support for acting as an Oblivious Proxy. Each Designated DoH 327 Server is expected to support acting as a proxy for Oblivious DoH. 328 A client MUST issue at least one query that is proxied through the 329 server before sending direct queries to the server. 331 o Support for acting as an Oblivious Target. Each Designated DoH 332 Server is expected to support acting as a target for Oblivious 333 DoH. A client MUST issue at least one query that is targeted at 334 the server through a proxy before sending direct queries to the 335 server. 337 Designated DoH Servers are expected to act both as Oblivious Proxies 338 and as Oblivious Targets to ensure that clients have sufficient 339 options for preserving privacy using Oblivious DoH. Oblivious 340 Targets are expected to act as Oblivious Proxies to ensure that no 341 Oblivious DoH server can act as only a target (thus being able to see 342 patterns in name resolution, which might have value to a resolver) 343 and require other servers to take on a disproportionate load of 344 proxying. 346 Clients MAY further choose to restrict the whitelist by other local 347 policy. For example, a client system can have a list of trusted 348 resolver configurations, and it can limit the whitelist of Designated 349 DoH Servers to configurations that match this list. Alternatively, a 350 client system can check a server against a list of audited and 351 approved DoH Servers that have properties that the client approves. 353 Clients SHOULD NOT whitelist authority mappings for effective top- 354 level domains (eTLDs), such as ".com". 356 If a client detects at any point after whitelisting a DoH server that 357 the server no longer meets the criteria for whitelisting, such as 358 consistently failing to proxy or receive Oblivious DoH queries, the 359 client SHOULD remove the DoH server from its whitelist. 361 3.1.2. Accessing Extended Information 363 When a Designated DoH Server is discovered, clients SHOULD also check 364 to see if this server provides an extended configuration in the form 365 of a Web PvD (Section 4.3). To do this, the client performs a GET 366 request to the DoH URI, indicating that it accepts a media type of 367 "application/pvd+json" [I-D.ietf-intarea-provisioning-domains]. When 368 requesting the PvD information, the query and fragment components of 369 the requested path are left empty. Note that this is different from 370 a GET request for the "application/dns-message" type, in which the 371 query variable "dns" contains an encoded version of a DNS message. 373 In response, the server will return the JSON content for the PvD, if 374 present. The content-type MUST be "application/pvd+json". 376 The following exchange shows an example of a client retrieving a Web 377 PvD configuration for a DoH server with the URI Template 378 "https://dnsserver.example.net/dns-query". 380 The client sends: 382 :method = GET 383 :scheme = https 384 :authority = dnsserver.example.net 385 :path = /dns-query 386 accept = application/pvd+json 388 And the server replies: 390 :status = 200 391 content-type = application/pvd+json 392 content-length = 175 393 cache-control = max-age=86400 395 397 If the server does not support retrieving any extended PvD 398 information, it MUST reply with HTTP status code 415 (Unsupported 399 Media Type, [RFC7231]). 401 If the retrieved JSON contains a "dnsZones" array 402 [I-D.ietf-intarea-provisioning-domains], the client SHOULD perform an 403 SVCB record lookup of each of the listed zones on the DoH server and 404 validate that the DoH server is a designated server for the domain; 405 and if it is, add the domain to the local configuration. 407 3.2. Discovering Local Resolvers 409 If the local network provides configuration with an Explicit 410 Provisioning Domain (PvD), as defined by 411 [I-D.ietf-intarea-provisioning-domains], clients can learn about 412 domains for which the local network's resolver is authoritative. 414 If an RA provided by the router on the network defines an Explicit 415 PvD that has additional information, and this additional information 416 JSON dictionary contains the key "dohTemplate" (Section 10), then the 417 client SHOULD add this DoH server to its list of known DoH 418 configurations. The domains that the DoH server claims authority for 419 are listed in the "dnsZones" key. Clients MUST use an SVCB record 420 from the locally-provisioned DoH server and validate the answer with 421 DNSSEC [RFC4033] before creating a mapping from the domain to the 422 server. Once this has been validated, clients can use this server 423 for resolution as described in step 2 of Section 3.3. 425 See Section 6 for local deployment considerations. 427 3.3. Hostname Resolution Algorithm 429 When establishing a secure connection to a certain hostname, clients 430 need to first determine which resolver configuration ought to be used 431 for DNS resolution. 433 Several of the steps outlined in this algorithm take into account the 434 success or failure of name resolution. Failure can be indicated 435 either by a DNS response, such as SERVFAIL or NXDOMAIN, or by a 436 connection-level failure, such as a TCP reset, TLS handshake failure, 437 or an HTTP response error status. In effect, any unsuccessful 438 attempt to resolve a name can cause the client to try another 439 resolver if permitted by the algorithm. This is particularly useful 440 for cases in which a name may not be resolvable over public DNS but 441 has a valid answer only on the local network. 443 Given a specific hostname, the order of preference for which resolver 444 to use SHOULD be: 446 1. An Exclusive Direct Resolver, such as a resolver provisioned by a 447 VPN, with domain rules that include the hostname being resolved. 448 If the resolution fails, the connection will fail. See 449 Section 3.2 and Section 6. 451 2. A Direct Resolver, such as a local router, with domain rules that 452 are known to be authoritative for the domain containing the 453 hostname. If the resolution fails, the connection will try the 454 next resolver configuration based on this list. 456 3. The most specific Designated DoH Server that has been whitelisted 457 (Section 3.1.1) for the domain containing the hostname, i.e., the 458 designated DoH server which is associated with the longest 459 matching suffix of the hostname. For example, given two 460 Designated DoH Servers, one for "foo.example.com" and another 461 "example.com", clients connecting to "bar.foo.example.com" should 462 use the former. Note that the matching MUST be performed on 463 entire labels. That is, if "example.com" has a designated DoH 464 server, it can be used for "foo.example.com", but not for 465 "badexample.com". If the resolution fails, the connection can 466 either use an Oblivious DoH resolver (Step 4) or the default 467 resolver (Step 5). Privacy-Sensitive Connections SHOULD NOT skip 468 Step 4. Other connections MAY skip Step 4, based on system 469 policy. 471 4. Oblivious DoH queries using multiple DoH Servers 472 ([I-D.pauly-dprive-oblivious-doh]). If this resolution fails, 473 Privacy-Sensitive Connections will fail. All other connections 474 will use the last resort, the default Direct Resolvers. 476 5. The default Direct Resolver, generally the resolver provisioned 477 by the local router, is used as the last resort for any 478 connection that is not explicitly Privacy-Sensitive [RFC2132] 479 [RFC8106]. 481 If the system allows the user to specify a preferred encrypted 482 resolver, such as allowing the user to manually configure a DoH 483 server URI to use by default, the use of this resolver SHOULD come 484 between steps 2 and 3. This ensures that VPN-managed and locally- 485 accessible names remain accessible while all other names are resolved 486 using the user preference. 488 Resolution on behalf of system traffic, such as interactions required 489 to detect and access a Captive Network Portal, require the use of the 490 default Direct Resolver. System traffic SHOULD have an exception to 491 this algorithm, and only use Steps 2 and 5 (those that use a resolver 492 provisioned by the local network). Further deployment considerations 493 for captive networks and walled-garden networks can be found in 494 Section 6.2.3. 496 3.4. Oblivious Resolution 498 For all privacy-sensitive connection queries for names that do not 499 correspond to a Designated DoH Server, the client SHOULD use 500 Oblivious DoH to help conceal its IP address from eavesdroppers and 501 untrusted resolvers. 503 Disassociation of client IPs from query content is achieved by using 504 Oblivious DoH [I-D.pauly-dprive-oblivious-doh]. This extension to 505 DoH allows a client to encrypt a query with a target DoH server's 506 public key, and proxy the query through another server. The query is 507 packaged with a unique client-defined symmetric key that is used to 508 sign the DNS answer, which is sent back to the client via the proxy. 510 All DoH Servers that are used as Designated DoH Servers by the client 511 MUST support being both an Oblivious Proxy and an Oblivious Target, 512 as described in the server requirements (Section 4). 514 Since each Designated DoH Server can act as one of two roles in an 515 proxied exchange, there are (N) * (N - 1) / 2 possible pairs of 516 servers, where N is the number of whitelisted servers. While clients 517 SHOULD use a variety of server pairs in rotation to decrease the 518 ability for any given server to track client queries, it is not 519 expected that all possible combinations will be used. Some 520 combinations will be able to handle more load than others, and some 521 will have better latency properties than others. To optimize 522 performance, clients SHOULD maintain statistics to track the 523 performance characteristics and success rates of particular pairs. 525 Clients that are performing Oblivious DoH resolution SHOULD fall back 526 to another pair of servers if a first query times out, with a 527 locally-determined limit for the number of fallback attempts that 528 will be performed. 530 3.5. Handling Network Changes 532 Whenever a client joins a new network, it SHOULD wait to receive 533 local configuration for resolvers before using any Designated DoH 534 servers. The local network might be authoritative for some names, or 535 might require filtering. 537 Once the local configuration of the new network has been received, 538 the client MAY use Designated DoH configuration that it discovered 539 when associated with another network. These configurations can still 540 be considered valid since they came from DNSSEC-signed records. 541 However, it is possible that different resolver IP addresses would be 542 returned when looking up the designated server on the new network, 543 which can provide a more optimal route through the Internet, so 544 clients SHOULD perform new queries to refresh their mappings by 545 making queries on connection on this new interface. 547 4. Server Requirements 549 Any server deployment that provides a set of services within one or 550 more domains, such as a CDN, can run a server node that allows 551 clients to run Adaptive DNS. A new server node can be added at any 552 time, and can be used once it is advertised to clients and can be 553 validated and whitelisted. The system overall is intended to scale 554 and provide improved performance as more nodes become available. 556 The basic requirements to participate as a server node in this 557 architecture are described below. 559 4.1. Provide a DoH Server 561 Each server node is primarily defined by a DoH server [RFC8484] that 562 is designated for a set of domains, and also provides Oblivious DoH 563 functionality. As such, the DoH servers MUST be able to act as 564 recursive resolvers that accept queries for records and domains 565 beyond those for which the servers are specifically designated. 567 4.1.1. Oblivious DoH Proxy 569 The DoH servers MUST be able to act as Oblivious Proxies. In this 570 function, they will proxy encrypted queries and answers between 571 clients and Oblivious Target DoH servers. 573 4.1.2. Oblivious DoH Target 575 The DoH servers MUST be able to act as Oblivious Targets. In this 576 function, they will accept encrypted proxied queries from clients via 577 Oblivious Proxy DoH servers, and provide encrypted answers using 578 client keys. 580 4.1.3. Keying Material 582 In order to support acting as an Oblivious Target, a DoH server needs 583 to provide a public HPKE [I-D.irtf-cfrg-hpke] key that can be used to 584 encrypt client queries. This key is advertised in the SVCB record 585 [I-D.pauly-dprive-oblivious-doh]. 587 DoH servers also SHOULD provide an ESNI [I-D.ietf-tls-esni] key to 588 encrypt the Server Name Indication field in TLS handshakes to the DoH 589 server. 591 4.2. Advertise the DoH Server 593 The primary mechanism for advertising a Designated DoH Server is a 594 SVCB DNS record (Section 3.1). This record MUST contain both the URI 595 Template of the DoH Server as well as the Oblivious DoH Public Key. 596 It MAY contain the ESNI key [I-D.ietf-tls-esni]. 598 Servers MUST ensure that any SVCB records are signed with DNSSEC 599 [RFC4033]. 601 4.3. Provide Extended Configuration as a Web PvD 603 Beyond providing basic DoH server functionality, server nodes SHOULD 604 provide a mechanism that allows clients to look up properties and 605 configuration for the server deployment. Amongst other information, 606 this configuration can optionally contain a list of some popular 607 domains for which this server is designated. Clients can use this 608 list to optimize lookups for common names. 610 This set of extended configuration information is referred to as a 611 Web Provisioning Domain, or a Web PvD. Provisioning Domains are sets 612 of consistent information that clients can use to access networks, 613 including rules for resolution and proxying. Generally, these PvDs 614 are provisioned directly, such as by a local router or a VPN. 615 [I-D.ietf-intarea-provisioning-domains] defines an extensible 616 configuration dictionary that can be used to add information to local 617 PvD configurations. Web PvDs share the same JSON configuration 618 format, and share the registry of keys defined as "Additional 619 Information PvD Keys". 621 If present, the PvD JSON configuration MUST be made available to 622 clients that request the "application/pvd+json" media type in a GET 623 request to the DoH server's URI 624 [I-D.ietf-intarea-provisioning-domains]. Clients MUST include this 625 media type as an Accept header in their GET requests, and servers 626 MUST mark this media type as their Content-Type header in responses. 627 If the PvD JSON format is not supported, the server MUST reply with 628 HTTP status code 415 [RFC7231]. 630 The "identifier" key in the JSON configuration SHOULD be the hostname 631 of the DoH Server itself. 633 For Web PvDs, the "prefixes" key within the JSON configuration SHOULD 634 contain an empty array. 636 The key "dnsZones", which contains an array of domains as strings 637 [I-D.ietf-intarea-provisioning-domains], indicates the zones that 638 belong to the PvD. Any zone that is listed in this array for a Web 639 PvD MUST have a corresponding SVCB record that defines the DoH server 640 as designated for the zone. Servers SHOULD include in this array any 641 names that are considered default or well-known for the deployment, 642 but is not required or expected to list all zones or domains for 643 which it is designated. The trade-off here is that zones that are 644 listed can be fetched and validated automatically by clients, thus 645 removing a bootstrapping step in discovering mappings from domains to 646 Designated DoH Servers. 648 Clients that retrieve the Web PvD JSON dictionary SHOULD perform an 649 SVCB record query for each of the entries in the "dnsZones" array in 650 order to populate the mappings of domains. These MAY be performed in 651 an oblivious fashion, but MAY also be queried directly on the DoH 652 server (since the information is not user-specific, but in response 653 to generic server-driven content). Servers can choose to 654 preemptively transfer the relevant SVCB records if the PvD 655 information retrieval is done with an HTTP version that supports PUSH 656 semantics. This allows the server to avoid a round trip in zone 657 validation even before the client has started requested SVCB records. 658 Once the client requests an SVCB record for one of the names included 659 in the "dnsZones" array, the server can also include the SVCB records 660 for the other names in the array in the Additionals section of the 661 DNS response. 663 This document also registers one new key in the Additional 664 Information PvD Keys registry, to identify the URI Template for the 665 DoH server Section 10. When included in Web PvDs, this URI MUST 666 match the template in the SVCB DNS Record. 668 Beyond providing resolution configuration, the Web PvD configuration 669 can be extended to offer information about proxies and other services 670 offered by the server deployment. Such keys are not defined in this 671 document. 673 5. Server Deployment Considerations 675 When servers designate DoH servers for their names, the specific 676 deployment model can impact the effective privacy and performance 677 characteristics. 679 5.1. Single Content Provider 681 If a name always resolves to server IP addresses that are hosted by a 682 single content provider, the name ought to designate a single DoH 683 server. This DoH server will be most optimal when it is designated 684 by many or all names that are hosted by the same content provider. 685 This ensures that clients can increase connection reuse to reduce 686 latency in connection setup. 688 A DoH server that corresponds to the content provider that hosts 689 content has an opportunity to tune the responses provided to a client 690 based on the location inferred by the client IP address. 692 5.2. Multiple Content Providers 694 Some hostnames may resolve to server IP addresses that are hosted by 695 multiple content providers. In such scenarios, the deployment may 696 want to be able to control the percentage of traffic that flows to 697 each content provider. 699 In these scenarios, there can either be: 701 o multiple designated DoH servers that are advertised via SVCB DNS 702 Records; or, 704 o a single designated DoH server that can be referenced by one or 705 more SVCB DNS Records, operated by a party that is aware of both 706 content providers and can manage splitting the traffic. 708 If a server deployment wants to easily control the split of traffic 709 between different content providers, it ought to use the latter model 710 of using a single designated DoH server that can better control which 711 IP addresses are provided to clients. Otherwise, if a client is 712 aware of multiple DoH servers, it might use a single resolver 713 exclusively, which may lead to inconsistent behavior between clients 714 that choose different resolvers. 716 5.3. Avoid Narrow Deployments 718 Using designated DoH servers can improve the privacy of name 719 resolution whenever a DoH server is designated by many different 720 names within one or more domains. This limits the amount of 721 information leaked to an attacker observing traffic between a client 722 and a DoH server: the attacker only learns that the client might be 723 resolving one of the many names for which the server is designated 724 (or might be performing an Oblivious query). 726 However, if a deployment designates a given DoH server for only one 727 name, or a very small set of names, then it becomes easier for an 728 attacker to infer that a specific name is being accessed by a client. 729 For this reason, deployments are encouraged to avoid deploying a DoH 730 server that is only designated by a small number of names. Clients 731 can also choose to only whitelist DoH servers that are associated 732 with many names. 734 Beyond the benefits to privacy, having a larger number of names 735 designate a given DoH server improves the opportunity for DoH 736 connection reuse, which can improve the performance of name 737 resolutions. 739 6. Local Resolver Deployment Considerations 741 A key goal of Adaptive DNS is that clients will be able to use 742 Designated DoH Servers to improve the privacy of queries, without 743 entirely bypassing local network authority and policy. For example, 744 if a client is attached to an enterprise Wi-Fi network that provides 745 access and resolution for private names not generally accessible on 746 the Internet, such names will only be usable when a local resolver is 747 used. 749 In order to achieve this, a local network can advertise itself as 750 authoritative for a domain, allowing it to be used prior to external 751 servers in the client resolution algorithm Section 3.3. 753 6.1. Designating Local DoH Servers 755 If a local network wants to have clients send queries for a set of 756 private domains to its own resolver, it needs to define an explicit 757 provisioning domain [I-D.ietf-intarea-provisioning-domains]. The PvD 758 RA option SHOULD set the H-flag to indicate that Additional 759 Information is available. This Additional Information JSON object 760 SHOULD include both the "dohTemplate" and "dnsZones" keys to define 761 the local DoH server and the domains over which it claims authority. 763 In order to validate that a local resolver is designated for a given 764 zone, the client SHOULD issue a SVCB record query for the names 765 specified in the PvD information, using the DoH server specified in 766 the PvD information. If there is no SVCB record for a name that 767 points to the DoH server that can be validated using DNSSEC, the 768 client SHOULD NOT automatically create a designation from the domain 769 name to DoH server. See specific use cases in Section 6.2 for cases 770 in which a local resolver may still be used. 772 Although local Designated DoH Servers MAY support proxying Oblivious 773 DoH queries, a client SHOULD NOT select one of these servers as an 774 Oblivious Proxy. Doing so might reveal the client's location to the 775 Target based on the address of the proxy, which could contribute to 776 deanonymizing the client. Clients can make an exception to this 777 behavior if the DoH server designated by the local network is known 778 to be a non-local service, such as when a local network configures a 779 centralized public resolver to handle its DNS operations. 781 6.2. Local Use Cases 783 The various use cases for selecting locally-provisioned resolvers 784 require different approaches for deployment and client resolution. 785 The following list is not exhaustive, but provides guidance on how 786 these scenarios can be achieved using the Adaptive DNS algorithm. 788 6.2.1. Accessing Local-Only Resolvable Content 790 Some names are not resolvable using generic DNS resolvers, but 791 require using a DNS server that can resolve private names. This is 792 common in enterprise scenarios, in which an enterprise can have a set 793 of private names that it allows to be resolved when connected to a 794 VPN or an enterprise-managed Wi-Fi network. In this case, clients 795 that do not use the locally-provisioned resolver will fail to resolve 796 private names. 798 In these scenarios, the local network SHOULD designate a local DoH 799 server for the domains that are locally resolvable. For example, an 800 enterprise that owns "private.example.org" would advertise 801 "private.example.org" in its PvD information along with a DoH URI 802 template. Clients could then use that locally-configured resolver 803 with names under "private.example.org" according to the rules in 804 Section 6.1. 806 In general, clients SHOULD only create designated DoH server 807 associations when they can validate a SVCB record using DNSSEC. 808 However, some deployments of private names might not want to sign all 809 private names within a zone. There are thus a few possible 810 deployment models: 812 o "private.example.org" does have a DNSSEC-signed SVCB record that 813 points to the local DoH server. The client requests the SVCB 814 record for "private.example.org" using the local DoH server that 815 is specified in the PvD information, and from that point on uses 816 the local DoH server for names under "private.example.org". 818 o Instead of signing "private.example.org", the deployment provides 819 a DNSSEC-signed SVCB record for "example.org", thus steering all 820 resolution under "example.org" to the local resolver. 822 o No DNSSEC-signed SVCB record designates the local server. In this 823 case, clients have a hint that the local network can serve names 824 under "private.example.org", but do not have a way to validate the 825 designation. Clients can in this case try to resolve names using 826 external servers (such as via Oblivious DoH), and then MAY fall 827 back to using locally-provisioned resolvers if the names do not 828 resolve externally. This approach has the risk of exposing 829 private names to public resolvers, which can be undesirable for 830 certain enterprise deployments. Alternatively, if the client 831 trusts the local network based on specific policy configured on 832 the client, it can choose to resolve these names locally first. 833 Note that this approach risks exposing names to a potentially 834 malicious network that is masquerading as an authority for private 835 names if the network cannot be validated in some other manner. 837 Deployments SHOULD use the one of the first two approaches (signing 838 their records) whenever possible; the case of providing unsigned 839 names is only described as a possibility for handling legacy 840 enterprise deployments. Clients SHOULD choose to ignore any locally 841 designated names that are not signed unless there is a specific 842 policy configuration on the client. 844 6.2.2. Accessing Locally Optimized Content 846 Other names may be resolvable both publicly and on the local 847 resolver, but have more optimized servers that are accessible only 848 via the local network. For example, a Wi-Fi provider may provide 849 access to a cache of video content that provides lower latency than 850 publicly-accessible caches. 852 Names that are hosted locally in this way SHOULD use a designation 853 with a DNSSEC-signed SVCB record for the name. If a client discovers 854 that a local resolver is designated for a given name, the client 855 SHOULD prefer using connections to this locally-hosted content rather 856 than names resolved externally. 858 Note that having a DNSSEC-signed designation to the local resolver 859 provides a clear indication that the entity that manages a given name 860 has an explicit relationship with the local network provider. 862 6.2.3. Walled-Garden and Captive Network Deployments 864 Some networks do not provide any access to the general Internet, but 865 host local content that clients can access. For example, a network 866 on an airplane can give access to flight information and in-flight 867 media, but will not allow access to any external hosts or DNS 868 servers. These networks are often described as "walled-gardens". 870 Captive networks [I-D.ietf-capport-architecture] are similar in that 871 they block access to external hosts, although they can provide 872 generic access after some time. 874 If a walled-garden or captive network defines a PvD with additional 875 information, it can define zones for names that it hosts, such as 876 "airplane.example.com". It can also provide a locally-hosted 877 encrypted DNS server. 879 However, if such a network does not support explicitly advertising 880 local names, clients that try to establish connections to DoH servers 881 will experience connection failures. In these cases, system traffic 882 that is used for connecting to captive portals SHOULD use local 883 resolvers. In addition, clients MAY choose to fall back to using 884 direct resolution without any encryption if they determine that all 885 connectivity is blocked otherwise. Note that this comes with a risk 886 of a network blocking connections in order to induce this fallback 887 behavior, so clients might want to inform users about this possible 888 attack where appropriate, or prefer to not fall back if there is a 889 concern about leaking user data. 891 6.2.4. Network-Based Filtering 893 Some networks currently rely on manipulating DNS name resolution in 894 order to apply content filtering rules to clients associated with the 895 network. Using encrypted DNS resolvers that are not participating in 896 this filtering can bypass such enforcement. However, simply blocking 897 connections for filtering is indistinguishable from a malicious 898 attack from a client's perspective. 900 In order to indicate the presence of filtering requirements, a 901 network deployment can add the "requireDNSFiltering" and 902 "dnsFilteredZones" keys to its PvD information. The 903 "dnsFilteredZones" entry can contain an array of strings, each of 904 which is a domain name that the network requires clients to resolve 905 using the local resolver. If the array contains the string ".", it 906 indicates the network requires filtering for all domains. If 907 "requireDNSFiltering" is present with a boolean value of true, the 908 network is indicating that it expects all client systems to send the 909 names indicated by "dnsFilteredZones" to the local resolver. If 910 "requireDNSFiltering" is not present or set to false, then the 911 filtering service is considered to be optional for clients that want 912 to use it as a service to enforce desired policy. 914 Clients that receive indication of filtering requirements SHOULD NOT 915 use any other resolver for the filtered domains, but treat the 916 network as claiming authority. However, since this filtering cannot 917 be authenticated, this behavior SHOULD NOT be done silently without 918 user consent. 920 Networks that try to interfere with connections to encrypted DNS 921 resolvers without indicating a requirement for filtering cannot be 922 distinguished from misconfigurations or network attacks. Clients MAY 923 choose to avoid sending any user-initiated connections on such 924 networks to prevent malicious interception. 926 7. Performance Considerations 928 One of the challenges of using non-local DNS servers (such as cloud- 929 based DoH servers) is that recursive queries made by these servers 930 will originate from an IP address that is not necessarily 931 geographically related to the client. Many DNS servers make 932 assumptions about the geographic locality of clients to their 933 recursive resolvers to optimize answers. To avoid this problem, the 934 client's subnet can be forwarded to the authoritative server by the 935 recursive using the EDNS0 Client Subnet feature. Oblivious DoH 936 discourages this practice for privacy reasons. However, sharing this 937 subnet, while detrimental to privacy, can result in better targeted 938 DNS resolutions. 940 Adaptive DNS splits DoH queries into two sets: those made to 941 Designated DoH Servers, and those made to Oblivious DoH servers. 942 Oblivious queries are sensitive for privacy, and can encounter 943 performance degradation as a result of not using the client subnet. 944 Queries to designated DoH servers, on the other hand, are sent 945 directly by clients, so the client IP address is made available to 946 these servers. Since these servers are designated by the authority 947 for the names, they can use the IP address subnet information to tune 948 DNS answers. 950 Based on these properties, clients SHOULD prefer lookups via 951 Designated DoH Servers over oblivious mechanisms whenever possible. 952 Servers can encourage this by setting large TTLs for SVCB records and 953 using longer TTLs for responses returned by their Designated DoH 954 Server endpoints which can be more confident they have accurate 955 addressing information. 957 8. Security Considerations 959 In order to avoid interception and modification of the information 960 retrieved by clients using Adaptive DNS, all exchanges between 961 clients and servers are performed over encrypted connections, e.g., 962 TLS. 964 Malicious adversaries may block client connections to all DoH or 965 Oblivious DoH services as a Denial-of-Service (DoS) measure. Clients 966 which cannot connect to any proxy may, by local policy, fall back to 967 unencrypted DNS if this occurs. 969 9. Privacy Considerations 971 Clients must be careful in determining to which DoH servers they send 972 queries directly without proxying. A malicious DoH server that can 973 direct queries to itself can track or profile client activity. In 974 order to avoid the possibility of a spoofed SVCB record designating a 975 malicious DoH server for a name, clients MUST ensure that such 976 records validate using DNSSEC [RFC4033]. 978 Even servers that are officially designated can risk leaking or 979 logging information about client lookups. Such risk can be mitigated 980 by further restricting the list of DoH servers that are whitelisted 981 for direct use based on client policy. 983 Using Oblivious DoH reduces the risk that a single DoH server can 984 track or profile a client. However, clients should exercise caution 985 when using Oblivious DoH responses from resolvers that do not carry 986 DNSSEC signatures. An adversarial Oblivious Target resolver that 987 wishes to learn the IP address of clients requesting resolution for 988 sensitive domains can redirect clients to unique addresses of its 989 choosing. Clients that use these answers when establishing TLS 990 connections may then leak their local IP address to chosen server. 991 Thus, when Oblivious DoH answers are returned without DNSSEC, 992 Privacy-Sensitive Connections concerned about this attack SHOULD 993 conceal their IP address via a TLS- or HTTP-layer proxy or some other 994 tunneling mechanism. 996 An adversary able to see traffic on each path segment of a DoH or 997 Oblivious DoH query (e.g., from client to proxy, proxy to target, and 998 target to an authoritative DNS server) can link queries to specific 999 clients with high probability. Failure to observe traffic on any one 1000 of these path segments makes this linkability increasingly difficult. 1001 For example, if an adversary can only observe traffic between a 1002 client and proxy and egress traffic from a target, then it may be 1003 difficult identify a specific client's query among the recursive 1004 queries generated by the target. 1006 10. IANA Considerations 1008 10.1. DoH Template PvD Key 1010 This document adds a key to the "Additional Information PvD Keys" 1011 registry [I-D.ietf-intarea-provisioning-domains]. 1013 +----------+----------+-------+-------------------------------------+ 1014 | JSON key | Descript | Type | Example | 1015 | | ion | | | 1016 +----------+----------+-------+-------------------------------------+ 1017 | dohTempl | DoH URI | Strin | "https://dnsserver.example.net/dns- | 1018 | ate | Template | g | query{?dns}" | 1019 | | [RFC8484 | | | 1020 | | ] | | | 1021 +----------+----------+-------+-------------------------------------+ 1023 10.2. DNS Filtering PvD Keys 1025 This document adds a key to the "Additional Information PvD Keys" 1026 registry [I-D.ietf-intarea-provisioning-domains]. 1028 +---------------------+-------------------------+---------+---------+ 1029 | JSON key | Description | Type | Example | 1030 +---------------------+-------------------------+---------+---------+ 1031 | requireDNSFiltering | A flag to indicate that | Boolean | true | 1032 | | the network requires | | | 1033 | | filtering all DNS | | | 1034 | | traffic using the | | | 1035 | | provisioned resolver. | | | 1036 | | | | | 1037 | dnsFilteredZones | A list of DNS domains | Array | [ "." ] | 1038 | | as strings that | of | | 1039 | | represent domains that | Strings | | 1040 | | can be filtered by the | | | 1041 | | provisioned resolver. | | | 1042 +---------------------+-------------------------+---------+---------+ 1044 Any network that sets the "requireDNSFiltering" boolean to false but 1045 provides "dnsFilteredZones" advertises the optional service of 1046 filtering on the provisioned network. 1048 An "." in the "dnsFilteredZones" array represents a wildcard, which 1049 can be used to indicate that the network is requesting to filter all 1050 names. Any more specific string represents a domain that requires 1051 filtering on the network. 1053 10.3. DoH URI Template DNS Parameter 1055 If present, this parameters indicates the URI template of a DoH 1056 server that is designated for use with the name being resolved. This 1057 is a string encoded as UTF-8 characters. 1059 Name: dohuri 1061 SvcParamKey: TBD 1063 Meaning: URI template for a designated DoH server 1065 Reference: This document. 1067 11. Acknowledgments 1069 Thanks to Erik Nygren, Lorenzo Colitti, Tommy Jensen, Mikael 1070 Abrahamsson, Ben Schwartz, Ask Hansen, Leif Hedstrom, Tim McCoy, 1071 Stuart Cheshire, Miguel Vega, Joey Deng, Ted Lemon, and Elliot Briggs 1072 for their feedback and input on this document. 1074 12. References 1076 12.1. Normative References 1078 [I-D.ietf-intarea-provisioning-domains] 1079 Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. 1080 Shao, "Discovering Provisioning Domain Names and Data", 1081 draft-ietf-intarea-provisioning-domains-08 (work in 1082 progress), October 2019. 1084 [I-D.ietf-tls-esni] 1085 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, 1086 "Encrypted Server Name Indication for TLS 1.3", draft- 1087 ietf-tls-esni-04 (work in progress), July 2019. 1089 [I-D.irtf-cfrg-hpke] 1090 Barnes, R. and K. Bhargavan, "Hybrid Public Key 1091 Encryption", draft-irtf-cfrg-hpke-00 (work in progress), 1092 July 2019. 1094 [I-D.nygren-dnsop-svcb-httpssvc] 1095 Schwartz, B., Bishop, M., and E. Nygren, "Service binding 1096 and parameter specification via the DNS (DNS SVCB and 1097 HTTPSSVC)", draft-nygren-dnsop-svcb-httpssvc-00 (work in 1098 progress), September 2019. 1100 [I-D.pauly-dprive-oblivious-doh] 1101 Kinnear, E., Pauly, T., Wood, C., and P. McManus, 1102 "Oblivious DNS Over HTTPS", draft-pauly-dprive-oblivious- 1103 doh-00 (work in progress), October 2019. 1105 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1106 Rose, "DNS Security Introduction and Requirements", 1107 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1108 . 1110 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1111 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1112 DOI 10.17487/RFC7231, June 2014, 1113 . 1115 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1116 and P. Hoffman, "Specification for DNS over Transport 1117 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1118 2016, . 1120 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1121 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1122 . 1124 12.2. Informative References 1126 [I-D.ietf-capport-architecture] 1127 Larose, K. and D. Dolson, "CAPPORT Architecture", draft- 1128 ietf-capport-architecture-04 (work in progress), June 1129 2019. 1131 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1132 Requirement Levels", BCP 14, RFC 2119, 1133 DOI 10.17487/RFC2119, March 1997, 1134 . 1136 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 1137 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 1138 . 1140 [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 1141 "IPv6 Router Advertisement Options for DNS Configuration", 1142 RFC 8106, DOI 10.17487/RFC8106, March 2017, 1143 . 1145 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1146 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1147 May 2017, . 1149 Authors' Addresses 1151 Eric Kinnear 1152 Apple Inc. 1153 One Apple Park Way 1154 Cupertino, California 95014 1155 United States of America 1157 Email: ekinnear@apple.com 1159 Tommy Pauly 1160 Apple Inc. 1161 One Apple Park Way 1162 Cupertino, California 95014 1163 United States of America 1165 Email: tpauly@apple.com 1167 Chris Wood 1168 Apple Inc. 1169 One Apple Park Way 1170 Cupertino, California 95014 1171 United States of America 1173 Email: cawood@apple.com 1175 Patrick McManus 1176 Fastly 1178 Email: mcmanus@ducksong.com