Client DNS Filtering Profile Request
draft-hardaker-dprive-add-doh-dnsop-filter-request-00

Document Type Active Internet-Draft (individual)
Last updated 2019-09-27
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
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
         draft-hardaker-dprive-add-doh-dnsop-filter-request-00

Abstract

   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 http://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 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
   (http://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 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
   background.]

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
Show full document text