Internet DRAFT - draft-hardaker-dprive-add-doh-dnsop-filter-request


Network Working Group                                        W. Hardaker
Internet-Draft                                                   USC/ISI
Intended status: Standards Track                      September 26, 2019
Expires: March 29, 2020

                  Client DNS Filtering Profile Request


   This document defines a mechanism under which a client can request
   that an upstream recursive resolver perform DNS filtering on behalf
   of a client-requested policy.  This is may be done, for example,
   under a subscription model, where the client wishes not to get
   redirected to domains known to host malware or malicious content.
   This request is sent as an EDNS0 option with every DNS request, or
   potentially to just the first DNS request in a stream when using DNS
   over TLS, DNS over DTLS or DNS over DOH for example.

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

   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 March 29, 2020.

Copyright Notice

   Copyright (c) 2019 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
   ( 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

Hardaker                 Expires March 29, 2020                 [Page 1]
Internet-Draft             DNS Filter Request             September 2019

   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
     1.1.  Purpose of this document  . . . . . . . . . . . . . . . .   2
     1.2.  Real Introduction . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Requirements notation . . . . . . . . . . . . . . . . . .   4
   2.  Extension Overview  . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Extension Packet Format . . . . . . . . . . . . . . . . .   4
   3.  Filter Record Overview  . . . . . . . . . . . . . . . . . . .   4
   4.  ISP signalling  . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Resolver processing . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Example Filter List . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   [DOCUMENT STATUS NOTE: this specification is VERY INCOMPLETE and is
   at the stage of "discuss whether this is a good or bad idea in
   general", and not at the stage of "your processing steps are broken"
   or, worse "you mispelled misspelled".  Keep reading for further

1.1.  Purpose of this document

   Right now, the DNS ecosystem is being used in a multitude of ways
   that are intricately bound together based on its evolution over time.
   DNS resolvers today are acting as both a DNS resolution service, as
   originally intended, and as a control point by offering filtering
   (and rewriting) services on behalf of the client, the ISP, and
   policies imposed by enterprises/organizations and governments.  One
   significant issue that has arisen under some proposed deployment
   architectures for [DOH] in which Applications Doing DNS (in the ADD
   pseudo-WG) may bypass traditional DNS resolvers within ISPs,
   alleviating those ISPs from offering DNS-based filtering and
   protection services.

   This document is an attempt to see if those two roles can be safely
   severed, so users in an [DOH] world can select a resolver that best
   suits their resolution policies and separately select filtering
   policies that best suit their access requirements.

Hardaker                 Expires March 29, 2020                 [Page 2]
Internet-Draft             DNS Filter Request             September 2019

   There are many other ways such a policy transmission feature could be
   implemented.  DNS real-time blacklist (DNSRBL) like techniques could
   be used, ISPs could publish policy pointers under the DNS reverse
   tree, DoH clients could publish policies within HTTP headers
   (limiting its use to just DoH), ...  I selected the one below as the
   "most out of the box" to promote thinking, not because I expect it to
   be the best option.  Specifically, I have doubts that public large
   scale DoH providers will want to memorize large numbers of published
   policy lists (and hence, DNSRBL may actually be a better choice).

   [There are other ways to implement what is described below, but I
   wanted to pick a more novel idea to promote wider thinking than "use
   an RBL like pointer" or "use a HTTPS header for just DOH because
   that's really what triggered the filtering discussions in the first

1.2.  Real Introduction

   DNS today provides a distributed name resolution database that serves
   as the basis for many technologies, and is the starting point for
   nearly all communication that occurs on the Internet.  Because of
   this, it frequently serves as a filtering mechanism by Network
   Providers who which to deploy DNS filtering or data modification
   technologies, for better or worse.  As DNS is pushing further into
   being encrypted from client to recursive resolver by technologies
   such as [DNSTLS] and [DOH], clients are increasingly using encrypted
   communication to DNS resolvers that may have different or no
   filtering policies and mechanisms (protective or otherwise), than
   intended by the networking configuration distributed from their
   Internet Service Provider (ISP) or other access point.  This document
   puts the selection of a selective DNS filtering service back in the
   hands of the user, since DNS centralization threatens to remove
   client ability to do so.

   Specifically, this document defines a mechanism under which a client
   can request that its upstream recursive resolver perform DNS
   filtering on behalf of a client-requested policy.  This is may be
   done, for example, under a subscription model, where the client
   wishes not to get redirected to domains known to host malware or
   malicious content.  This request is sent as an EDNS0 [EDNS0] option
   with every DNS request, or potentially to just the first DNS request
   in a stream when using DNS over TLS, DNS over DTLS or DNS over DOH
   for example.

   One could argue that clients could accomplish these goals by simply
   using a different resolver.  However, this specifications allows
   decoupling of resolvers and filtering such that a default resolver
   configured in an operating system or application can still use a

Hardaker                 Expires March 29, 2020                 [Page 3]
Internet-Draft             DNS Filter Request             September 2019

   system-level configured filtering mechanism acting independently of
   resolution.  A client can then select the best resolver to support
   resolution services which can be independent from the best source of
   malicious content or other filtering.

1.3.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119]

2.  Extension Overview

2.1.  Extension Packet Format

   The EDNS0 option format for passing a Filter Request (FR) list to the
   upstream DNS resolver using the following format:

        0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   0: |                            OPTION-CODE                        |
   2: |                           OPTION-LENGTH                       |
   4: / FILTER-NAME ...                                            /

   The FILTER-NAME field is a normally encoded DNS NAME that is expected
   to point to a publicly published DNS record from the filtering
   service a client wishes to make use of.  Details of this record are
   documented in Section 3.

   XXX: better text for normally encoded, and compression, etc

3.  Filter Record Overview

   Filtering services that wish to publish a DNS domain filter list may
   publish a DNS record containing a URI from which a resolver may fetch
   the current filter list.  This published name MUST be of type TXT and
   MUST begin with _dnsfilter but otherwise may be published at any
   point in the DNS tree.  Multiple records SHOULD be considered as
   alternate fetch points and recursive resolvers supporting this
   specification should fetch the first one available and then continue
   with the steps outlined in Section 5.

   Example: 86400 IN TXT ""

Hardaker                 Expires March 29, 2020                 [Page 4]
Internet-Draft             DNS Filter Request             September 2019

   The name "" may then be referred to by clients
   in the FR extension packet.

4.  ISP signalling

   ISPs offering filtering service to their clients may signal suggested
   filtering lists to their clients via ... DHCP?  (because starting one
   fight in this document wasn't enough)

   Maybe a DNS request hosted by the dhcp configured resolver?

   (aka: ideas welcome here.)

5.  Resolver processing

   Recursive resolvers supporting this specification should perform the
   following steps upon receiving a request with a FILTER-NAME option.

   1.  If the recursive resolver does not support filtering, it should
       process the DNS request as normal and return an Extended DNS
       Error (EDE) error of "filteringNotSupported" along with the
       response.  Stop.

   2.  If the FILTER-NAME is not currently in its cached set of DNS
       filters, it should attempt to resolver the name pointed to by the
       FILTER-NAME record.  The list of returned URLs should attempted
       to be fetched, and the first successful download should be stored
       in a filter cache along with the FILTER-NAME and the cache length
       returned by the URL server [XXX: what's the HTTP field; I
       forget].  If no URL can be successfully retrieved, then the
       resolver should continue to process the DNS request without
       applying a filter and return an EDE error of

   3.  The filter list returned by the URL must be of type text/plain,
       and must be a simple list of domain names that are to be blocked
       as requested.  Names encode in the list MUST domain names, as
       encoded in printed zone-format names including any required
       internationalization support.  The names MUST not include a
       leading or trailing dot.  For simplicity, no wild-carding is
       supported and a prefix of "*." is assumed.  Partial end-matches
       MUST NOT but considered a match.  For example, a domain
       "" will match a filter entry of
       "" but MUST NOT match an entry of
       "".  See Section 5.1 for an example of what a
       filter list may look like.  If the client's request matches a
       filter in the requested filter list, a response is sent to the

Hardaker                 Expires March 29, 2020                 [Page 5]
Internet-Draft             DNS Filter Request             September 2019

       client with an REFUSED RCODE and a EDE error code of "errfiltered

   4.  The resolver should continue normal resolution of the client's

   XXX: should we add a 'stop' or 'continue' on error bit to the EDNS0

5.1.  Example Filter List

   An example filter list might include the following name list:
   [need an internationalization example here]

   Note that the last example matches everything under the 'example' TLD

6.  Security Considerations

   Modification, addition or removal of the EDNS0 option by device-in-
   the-middle attackers may cause unintended consequences for clients
   hoping to apply (or avoid) filtering.  It is advisable that DNS
   requests that make use of this option send it over an authenticated
   transport such as [DNSTLS] or [DOH].

   Similarly, providers of DNS FILTERING lists SHOULD published their
   FILTER-NAME within a DNSSEC signed zone.  They SHOULD offer (and
   require) URLs that make use of protected transports, such as [HTTPS].

7.  IANA Considerations

   This document adds two new EDE codes to the EDE (xxx: ref)
   specification: filteringNotSupported and filteringUnavailable.

8.  Informative References

   [DNSTLS]   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, <>.

   [DOH]      Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,

Hardaker                 Expires March 29, 2020                 [Page 6]
Internet-Draft             DNS Filter Request             September 2019

   [EDNS0]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, DOI 10.17487/RFC2671, August 1999,

   [HTTPS]    Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015, <https://www.rfc-

   [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-

Appendix A.  Acknowledgments

   peeps that help out will go here

Author's Address

   Wes Hardaker


Hardaker                 Expires March 29, 2020                 [Page 7]