idnits 2.17.1 draft-wing-dnsop-structured-dns-error-page-00.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 (9 July 2021) is 1021 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 269, but not defined == Outdated reference: A later version (-12) exists of draft-ietf-dprive-dnsoquic-02 -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 0 errors (**), 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 Intended status: Standards Track T. Reddy 5 Expires: 10 January 2022 McAfee 6 N. Cook 7 Open-Xchange 8 M. Boucadair 9 Orange 10 9 July 2021 12 Structured Data for DNS Access Denied Error Page 13 draft-wing-dnsop-structured-dns-error-page-00 15 Abstract 17 It can be valuable to communicate computer-parsable details about DNS 18 filtering to assist troubleshooting and problem resolution. This 19 document describes structured data to provide these details. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 10 January 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Structured Data . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 59 6. Usability Considerations . . . . . . . . . . . . . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 9.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 DNS clients using services which perform filtering may wish to 70 receive more information about such filtering and the reason for that 71 filtering. To this end, Extended DNS Error Codes [RFC8914] provide 72 information about when different types of filtering have occurred, 73 and DNS Access Denied Error Page [I-D.reddy-dnsop-error-page] 74 provides a URI to give further information to the end-user about the 75 reasons for the filtering. However, the latter draft assumes a 76 client with a user-interface that can display a web page to the end- 77 user, whereas many clients may in fact be "headless", i.e., acting on 78 behalf of other network elements; such clients can include DNS 79 forwarders and proxies. Such clients cannot make use of a web-page 80 designed for presentation to an end-user, but may instead be able to 81 make use of structured data. This draft provides a mechanism for 82 such clients to request and receive structured data from the URI 83 returned by the DNS Access Denied Error Page mechanism. 85 When a third party provides DNS filtering, there are deployments 86 where disclosing that third party to the host (which originated the 87 DNS query) is desirable but other deployments where such disclosure 88 is not desired. For example, the IT organization might contract 89 filtering to a third party but want trouble-tickets from employees to 90 be handled by IT, rather than having employees interact directly with 91 the third party. As another example, all the employees at a small 92 business or all the members of a household might be informed of the 93 third party so they can troubleshoot filtering with that third party 94 directly. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119][RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 This document makes use of the terms defined in [RFC8499]. 106 'Encrypted DNS' refers to any encrypted scheme to convey DNS 107 messages, for example, DNS-over-HTTPS [RFC8484], DNS-over-TLS 108 [RFC7858], or DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. 110 3. Structured Data 112 To receive structured DNS error page data, the client MUST query the 113 Error Page URI returned in [I-D.reddy-dnsop-error-page] with Content- 114 Type set to "application/json+structured-dns-error". The JSON has 115 one top-level name, "responsible", containing an array of 116 dictionaries for each party responsible for this particular DNS 117 filter. An array of responsible parties are possible in deployment 118 scenarios where two or more entities are involved in a DNS filtering 119 (the filtering may be for the same or distinct reasons by each 120 involved DNS filter service). The content of the array is structured 121 are as follows: 123 complaint: Is an array of URIs for the user to report mis-classified 124 DNS filtering. This is likely to solely contain an "https" URI, 125 but an array is provided in case telephone numbers or email or 126 other URIs are necessary. This field is mandatory and MUST 127 contain at least one URI. 129 justification: Includes the textual justification for this 130 particular DNS filtering. This field is optional. 132 name: is the human-friendly name of the organization that filtered 133 this particular DNS query. This field is optional. 135 regulation: the URI of the regulation authority for this DNS query 136 being filtered. This might point at an employment agreement (for 137 an enterprise performing filtering) or a national government 138 regulation (for an ISP performing filtering). This field is 139 optional. 141 The JSON data can be displayed to the user, logged, or otherwise used 142 to assist the end-user or IT staff with troubleshooting and 143 diagnosing the cause of the DNS filtering. 145 4. Examples 147 The examples use the folding defined in [RFC8792] for long lines. 149 An example with one entity, "example.net", that has filtered a DNS 150 query is shown in Figure 1, below. 152 { 153 "responsible": [ 154 { 155 "complaint": [ 156 "mailto:helpdesk@example.net?subject=\"incorrect filtering\ 157 of example.org at 1621902483\"", 158 "https://mistakes.example.net?domain=example.org?\ 159 time=1621902483", 160 "tel:+18305551212" 161 ], 162 "justification": "malware present for 23 days", 163 "name": "example.net Filtering Service", 164 "regulation": "https://laws.example.net?country=atlantis" 165 } 166 ] 167 } 169 Figure 1: Example of Filtering with One Entity 171 An example with two entities, "example.com" and "example.net", that 172 have filtered a DNS query is shown in Figure 2, below. 174 { 175 "responsible": [ 176 { 177 "complaint": [ 178 "mailto:helpdesk@example.net?subject=\"incorrect filtering\ 179 of example.org at 1621902483\"", 180 "https://mistake.example.net?domain=example.org?\ 181 time=1621902483", 182 "tel:+18305551212" 183 ], 184 "justification": "malware present for 23 days", 185 "name": "Example.net Filtering Service", 186 "regulation": "https://laws.example.net?country=atlantis" 187 }, 188 { 189 "complaint": [ 190 "mailto:abuse@example.com?subject=\"false positive filtering\ 191 example.org on 24-May-2021 5:03 GMT\"", 192 "https://example.net/report?d=example.org?t=38233", 193 "tel:+5305551212" 194 ], 195 "justification": "command and control malware", 196 "name": "Example.com IT department", 197 "regulation": "https://hr.example.com?state=CA" 198 } 199 ] 200 }} 202 Figure 2: Example of Filtering with Two Entities 204 5. Deployment Considerations 206 Over time a domain name may be considered risky, then safe, then 207 risky again, and later can elapse between the DNS EDNS0 error and the 208 user reporting a false positive and the DNS filtering service 209 receiving the user's complaint. Thus the URI is RECOMMENDED to 210 include sufficient detail to determine the state when the DNS EDNS0 211 response was generated. How this is encoded into the URI is an 212 implementation decision. 214 As discussed in the Introduction, some deployment models allow the 215 DNS filter provider to be conveyed to the end-user. In such a 216 deployment, state can be avoided in the DNS forwarder by conveying 217 the DNS filter provider's URL in the URL sent to the user. For 218 example, if the upstream DNS filter provider (example.net) indicates 219 their structured DNS error page for a query to example.org is 220 https://example.net?f=example.org&s=38, that URL can be conveyed to 221 the user as the URL-encoded parameter 222 https%3A%2F%2Fexample.net%3Ff%3Dexample.org%26s%3D38229 appended to 223 the DNS forwarder's DNS error page URL. 225 An array allows multiple DNS filters to be provided by specialized 226 services. For example, one service might filter access to malicious 227 domains and another filters domains due to an internal security 228 policy or court order. 230 6. Usability Considerations 232 The JSON values returned SHOULD be returned in the user's preferred 233 language as expressed by the Accept-Language HTTP header. 235 7. Security Considerations 237 Security considerations inherent to the use of DNS Error Page URI are 238 discussed in Section 7 of [I-D.reddy-dnsop-error-page]. 240 The structure data includes URLs that may be misused to return 241 infected or compromised websites. Means to detect and avoid such URL 242 are recommended. Likewise, contact URIs and telephone numbers may be 243 misused to return third-party contact points and thus lead to spam 244 these contacts. 246 8. IANA Considerations 248 This document requests IANA to register the "application/ 249 json+structured-dns-error" media type in the "Media Types" registry 250 [IANA-MediaTypes]. This registration follows the procedures 251 specified in [RFC6838]: 253 Type name: application 255 Subtype name: json+structured-dns-error 257 Required parameters: N/A 259 Optional parameters: N/A 261 Encoding considerations: as defined in Section 3 of [RFCXXXX]. 263 Security considerations: See Section 7 of [RFCXXXX]. 265 Interoperability considerations: N/A 267 Published specification: [RFCXXXX] 269 Applications that use this media type: Section 3 of [RFCXXXX]. 271 Fragment identifier considerations: N/A 273 Additional information: N/A 275 Person & email address to contact for further information: IETF, 276 iesg@ietf.org 278 Intended usage: COMMON 280 Restrictions on usage: none 282 Author: See Authors' Addresses section. 284 Change controller: IESG 286 Provisional registration? No 288 9. References 290 9.1. Normative References 292 [I-D.reddy-dnsop-error-page] 293 Reddy, T., Cook, N., Wing, D., and M. Boucadair, "DNS 294 Access Denied Error Page", Work in Progress, Internet- 295 Draft, draft-reddy-dnsop-error-page-08, 4 June 2021, 296 . 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 305 Specifications and Registration Procedures", BCP 13, 306 RFC 6838, DOI 10.17487/RFC6838, January 2013, 307 . 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 9.2. Informative References 315 [I-D.ietf-dprive-dnsoquic] 316 Huitema, C., Mankin, A., and S. Dickinson, "Specification 317 of DNS over Dedicated QUIC Connections", Work in Progress, 318 Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February 319 2021, . 322 [IANA-MediaTypes] 323 IANA, "Media Types", 324 . 326 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 327 and P. Hoffman, "Specification for DNS over Transport 328 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 329 2016, . 331 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 332 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 333 . 335 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 336 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 337 January 2019, . 339 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, 340 "Handling Long Lines in Content of Internet-Drafts and 341 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, 342 . 344 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. 345 Lawrence, "Extended DNS Errors", RFC 8914, 346 DOI 10.17487/RFC8914, October 2020, 347 . 349 Authors' Addresses 351 Dan Wing 352 Citrix Systems, Inc. 353 United States of America 355 Email: dwing-ietf@fuggles.com 357 Tirumaleswar Reddy 358 McAfee, Inc. 359 Embassy Golf Link Business Park 360 Bangalore 560071 361 Karnataka 362 India 364 Email: kondtir@gmail.com 366 Neil Cook 367 Open-Xchange 368 United Kingdom 370 Email: neil.cook@noware.co.uk 372 Mohamed Boucadair 373 Orange 374 35000 Rennes 375 France 377 Email: mohamed.boucadair@orange.com