DNSOP WG D. Wing Internet-Draft Citrix Intended status: Standards Track T. Reddy Expires: 10 January 2022 McAfee N. Cook Open-Xchange M. Boucadair Orange 9 July 2021 Structured Data for DNS Access Denied Error Page draft-wing-dnsop-structured-dns-error-page-00 Abstract It can be valuable to communicate computer-parsable details about DNS filtering to assist troubleshooting and problem resolution. This document describes structured data to provide these details. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 10 January 2022. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. Wing, et al. Expires 10 January 2022 [Page 1] Internet-Draft Structured DNS Access Denied Error Page July 2021 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Structured Data . . . . . . . . . . . . . . . . . . . . . . . 3 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 6. Usability Considerations . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction DNS clients using services which perform filtering may wish to receive more information about such filtering and the reason for that filtering. To this end, Extended DNS Error Codes [RFC8914] provide information about when different types of filtering have occurred, and DNS Access Denied Error Page [I-D.reddy-dnsop-error-page] provides a URI to give further information to the end-user about the reasons for the filtering. However, the latter draft assumes a client with a user-interface that can display a web page to the end- user, whereas many clients may in fact be "headless", i.e., acting on behalf of other network elements; such clients can include DNS forwarders and proxies. Such clients cannot make use of a web-page designed for presentation to an end-user, but may instead be able to make use of structured data. This draft provides a mechanism for such clients to request and receive structured data from the URI returned by the DNS Access Denied Error Page mechanism. When a third party provides DNS filtering, there are deployments where disclosing that third party to the host (which originated the DNS query) is desirable but other deployments where such disclosure is not desired. For example, the IT organization might contract filtering to a third party but want trouble-tickets from employees to be handled by IT, rather than having employees interact directly with Wing, et al. Expires 10 January 2022 [Page 2] Internet-Draft Structured DNS Access Denied Error Page July 2021 the third party. As another example, all the employees at a small business or all the members of a household might be informed of the third party so they can troubleshoot filtering with that third party directly. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in [RFC8499]. 'Encrypted DNS' refers to any encrypted scheme to convey DNS messages, for example, DNS-over-HTTPS [RFC8484], DNS-over-TLS [RFC7858], or DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. 3. Structured Data To receive structured DNS error page data, the client MUST query the Error Page URI returned in [I-D.reddy-dnsop-error-page] with Content- Type set to "application/json+structured-dns-error". The JSON has one top-level name, "responsible", containing an array of dictionaries for each party responsible for this particular DNS filter. An array of responsible parties are possible in deployment scenarios where two or more entities are involved in a DNS filtering (the filtering may be for the same or distinct reasons by each involved DNS filter service). The content of the array is structured are as follows: complaint: Is an array of URIs for the user to report mis-classified DNS filtering. This is likely to solely contain an "https" URI, but an array is provided in case telephone numbers or email or other URIs are necessary. This field is mandatory and MUST contain at least one URI. justification: Includes the textual justification for this particular DNS filtering. This field is optional. name: is the human-friendly name of the organization that filtered this particular DNS query. This field is optional. regulation: the URI of the regulation authority for this DNS query Wing, et al. Expires 10 January 2022 [Page 3] Internet-Draft Structured DNS Access Denied Error Page July 2021 being filtered. This might point at an employment agreement (for an enterprise performing filtering) or a national government regulation (for an ISP performing filtering). This field is optional. The JSON data can be displayed to the user, logged, or otherwise used to assist the end-user or IT staff with troubleshooting and diagnosing the cause of the DNS filtering. 4. Examples The examples use the folding defined in [RFC8792] for long lines. An example with one entity, "example.net", that has filtered a DNS query is shown in Figure 1, below. { "responsible": [ { "complaint": [ "mailto:helpdesk@example.net?subject=\"incorrect filtering\ of example.org at 1621902483\"", "https://mistakes.example.net?domain=example.org?\ time=1621902483", "tel:+18305551212" ], "justification": "malware present for 23 days", "name": "example.net Filtering Service", "regulation": "https://laws.example.net?country=atlantis" } ] } Figure 1: Example of Filtering with One Entity An example with two entities, "example.com" and "example.net", that have filtered a DNS query is shown in Figure 2, below. Wing, et al. Expires 10 January 2022 [Page 4] Internet-Draft Structured DNS Access Denied Error Page July 2021 { "responsible": [ { "complaint": [ "mailto:helpdesk@example.net?subject=\"incorrect filtering\ of example.org at 1621902483\"", "https://mistake.example.net?domain=example.org?\ time=1621902483", "tel:+18305551212" ], "justification": "malware present for 23 days", "name": "Example.net Filtering Service", "regulation": "https://laws.example.net?country=atlantis" }, { "complaint": [ "mailto:abuse@example.com?subject=\"false positive filtering\ example.org on 24-May-2021 5:03 GMT\"", "https://example.net/report?d=example.org?t=38233", "tel:+5305551212" ], "justification": "command and control malware", "name": "Example.com IT department", "regulation": "https://hr.example.com?state=CA" } ] }} Figure 2: Example of Filtering with Two Entities 5. Deployment Considerations Over time a domain name may be considered risky, then safe, then risky again, and later can elapse between the DNS EDNS0 error and the user reporting a false positive and the DNS filtering service receiving the user's complaint. Thus the URI is RECOMMENDED to include sufficient detail to determine the state when the DNS EDNS0 response was generated. How this is encoded into the URI is an implementation decision. Wing, et al. Expires 10 January 2022 [Page 5] Internet-Draft Structured DNS Access Denied Error Page July 2021 As discussed in the Introduction, some deployment models allow the DNS filter provider to be conveyed to the end-user. In such a deployment, state can be avoided in the DNS forwarder by conveying the DNS filter provider's URL in the URL sent to the user. For example, if the upstream DNS filter provider (example.net) indicates their structured DNS error page for a query to example.org is https://example.net?f=example.org&s=38, that URL can be conveyed to the user as the URL-encoded parameter https%3A%2F%2Fexample.net%3Ff%3Dexample.org%26s%3D38229 appended to the DNS forwarder's DNS error page URL. An array allows multiple DNS filters to be provided by specialized services. For example, one service might filter access to malicious domains and another filters domains due to an internal security policy or court order. 6. Usability Considerations The JSON values returned SHOULD be returned in the user's preferred language as expressed by the Accept-Language HTTP header. 7. Security Considerations Security considerations inherent to the use of DNS Error Page URI are discussed in Section 7 of [I-D.reddy-dnsop-error-page]. The structure data includes URLs that may be misused to return infected or compromised websites. Means to detect and avoid such URL are recommended. Likewise, contact URIs and telephone numbers may be misused to return third-party contact points and thus lead to spam these contacts. 8. IANA Considerations This document requests IANA to register the "application/ json+structured-dns-error" media type in the "Media Types" registry [IANA-MediaTypes]. This registration follows the procedures specified in [RFC6838]: Wing, et al. Expires 10 January 2022 [Page 6] Internet-Draft Structured DNS Access Denied Error Page July 2021 Type name: application Subtype name: json+structured-dns-error Required parameters: N/A Optional parameters: N/A Encoding considerations: as defined in Section 3 of [RFCXXXX]. Security considerations: See Section 7 of [RFCXXXX]. Interoperability considerations: N/A Published specification: [RFCXXXX] Applications that use this media type: Section 3 of [RFCXXXX]. Fragment identifier considerations: N/A Additional information: N/A Person & email address to contact for further information: IETF, iesg@ietf.org Intended usage: COMMON Restrictions on usage: none Author: See Authors' Addresses section. Change controller: IESG Provisional registration? No 9. References 9.1. Normative References [I-D.reddy-dnsop-error-page] Reddy, T., Cook, N., Wing, D., and M. Boucadair, "DNS Access Denied Error Page", Work in Progress, Internet- Draft, draft-reddy-dnsop-error-page-08, 4 June 2021, . Wing, et al. Expires 10 January 2022 [Page 7] Internet-Draft Structured DNS Access Denied Error Page July 2021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [I-D.ietf-dprive-dnsoquic] Huitema, C., Mankin, A., and S. Dickinson, "Specification of DNS over Dedicated QUIC Connections", Work in Progress, Internet-Draft, draft-ietf-dprive-dnsoquic-02, 22 February 2021, . [IANA-MediaTypes] IANA, "Media Types", . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, "Handling Long Lines in Content of Internet-Drafts and RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, . Wing, et al. Expires 10 January 2022 [Page 8] Internet-Draft Structured DNS Access Denied Error Page July 2021 [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, October 2020, . Authors' Addresses Dan Wing Citrix Systems, Inc. United States of America Email: dwing-ietf@fuggles.com Tirumaleswar Reddy McAfee, Inc. Embassy Golf Link Business Park Bangalore 560071 Karnataka India Email: kondtir@gmail.com Neil Cook Open-Xchange United Kingdom Email: neil.cook@noware.co.uk Mohamed Boucadair Orange 35000 Rennes France Email: mohamed.boucadair@orange.com Wing, et al. Expires 10 January 2022 [Page 9]