<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.20 (Ruby 3.3.5) -->
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-nottingham-public-resolver-errors-00" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.24.0 -->
  <front>
    <title>Extensions for DNS Public Resolvers</title>
    <seriesInfo name="Internet-Draft" value="draft-nottingham-public-resolver-errors-00"/>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization>Cloudflare</organization>
      <address>
        <postal>
          <postalLine>Prahran</postalLine>
          <postalLine>Australia</postalLine>
        </postal>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>
    <date year="2024" month="November" day="05"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 27?>

<t><xref target="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.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/mnot/public-resolver-errors"/>.</t>
    </note>
  </front>
  <middle>
    <?line 31?>

<section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="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.</t>
      <t>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.</t>
      <t>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.</t>
      <t>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.</t>
      <section anchor="notational-conventions">
        <name>Notational Conventions</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="op-id">
      <name>DNS Resolver Operator ID</name>
      <t>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:</t>
      <sourcecode type="json"><![CDATA[
{
  "ro": "exampleResolver"
}
]]></sourcecode>
      <t>The value of the "ro" field <bcp14>MUST</bcp14> be registered in the DNS Resolver Operator registry; see <xref target="registry"/>. Unregistered values <bcp14>MUST</bcp14> be ignored, and registered values <bcp14>MAY</bcp14> be ignored.</t>
    </section>
    <section anchor="incident-id">
      <name>Filtering Incident ID</name>
      <t>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:</t>
      <sourcecode type="json"><![CDATA[
{
  "inc": "abc123"
}
]]></sourcecode>
    </section>
    <section anchor="template">
      <name>Incident Resolution Templates</name>
      <t>An Incident Resolution Template is a URI Template <xref target="RFC6570"/> that, upon expansion, provides a URI that can be dereferenced to obtain a Filtering Incident Description document (see <xref target="format"/>).</t>
      <t>It <bcp14>MUST</bcp14> be a Level 1 or Level 2 template (see <xref section="1.2" sectionFormat="of" target="RFC6570"/>). It has the following variables available to it:</t>
      <ul spacing="normal">
        <li>
          <t>ro: the DNS Resolver Operator ID (see {op-id})</t>
        </li>
        <li>
          <t>inc: the Filtering Incident ID (see {incident-id})</t>
        </li>
      </ul>
      <t>For example:</t>
      <t>~~
