Running DNS in Existing QUIC Connections
draft-hoffman-dns-in-existing-quic-00

Network Working Group                                         P. Hoffman
Internet-Draft                                                     ICANN
Intended status: Standards Track                          April 10, 2017
Expires: October 12, 2017

                Running DNS in Existing QUIC Connections
                  draft-hoffman-dns-in-existing-quic-00

Abstract

   Intermediaries such as governments and ISPs spoof DNS responses, and
   block DNS requests to particular recursive resolvers, for a variety
   of reasons.  They spoof by capturing traffic on port 53, or by
   redirecting port 853 traffic in the hopes that the client is using
   opportunistic encryption.  They block if they know the address of a
   resolver that they don't like, such as public resolvers that give
   honest answers.

   This document describes how to run DNS service over existing QUIC
   connections, such as those being used for HTTP for basic web service.
   This design prevents intermediaries from spoofing DNS responses, and
   makes it impossible for intermediaries to block the use of those
   recursive resolvers without blocking the desired HTTP connections.
   It also prevents intermediaries or passive observers from seeing the
   DNS traffic.  This design is meant for communication between a DNS
   stub resolver and a DNS recursive resolver.

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 October 12, 2017.

Hoffman                 Expires October 12, 2017                [Page 1]
Internet-Draft            DNS in Existing QUIC                April 2017

Copyright Notice

   Copyright (c) 2017 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
   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
   2.  DNS in Existing QUIC Connections  . . . . . . . . . . . . . .   3
     2.1.  QUIC DNS Frame Definition . . . . . . . . . . . . . . . .   3
     2.2.  Service Discovery . . . . . . . . . . . . . . . . . . . .   4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   It is expected that, in the not-distant future, Internet users will
   be running QUIC [I-D.ietf-quic-transport] for basic web service to
   many web sites.  Large web sites who care about good DNS resolution
   service (that is, DNS resolution that is not subject to getting wrong
   answers from intermediaries) might want to offer DNS resolution on
   the same servers as those running HTTP over QUIC.  Running DNS over
   existing QUIC connection prevents intermediaries from spoofing DNS
   responses, and makes it impossible for intermediaries to block the
   use of those recursive resolvers without blocking the desired HTTP
   connections.

   This document covers only the use case of getting DNS service once a
   QUIC connection is already set up.  That means that the user already
   has some DNS service before getting to the DNS resolver that is
   running in the existing QUIC connection.  That original DNS service
   might be standard DNS running on port 53 ([RFC1035]), or DNS-in-TLS
   running on port 853 ([RFC7858]), or even DNS in its own QUIC
   connection that could be defined in the future.  Regardless, this

Hoffman                 Expires October 12, 2017                [Page 2]
Internet-Draft            DNS in Existing QUIC                April 2017

   document is describing a second DNS service for the user, one that
   was bootstrapped by running DNS in a way that might have been spoofed
   by an intermediary.

   A beneficial effect of using DNS over existing QUIC connections after
   using DNS over port 53 is that the DNS messages are then encrypted.

   A parallel document, [draft-hoffman-dns-in-existing-http2], covers
   approximately the same use cases as this one, but describes how to
   carry DNS in HTTP/2 over TLS.  A different parallel document,
   [draft-huitema-quic-dnsoquic], covers a very different use case,
   namely starting new individual QUIC connections in order to pass DNS
   traffic.

2.  DNS in Existing QUIC Connections

   **** This section, which is the meat of the protocol, is completely
   tentative.  The choice of using a new frame is an early guess for a
   protocol that meets the desing objectives given above; the QUIC WG
   might have (much) better alternatives.  For example, reserved streams
   might be a better idea than a new type of frame.  As
   [I-D.ietf-quic-transport] matures, this section will become more
   definitive.  ****

   This document defines a new type of QUIC frame, "DNS".

   DNS in QUIC is run as a stream of DNS frames.  The DNS stub resolver
   opens an QUIC stream if it is not already open.  The stub resolver
   then sends DNS wire-format requests ([RFC1035]), and the recursive
   resolver sends wire-format requests in the same stream.  The wire
   format used is that for DNS over UDP (not with the extra two-octet
   header defined in [RFC1035] for TCP).  Either side can close the QUIC
   stream for DNS whenever they wish.

