idnits 2.17.1 draft-wing-dnsop-structured-dns-error-page-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 : ---------------------------------------------------------------------------- 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 (13 October 2021) is 919 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) == Missing Reference: 'RFCXXXX' is mentioned on line 507, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-05 == 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: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP WG D. Wing 3 Internet-Draft Citrix 4 Intended status: Standards Track T. Reddy 5 Expires: 16 April 2022 Akamai 6 N. Cook 7 Open-Xchange 8 M. Boucadair 9 Orange 10 13 October 2021 12 Structured Data for Filtered DNS 13 draft-wing-dnsop-structured-dns-error-page-01 15 Abstract 17 DNS filtering is widely deployed for network security, but filtered 18 DNS responses lack information for the end user to understand the 19 reason for the filtering. Existing mechanisms to provide detail to 20 end users cause harm especially if the blocked DNS response is to an 21 HTTPS website. 23 This document defines a mechanism to explain the reason for the DNS 24 filtering and provides HTTPS URIs to get more detail. This 25 information can be parsed by the client and displayed, logged, or 26 used for other purposes. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 16 April 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Structured Error EDNS(0) Option Code . . . . . . . . . . . . 6 64 4. Structured JSON . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. Client Generating Request . . . . . . . . . . . . . . . . 8 67 5.2. Server Generating Response . . . . . . . . . . . . . . . 8 68 5.3. Client Processing Response . . . . . . . . . . . . . . . 8 69 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 10.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 DNS filters are deployed for a variety of reasons including endpoint 81 security, parental filtering, and filtering required by law 82 enforcement. Network-based security solutions such as firewalls and 83 Intrusion Prevention Systems (IPS) rely upon network traffic 84 inspection to implement perimeter-based security policies and operate 85 by filtering DNS responses. In a home, DNS filtering is used for the 86 same reasons as above and additionally for parental control. 87 Internet Service Providers typically block access to some DNS domains 88 due to a requirement imposed by an external entity (e.g., law 89 enforcement agency) also performed using DNS-based content filtering. 91 Users of DNS services which perform filtering may wish to receive 92 more information about such filtering to resolve problems with the 93 filter -- for example to contact the administrator to whitelist a 94 domain that was erroneously filtered or to understand the reason a 95 particular domain was filtered. With that information, the user can 96 choose another network, open a trouble ticket with the DNS 97 administrator to resolve erroneous filtering, log the information, or 98 other uses. 100 DNS responses can be filtered by sending a bogus (also called, 101 "forged") A or AAAA response, NXDOMAIN error or empty answer, or an 102 extended DNS error (EDE) code defined in [RFC8914]. Each of these 103 methods have advantages and disadvantages that are discussed below: 105 1. The DNS response is forged to provide a list of IP addresses that 106 points to an HTTP(S) server alerting the end user about the 107 reason for blocking access to the requested domain (e.g., 108 malware). When an HTTP(S) enabled domain name is blocked, the 109 network security device (e.g., CPE, firewall) presents a block 110 page instead of the HTTP response from the content provider 111 hosting that domain. If an HTTP enabled domain name is blocked, 112 the network security device intercepts the HTTP request and 113 returns a block page over HTTP. If an HTTPS enabled domain is 114 blocked, the block page is also served over HTTPS. In order to 115 return a block page over HTTPS, man in the middle (MITM) is 116 enabled on endpoints by generating a local root certificate and 117 an accompanying (local) public/private key pair. The local root 118 certificate is installed on the endpoint while the network 119 security device(s) stores a copy of the private key. During the 120 TLS handshake, the network security device modifies the 121 certificate provided by the server and (re)signs it using the 122 private key from the local root certificate. 124 * However, configuring the local root certificate on endpoints 125 is not a viable option in several deployments like home 126 networks, schools, Small Office/Home Office (SOHO), and Small/ 127 Medium Enterprise (SME). In these cases, the typical behavior 128 is that the forged DNS response directs the user towards a 129 server hosted to display the block page which breaks the TLS 130 connection. For web-browsing this then results in an HTTPS 131 certificate error message indicating that a secure connection 132 could not be established, which gives no information to the 133 end-user about the reason for the error. The typical errors 134 are "The security certificate presented by this website was 135 not issued by a trusted certificate authority" (Internet 136 Explorer/Edge"), "The site's security certificate is not 137 trusted" (Chrome), "This Connection is Untrusted" (Firefox), 138 "Safari can't verify the identity of the website..." (Safari 139 on MacOS)". 141 * Enterprise networks do not assume that all the connected 142 devices are managed by the IT team or Mobile Device Management 143 (MDM) devices, especially in the quite common Bring Your Own 144 Device (BYOD) scenario. In addition, the local root 145 certificate cannot be installed on IoT devices without a 146 device management tool. 148 * An end user does not know why the connection was reset and, 149 consequently, may repeatedly try to reach the domain but with 150 no success. Frustrated, the end user may switch to an 151 alternate network that offers no DNS-level protection against 152 malware and phishing, potentially compromising both security 153 and privacy. Furthermore, certificate errors train users to 154 click through certificate errors, which is a bad security 155 practice. To eliminate the need for an end user to click 156 through certificate errors, an end user may manually install a 157 local root certificate on a host device. Doing so, however, 158 is also a bad security practice as it creates a security 159 vulnerability that may be exploited by a MITM attack. When a 160 manually installed local root certificate expires, the user 161 has to (again) manually install the new local root 162 certificate. 164 2. The DNS response is forged to provide a NXDOMAIN response to 165 cause the DNS lookup to terminate in failure. In this case, an 166 end user does not know why the domain cannot be reached and may 167 repeatedly try to reach the domain but with no success. 168 Frustrated, the end user may use insecure connections to reach 169 the domain, potentially compromising both security and privacy. 171 3. The extended error codes Blocked, Censored, and Filtered defined 172 in Section 4 of [RFC8914] can be returned by a DNS server to 173 provide additional information about the cause of an DNS error. 174 If the extended error code "Forged Answer" defined in Section 4.5 175 of [RFC8914] is returned by the DNS server, the client can 176 identify the DNS response is forged together with the reason for 177 HTTPS certificate error. 179 4. These extended error codes do not suffer from the limitations 180 discussed in bullets (1) and (2), but the user still does not 181 know the exact reason nor he/she is aware of the exact entity 182 blocking the access to the domain. For example, a DNS server may 183 block access to a domain based on the content category such as 184 "Adult Content" to enforce parental control, "Violence & 185 Terrorism" due to an external requirement imposed by an external 186 entity (e.g., Law Enforcement Agency), etc. These content 187 categories cannot be standardized because the classification of 188 domains into content categories is vendor specific, typically 189 ranges from 40 to 100 types of categories depending on the vendor 190 and the categories keep evolving. Furthermore, the threat data 191 used to categorize domains may sometimes misclassify domains 192 (e.g., domains wrongly classified as Domain Generation Algorithm 193 (DGA) by deep learning techniques, domain wrongly classified as 194 phishing due to crowd sourcing, new domains not categorized by 195 the threat data). A user needs to know the contact details of 196 the IT/InfoSec team to raise a complaint. 198 5. When a resolver or forwarder forwards the received EDE option, 199 the EXTRA-TEXT field only conveys the source of the error 200 (Section 3 of [RFC8914]) and does not provide additional textual 201 information about the cause of the error. 203 For both DNS filtering mechanisms described above, the DNS server can 204 return extended error codes Blocked, Censored, Filtered, or Forged 205 Answer defined in Section 4 of [RFC8914]. However, these codes only 206 explain that filtering occurred but lack detail for the user to 207 diagnose erroneous filtering. 209 No matter which type of response is generated (forged IP address(es), 210 NXDOMAIN or empty answer, even with an extended error code), the user 211 who triggered the DNS query has little chance to understand which 212 entity filtered the query, how to report a mistake in the filter, or 213 why the entity filtered it at all. This document describes a 214 mechanism to provide such detail. 216 One of the other benefits of this approach is to eliminate the need 217 to "spoof" block pages for HTTPS resources. This is achieved since 218 clients implementing this approach would be able to display a 219 meaningful error message, and would not need to connect to such a 220 block page. This approach thus avoids the need to install a local 221 root certificate authority on those IT-managed devices. 223 This document describes a protocol containing parsable data in a new 224 EDNS(0) [RFC6891] option code. 226 Clients indicate their support of this specification in their DNS 227 query so the DNS server can tailor its DNS response accordingly. The 228 information returned in a DNS response allows combinations of 229 headless devices (i.e., those lacking a display or other means to 230 communicate with a human), operating systems, and web browsers to be 231 informed of the filtering. This information returned can be logged 232 and/or displayed to the user, as appropriate for the user interface 233 capabilities of the client hardware and software. 235 This document does not recomment DNS filtering, but provides a 236 mechanism for better transparency to explain to the users why some 237 DNS queries are filtered. 239 2. Terminology 241 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 242 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 243 "OPTIONAL" in this document are to be interpreted as described in BCP 244 14 [RFC2119][RFC8174] when, and only when, they appear in all 245 capitals, as shown here. 247 This document uses terms defined in DNS Terminology [RFC8499]. 249 "Requestor" refers to the side that sends a request. "Responder" 250 refers to an authoritative, recursive resolver or other DNS component 251 that responds to questions. Other terminology is used here as 252 defined in the RFCs cited by this document. 254 "Encrypted DNS" refers to any encrypted scheme to convey DNS 255 messages, for example, DNS-over-HTTPS [RFC8484], DNS-over-TLS 256 [RFC7858], or DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. 258 3. Structured Error EDNS(0) Option Code 260 This document defines a new EDNS(0) [RFC6891] option code (OPT) to 261 include JSON providing information in the DNS response describing 262 filtering that occurred for this query, defined in Figure 1. 264 The value of this EDNS(0) option code (OPT) is TBA-BY-IANA. 266 1 1 1 1 1 1 267 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 268 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 269 | STRUCTURED-ERROR-LENGTH (fixed, two octets) | 270 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 271 / STRUCTURED-ERROR-JSON (variable size) / 272 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 274 Figure 1: Structured Error EDNS(0) Option Code 276 The description of the fields is as follows: 278 STRUCTURED-ERROR-LENGTH: Two octets containing the length of 279 STRUCTURED-ERROR-JSON, in octets. It MUST NOT be set to 0. 281 STRUCTURED-ERROR-JSON: JSON containing DNS filtering information 282 encoded in JSON, defined in Section 4. 284 4. Structured JSON 286 STRUCTURED-ERROR-JSON contains the following JSON names: 288 c: (complaint) a partial URI for the user to further diagnose and 289 possibly report mis-classified DNS filtering. The value is 290 converted to an expanded absolute URI. This field is optional, 291 but note its absence still allows a URI to be formed. 293 d: (domain) Contains the domain-name of the encrypted DNS server. 294 This is used to create the expanded URIs for both the "c" and "r" 295 fields, and also detect undesired forwarding of EDNS(0) options. 296 This field is mandatory. 298 j: (justification) the textual justification for this particular DNS 299 filtering. This field is mandatory. 301 o: (organization) human-friendly name of the organization that 302 filtered this particular DNS query. This field is optional. 304 r: (regulation) a partial URI to retrieve the public or private 305 rule, law, or regulation describing the reason for this DNS 306 filter. This might point at an employment agreement (for an 307 enterprise performing filtering) or a national government 308 regulation (for an ISP performing filtering). This field is 309 optional, but note its absence still allows a URI to be formed. 311 To reduce packet overhead the generated JSON SHOULD be as short as 312 possible: short domain names, concise text in the values for the "j" 313 and "o" names, and minified JSON (that is, without spaces or line 314 breaks between JSON elements). 316 The JSON data can be parsed to display to the user, logged, or 317 otherwise used to assist the end-user or IT staff with 318 troubleshooting and diagnosing the cause of the DNS filtering. 320 5. Protocol Operation 322 5.1. Client Generating Request 324 When generating a DNS query, the client MUST include the Structured 325 Error EDNS(0) option when encrypted DNS is used so the DNS server 326 knows that the client is compliant with this specification. 328 5.2. Server Generating Response 330 When the DNS server filters its DNS response to an A or AAAA record 331 query, the DNS response MAY contain an empty answer, NXDOMAIN, or a 332 forged A or AAAA response, as desired by the DNS server. In 333 addition, if the query contained the Structured Error EDNS(0) option, 334 the DNS server MAY return more detail in the STRUCTURED-ERROR-JSON, 335 as described below. 337 Over time a domain name might be filtered, then not filtered, then 338 filtered again. Additionally, the user might take minutes or even 339 days before investigating a filtered DNS query. Thus the complaint 340 URI is RECOMMENDED to include sufficient detail to determine the 341 filtering state when the DNS filtering occurred. If and how this is 342 encoded into the complaint URI is an implementation decision. 344 5.3. Client Processing Response 346 On receipt of the DNS response, the following actions are performed 347 specific to Structured Error EDNS(0) option, in no particular order: 349 * The requestor MUST check that the response was received over an 350 encrypted DNS channel. If not, the requestor MUST discard any 351 returned Structured Error EDNS(0) option. 353 * If the DNS response contains more than one Structured Error 354 EDNS(0) option, the requestor MUST discard all Structured Error 355 ENDS(0) options. 357 * The DNS response MUST also contain an extended error code of 358 "Censored", "Blocked", "Filtered" or "Forged", otherwise the 359 Structured Error EDNS(0) option is discarded. 361 * If either of the mandatory JSON names "d" and "j" are missing or 362 have empty values in the Structured Error EDNS(0) option, the 363 option is discarded. 365 * The Requestor expands the values in "c" and "r" by prefixing the 366 two values with "https://" and the value of the "d" name. Then 367 the Requestor further expands each of the "c" and "r" URIs by 368 appending two URL query parameters: "type" indicating the name of 369 the DNS resource record type queried and "name" indicating the 370 name of the DNS resource record queried. 372 | Note the parial URI value in "c" or "r" will already contain 373 | zero or more query parameters so implementations should 374 | substitute "?" and "&" accordingly. 376 * If a DNS client has enabled opportunistic privacy profile 377 (Section 5 of [RFC8310]) for DoT, the DNS client will either 378 fallback to an encrypted connection without authenticating the DNS 379 server provided by the local network or fallback to clear text 380 DNS, and cannot exchange encrypted DNS messages. Both of these 381 fallback mechanisms adversely impacts security and privacy. If 382 the DNS client has enabled opportunistic privacy profile for DoT, 383 the DNS client MUST ignore the Structured DNS Error EDNS(0) option 384 responses, but SHOULD process other parts of the response. 386 * If a DNS client has enabled strict privacy profile (Section 5 of 387 [RFC8310]) for DoT, the DNS client requires an encrypted 388 connection and successful authentication of the DNS server; this 389 mitigates both passive eavesdropping and client redirection (at 390 the expense of providing no DNS service if an encrypted, 391 authenticated connection is not available). If the DNS client has 392 enabled strict privacy profile for DoT, the client MAY process the 393 Structured DNS Error EDNS(0) option of the DNS response. Note 394 that the strict and opportunistic privacy profiles as defined in 395 [RFC8310] only apply to DoT; there has been no such distinction 396 made for DoH. 398 * If the DNS client determines that the encrypted DNS server does 399 not offer DNS filtering service, it MUST reject the Structured 400 Error EDNS(0) option. For example, the DNS client can learn 401 whether the encrypted DNS resolver performs DNS-based content 402 filtering or not by retrieving resolver information using the 403 method defined in [I-D.reddy-add-resolver-info]. 405 * DNS forwarders (or DNS proxies) are supposed to propagate unknown 406 EDNS(0) options (Sections 4.1 and 4.4.1 of [RFC5625]), which means 407 the Structured Error EDNS(0) option may get propagated by such a 408 DNS server. To detect this scenario, the DNS client MUST verify 409 the domain name in the Structured Error "d" value matches the 410 domain name of the encrypted DNS resolver. If this match fails, 411 the DNS client MUST ignore the Structured Error EDNS(0) option in 412 the response. 414 6. Examples 416 An example showing the nameserver at 'ns.example.net' that filtered a 417 DNS "A" record query for 'example.org' is shown in Figure 2. 419 { 420 "c": "?time=1621902483", 421 "d": "ns.example.com", 422 "j": "malware present for 23 days", 423 "o": "example.net Filtering Service", 424 "r": "?country=atlantis" 425 } 427 Figure 2: JSON returned in EDNS(0) Structured Error response 429 In Figure 3 the same content is shown with minified JSON (no 430 whitespace, no blank lines) with '\' line wrapping per [RFC8792]. 432 ============== NOTE: '\' line wrapping per RFC 8792 =============== 434 {"c":"?time=1621902483","d":"ns.example.com","j":"malware present \ 435 for 23 days","o":"example.net Filtering Service","r":\ 436 "?country=atlantis"} 438 Figure 3: Minified response 440 Upon receipt, the two partial URIs ("c" and "r") are expanded to 441 become fully-formed URIs. The class, type, and name are pulled from 442 the DNS response (that matches the associated query) so that the 443 fully-formed "c" URI becomes 444 "https://ns.example.net?time=1621902483&type=a&name=example.org" and 445 the "r" URI becomes 446 "https://ns.example.net?country=atlantis&type=a&name=example.org". 448 7. Security Considerations 450 Security considerations in Section 6 of [RFC8914] apply to this 451 document. 453 To minimize impact of active on-path attacks on the DNS channel, the 454 client validates the response as described in Section 5.3. 456 If the browser visits either of the URIs in the response ("c" or 457 "r"), the browser SHOULD reduce the attack surface of the client by 458 using an isolated environment precautions such as clearly labeling 459 the page as untrusted or prevent user interaction with the page. 460 Such isolation should prevent transmitting cookies, block JavaScript, 461 block auto-fill of credentials or personal information, and be 462 isolated from the user's normal environment. 464 When displaying the free-form text of "o" and "j", the browser SHOULD 465 NOT make any of those elements into actionable (clickable) links. 467 Although the "d" value is validated, an attacker who is able to 468 inject the Structured Error EDNS(0) option so that a DNS proxy or DNS 469 forwarder, unaware of the option, will forward it and pass the 470 validation checks described in Section 5.3. This means the other 471 JSON fields can be controlled by the attacker. The "j" and "o" 472 fields are, perhaps, the most interesting for an attacker to modify 473 for nefarious purposes, because the "d" field has to match the 474 encrypted DNS server's name and the expanded URIs from the "c" and 475 "r" will point at the DNS resolver not under the attacker's control. 477 | The authors anticipate enhancements to 478 | [I-D.reddy-add-resolver-info] will reduce or eliminate the 479 | concern described in previous paragraph. 481 8. IANA Considerations 483 This document requests IANA assign a DNS EDNS0 Option Code (OPT) 484 value in the Expert Review range named "Structured DNS Error". 486 This document requests IANA to register the "application/ 487 json+structured-dns-error" media type in the "Media Types" registry 488 [IANA-MediaTypes]. This registration follows the procedures 489 specified in [RFC6838]: 491 Type name: application 493 Subtype name: json+structured-dns-error 495 Required parameters: N/A 497 Optional parameters: N/A 499 Encoding considerations: as defined in Section NN of [RFCXXXX]. 501 Security considerations: See Section NNN of [RFCXXXX]. 503 Interoperability considerations: N/A 505 Published specification: [RFCXXXX] 507 Applications that use this media type: Section NNNN of [RFCXXXX]. 509 Fragment identifier considerations: N/A 511 Additional information: N/A 513 Person & email address to contact for further information: IETF, 514 iesg@ietf.org 516 Intended usage: COMMON 518 Restrictions on usage: none 520 Author: See Authors' Addresses section. 522 Change controller: IESG 524 Provisional registration? No 526 9. Changes 528 This section is to be removed before publishing as an RFC. 530 9.1. Changes from 00 to 01 532 * removed support for multiple responsible parties 534 * one-character JSON names to minimize JSON length 536 * partial URI sent in "c" and "r" names, combined with "d" name sent 537 in JSON to minimize attack surface and minimize JSON length 539 * moved EDNS(0) forgery-mitigation text, some Security 540 Considerations text, and some other text from 541 [I-D.reddy-dnsop-error-page] to this document 543 10. References 545 10.1. Normative References 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, 549 DOI 10.17487/RFC2119, March 1997, 550 . 552 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 553 Specifications and Registration Procedures", BCP 13, 554 RFC 6838, DOI 10.17487/RFC6838, January 2013, 555 . 557 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 558 for DNS (EDNS(0))", STD 75, RFC 6891, 559 DOI 10.17487/RFC6891, April 2013, 560 . 562 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 563 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 564 May 2017, . 566 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 567 for DNS over TLS and DNS over DTLS", RFC 8310, 568 DOI 10.17487/RFC8310, March 2018, 569 . 571 10.2. Informative References 573 [I-D.ietf-dprive-dnsoquic] 574 Huitema, C., Dickinson, S., and A. Mankin, "DNS over 575 Dedicated QUIC Connections", Work in Progress, Internet- 576 Draft, draft-ietf-dprive-dnsoquic-05, 11 October 2021, 577 . 580 [I-D.reddy-add-resolver-info] 581 Reddy, T. and M. Boucadair, "DNS Resolver Information", 582 Work in Progress, Internet-Draft, draft-reddy-add- 583 resolver-info-03, 13 April 2021, 584 . 587 [I-D.reddy-dnsop-error-page] 588 Reddy, T., Cook, N., Wing, D., and M. Boucadair, "DNS 589 Access Denied Error Page", Work in Progress, Internet- 590 Draft, draft-reddy-dnsop-error-page-08, 4 June 2021, 591 . 594 [IANA-MediaTypes] 595 IANA, "Media Types", 596 . 598 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 599 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 600 . 602 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 603 and P. Hoffman, "Specification for DNS over Transport 604 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 605 2016, . 607 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 608 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 609 . 611 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 612 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 613 January 2019, . 615 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 616 "Handling Long Lines in Content of Internet-Drafts and 617 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 618 . 620 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 621 Lawrence, "Extended DNS Errors", RFC 8914, 622 DOI 10.17487/RFC8914, October 2020, 623 . 625 Authors' Addresses 627 Dan Wing 628 Citrix Systems, Inc. 629 United States of America 631 Email: dwing-ietf@fuggles.com 632 Tirumaleswar Reddy 633 Akamai 634 Bangalore 635 Karnataka 636 India 638 Email: kondtir@gmail.com 640 Neil Cook 641 Open-Xchange 642 United Kingdom 644 Email: neil.cook@noware.co.uk 646 Mohamed Boucadair 647 Orange 648 35000 Rennes 649 France 651 Email: mohamed.boucadair@orange.com