https://resolver.example.com/filtering-incidents/{inc}
~~</t>
      <t>When dereferencing this URL, HTTP content negotiation for language <bcp14>SHOULD</bcp14> be used; see <xref section="12" sectionFormat="of" target="RFC9110"/>.</t>
    </section>
    <section anchor="format">
      <name>The Filtering Incident Description Format</name>
      <t>The Filtering Incident Description Format is a JSON <xref target="RFC8259"/> document format for returning information about a particular filtering incident. Its root is an Object, with the following members:</t>
      <ul spacing="normal">
        <li>
          <t>inc: String; the Filtering Incident ID</t>
        </li>
        <li>
          <t>resolver: String; a short textual name for the resolver operator (<bcp14>RECOMMENDED</bcp14> to be no longer than 64 characters)</t>
        </li>
        <li>
          <t>authority: String; a short textual name for the authority that required the filtering (<bcp14>RECOMMENDED</bcp14> to be no longer than 64 characters)</t>
        </li>
        <li>
          <t>description: String; a short textual description of the incident (<bcp14>RECOMMENDED</bcp14> to be no longer than 256 characters)</t>
        </li>
      </ul>
      <t>All members above are mandatory. New members can be added by updating this specification.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="extra-text-json-names">
        <name>EXTRA-TEXT JSON Names</name>
        <t>IANA will register the following fields in the "EXTRA-TEXT JSON Names" sub-registry established by <xref target="I-D.ietf-dnsop-structured-dns-error"/>:</t>
        <ul spacing="normal">
          <li>
            <t>JSON Name: "ro"</t>
          </li>
          <li>
            <t>Short Description: a short, textual string that uniquely identifies the operator of a DNS resolver</t>
          </li>
          <li>
            <t>Mandatory: no</t>
          </li>
          <li>
            <t>Specification: [this document]</t>
          </li>
          <li>
            <t>JSON Name: "inc"</t>
          </li>
          <li>
            <t>Short Description: an opaque, string identifier for a particular filtering incident</t>
          </li>
          <li>
            <t>Mandatory: no</t>
          </li>
          <li>
            <t>Specification: [this document]</t>
          </li>
        </ul>
      </section>
      <section anchor="registry">
        <name>The DNS Resolver Identifier Registry</name>
        <t>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.</t>
        <t>It contains the following fields:</t>
        <ul spacing="normal">
          <li>
            <t>Name: The name of the DNS resolver operator</t>
          </li>
          <li>
            <t>Contact: an e-mail address or other appropriate contact mechanism</t>
          </li>
          <li>
            <t>DNS Resolver Operator ID: see <xref target="op-id"/></t>
          </li>
          <li>
            <t>Incident Resolution Template: see <xref target="template"/></t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>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.</t>
      <t>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.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="I-D.ietf-dnsop-structured-dns-error">
        <front>
          <title>Structured Error Data for Filtered DNS</title>
          <author fullname="Dan Wing" initials="D." surname="Wing">
            <organization>Citrix Systems, Inc.</organization>
          </author>
          <author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy.K">
            <organization>Nokia</organization>
          </author>
          <author fullname="Neil Cook" initials="N." surname="Cook">
            <organization>Open-Xchange</organization>
          </author>
          <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
            <organization>Orange</organization>
          </author>
          <date day="28" month="July" year="2024"/>
          <abstract>
            <t>   DNS filtering is widely deployed for various reasons, including
   network security.  However, filtered DNS responses lack structured
   information for end users to understand the reason for the filtering.
   Existing mechanisms to provide explanatory details to end users cause
   harm especially if the blocked DNS response is for HTTPS resources.

   This document updates RFC 8914 by signaling client support for
   structuring the EXTRA-TEXT field of the Extended DNS Error to provide
   details on the DNS filtering.  Such details can be parsed by the
   client and displayed, logged, or used for other purposes.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-structured-dns-error-09"/>
      </reference>
      <reference anchor="RFC2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date month="March" year="1997"/>
          <abstract>
            <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date month="May" year="2017"/>
          <abstract>
            <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
          </abstract>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="RFC6570">
        <front>
          <title>URI Template</title>
          <author fullname="J. Gregorio" initials="J." surname="Gregorio"/>
          <author fullname="R. Fielding" initials="R." surname="Fielding"/>
          <author fullname="M. Hadley" initials="M." surname="Hadley"/>
          <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
          <author fullname="D. Orchard" initials="D." surname="Orchard"/>
          <date month="March" year="2012"/>
          <abstract>
            <t>A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6570"/>
        <seriesInfo name="DOI" value="10.17487/RFC6570"/>
      </reference>
      <reference anchor="RFC9110">
        <front>
          <title>HTTP Semantics</title>
          <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
          <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
          <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
          <date month="June" year="2022"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
            <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="97"/>
        <seriesInfo name="RFC" value="9110"/>
        <seriesInfo name="DOI" value="10.17487/RFC9110"/>
      </reference>
      <reference anchor="RFC8259">
        <front>
          <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
          <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
          <date month="December" year="2017"/>
          <abstract>
            <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
            <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="90"/>
        <seriesInfo name="RFC" value="8259"/>
        <seriesInfo name="DOI" value="10.17487/RFC8259"/>
      </reference>
    </references>
    <?line 150?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA9VY63IbtxX+v0+BUn+kDElLqu3ETCapqkutji6uLpN6Mp4M
