Network Working Group P. Hoffman Internet-Draft ICANN Intended status: Standards Track April 10, 2017 Expires: October 12, 2017 Running DNS in Existing HTTP/2 Connections draft-hoffman-dns-in-existing-http2-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 HTTP/2 connections over TLS, 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 HTTP/2 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 HTTP/2 over TLS Connections . . . . . . . . . 3 2.1. HTTP/2 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction HTTP/2 [RFC7540] over TLS is now used widely by 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/2 over TLS. Running DNS over existing HTTP/2 over TLS 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 HTTP/2 over TLS 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 HTTP/2 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 HTTP/2 over TLS connection that could be defined in the future. Regardless, this document is describing a second DNS service for the user, one Hoffman Expires October 12, 2017 [Page 2] Internet-Draft DNS in Existing HTTP/2 April 2017 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 HTTP/2 over TLS connections after using DNS over port 53 is that the DNS messages are then encrypted. A parallel document, [draft-hoffman-dns-in-existing-quic], covers approximately the same use cases as this one, but describes how to carry DNS in QUIC streams. 2. DNS in Existing HTTP/2 over TLS Connections **** This section, which is the meat of the protocol, is completely tentative. People might have strong opinions on how to best run DNS over HTTP/2. The choice of using a new frame is an early guess for a protocol that meets the desing objectives given above; the HTTPBIS WG might have (much) better alternatives. For example, reserved streams might be a better idea than a new type of frame. **** This document defines a new type of HTTP/2 frame, "DNS". DNS in HTTP/2 is run as a stream of DNS frames. The DNS stub resolver opens an HTTP/2 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 HTTP/2 stream for DNS whenever they wish. 2.1. HTTP/2 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 HTTP/2 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 DATA frame in [RFC7540]. The DNS frame uses the END_STREAM and PADDED frame flags, identically to the DATA frame in [RFC7540]. 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 DATA frame in [RFC7540]. 2.2. Service Discovery The DNS stub resolver discovers whether the HTTP/2 server with the exisiting connection supports DNS resolution by attempting to open a DNS stream in the HTTP/2 connection. Because opening a HTTP/2 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 HTTP/2 April 2017 3. IANA Considerations This section will eventually have a request to assign a new value, TBD, to the "HTTP/2 Frame Type" registry. 4. Security Considerations Running DNS over existing HTTP/2 over TLS connections relies on the security of the TLS connections themselves. A beneficial effect of using DNS over existing HTTP/2 over TLS 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 [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [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, . 5.2. Informative References [draft-hoffman-dns-in-existing-quic] Hoffman, P., "Running DNS in Existing QUIC Connections", 2017, . Author's Address Paul Hoffman ICANN Email: paul.hoffman@icann.org Hoffman Expires October 12, 2017 [Page 5]