idnits 2.17.1 draft-reddy-dnsop-error-page-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 4, 2021) is 1056 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) == Unused Reference: 'RFC4648' is defined on line 508, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-02 == Outdated reference: A later version (-06) exists of draft-reddy-add-resolver-info-03 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP WG T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track N. Cook 5 Expires: December 6, 2021 Open-Xchange 6 D. Wing 7 Citrix 8 M. Boucadair 9 Orange 10 June 4, 2021 12 DNS Access Denied Error Page 13 draft-reddy-dnsop-error-page-08 15 Abstract 17 When a DNS server filters a query, the response to such query conveys 18 no detailed explanation that elaborates why that query was blocked, 19 leading thus to end-user confusion. A solution to this problem is 20 needed in order to enhance the user experience. 22 This document defines a method to return an URI that explains the 23 reason why a DNS query was filtered by a DNS server. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 6, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Error Page URI EDNS0 Option Format . . . . . . . . . . . . . 6 62 4. Error Page URI Processing . . . . . . . . . . . . . . . . . . 7 63 4.1. Mitigating EDNS0 Forgery . . . . . . . . . . . . . . . . 8 64 5. Error Page . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6. Usability Considerations . . . . . . . . . . . . . . . . . . 10 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 8.1. A New Error Page URI EDNS Option . . . . . . . . . . . . 11 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 10.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 DNS filters are deployed for a variety of reasons, including endpoint 78 security, parental filtering, and filtering required by law 79 enforcement. Some of these reasons are discussed in more detail 80 below: 82 o Various network security services are provided by Enterprise 83 networks to protect endpoints (e.g., Hosts including IoT devices). 84 Network-based security solutions such as firewalls and Intrusion 85 Prevention Systems (IPS) rely upon network traffic inspection to 86 implement perimeter-based security policies. The network security 87 services may, for example, prevent malware download, block known 88 malicious domains, block phishing sites, etc. 90 These network security services act on DNS queries originating 91 from endpoints. For example, DNS firewalls, a method of 92 expressing DNS response policy information inside specially 93 constructed DNS zones, known as Response Policy Zones (RPZs) 94 allows DNS servers to modify their DNS responses in real time in 95 order to stop access to malware and phishing domains. Note that 96 some of the commonly known types of malware are viruses, worms, 97 trojans, bots, ransomware, backdoors, spyware, and adware. 99 o Network devices in a home network offer network security to 100 protect the devices within the home network by performing DNS- 101 based content filtering. The network security service may, for 102 example, block access to specific domains to enforce parental 103 control, block access to malware sites, etc. 105 o Internet Service Providers (ISPs) typically block access to some 106 DNS domains due to a requirement imposed by an external entity 107 (e.g., Law Enforcement Agency). Such blocking is performed using 108 DNS-based content filtering. 110 DNS responses can be filtered by sending a bogus (also called, 111 "forged") A or AAAA response, NXDOMAIN error or empty answer, or an 112 extended DNS error (EDE) code defined in [RFC8914]. Each of these 113 methods have advantages and disadvantages that are discussed below: 115 1. The DNS response is forged to provide a list of IP addresses that 116 points to an HTTP(S) server alerting the end user about the 117 reason for blocking access to the requested domain (e.g., 118 malware). When an HTTP(S) enabled domain name is blocked, the 119 network security device (e.g., CPE, firewall) presents a block 120 page instead of the HTTP response from the content provider 121 hosting that domain. If an HTTP enabled domain name is blocked, 122 the network security device intercepts the HTTP request and 123 returns a block page over HTTP. If an HTTPS enabled domain is 124 blocked, the block page is also served over HTTPS. In order to 125 return a block page over HTTPS, man in the middle (MITM) is 126 enabled on endpoints by generating a local root certificate and 127 an accompanying (local) public/private key pair. The local root 128 certificate is installed on the endpoint while the network 129 security device(s) stores a copy of the private key. During the 130 TLS handshake, the network security device modifies the 131 certificate provided by the server and (re)signs it using the 132 private key from the local root certificate. 134 * However, configuring the local root certificate on endpoints 135 is not a viable option in several deployments like home 136 networks, schools, Small Office/Home Office (SOHO), and Small/ 137 Medium Enterprise (SME). In these cases, the typical behavior 138 is that the forged DNS response directs the user towards a 139 server hosted to display the block page which breaks the TLS 140 connection. For web-browsing this then results in an HTTPS 141 certificate error message indicating that a secure connection 142 could not be established, which gives no information to the 143 end-user about the reason for the error. 145 The typical errors are "The security certificate presented by 146 this website was not issued by a trusted certificate 147 authority" (Internet Explorer/Edge"), "The site's security 148 certificate is not trusted" (Chrome), "This Connection is 149 Untrusted" (Firefox), "Safari can't verify the identity of the 150 website..." (Safari on MacOS)". 152 * Enterprise networks do not assume that all the connected 153 devices are managed by the IT team or Mobile Device Management 154 (MDM) devices, especially in the quite common Bring Your Own 155 Device (BYOD) scenario. In addition, the local root 156 certificate cannot be installed on IoT devices without a 157 device management tool. 159 * An end user does not know why the connection was reset and, 160 consequently, may repeatedly try to reach the domain but with 161 no success. Frustrated, the end user may switch to an 162 alternate network that offers no DNS-level protection against 163 malware and phishing, potentially compromising both security 164 and privacy. Furthermore, certificate errors train users to 165 click through certificate errors, which is a bad security 166 practice. To eliminate the need for an end user to click 167 through certificate errors, an end user may manually install a 168 local root certificate on a host device (e.g. 169 [Chrome-Install-Cert]). Doing so, however, is also a bad 170 security practice as it creates a security vulnerability that 171 may be exploited by a MITM attack. When a manually installed 172 local root certificate expires, the user has to (again) 173 manually install the new local root certificate. 175 2. The DNS response is forged to provide a NXDOMAIN response to 176 cause the DNS lookup to terminate in failure. In this case, an 177 end user does not know why the domain cannot be reached and may 178 repeatedly try to reach the domain but with no success. 179 Frustrated, the end user may use insecure connections to reach 180 the domain, potentially compromising both security and privacy. 182 3. The extended error codes Blocked, Censored, and Filtered defined 183 in Section 4 of [RFC8914] can be returned by a DNS server to 184 provide additional information about the cause of an DNS error. 185 If the extended error code "Forged Answer" defined in Section 4.5 186 of [RFC8914] is returned by the DNS server, the client can 187 identify the DNS response is forged together with the reason for 188 HTTPS certificate error. 190 These extended error codes do not suffer from the limitations 191 discussed in bullets (1) and (2), but the user still does not 192 know the exact reason nor he/she is aware of the exact entity 193 blocking the access to the domain. For example, a DNS server may 194 block access to a domain based on the content category such as 195 "Adult Content" to enforce parental control, "Violence & 196 Terrorism" due to an external requirement imposed by an external 197 entity (e.g., Law Enforcement Agency), etc. These content 198 categories cannot be standardized because the classification of 199 domains into content categories is vendor specific, typically 200 ranges from 40 to 100 types of categories depending on the vendor 201 and the categories keep evolving. Furthermore, the threat data 202 used to categorize domains may sometimes misclassify domains 203 (e.g., domains wrongly classified as Domain Generation Algorithm 204 (DGA) by deep learning techniques, domain wrongly classified as 205 phishing due to crowd sourcing, new domains not categorized by 206 the threat data). A user needs to know the contact details of 207 the IT/InfoSec team to raise a complaint. 209 4. The EXTRA-TEXT field of the EDE option defined in Section 2 of 210 [RFC8914] can include additional textual information about the 211 cause of the error, but the information could be provided in a 212 language that is not understood by the user. When a resolver or 213 forwarder forwards the received EDE option, the EXTRA-TEXT field 214 only conveys the source of the error (Section 3 of [RFC8914]) and 215 does not provide additional textual information about the cause 216 of the error. Most importantly, EDE option does not offer 217 authenticated information; it can thus be spoofed by an attacker. 218 In addition, the additional textual information may not be able 219 to convey all of the required information about the cause of the 220 DNS error because lengthy EXTRA-TEXT content would be truncated 221 to prevent fragmentation (Section 3 of [RFC8914]). 223 No matter which type of response is generated (forged IP address(es), 224 NXDOMAIN or empty answer, or an extended error code), the user who 225 triggered the DNS query has little chance to understand which entity 226 filtered the query, how to report a mistake in the filter, or why the 227 entity filtered it at all. This document describes a mechanism to 228 provide an URI which, when accessed, provides such information to the 229 user. 231 One of the other benefits of this approach is to eliminate the need 232 to "spoof" block pages for HTTPS resources. This is achieved as the 233 block page no longer needs to create a signed certificate when 234 blocking a destination. This approach avoids the need to install a 235 local root certificate authority on those IT-managed devices. 237 2. Terminology 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 241 "OPTIONAL" in this document are to be interpreted as described in BCP 242 14 [RFC2119][RFC8174] when, and only when, they appear in all 243 capitals, as shown here. 245 This document makes use of the terms defined in [RFC8499]. 247 'Encrypted DNS' refers to any encrypted scheme to convey DNS 248 messages, for example, DNS-over-HTTPS [RFC8484], DNS-over-TLS 249 [RFC7858], or DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. 251 3. Error Page URI EDNS0 Option Format 253 This document uses an EDNS0 [RFC6891] option to include the URI that 254 provides additional information in a DNS response about the cause of 255 blocking access to a requested domain. This option is structured as 256 depicted in Figure 1. 258 1 1 1 1 1 1 259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 260 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 261 | OPTION-CODE | 262 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 263 | OPTION-LENGTH | 264 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 265 | ERROR-PAGE-URI-LENGTH (fixed size) | 266 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 267 / ERROR-PAGE-URI (variable size) / 268 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 270 Figure 1: Error Page URI EDNS0 Option Format 272 The description of the fields is as follows: 274 o OPTION-CODE: TBD, indicates the code assigned for Error Page URI 275 (Section 6.1.2 of [RFC6891]). [RFC Editor: change TBD to the 276 proper code once assigned by IANA.] 278 o OPTION-LENGTH: See Section 6.1.2 of [RFC6891]. This field 279 contains the length of the payload (everything after OPTION- 280 LENGTH) in octets. The variability of the option length stems 281 from the variable-length ERROR-PAGE-URI field. 283 o ERROR-PAGE-URI-LENGTH: This 16-bit field indicates the length of 284 ERROR-PAGE-URI. It MUST NOT be set to 0. 286 o ERROR-PAGE-URI: A variable length UTF-8 encoded [RFC5198] text 287 field containing the URI Template [RFC6570] that gives additional 288 information about the cause of blocking access to a domain. The 289 ERROR-PAGE-URI field MUST NOT be zero octets in length. 291 The Error Page URI option can be included in any response (SERVFAIL, 292 NXDOMAIN, REFUSED, and even NOERROR, etc.) to a query that includes 293 OPT Pseudo-RR [RFC6891]. 295 The URI Template defined in ERROR-PAGE-URI describes how to construct 296 the URL to fetch the error page. The agent acting as the HTTPS 297 client on the endpoint encodes an FQDN to which access is denied into 298 an HTTP GET request to retrieve the error page. The HTTPS server 299 returning the error page defines the URI used by the HTTP GET request 300 through the use of a URI Template. The URI Template is processed 301 with a defined variable "target-domain" whose value is set to the 302 FQDN to which access is denied. 304 The FQDN is provided as the variable value for "target-domain" to 305 expand the URI Template into an URI reference in the HTTP GET 306 request. 308 An example is illustrated below: 310 If the URI Template is "https://resolver.example.net/block- 311 page{?target-domain}" for the HTTPS server returning the error 312 page and access to the target domain "example.com" is blocked by 313 the encrypted DNS server, the variable "target-domain" has the 314 value "example.com" sent in an HTTP GET request. In the above 315 example, the expansion of the above URI Template is 316 "https://resolver.example.net/block-page?target- 317 domain=example.com". 319 HTTP/2 [RFC7540] is the minimum RECOMMENDED HTTP version to use to 320 retrieve the error page. The HTTPS client retrieving the error page 321 MUST verify the entire certification path as per [RFC5280]. The 322 HTTPS client additionally uses validation techniques described in 323 [RFC6125] to compare the domain name in the error page URI to the 324 server certificate provided in TLS handshake. See [RFC7525] for 325 additional TLS recommendations. 327 4. Error Page URI Processing 329 The DNS client MUST follow the rules below to process the Error Page 330 URI EDNS0 option: 332 o If the DNS response contains more than one Error Page URI EDNS0 333 option, the DNS client MUST discard all Error Page URI EDNS0 334 options in the DNS response. 336 o The Error Page URI EDNS0 option MUST be processed by the DNS 337 client for a "Censored", "Blocked", "Filtered" or "Forged" 338 extended error codes and MUST be ignored for any other type of 339 extended DNS error code. When "Censored", "Blocked", "Filtered" 340 or "Forged" extended error code is returned in conjunction with an 341 Error Page URI EDNS0 option, any other resource records in the 342 answer MUST be ignored by clients supporting this specification. 344 o The DNS client MUST reject the error page URI if the scheme is not 345 "https". 347 4.1. Mitigating EDNS0 Forgery 349 The Error Page URI EDNS0 option is susceptible to forgery. An 350 attacker (e.g., a man in the middle (MITM)) could insert an extended 351 Error Page URI EDNS0 option into the DNS response causing a client to 352 attempt to visit that URI. For instance, the attacker can be located 353 between the stub resolver and DNS recursive server or between the DNS 354 proxy and the upstream resolver. To mitigate that attack, the 355 following measures are enforced: 357 o The DNS client MUST NOT process the DNS response with Error Page 358 URI EDNS0 option unless DNS messages exchanged are 359 cryptographically protected using encrypted DNS. 361 o If a DNS client has enabled opportunistic privacy profile 362 (Section 5 of [RFC8310]) for DoT, the DNS client will either 363 fallback to an encrypted connection without authenticating the DNS 364 server provided by the local network or fallback to clear text 365 DNS, and cannot exchange encrypted DNS messages. Both of these 366 fallback mechanisms adversely impacts security and privacy. If 367 the DNS client has enabled opportunistic privacy profile for DoT, 368 the DNS client MUST ignore Error Page URI EDNS0 option in 369 responses, but SHOULD process other parts of the response. 371 o If a DNS client has enabled strict privacy profile (Section 5 of 372 [RFC8310]) for DoT, the DNS client requires an encrypted 373 connection and successful authentication of the DNS server; this 374 mitigates both passive eavesdropping and client redirection (at 375 the expense of providing no DNS service if an encrypted, 376 authenticated connection is not available). If the DNS client has 377 enabled strict privacy profile for DoT, the client can process the 378 DNS response with Error Page URI EDNS0 option. Note that the 379 strict and opportunistic privacy profiles as defined in [RFC8310] 380 only applies to DoT protocol, there has been no such distinction 381 made for DoH protocol. 383 o If the DNS client determines that the encrypted DNS server does 384 not offer DNS filtering service, it MUST reject the Error Page URI 385 EDNS0 option. For example, the DNS client can learn whether the 386 encrypted DNS resolver performs DNS-based content filtering or not 387 by retrieving resolver information using the method defined in 388 [I-D.reddy-add-resolver-info]. 390 o DNS forwarders (or DNS proxies) are supposed to propagate unknown 391 EDNS0 options (Sections 4.1 and 4.4.1 of [RFC5625]), which means 392 the Error Page URI EDNS0 option may get propagated by such a DNS 393 server. To detect this scenario, the DNS client MUST verify the 394 domain name in the Error Page URI matches the domain name of the 395 encrypted DNS resolver. If this match fails, the DNS client MUST 396 ignore Error Page URI EDNS0 option in the response, but SHOULD 397 process other parts of the response. 399 5. Error Page 401 The following outlines the RECOMMENDED contents of an error page to 402 assist the operator developing the error page: 404 o The exact reason for blocking access to the domain. If the domain 405 is blocked based on some threat data, the threat type associated 406 with the blocked domain can be provided/displayed to the end user. 407 For example, the reason can indicate the type of malware blocked 408 like spyware and the damage it can do the security and privacy of 409 the user. 411 o The domain name blocked. 413 o If query was blocked by regulation, a pointer to a regulatory text 414 that mandates this query block. 416 o The entity (or organization) blocking the access to the domain and 417 contact details of the IT/InfoSec team to raise a complaint. 419 o The blocked error page to not include Ads and dynamic content. 421 The content of the error page discussed above is non-normative, the 422 above text only provides the guidelines and template for the error 423 page and: 425 o does not attempt to offer an exhaustive list for the contents of 426 an error page. 428 o it is not intended to form the basis of any legal/compliance for 429 developing the error page. 431 6. Usability Considerations 433 The error page SHOULD be returned in the user's preferred language as 434 expressed by the Accept-Language HTTP header. 436 7. Security Considerations 438 Security considerations in Section 6 of [RFC8914] and [RFC8624] need 439 to be taken into consideration. 441 The Error Page URI EDNS0 option causes an HTTPS retrieval by the 442 client. To prevent forgery of the Error Page URI EDNS0 option, this 443 specification requires it only be sent only over an encrypted DNS 444 channel with an authorized DNS server. 446 The client knows it is connecting to a HTTPS server returning the 447 error page. To reduce threat surface the client can retrieve the 448 Error Page URL using, for example, an isolated environment and take 449 other precautions such as clearly labeling the page as untrusted or 450 prevent user interaction with the page. Such isolation should 451 prevent transmitting cookies, block JavaScript, block auto-fill of 452 credentials or personal information, and be isolated from the user's 453 normal environment. 455 Browsers perform some of the above restrictions when accessing 456 captive portals (Section 5 of [RFC8910] or [Safari-Cookie]), during 457 private browsing, or using containerization [Facebook-Container]. 459 Note that the means to use a sandbox environment and a user interface 460 presenting the error page are not covered in this document. By its 461 nature, these aspects are implementation specific and best left to 462 the application and user interface designers. 464 The encrypted DNS session provides transport security for the 465 interaction between the DNS client and server, but DNSSEC signing and 466 validation is not possible for the Error Page URI EDNS0 option 467 returning the Error Page URI Template. However, this specification 468 mandates the DNS client to not process DNS response with Error Page 469 URI EDNS0 option if domain name in the Error Page URI does not match 470 the domain name of the encrypted DNS server. The validation ensures 471 both the servers are operated by the same entity and have the same 472 origin (similar to the Same Origin Policy (SOP)). 474 By design, the object referenced by the error page URL potentially 475 exposes additional information about the DNS resolution process that 476 may leak information. An example of this is the reason for blocking 477 the access to the domain name and the entity blocking access to the 478 domain. 480 8. IANA Considerations 482 8.1. A New Error Page URI EDNS Option 484 This document defines a new EDNS(0) option, entitled "Error Page 485 URI", assigned a value of TBD from the "DNS EDNS0 Option Codes (OPT)" 486 registry [to be removed upon publication: 487 [http://www.iana.org/assignments/dns-parameters/dns- 488 parameters.xhtml#dns-parameters-11] 490 Value Name Status Reference 491 ----- ---------------- ------ ------------------ 492 TBD Error Page URI Standard [ This document ] 494 9. Acknowledgements 496 Thanks to Vittorio Bertola, Wes Hardaker, Ben Schwartz, Erid Orth, 497 Viktor Dukhovni, Warren Kumari and Bob Harold for the comments. 499 10. References 501 10.1. Normative References 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 509 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 510 . 512 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 513 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 514 . 516 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 517 Housley, R., and W. Polk, "Internet X.509 Public Key 518 Infrastructure Certificate and Certificate Revocation List 519 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 520 . 522 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 523 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 524 . 526 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 527 Verification of Domain-Based Application Service Identity 528 within Internet Public Key Infrastructure Using X.509 529 (PKIX) Certificates in the Context of Transport Layer 530 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 531 2011, . 533 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 534 and D. Orchard, "URI Template", RFC 6570, 535 DOI 10.17487/RFC6570, March 2012, 536 . 538 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 539 for DNS (EDNS(0))", STD 75, RFC 6891, 540 DOI 10.17487/RFC6891, April 2013, 541 . 543 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 544 "Recommendations for Secure Use of Transport Layer 545 Security (TLS) and Datagram Transport Layer Security 546 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 547 2015, . 549 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 550 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 551 DOI 10.17487/RFC7540, May 2015, 552 . 554 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 555 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 556 May 2017, . 558 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 559 for DNS over TLS and DNS over DTLS", RFC 8310, 560 DOI 10.17487/RFC8310, March 2018, 561 . 563 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 564 Requirements and Usage Guidance for DNSSEC", RFC 8624, 565 DOI 10.17487/RFC8624, June 2019, 566 . 568 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 569 Lawrence, "Extended DNS Errors", RFC 8914, 570 DOI 10.17487/RFC8914, October 2020, 571 . 573 10.2. Informative References 575 [Chrome-Install-Cert] 576 "How to manually install the Securly SSL certificate in 577 Chrome", . 581 [Facebook-Container] 582 "Facebook container for Firefox", 583 . 586 [I-D.ietf-dprive-dnsoquic] 587 Huitema, C., Mankin, A., and S. Dickinson, "Specification 588 of DNS over Dedicated QUIC Connections", draft-ietf- 589 dprive-dnsoquic-02 (work in progress), February 2021. 591 [I-D.reddy-add-resolver-info] 592 Reddy, T. and M. Boucadair, "DNS Resolver Information", 593 draft-reddy-add-resolver-info-03 (work in progress), April 594 2021. 596 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 597 and P. Hoffman, "Specification for DNS over Transport 598 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 599 2016, . 601 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 602 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 603 . 605 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 606 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 607 January 2019, . 609 [RFC8910] Kumari, W. and E. Kline, "Captive-Portal Identification in 610 DHCP and Router Advertisements (RAs)", RFC 8910, 611 DOI 10.17487/RFC8910, September 2020, 612 . 614 [Safari-Cookie] 615 "Isolated cookie store (CVE-2016-1730)", 616 . 618 Authors' Addresses 620 Tirumaleswar Reddy 621 McAfee, Inc. 622 Embassy Golf Link Business Park 623 Bangalore, Karnataka 560071 624 India 626 Email: kondtir@gmail.com 628 Neil Cook 629 Open-Xchange 630 UK 632 Email: neil.cook@noware.co.uk 634 Dan Wing 635 Citrix Systems, Inc. 636 USA 638 Email: dwing-ietf@fuggles.com 640 Mohamed Boucadair 641 Orange 642 Rennes 35000 643 France 645 Email: mohamed.boucadair@orange.com