2.1.  QUIC DNS Frame Definition

   DNS frames (type=0xTBD) convey variable-length sequences of octets
   associated with a DNS message.  One or more DNS frames are used, for
   instance, to carry a DNS request or response payload.

   DNS frames MAY also contain padding.  Padding can be added to DNS
   frames to obscure the size of messages.  Padding is a security
   feature; see Section 4.

   The format of the DNS frame is:

Hoffman                 Expires October 12, 2017                [Page 3]
Internet-Draft            DNS in Existing QUIC                April 2017

   +---------------+
   |Pad Length? (8)|
   +---------------+-----------------------------------------------+
   |                         DNS message (*)                     ...
   +---------------------------------------------------------------+
   |                           Padding (*)                       ...
   +---------------------------------------------------------------+

                        Figure 1: DNS frame format

   The DNS frame contains the following fields:

   Pad Length:  An 8-bit field containing the length of the frame
      padding in units of octets.  This field is conditional (as
      signified by a "?" in the diagram) and is only present if the
      PADDED flag is set for the frame.

   DNS message:  The wire-format of the message.  The wire format used
      is that for DNS over UDP (not with the extra two-octet header
      defined in [RFC1035] for TCP).

   Padding:  Padding octets that contain no application semantic value.
      This is handled identically to padding in the STREAM frame in
      [I-D.ietf-quic-transport].

   The DNS frame uses the RST_STREAM and PADDED frame flags, identically
   to the STREAM frame in [I-D.ietf-quic-transport].

   DNS frames MUST be associated with a stream.  If a DNS frame is
   received whose stream identifier field is 0x0, the recipient MUST
   respond with a connection error of type PROTOCOL_ERROR.

   DNS frames are subject to flow control identical to the STREAM frame
   in [I-D.ietf-quic-transport].

2.2.  Service Discovery

   The DNS stub resolver discovers whether the QUIC server with the
   exisiting connection supports DNS resolution by attempting to open a
   DNS stream in the QUIC connection.  Because opening a QUIC stream
   requires sending protocol data, the stub resolver needs to pick a DNS
   request to use as a probe for DNS resolution service.  The stub
   resolver might send a request for data it actually wants, or it could
   send a request that it does not care about, such as the A record for
   example.com.

Hoffman                 Expires October 12, 2017                [Page 4]
Internet-Draft            DNS in Existing QUIC                April 2017

3.  IANA Considerations

   As this document gets closer to completion, this section will mostly
   likely be filled in with an assignment from one or more QUIC-related
   registries.

4.  Security Considerations

   Running DNS over existing QUIC connections relies on the security of
   the QUIC connections themselves.

   A beneficial effect of using DNS over existing QUIC connections after
   using DNS over port 53 is that the DNS messages are then encrypted.

   *** Copy some text about the uses (and abuses) of padding from
   Section 10.7 of RFC 7540 here. ***

5.  References

5.1.  Normative References

   [I-D.ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", draft-ietf-quic-transport-02 (work
              in progress), March 2017.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC7858]  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, <http://www.rfc-editor.org/info/rfc7858>.

5.2.  Informative References

   [draft-hoffman-dns-in-existing-http2]
              Hoffman, P., "Running DNS in Existing HTTP/2 Connections",
              2017, <https://tools.ietf.org/id/draft-hoffman-dns-in-
              existing-http2>.

   [draft-huitema-quic-dnsoquic]
              Huitema, C. and et. al, "Specification of DNS over QUIC",
              2017, <https://tools.ietf.org/id/draft-huitema-quic-
              dnsoquic>.

Hoffman                 Expires October 12, 2017                [Page 5]
Internet-Draft            DNS in Existing QUIC                April 2017

Author's Address

   Paul Hoffman
   ICANN

   Email: paul.hoffman@icann.org

Hoffman                 Expires October 12, 2017                [Page 6]