Extensions for DNS Public Resolvers
draft-nottingham-public-resolver-errors-00

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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
              structured-dns-error-09>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570,
              DOI 10.17487/RFC6570, March 2012,
              <https://www.rfc-editor.org/rfc/rfc6570>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/rfc/rfc8259>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

Author's Address

   Mark Nottingham
   Cloudflare
   Prahran
   Australia
   Email: mnot@mnot.net
   URI:   https://www.mnot.net/

Nottingham                 Expires 9 May 2025                   [Page 6]