uAuSiHYXGwBLmtXIz9Jn6ZP1OwfY5VKiHE/a/mhmIi+BA+Cc73znAgwGg8Rr
n6uROP7oVem0KZ2YGCuOLq7Fu3qc61RcKWfyubIukeOxVfNRkpm0lAUWZVZO
/KA03utyOpPFoOIlAxuXDJS1xrrB7m6SSa9GSYq/U2OXI+F8liS6siPhbe38
/u7um9395E4tF8ZmI3FaemVL5QdHdESSOC/L7GeZmxLHLpVLXCGt//nX2njl
RqI0SaVH4idv0r7AH11mqvR94Yz1Vk0cvpZF/PBWp5hKTVHJ+FFAGFO6zHWp
PiSJrP3M2FEiBonAf7rEEedDcdEaysMBg3Np7x7PGDuVpf6H9MBzJA5zU2eT
XFrFk5WBMfmIv4UYiHdWzqws+Xdq6tITPAfAxMpcSx5WhdT5SBRA+k/0Zwhk
eKK2sHrmfeVGL14sFothM/siSZLBYCDkmPZJgeD9/R9OB0dDrfxkkJXOVAPM
1KmvrcpoIPjq4QHWemuyOlVOrCQEzwp4Ubb8gJcr8AVyfia9mMm5EmOlSjHR
ObynsqG4mWkXWCJcPZ0q552QWaY9E82bsLJQ6Qx4uWIYlC50luUKFmwRD1gZ
WvB/Y8PNTDnVkYHnoRGOLKDEeClcpVI9QWilpkxB83j4j2osxtYsHGItaCLH
pvaismauM9ArbsK0inNkQ1CV5tWciEw6qTITNW00BISiQqzotAYFER0ztYwa
IeIzaARx6AokSA8lrHZ30Nk5hBHCNRML7WchSh/rgMBQ1gejIpohVdDmZgXu
ECQHJOWTDZypbYr1E2sKUZcUdySV8rmgMZLBnVC5Kp7YJUylCFoxlxZ8WAoz
EdJ7md7htL9oAMHGdGab7TJV5WYZdjRBqsk2yA51OlvTsFQq45PHitzldEas
ADzxNCQ5DINteQ6ykO/BFngMUS5zMNnrKYxhZF2DLdAqdKkL7QgPUkAWFPgC
OU74ZaVI3a4SqbQwIwuoknyXuuw/0aOhJlWLy0pZ6cHx06Me7wqBk5Ymp2Wq
KT9idtgTFwr+xRrWm70UONFCPSI/eyWzSJ5UloQG5ljOjL3Updiu2Zq3Nzfv
rndwHopETSAHbgcLEEcKwrkjA8mONhJWHNZRuT7HaNQowLDG6wh1G3ekP5Lf
Gq1dKnPGB8yfKlHWxZipM2EATQSJYyQaqD3toz5CL4aBdIdxcApImdPR/dYB
m9BGsOR5Fx0H9iJ7zVW+bIxZcy0zfz12Wr0idLlmrmZKFZGIAGBOWEkRCq6Y
GpMJcFCJbTWcDvtxHGfKOfCWY8xQwKxO2ekzbzTZaEAiThGKArfdneyM+xOo
WOqZuvIuzmobdSVDCoOcglpTOmwFheGgrS0qjDwN7A5NSemJMiKnSIFiL6ja
O9E7v72+6fXDv+Likr+vjv92e3p1fETf128Pzs7ajyRKXL+9vD07Wn2tVh5e
np8fXxyFxRgVa0NJ7/zgPWYoMHqX725OLy8OznrsZ871DXMpSwbA2X64z3Po
J5lyqdVjjkjx58N3//rn3kuB4nR1cri/t/cGBSj8+Gbv65f4sUBSC6eZEi4J
PymUEllVSlraRYI2qaw0WgN0IkgvbmYWpUBgKiD51U+EzIeR+G6cVnsvv48D
ZPDaYIPZ2iBj9nTkyeIA4oahDce0aK6NP0J6Xd+D92u/G9w7g9/9QP2XGOx9
88P3XP2fjbL7LdR+nT0kycHzQprKA2C0yCVeffQ1SEjdH5MXgVWX+tea4pLz
DdJQSNNt/HFJWYtNJArOD6t8zAuO/35zdTC4wT/IYyrPmuzGPTWlItrjmJuP
UEsx99fry4soTX2k6FnTG4oTiKiPsqjQkifJp0+fxC8Ojc89mj0SGIlenG0M
7iUPJBYCai7zWjWHk3w8gKkCFls11Y67mkbzzdgFObv8FqlAgcrN74eHobgt
O7vwga7dX09LJIEsUH2D2MH7jhTlB7GxJsG7TRFofLxZjhxcwl0Sbuw3rm2d
abmAyE7zs6HKsEcLPZ15zqtNOeKS2lloFY5w4NEYPRe1BFxqxup/SQio+BuM
IAlQQo7Tvf0/tkzYWmHErq05Pd8obMGdyP2Wj98EbflZ6RBDt1enq5GQ2V6/
+noXmY3iqC9q9CFUMyVfIPuxYVXN0tgAcNNA3dME/5fpWvMgN3n4iLNsxQq1
OXk7UDIU0IeHHdAILmgYKMUZeuBc7OEKFj/3RWNus/Za8XVC7A33yTGtNTvs
zZkMWWCCjs4sSCHqIamCuk4xherawyFfoeqOPt8RhFNDvtrBAngtrNhM6iDe
DYCdJHnMgqS587WZKc4OcZt90dJ80GzjXtCORJAk+RHlp+OHkA7h59ursz63
b9TnetKmxF3d69inQINcltNaopGKZSG2OU2aaHFlWIklb/b2gCtH+s1mg7s+
PmGfgp/RuSGpfdki5imHUKy8+6+oDLe0CVuyFajitS03X6e+IFs4eNz4mHsu
x78oekNoo3jFmkJxs8kcYZdfc3769nnXE5miO1fSsYK1BYxzA5nBV7WGb23J
2u6U39i7lGh/TTlVtAQqv34p0DHTmwB1gTgzPHZov/zCQ1v5ENiUGrXlXll1
IPsdimQrtz6vSkeoyaqNd77gzP1Xr9cOTQ7QdkVPEQXozo2mr0ABIziXQ9yO
Fq1AzGG4LIcrb11Bqo2fpngwn5jzpwcXB9T28qVRxs4XTXGnPDBlLwAvZlic
7w9N7XxEKa4OrikyvY3b9HCFHQ+aii1QtJCvtJsFje/vv+j9hEnb7jniXgIj
1+yJo66b/ssNFg45b7DnVz0c2oWVnvi6LfqHx4pSSXxG0/+wU/gdqm2FtLdW
GU5Xh141TrrfajusLgta30G1EjRshMINtPdb2+Jqz9kq/AxZrjK4zS0peU20
dX6AagE8wjdd+8CS7ZPDk2vcDmWOMK+ns8DiQi6x06R2am3DeEWlmKHraajp
XOZTVdGtl+qwq2qrTe1CqabigpL/uMgGbjPxgisJOc47Mcq7NGkZBOlD2i/1
7GA1oIfS9jWLGMZPG7hmWVNZes4K56edBzvs8VztHsXKFor3AyQ/1yw10m17
9UBJAFWx5mz5OBHcPEka4I4Kjxixg4LjFwCeutHOy1jE/PN0pSskPWOgLeVe
C8Ev41MC9kSySylc6YHg8UPfc1hjtdRF+yJaKNm6v2wfw8T2ZNWq9HHfDYDT
81h4sOhuvcMZlbdtbNpgiH76GMmxHLWi2zQ/26BHIb+ScfQIniRvzQIdoO03
jyZ1moIVkzpfU3hhamq5VeCuVURxotJH3bx3NnqsQiw8C8F7dVWZ5gFUPgOb
VamZgmhBiuANbmjuDuRvUITeTHKap6DzUeeVi8lT2VyCu1OFWGJOdKzAz8wI
Z4bx3X+M4ST5N/srAIfgGQAA

-->

</rfc>
