idnits 2.17.1 draft-wing-dnsop-structured-dns-error-page-03.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 (27 April 2022) is 727 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 444, but not defined ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-06) exists of draft-reddy-add-resolver-info-05 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 3 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 Updates: 8914 (if approved) T. Reddy 5 Intended status: Standards Track Akamai 6 Expires: 29 October 2022 N. Cook 7 Open-Xchange 8 M. Boucadair 9 Orange 10 27 April 2022 12 Structured Data for Filtered DNS 13 draft-wing-dnsop-structured-dns-error-page-03 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 updates RFC8914's EXTRA-TEXT field to provide 24 information on DNS filtering. This information can be parsed by the 25 client and displayed, logged, or used for other purposes. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 29 October 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. I-JSON in EXTRA-TEXT field . . . . . . . . . . . . . . . . . 6 63 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Client Generating Request . . . . . . . . . . . . . . . . 6 65 4.2. Server Generating Response . . . . . . . . . . . . . . . 7 66 4.3. Client Processing Response . . . . . . . . . . . . . . . 7 67 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 9.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 DNS filters are deployed for a variety of reasons including endpoint 79 security, parental filtering, and filtering required by law 80 enforcement. Network-based security solutions such as firewalls and 81 Intrusion Prevention Systems (IPS) rely upon network traffic 82 inspection to implement perimeter-based security policies and operate 83 by filtering DNS responses. In a home, DNS filtering is used for the 84 same reasons as above and additionally for parental control. 85 Internet Service Providers typically block access to some DNS domains 86 due to a requirement imposed by an external entity (e.g., law 87 enforcement agency) also performed using DNS-based content filtering. 89 Users of DNS services which perform filtering may wish to receive 90 more information about such filtering to resolve problems with the 91 filter -- for example to contact the administrator to allowlist a 92 domain that was erroneously filtered or to understand the reason a 93 particular domain was filtered. With that information, the user can 94 choose another network, open a trouble ticket with the DNS 95 administrator to resolve erroneous filtering, log the information, or 96 other uses. 98 DNS responses can be filtered by sending a bogus (also called, 99 "forged") A or AAAA response, NXDOMAIN error or empty answer, or an 100 extended DNS error (EDE) code defined in [RFC8914]. Each of these 101 methods have advantages and disadvantages that are discussed below: 103 1. The DNS response is forged to provide a list of IP addresses that 104 points to an HTTP(S) server alerting the end user about the 105 reason for blocking access to the requested domain (e.g., 106 malware). When an HTTP(S) enabled domain name is blocked, the 107 network security device (e.g., CPE, firewall) presents a block 108 page instead of the HTTP response from the content provider 109 hosting that domain. If an HTTP enabled domain name is blocked, 110 the network security device intercepts the HTTP request and 111 returns a block page over HTTP. If an HTTPS enabled domain is 112 blocked, the block page is also served over HTTPS. In order to 113 return a block page over HTTPS, man in the middle (MITM) is 114 enabled on endpoints by generating a local root certificate and 115 an accompanying (local) public/private key pair. The local root 116 certificate is installed on the endpoint while the network 117 security device(s) stores a copy of the private key. During the 118 TLS handshake, the network security device modifies the 119 certificate provided by the server and (re)signs it using the 120 private key from the local root certificate. 122 * However, configuring the local root certificate on endpoints 123 is not a viable option in several deployments like home 124 networks, schools, Small Office/Home Office (SOHO), and Small/ 125 Medium Enterprise (SME). In these cases, the typical behavior 126 is that the filtered DNS response points to a server that will 127 display the block page. If the client is using HTTPS (via web 128 browser or another application) this results in a certificate 129 validation error which gives no information to the end-user 130 about the reason for the DNS filtering. Browsers will display 131 errors such as "The security certificate presented by this 132 website was not issued by a trusted certificate authority" 133 (Internet Explorer/Edge"), "The site's security certificate is 134 not trusted" (Chrome), "This Connection is Untrusted" 135 (Firefox), "Safari can't verify the identity of the 136 website..." (Safari on MacOS). Applications might display 137 even more cryptic error messages. 139 * Enterprise networks do not assume that all the connected 140 devices are managed by the IT team or Mobile Device Management 141 (MDM) devices, especially in the quite common Bring Your Own 142 Device (BYOD) scenario. In addition, the local root 143 certificate cannot be installed on IoT devices without a 144 device management tool. 146 * An end user does not know why the connection was prevented 147 and, consequently, may repeatedly try to reach the domain but 148 with no success. Frustrated, the end user may switch to an 149 alternate network that offers no DNS filtering against malware 150 and phishing, potentially compromising both security and 151 privacy. Furthermore, certificate errors train users to click 152 through certificate errors, which is a bad security practice. 153 To eliminate the need for an end user to click through 154 certificate errors, an end user may manually install a local 155 root certificate on a host device. Doing so, however, is also 156 a bad security practice as it creates a security vulnerability 157 that may be exploited by a MITM attack. When a manually 158 installed local root certificate expires, the user has to 159 (again) manually install the new local root certificate. 161 2. The DNS response is forged to provide a NXDOMAIN response to 162 cause the DNS lookup to terminate in failure. In this case, an 163 end user does not know why the domain cannot be reached and may 164 repeatedly try to reach the domain but with no success. 165 Frustrated, the end user may use insecure connections to reach 166 the domain, potentially compromising both security and privacy. 168 3. The extended error codes Blocked, Censored, and Filtered defined 169 in Section 4 of [RFC8914] can be returned by a DNS server to 170 provide additional information about the cause of an DNS error. 171 If the extended error code "Forged Answer" defined in Section 4.5 172 of [RFC8914] is returned by the DNS server, the client can 173 identify the DNS response is forged together with the reason for 174 HTTPS certificate error. 176 4. These extended error codes do not suffer from the limitations 177 discussed in bullets (1) and (2), but the user still does not 178 know the exact reason nor he/she is aware of the exact entity 179 blocking the access to the domain. For example, a DNS server may 180 block access to a domain based on the content category such as 181 "Adult Content" to enforce parental control, "Violence & 182 Terrorism" due to an external requirement imposed by an external 183 entity (e.g., Law Enforcement Agency), etc. These content 184 categories cannot be standardized because the classification of 185 domains into content categories is vendor specific, typically 186 ranges from 40 to 100 types of categories depending on the vendor 187 and the categories keep evolving. Furthermore, the threat data 188 used to categorize domains may sometimes misclassify domains 189 (e.g., domains wrongly classified as Domain Generation Algorithm 190 (DGA) by deep learning techniques, domain wrongly classified as 191 phishing due to crowd sourcing, new domains not categorized by 192 the threat data). A user needs to know the contact details of 193 the IT/InfoSec team to raise a complaint. 195 5. When a resolver or forwarder forwards the received EDE option, 196 the EXTRA-TEXT field only conveys the source of the error 197 (Section 3 of [RFC8914]) and does not provide additional textual 198 information about the cause of the error. 200 For both DNS filtering mechanisms described above, the DNS server can 201 return extended error codes Blocked, Censored, Filtered, or Forged 202 Answer defined in Section 4 of [RFC8914]. However, these codes only 203 explain that filtering occurred but lack detail for the user to 204 diagnose erroneous filtering. 206 No matter which type of response is generated (forged IP address(es), 207 NXDOMAIN or empty answer, even with an extended error code), the user 208 who triggered the DNS query has little chance to understand which 209 entity filtered the query, how to report a mistake in the filter, or 210 why the entity filtered it at all. This document describes a 211 mechanism to provide such detail. 213 One of the other benefits of this approach is to eliminate the need 214 to "spoof" block pages for HTTPS resources. This is achieved since 215 clients implementing this approach would be able to display a 216 meaningful error message, and would not need to connect to such a 217 block page. This approach thus avoids the need to install a local 218 root certificate authority on those IT-managed devices. 220 This document describes a format for computer-parsable data in the 221 EXTRA-TEXT field of Extended DNS Errors [RFC8914]. 223 This document does not recommend DNS filtering but provides a 224 mechanism for better transparency to explain to the users why some 225 DNS queries are filtered. 227 2. Terminology 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 231 "OPTIONAL" in this document are to be interpreted as described in BCP 232 14 [RFC2119][RFC8174] when, and only when, they appear in all 233 capitals, as shown here. 235 This document uses terms defined in DNS Terminology [RFC8499]. 237 "Requestor" refers to the side that sends a request. "Responder" 238 refers to an authoritative, recursive resolver or other DNS component 239 that responds to questions. Other terminology is used here as 240 defined in the RFCs cited by this document. 242 "Encrypted DNS" refers to any encrypted scheme to convey DNS 243 messages, for example, DNS-over-HTTPS [RFC8484], DNS-over-TLS 244 [RFC7858], or DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. 246 3. I-JSON in EXTRA-TEXT field 248 Servers compliant with this specification send I-JSON data in the 249 EXTRA-TEXT field [RFC8914] using the Internet JSON (I-JSON) message 250 format [RFC7493]. 252 | Note that [RFC7493] was based on [RFC7159], but [RFC7159] was 253 | replaced by [RFC8259]. 255 This document defines the following JSON names: 257 c: (contact) The contact details of the IT/InfoSec team to report 258 mis-classified DNS filtering. This field is structured as an 259 array of contact URIs (e.g., tel, sips, https). At least one 260 contact URI MUST be included. This field is mandatory. 262 j: (justification) the textual justification for this particular DNS 263 filtering. This field is mandatory. 265 o: (organization) human-friendly name of the organization that 266 filtered this particular DNS query. This field is optional. 268 New JSON names MUST be defined in the IANA registry (Section 7), 269 consist only of lower-case ASCII characters, digits, and hyphens 270 (that is, Unicode characters U+0061 through 007A, U+0030 through 271 U+0039, and U+002D). These names MUST be 63 characters or shorter 272 and it is RECOMMENDED they be as short as possible. 274 To reduce packet overhead the generated JSON SHOULD be as short as 275 possible: short domain names, concise text in the values for the "j" 276 and "o" names, and minified JSON (that is, without spaces or line 277 breaks between JSON elements). 279 The JSON data can be parsed to display to the user, logged, or 280 otherwise used to assist the end-user or IT staff with 281 troubleshooting and diagnosing the cause of the DNS filtering. 283 4. Protocol Operation 285 4.1. Client Generating Request 287 When generating a DNS query, the client MUST include the OPT pseudo- 288 RR [RFC6891] to elicit the Extended DNS Error option [RFC8914] in the 289 DNS response. 291 4.2. Server Generating Response 293 When the DNS server filters its DNS response to an A or AAAA record 294 query, the DNS response MAY contain an empty answer, NXDOMAIN, or a 295 forged A or AAAA response, as desired by the DNS server. In 296 addition, if the query contained the OPT pseudo-RR the DNS server MAY 297 return more detail in the EXTRA-TEXT field as described in 298 Section 4.3. 300 Servers may decide to return small TTL values in filtered DNS 301 responses (e.g., 2 seconds) to handle domain category and reputation 302 updates. 304 4.3. Client Processing Response 306 On receipt of a DNS response with an Extended DNS Error option, the 307 following actions are performed if the EXTRA-TEXT field contains 308 valid JSON: 310 * The response MUST be received over an encrypted DNS channel. If 311 not, the requestor MUST discard data in the EXTRA-TEXT field. 313 * The response MUST be received from a DNS server which advertised 314 EDE support via RESINFO [I-D.reddy-add-resolver-info]. 316 * Servers which don't support this specification might use plain 317 text in the EXTRA-TEXT field so that requestors SHOULD properly 318 handle both plaintext and JSON text in the EXTRA-TEXT field. 320 * The DNS response MUST also contain an extended error code of 321 "Censored", "Blocked", "Filtered" or "Forged" [RFC8914], otherwise 322 the EXTRA-TEXT field is discarded. 324 * If either of the mandatory JSON names "c" and "j" are missing or 325 have empty values in the EXTRA-TEXT field, the entire JSON is 326 discarded. 328 * If a DNS client has enabled opportunistic privacy profile 329 (Section 5 of [RFC8310]) for DoT, the DNS client will either 330 fallback to an encrypted connection without authenticating the DNS 331 server provided by the local network or fallback to clear text 332 DNS, and cannot exchange encrypted DNS messages. Both of these 333 fallback mechanisms adversely impacts security and privacy. If 334 the DNS client has enabled opportunistic privacy profile for DoT, 335 the DNS client MUST ignore the EXTRA-TEXT field of the EDE 336 responses, but SHOULD process other parts of the response. 338 * If a DNS client has enabled strict privacy profile (Section 5 of 339 [RFC8310]) for DoT, the DNS client requires an encrypted 340 connection and successful authentication of the DNS server; this 341 mitigates both passive eavesdropping and client redirection (at 342 the expense of providing no DNS service if an encrypted, 343 authenticated connection is not available). If the DNS client has 344 enabled strict privacy profile for DoT, the client MAY process the 345 EXTRA-TEXT field of the DNS response. Note that the strict and 346 opportunistic privacy profiles as defined in [RFC8310] only apply 347 to DoT; there has been no such distinction made for DoH. 349 * If the DNS client determines that the encrypted DNS server does 350 not offer DNS filtering service, it MUST discard the EXTRA-TEXT 351 field of the EDE response. For example, the DNS client can learn 352 whether the encrypted DNS resolver performs DNS-based content 353 filtering or not by retrieving resolver information using the 354 method defined in [I-D.reddy-add-resolver-info]. 356 * When a forwarder receives an EDE option, whether or not (and how) 357 to pass along JSON information in the EXTRA-TEXT on to their 358 client is implementation dependent [RFC5625]. Implementations MAY 359 choose to not forward the JSON information, or they MAY choose to 360 create a new EDE option that conveys the information in the "c" 361 and "j" fields encoded in the JSON object. 363 5. Examples 365 An example showing the nameserver at 'ns.example.net' that filtered a 366 DNS "A" record query for 'example.org' is shown in Figure 1. 368 { 369 "c": ["tel:+358-555-1234567", "sips:bob@bobphone.example.com", 370 "https://ticket.example.com?d=example.org&t=1650560748"], 371 "j": "malware present for 23 days", 372 "o": "example.net Filtering Service" 373 } 375 Figure 1: JSON returned in EXTRA-TEXT field of Extended DNS Error 376 response 378 In Figure 2 the same content is shown with minified JSON (no 379 whitespace, no blank lines) with '\' line wrapping per [RFC8792]. 381 ============== NOTE: '\' line wrapping per RFC 8792 =============== 383 {"c":["tel:+358-555-1234567","sips:bob@bobphone.example.com", \ 384 "https://ticket.example.com?d=example.org&t=1650560748"], \ 385 "j":"malware present for 23 days","o":"example.net Filtering \ 386 Service"} 388 Figure 2: Minified response 390 6. Security Considerations 392 Security considerations in Section 6 of [RFC8914] apply to this 393 document. 395 To minimize impact of active on-path attacks on the DNS channel, the 396 client validates the response as described in Section 4.3. 398 A client might choose to display the information in the EXTRA-TEXT 399 field if and only if the encrypted resolver has sufficient 400 reputation, according to some local policy (e.g. user configuration, 401 administrative configuration, or a built-in list of respectable 402 resolvers). This limits the ability of a malicious encrypted 403 resolver to cause harm. If the client decides not to display the all 404 of the information in the EXTRA-TEXT field, it can be logged for 405 diagnostics purpose and the client can only display the resolver 406 hostname that blocked the domain and error description for the EDE 407 code to the end-user. 409 When displaying the free-form text of "c" and "j", the browser SHOULD 410 NOT make any of those elements into actionable (clickable) links. 412 An attacker might inject (or modify) the EDE EXTRA-TEXT field with an 413 DNS proxy or DNS forwarder that is unaware of EDE. Such a DNS proxy 414 or DNS forwarder will forward that attacker-controlled EDE option. 415 To prevent such an attack, clients supporting this document MUST 416 discard the EDE option if their DNS server does not signal EDE 417 support via RESINFO [I-D.reddy-add-resolver-info]. As recommended in 418 [I-D.reddy-add-resolver-info], RESINFO should be retrieved over an 419 encrypted DNS channel or integrity protected with DNSSEC. 421 7. IANA Considerations 423 This document requests IANA to register the "application/ 424 json+structured-dns-error" media type in the "Media Types" registry 425 [IANA-MediaTypes]. This registration follows the procedures 426 specified in [RFC6838]: 428 Type name: application 430 Subtype name: json+structured-dns-error 432 Required parameters: N/A 434 Optional parameters: N/A 436 Encoding considerations: as defined in Section NN of [RFCXXXX]. 438 Security considerations: See Section NNN of [RFCXXXX]. 440 Interoperability considerations: N/A 442 Published specification: [RFCXXXX] 444 Applications that use this media type: Section NNNN of [RFCXXXX]. 446 Fragment identifier considerations: N/A 448 Additional information: N/A 450 Person & email address to contact for further information: IETF, 451 iesg@ietf.org 453 Intended usage: COMMON 455 Restrictions on usage: none 457 Author: See Authors' Addresses section. 459 Change controller: IESG 461 Provisional registration? No 463 8. Changes 465 This section is to be removed before publishing as an RFC. 467 8.1. Changes from 02 to 03 469 * Require using RESINFO [I-D.reddy-add-resolver-info] in client 470 processing and added discussion of attack mitigation of using 471 RESINFO. 473 * Removed validation of URI domain suffix, which we can't do for 474 some URLs (e.g., tel:), is difficult/impossible for others when 475 3rd party is handling level one support (e.g., sips:). Instead 476 rely on RESINFO telling us if EDE is supported by the DNS server 477 and, if so, expect it to properly support EDE rather than blindly 478 forward an unknown DNS option. 480 * Removed 'partial URI' text 482 8.2. Changes from 01 to 02 484 * repurpose Extended DNS Error's EXTRA-TEXT field to carry JSON, 485 which also means this document updates RFC8914 487 * clarified DNS forwarders might forward EXTRA-TEXT without change 488 or might rewrite "j" and "d" 490 8.3. Changes from 00 to 01 492 * removed support for multiple responsible parties 494 * one-character JSON names to minimize JSON length 496 * partial URI sent in "c" and "r" names, combined with "d" name sent 497 in JSON to minimize attack surface and minimize JSON length 499 * moved EDNS(0) forgery-mitigation text, some Security 500 Considerations text, and some other text from 501 [I-D.reddy-dnsop-error-page] to this document 503 9. References 505 9.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, 509 DOI 10.17487/RFC2119, March 1997, 510 . 512 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 513 Specifications and Registration Procedures", BCP 13, 514 RFC 6838, DOI 10.17487/RFC6838, January 2013, 515 . 517 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 518 for DNS (EDNS(0))", STD 75, RFC 6891, 519 DOI 10.17487/RFC6891, April 2013, 520 . 522 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 523 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 524 2014, . 526 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 527 DOI 10.17487/RFC7493, March 2015, 528 . 530 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 531 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 532 May 2017, . 534 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 535 for DNS over TLS and DNS over DTLS", RFC 8310, 536 DOI 10.17487/RFC8310, March 2018, 537 . 539 9.2. Informative References 541 [I-D.ietf-dprive-dnsoquic] 542 Huitema, C., Dickinson, S., and A. Mankin, "DNS over 543 Dedicated QUIC Connections", Work in Progress, Internet- 544 Draft, draft-ietf-dprive-dnsoquic-12, 20 April 2022, 545 . 548 [I-D.reddy-add-resolver-info] 549 Reddy, T. and M. Boucadair, "DNS Resolver Information", 550 Work in Progress, Internet-Draft, draft-reddy-add- 551 resolver-info-05, 13 April 2022, 552 . 555 [I-D.reddy-dnsop-error-page] 556 Reddy, T., Cook, N., Wing, D., and M. Boucadair, "DNS 557 Access Denied Error Page", Work in Progress, Internet- 558 Draft, draft-reddy-dnsop-error-page-08, 4 June 2021, 559 . 562 [IANA-MediaTypes] 563 IANA, "Media Types", 564 . 566 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 567 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 568 . 570 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 571 and P. Hoffman, "Specification for DNS over Transport 572 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 573 2016, . 575 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 576 Interchange Format", STD 90, RFC 8259, 577 DOI 10.17487/RFC8259, December 2017, 578 . 580 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 581 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 582 . 584 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 585 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 586 January 2019, . 588 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 589 "Handling Long Lines in Content of Internet-Drafts and 590 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 591 . 593 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 594 Lawrence, "Extended DNS Errors", RFC 8914, 595 DOI 10.17487/RFC8914, October 2020, 596 . 598 Authors' Addresses 600 Dan Wing 601 Citrix Systems, Inc. 602 United States of America 603 Email: dwing-ietf@fuggles.com 605 Tirumaleswar Reddy 606 Akamai 607 Bangalore 608 Karnataka 609 India 610 Email: kondtir@gmail.com 612 Neil Cook 613 Open-Xchange 614 United Kingdom 615 Email: neil.cook@noware.co.uk 616 Mohamed Boucadair 617 Orange 618 35000 Rennes 619 France 620 Email: mohamed.boucadair@orange.com