Running DNS in Existing QUIC Connections
draft-hoffman-dns-in-existing-quic-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Author | Paul E. Hoffman | ||
Last updated | 2017-04-10 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
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]