Network Working Group M. Nottingham Internet-Draft Cloudflare Intended status: Standards Track 5 November 2024 Expires: 9 May 2025 Extensions for DNS Public Resolvers draft-nottingham-public-resolver-errors-00 Abstract [I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This draft suggests additions to that mechanism. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/mnot/public-resolver-errors. 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 9 May 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Nottingham Expires 9 May 2025 [Page 1] Internet-Draft Extensions for DNS Public Resolvers November 2024 and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 2. DNS Resolver Operator ID . . . . . . . . . . . . . . . . . . 3 3. Filtering Incident ID . . . . . . . . . . . . . . . . . . . . 3 4. Incident Resolution Templates . . . . . . . . . . . . . . . . 3 5. The Filtering Incident Description Format . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6.1. EXTRA-TEXT JSON Names . . . . . . . . . . . . . . . . . . 4 6.2. The DNS Resolver Identifier Registry . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction [I-D.ietf-dnsop-structured-dns-error] introduces structured error data for DNS responses that have been filtered. This draft suggests additions to that mechanism. These additions are informed by specific concerns that Web browsers have about providing information about DNS filtering events to end users. In particular, they are intended to address the risks associated with trusting information inserted by DNS resolvers into responses. Presenting information sourced from unauthenticated network elements to end users opens a variety of attacks. Given the variety of network deployments on the Internet, such information needs to be considered as attacker-controlled. This proposal mitigates these risks by minimising the amount and type of information carried into the DNS response to a "DNS Resolver Operator ID" and a "Filtering Incident ID." Neither is presented to end users: instead, they can be used to obtain (using HTTPS) a document that carries details of the specific filtering incident, for presentation to end users. Nottingham Expires 9 May 2025 [Page 2] Internet-Draft Extensions for DNS Public Resolvers November 2024 This mechanism is not intended to scale to large numbers of DNS operators. Instead, it is expected that in typical use, the DNS Resolver Operator ID will be used to selectively present information from DNS resolvers operators that clients deem to be serving a public good role (e.g., publicly available open resolvers), to aid those parties in serving the public interest by making their operation more transparent. 1.1. Notational Conventions 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. 2. DNS Resolver Operator ID A DNS Resolver Operator ID is a short, textual string that uniquely identifies the operator of a DNS resolver. It is carried in the EXTRA-TEXT field of the Extended DNS Error with the JSON field name "ro". For example: { "ro": "exampleResolver" } The value of the "ro" field MUST be registered in the DNS Resolver Operator registry; see Section 6.2. Unregistered values MUST be ignored, and registered values MAY be ignored. 3. Filtering Incident ID A Filtering Incident ID is an opaque, string identifier for a particular filtering incident. It might be specific to a particular request, but need not be. It is carried in the EXTRA-TEXT field of the Extended DNS Error with the JSON field name "inc". For example: { "inc": "abc123" } 4. Incident Resolution Templates An Incident Resolution Template is a URI Template [RFC6570] that, upon expansion, provides a URI that can be dereferenced to obtain a Filtering Incident Description document (see Section 5). Nottingham Expires 9 May 2025 [Page 3] Internet-Draft Extensions for DNS Public Resolvers November 2024 It MUST be a Level 1 or Level 2 template (see Section 1.2 of [RFC6570]). It has the following variables available to it: * ro: the DNS Resolver Operator ID (see {op-id}) * inc: the Filtering Incident ID (see {incident-id}) For example: ~~ https://resolver.example.com/filtering-incidents/{inc} ~~ When dereferencing this URL, HTTP content negotiation for language SHOULD be used; see Section 12 of [RFC9110]. 5. The Filtering Incident Description Format The Filtering Incident Description Format is a JSON [RFC8259] document format for returning information about a particular filtering incident. Its root is an Object, with the following members: * inc: String; the Filtering Incident ID * resolver: String; a short textual name for the resolver operator (RECOMMENDED to be no longer than 64 characters) * authority: String; a short textual name for the authority that required the filtering (RECOMMENDED to be no longer than 64 characters) * description: String; a short textual description of the incident (RECOMMENDED to be no longer than 256 characters) All members above are mandatory. New members can be added by updating this specification. 6. IANA Considerations 6.1. EXTRA-TEXT JSON Names IANA will register the following fields in the "EXTRA-TEXT JSON Names" sub-registry established by [I-D.ietf-dnsop-structured-dns-error]: * JSON Name: "ro" * Short Description: a short, textual string that uniquely identifies the operator of a DNS resolver Nottingham Expires 9 May 2025 [Page 4] Internet-Draft Extensions for DNS Public Resolvers November 2024 * Mandatory: no * Specification: [this document] * JSON Name: "inc" * Short Description: an opaque, string identifier for a particular filtering incident * Mandatory: no * Specification: [this document] 6.2. The DNS Resolver Identifier Registry IANA will establish a new registry, the "DNS Resolver Identifier Registry." Its registration policy is first-come, first-served (FCFS), although IANA may refuse registrations that are deemed to be deceptive or spurious. It contains the following fields: * Name: The name of the DNS resolver operator * Contact: an e-mail address or other appropriate contact mechanism * DNS Resolver Operator ID: see Section 2 * Incident Resolution Template: see Section 4 7. Security Considerations This specification does not provide a way to authenticate that a particular filtering incident as experienced by a client was actually associated with the DNS resolver operator claimed. This means that an attacker (for example, one controlling a DNS resolver) can claim that a filtering incident is associated with an operator when it in fact was not. However, to be successful an attacker would need to reuse an existing incident identifier that is supported by a DNS resolver operator recognised by the client. It is not currently thought to be particularly advantageous to an attacker to do so. 8. Normative References Nottingham Expires 9 May 2025 [Page 5] Internet-Draft Extensions for DNS Public Resolvers November 2024 [I-D.ietf-dnsop-structured-dns-error] Wing, D., Reddy.K, T., Cook, N., and M. Boucadair, "Structured Error Data for Filtered DNS", Work in Progress, Internet-Draft, draft-ietf-dnsop-structured-dns- error-09, 28 July 2024, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . Author's Address Mark Nottingham Cloudflare Prahran Australia Email: mnot@mnot.net URI: https://www.mnot.net/ Nottingham Expires 9 May 2025 [Page 6]