]> Cloudflare

Melbourne Australia mnot@mnot.net https://www.mnot.net/

Google

USA davidcadrian@gmail.com

Internet-Draft introduces structured error data for DNS responses that have been filtered. This specification allows more specific details of filtering incidents to be conveyed. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction Internet DNS resolvers are increasingly subject to legal orders that require blocking or filtering of specific names. Because such filtering happens during DNS resolution, there is not an effective way to communicate what is happening to end users, often resulting in misattribution of the issue as a technical problem, rather than a policy intervention. Some organizations such as Lumen monitor legally-mandated filtering as a public service, tracking specific filtering incidents in publicly accessible databases. Other parties may also choose to track filtering requests over time and make them available. This draft defines a mechanism for DNS resolvers to convey identifiers for entries in such databases, based upon the structured error data for DNS responses introduced by . A consuming party (e.g., a Web browser) can use this information to construct a link to the specific entry in one or more databases of filtering incidents. This enables user agents to direct users to additional context about the filtering incident they encountered. The information conveyed is a DNS Filtering Database Entry, specified in . This abstraction is necessary because allowing DNS resolvers to inject links or user-visible messages would bring unique challenges. DNS resolvers are often automatically configured by unknown networks and DNS responses are unauthenticated, so these messages can come from untrusted parties -- including attackers (e.g., the so-called "coffee shop" attack) that leverage many users' lack of a nuanced model of the trust relationships between all of the parties that are involved in the service they are using. This specification attempts to mitigate these risks by minimising the information carried in the DNS response to abstract, publicly registered identifiers associated with databases of filtering incidents -- the DNS Filtering Database Entry -- rather than arbitrary URLs. An application can choose which database identifiers they support and are willing to direct their users to, without enabling every DNS server to surface arbitrary links and text, and without requiring the consuming party to independently track which URLs are in use.

Example In typical use, a DNS query that is filtered might contain an Extended DNS Error Code 17 (see ) and an EXTRA-TEXT field "fdbs", which is an array of references to filtering database entries: This indicates that the filtering incident can be accessed in two different databases, along with the ID associated with each database. In this example, the data is available in the "example" database at identifier "abc123", and in the "lumen" database at identifier "def456". An application that decides to present the "example" entry to its users would look up "example" in a local copy of the DNS Filtering Incident Database Registry (see ) and obtain the corresponding URI template (see ). For purposes of this example, assume that the registry entry for that value contains: That URI template can be expanded using the value of "id" to: The application could (but might not) then decide to convey some or all of this information to its user; for example:

• The webpage at www.example.net was blocked by your DNS resolver due to a legal request. More information is available here: https://example.com/filtering-incidents/abc123

Note that there is no requirement for the resolver to convey any particular information here. The resolver both chooses which database providers it supports, and can evaluate whatever mechanisms it chooses to determine if and when to provide a link to the database entry.

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 when, and only when, they appear in all capitals, as shown here.

Data Types This section defines the data types used to look up the details of a filtering incident from a DNS error response. Note that these identifiers are not suitable for presentation to end users.

DNS Filtering Database Entry A Filtering Database Operator ID is a string identifier for the operator of a database of filtering incidents. It uses the key "db". A Filtering Incident ID is a string identifier for a particular filtering incident. It might be specific to a particular request, but need not be. It uses the key "id". An object containing both a Filtering Database Operator ID and a Filtering Incident ID is a Filtering Database Entry.

DNS Filtering Database Entry List A DNS Filtering Database Entries list is an array of Filtering Database Entry objects. Each entry MUST be related to the same underlying incident. It is carried in the EXTRA-TEXT field of the Extended DNS Error with the JSON field name "fdbs". For example: Different applications will implement support for a varying set of database operators. Resolvers provide a list of entries (rather than a single entry) so that they can support as many databases as possible.

Database Entry Resolution Templates An Database Entry Resolution Template is a URI Template contained in the DNS Filtering Database Registry () that, upon expansion, provides a URI that can be dereferenced to obtain details about the filtering incident. It MUST be a Level 1 or Level 2 template (see ). It has the following variables from the Filtering Database Entry (see ) available to it:

db:

the Filtering Database Operator ID

id:

the Filtering Incident ID

For example: Applications MUST store a local copy of the DNS Filtering Database Registry () for purposes of template lookup; they MUST NOT query the IANA registry upon each use. The registry is keyed by the Filtering Database Operator ID.

IANA Considerations

EXTRA-TEXT JSON Names IANA will register the following fields in the "EXTRA-TEXT JSON Names" sub-registry established by :

JSON Name:

"fdbs"

Short Description:

a array of filtering database entries

Mandatory:

no

Specification:

this document

The DNS Filtering Database Registry IANA will establish a new registry, the "DNS Filtering Database Registry." Its registration policy is first-come, first-served (FCFS), although IANA may refuse registrations that it deems to be deceptive or spurious. It contains the following fields:

Name:

The name of the DNS Filtering Database

Contact:

an e-mail address or other appropriate contact mechanism

Filtering Database Operator ID:

see

Database Entry Resolution Template:

see

The Database Entry Resolution Template can be updated by the contact at any time. However, operators SHOULD accommodate potentially long lag times for applications to update their copies of the registry.

Security Considerations This specification does not provide a way to authenticate that a particular filtering incident as experienced by an application was actually associated with the information presented. This means that an attacker (for example, one controlling a DNS resolver) can claim that a particular filtering incident is occurring when in fact it is not. However, a successful attack would need to reuse an existing DNS Filtering Database Operator ID and Filtering Incident ID that combine to expand to a URL that can be successfully dereferenced. Doing so is not currently thought to be particularly advantageous to an attacker to do so. Future iterations of this specification may introduce more robust protections. The details of DNS responses are not available to all applications, depending on how they are architected and the information made available to them by their host. As a result, this mechanism is not reliable; some applications will not be able to display this error information. Because the registry is first-come first-served, applications (such as Web browsers) will need to exercise judgement regarding which database operators' error messages they display to users. This decision might be influenced by the identity of the resolver producing the error message, the database operator, or local configuration.

Privacy Considerations An application dereferencing an incident URL may reveal the IP address of the user to the filtering database operator, along with the fact that the user attempted to resolve a specific domain whose resolution was filtered or censored. In some jurisdictions this exposure may carry meaningful risk to the user. While allowing users the choice to trust only specific filtering databases may mitigate the risk from a filtering database operator, on-path network observers may still infer that the user encountered a filtering incident for a sensitive domain based on a connection to the filtering database. To mitigate this risk, applications can choose to route incident URL fetches through a privacy-preserving mechanism like a proxy. In absence of such a proxy, applications MUST NOT automatically fetch incident URLs without explicit user action. Applications and users should be aware that a resolver and filtering database operator acting in collusion, or a single party operating in both roles, could use unique Filtering Incident IDs to correlate user activity across requests. As such, applications should get explicit input from users on which filtering database operators they trust, and consequently disregard any entries from operators the user does not explicitly trust.

References Normative References Citrix Systems, Inc. Nokia Open-Xchange Orange 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. This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs. 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. 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. 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] Informative References n.d.

Acknowledgements Thanks to Lars Eggert, Tommy Pauly, Emily Stark, and Martin Thomson for their input to this specification.