Internet Engineering Task Force                                  L. Song
Internet-Draft                                Beijing Internet Institute
Intended status: Experimental                                   P. Vixie
Expires: September 28, 2017 22, 2018                                         TISF
                                                                 S. Kerr
                                                                  R. Wan
                                              Beijing Internet Institute
                                                          March 27, 2017 21, 2018

                  An Proxy Use Case of DNS wire-format over HTTP
                draft-ietf-dnsop-dns-wireformat-http-01 HTTPS
                draft-ietf-dnsop-dns-wireformat-http-02

Abstract

   This memo introduces a way DNS proxy use case to tunnel DNS data query and
   response over HTTP. HTTPs using DOH, a newly proposed DNS transport.  This may be
   is useful in any some situation where DNS is not working properly, such as
   when there properly and DOH
   is middlebox misbehavior. not widely available for many stub-resolvers.

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/. https://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 September 28, 2017. 22, 2018.

Copyright Notice

   Copyright (c) 2017 2018 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)
   (https://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.  Methodology and Configuration . . . . . . . . . . . . . . . .   3
   3.  DNS-over-HTTP Message Format  . . . . . . . . . . . . . . . .   4
     3.1.  Request Method  . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Response Status Code  . . . . . . . . . . . . . . . . . .   5
     3.3.  Header Fields . . . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Message Body  . .  Use case description  . . . . . . . . . . . . . . . . . . . .   6
   4.   3
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
   6.   3
   4.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.   4
     4.1.  Registration of application/dns-tcpwireformat Media Type    4
   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   8.   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10   6

1.  Introduction

   RFC 1035 [RFC1035] specifies the wire format for DNS messages.  It
   also specifies DNS transport on UDP and TCP on port 53, which is
   still used today.  However, there are other ways to access DNS
   database, for example in  To enhance the availability of honest DNS, a different data format or via alternative new
   DNS transport.  These approaches are summarized in [draft-shane-
   review-DNS-over-http].

   One of alternative way of using transport DOH is proposed which transport DNS described over HTTPs
   [I-D.ietf-doh-dns-over-https], in that document is a way to
   transport cure DNS's long-time
   suffering from on-path attack by spoofing and blocking.

   This memo introduces a DNS binary data inside HTTP, with proxy use case to leverage the goal of improving DNS
   service availability.  The DNS traffic is simply sent DOH
   protocol as web traffic
   using port 80/443 a substrate to tunnel DNS data over HTTP.  It can bypass badly behaving middle
   boxes like firewalls, proxies or traffic shaping devices on path HTTPs which might interfere with normal DNS traffic [RFC5625] [DOTSE]
   [SAC035].

   This approach has is called
   called DOH proxy in the advantage that HTTP usually makes it through
   even rest of the worst coffee shop or hotel room firewalls, as Internet document.  It is useful
   especially when most DNS stub-resolvers and servers are not aware the
   new DOH protocol, but a public or private proxy using DOH can be
   deployed and offer DOH capacity to users
   expect web browsing to always work.  It also benefits from HTTP's
   support for persistent TCP connections (see section 6.3 in
   [RFC7230]).  Note that 5966bis [I-D.ietf-dnsop-5966bis] specifies bypass the
   persistent feature for networks where
   DNS on TCP port 53, but current is not working properly.

   Just as a normal DNS software
   does proxy described in [RFC5625], DOH proxy works as
   a simple DNS forwarder keeping the transparency principle, so any
   "hop-by-hop" mechanisms or newly introduced protocol extensions
   operate as if the proxy were not generally support this mode there.  The only difference is DOH
   proxy consist two part, a proxy client as a initiator of operation.  Finally, HTTPS
   provides data integrity DOH tunnel
   and privacy.

   One alternative idea a proxy server as a terminator.

   In order to keep the transparency of DOH proxy, a new media type is
   required in DOH proxy use case to simply allow the proxy client and proxy
   server use the same transport (UDP or TCP) connecting sub-resolver
   and far-end server.

   May REMOVE BEFORE PUBLICATION: Comparing using a general VPN, rather than a custom
   protocol for this purpose.  While this is possible, the DNS over HTTP
   wire format protocol presented here works DOH
   proxy can work on an actual HTTP server, so it can be hosted on a
   machine that also serves web pages.  This means that DNS over HTTP is
   slightly more "stealthy" than a VPN, in that it can be
   indistinguishable from normal web traffic.

   Unlike

2.  Use case description

   As mentioned in introduction, DOH proxy is a REST special use case to
   provide to end users with better DNS API using JSON [I-D.bortzmeyer-dns-json] or XML
   [I-D.mohan-dns-query-xml] encoding availability by leveraging the
   DOH protocol.  The proxy client and proxy server speak DOH which
   served as a tunnel for DNS data, in this approach
   wire-format data query and response.

   The typical scenario is wrapped with that a HTTP header DOH proxy sitting between stub-
   resolver and transmitted on
   port 80 or 443. the recursive server.  The protocol stub-resolver is intended configured
   sending DNS query to serve as a sort of DNS
   VPN, proxy client and does not introduce another format of expected reply from the same
   proxy client.  If proxy client receives the query via UDP, then it
   will carry the media type "application/dns-udpwireformat" in the HTTP
   request and includes the DNS data.  It is also
   possible query as the message body as defined in
   DOH protocol.  If proxy client receives the query via TCP, then it
   will carry a new DNS APIs for advanced usage media type defined in application
   development.  For example, web developers can create arbitrary HTTP/
   HTTPS queries this document "application/
   dns-tcpwireformat" and get DNS responses in their JavaScript apps.

   This memo aims to describe how the DNS binary over HTTP concept
   works.  Hopefully implementations by different developers following
   this memo can speak DOH with each other.

   This mechanism is designed for client stub resolver to recursive
   server.  DNS zone transfer, DNS updates, and anything other than
   simple DNS queries are out-of-scope for this document.

2.  Methodology and Configuration

   As mentioned in introduction, the basic methodology is wrapping the
   DNS wire-format data into an HTTP header and transmitting on port 80
   or 443.  However, there are two different scenarios for
   implementation.

   Scenario 1:

   The DNS proxy server implementation handles DNS queries and responses via
   both UDP and TCP on port 53, and HTTP on port 80 or 443.  It works as
   follows:

   1.  The client creates a with the same DNS
   query message.

   2.  The client encapsulates without the two-byte length field defined in DNS message over TCP
   [section 4.2.2 in a HTTP message body
       and assigns parameters with the HTTP header.

   3. [RFC1035]].

   The client connects to the proxy server MUST be able to process both "application/dns-
   udpwireformat" and issues an HTTP POST "application/dns-tcpwireformat" request
       method.  This may re-use an existing HTTP connection.

   4.  The server decapsulates messages
   and forward the HTTP packet query to get a configured recursive server using the DNS query, same
   transport between sub-resolver and
       resolves the DNS query.

   5. proxy client.  The server encapsulates the DNS response in HTTP and sends it will
   be delivered back via the HTTP session.

   Scenario 2: to sub-resolver accordingly.  In this scenario there is a DNS-HTTP DOH proxy sitting between stub-
   resolver and the recursive server.  The stub uses use
   case, each DNS query-response pair is mapped into a client proxy and DOH query-
   response pair.  And the recursive server uses a server proxy.  This works like a transport for DNS VPN query and transmits wire-format DNS messages over HTTP between response MUST be
   the same.

   It is possible that a proxy client and a server, as follows:

   1.  The stub-resolver sends a DNS query (over UDP or TCP) to the
       proxy client.

   2.  The proxy client encapsulates the DNS message module can be deployed in an HTTP message
       body and assigns parameters the
   same host with the HTTP header.

   3.  The proxy client connects sub-client listening to the a loop-back address.  A
   proxy server and issues an HTTP
       POST request method.  This may re-use an existing HTTP
       connection.

   4.  The proxy server decapsulates the HTTP packet to get the DNS
       query, and sends it to a real DNS server over UDP/TCP.

   5.  The proxy server encapsulates the DNS response in HTTP and sends
       it back via the HTTP session.

   6.  The proxy client decapsulates the DNS message from the HTTP
       response and sends it back to the stub-resolver via previous DNS
       session (either UDP or TCP).

   It is possible that these scenarios are mixed.  The server may speak
   DNS over HTTP directly and the client use a proxy, or the other way
   around.

   Note that the proxy client can be implemented listening that way to a loop-
   back address in the same host with stub-resolver.  The proxy server
   can be implemented as a caching server recursive DNS
   process as well.  The can be combined to form four deployment
   scenarios of DOH proxy use case.

   It is also possible to use the proxy server as a regular web server
   at the same time that is acting as a proxy server.

3.  DNS-over-HTTP Message Format

   DNS over HTTP is not tied to a specific version of HTTP, and should
   work with HTTP 1.1 [RFC7230] and HTTP/2 [RFC7540].  This section
   describes

   Note that the details of proxy client will face the DNS over HTTP message format.

3.1.  Request Method

   A DNS message is sent over HTTP from same bootstrapping problem
   described in DOH when the client HTTPs request needs to resolve the name of
   server via a
   properly-formed HTTP request.  This is a POST method request [section
   4.3.3 in RFC 7231 [RFC7231]].  If a GET method and send the request to on IP address.  The strategy is sent either
   use the IP directly or use another resolver (like the normal DHCP-
   supplied resolver) to lookup the
   server, it optionally returns a human-readable page showing
   information targeted at users.

   Note that choosing POST (and not GET) as IP of the request method for DNS
   wire-format over HTTP server.

3.  Security Considerations

   The DOH proxy use case does not introduce new protocol and any new
   security considerations since it is mainly based built on two reasons.  One is that the protocol DNS over HTTPS
   protocols.  All security considerations and recommendations apply in
   DOH proxy use case.

   Since DOH proxy is designed using HTTP as a tunnel-like technology
   carrying data from one side to another, not also a web service with
   RESTful framework.  Another is that from special DNS proxy, the view security
   recommendations of implementation
   some servers or middleboxes may ignore an undefined entity-body if
   using GET; and HTTP libraries have varying support for using GET with
   a payload.

   The target URI is provided explicitly by the services provider.
   Derived from the target URI, the request-target in request-line
   identifies the target resource upon which to apply the request.  To
   avoid URI conflicts and enhance interoperability, DNS wire-format
   over HTTP uses a well-known URI.  As defined in RFC 5785 [RFC5785],
   it begins with the characters "/.well-known/" and the name "dns-
   wireformat".  So the request-target for DNS wire-format over HTTP
   SHOULD be '/.well-known/dns-wireformat'.

   A DNS transaction over HTTP has no specific requirements for the
   transport protocol; developers can use any version of HTTP to
   accomplish the transaction.  But developers should be aware that HTTP
   1.1 [RFC7230] and HTTP/2 [RFC7540] do have differences in performance
   regarding multiplexing.  HTTP/2 is fully multiplexed, instead of
   ordered and blocking.  Because there is a general desire to achieve
   similar performance with DNS over UDP, the modern HTTP/2 is preferred
   for DNS over HTTP implementation.  Note that there should be no
   problem for advanced HTTP protocol in the future deployed for DNS
   over HTTP.

3.2.  Response Status Code

   The status code [Section 6 of [RFC7231]], only reflects the status of
   the HTTP connection.  If the request has succeeded, the status code
   is 200 (OK).

   If the request fails, the proxy server will supply an appropriate
   error code, typically 4xx (client error) if the client has provided a
   query that the server cannot understand for some reasons, or 5xx
   (server error) if some server-side problem prevented a query from
   succeeding.

   To be clear, a failure on the DNS side should result in a status code
   of 200 (OK) as long as the HTTP request is valid and can be answered.
   The DNS error will be returned via the encapsulated DNS message.

3.3.  Header Fields

   By definition header fields are key:value pairs that can be used to
   communicate data about the message, its payload, the target resource,
   or the connection (for example control data).

   The Content-Type: header field should be set to "application/dns-
   wireformat".

   We add one a new header field:

   Proxy-DNS-Transport: xyz

   Where xyz is either UDP or TCP, which is the client's indication of
   how it received the underlying DNS query, and which the server will
   use when sending the query to the far-end DNS server.  This means if
   a stub DNS client asks for TCP, then that's what the far-end DNS
   server will see, and likewise for UDP.

   Exposing the transport protocol of the query allows the HTTP server
   proxy to send DNS queries to the recursive resolver that look like
   those that the DNS client is sending to the client proxy.  If the
   stub resolver sent a UDP packet, then this allows the recursive
   resolver to implement the logic of truncating the packet properly,
   instead of requiring that the HTTP client proxy somehow manage that
   functionality.

   For a stub resolver that connects directly via HTTP to the HTTP
   server proxy then this flag should be set to TCP, as the entire
   response can always be delivered so truncation is never required.

   The client MUST include this option.  If it is missing then it is an
   error and the server should respond with HTTP code 400 (bad request).

3.4.  Message Body

   As mentioned, the message body is DNS wire-format data.  DNS messages
   sent over TCP connections is prefixed with a two-byte length field
   which gives the message length [section 4.2.2 in RFC 1035 [RFC1035]],
   excluding the two-byte length field.  This length field allows the
   low-level processing to assemble a complete message before beginning
   to parse it.  But when HTTP is used, the HTTP protocol itself keeps
   track of the length of the message, so there is no need to transmit
   this separately.

   Since the two-byte length field is redundant, when the client proxy
   receives a DNS message over TCP or when the server sends an answer
   for a TCP query, it MUST NOT include the length field in the message
   sent.  The length of the message sent by HTTP is only the size of the
   DNS message itself, and MUST NOT include this two-byte length header.

4.  Security Considerations

   This protocol does not introduce any new security considerations
   since it is built on the DNS and HTTP protocols.

   Since this protocol transmits DNS messages, all of the security
   concerns that stub resolvers and recursive resolvers have with DNS
   messages apply.  However, since HTTP uses TCP as the underlying
   protocol, DNS reflection or amplification attacks are not possible.

   Since HTTP is used, all of the security concerns of HTTP are also
   present.

   Servers and clients SHOULD use TLS for communication.  It provides
   privacy and integrity for HTTP sessions.  If TLS is used, then all of
   the security concerns of TLS are proxy RFC 5625 [RFC5625] also present.

   As specified apply in RFC 5246 [RFC5246], both the HTTP server and client
   can be authenticated or not authenticated.  Clients SHOULD
   authenticate the certificate of the HTTP server they connect to.  The
   DNS service providers can decide whether to authenticate the client
   side based on their own requirement for security and privacy.  For
   example, clients of an open resolver do not require authentication. DOH
   proxy use case.

   Note that the ability to perform DNS queries in this way may allow
   users to bypass local DNS policy.  This is problematic in any
   environment where administrators need to enforce specific DNS
   behavior, such as an enterprise environment.  The protocol outlined
   here does not introduce any new capabilities in this area, but by
   creating a more standardized way of doing this it may cause
   operational problems for enterprise administrators.

5.  Privacy Considerations

   DNS over HTTP involves sending DNS requests, so is subject to most of
   the problems documented in RFC 7626 [RFC7626].  In particular the
   resolver handling the request sees the contents of every query and
   answer, as does any proxy involved on either the client or server
   side.

   Use of TLS encryption will prevent attackers from seeing the plain
   DNS queries on the wire.  However, the warnings about privacy in RFC
   7858 [RFC7858] apply: "Even with encrypted messages, a well-
   positioned party may be able to glean certain details from an
   analysis of message timings and sizes."

   If a server requires a client-side certificate or other
   authentication, then this may allow an attacker to identify which
   user is active and when, if they gain access to the server logs.

   The use of perform DNS over HTTP queries in this way may act as a strong signal to any
   surviellers that the user is attempting allow
   users to bypass local DNS policy
   either to get different answers or hide their traffic.  Various
   techniques could policy.  This may be used problematic in any
   environment where administrators need to discover this, enforce specific DNS
   behavior, such as observing web
   traffic without an enterprise environment.  The protocol outlined
   here does not introduce any corresponding DNS traffic.

6. new capabilities in this area, but by
   creating a more standardized way of doing this it may cause
   operational problems for enterprise administrators.

4.  IANA considerations

4.1.  Registration for a new of application/dns-tcpwireformat Media Type: dns-wireformat Type
    To: ietf-types@iana.org
    Subject: Registration for of MIME media type
             application/dns-tcpwireformat

    MIME media type name: application

    MIME subtype name: dns-tcpwireformat

    Required parameters: n/a

    Optional parameters: n/a

    Encoding considerations: This is a new HTTP header field: Proxy-DNS-Transport

   Registration for binary format. The contents are a new Well-Known URI: "dns-wireformat"

7.
    DNS message as defined in RFC 1035. The format used here is for DNS
    over UDP, which is the format defined in the diagrams in RFC 1035.

    Security considerations:  The security considerations for carrying
    this data are the same for carrying DNS without encryption.

    Interoperability considerations:  None.

    Published specification:  This document.

    Applications that use this media type:
      Systems that want to ship DNS messages via HTTP.

    Additional information:

    Magic number(s):  n/a

    File extension(s):  n/a

    Macintosh file type code(s):  n/a

    Person & email address to contact for further information:
       Linjian Song, songlinjian@gmail.com

    Intended usage:  COMMON

    Restrictions on usage:  n/a

    Author:  Linjian Song, songlinjian@gmail.com

    Change controller:  IESG

5.  Acknowledgments

   Thanks to Bob Harold, Paul Hoffman, Julian Reschke, and Erik Kline
   for review.

8.

6.  References

   [DOTSE]    and , "DNSSEC Tests of Consumer Broadband Routers",
              February 2008,
              <http://www.iis.se/docs/Routertester_en.pdf>.

   [I-D.bortzmeyer-dns-json]
              Bortzmeyer, S., "JSON format to represent DNS data",
              draft-bortzmeyer-dns-json-01 (work in progress), February
              2013.

   [I-D.ietf-dnsop-5966bis]
              Dickinson, J., Dickinson, S., Bellis, R., Mankin, A.,

   [I-D.ietf-doh-dns-over-https]
              Hoffman, P. and
              D. Wessels, P. McManus, "DNS Transport Queries over TCP - Implementation
              Requirements", draft-ietf-dnsop-5966bis-04 HTTPS",
              draft-ietf-doh-dns-over-https-03 (work in progress), November 2015.

   [I-D.mohan-dns-query-xml]
              Parthasarathy, M. and P. Vixie, "Representing DNS messages
              using XML", draft-mohan-dns-query-xml-00 (work in
              progress), September 2011.
              February 2018.

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

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc1035>.

   [RFC5625]  Bellis, R., "DNS Proxy Implementation Guidelines",
              BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
              <http://www.rfc-editor.org/info/rfc5625>.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              DOI 10.17487/RFC5785, April 2010,
              <http://www.rfc-editor.org/info/rfc5785>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <http://www.rfc-editor.org/info/rfc7231>.

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

   [RFC7626]  Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626,
              DOI 10.17487/RFC7626, August 2015,
              <http://www.rfc-editor.org/info/rfc7626>.

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

   [SAC035]   ICANN Security and Stability Advisory Committee, "DNSSEC
              Impact on Broadband Routers and Firewalls", 2008.
              <https://www.rfc-editor.org/info/rfc5625>.

Authors' Addresses

   Linjian Song
   Beijing Internet Institute
   2508 Room, 25th
   2nd Floor, Tower A, Time Fortune Building 5, No.58 Jing Hai Wu Lu, BDA
   Beijing  100028  100176
   P. R. China

   Email: songlinjian@gmail.com
   URI:   http://www.biigroup.com/

   Paul Vixie
   TISF
   11400 La Honda Road
   Woodside, California  94062
   US

   Email: vixie@tisf.net
   URI:   http://www.redbarn.org/

   Shane Kerr
   Beijing Internet Institute
   2/F, Building 5, No.58 Jinghai Road, BDA
   Beijing  100176
   CN

   Email: shane@biigroup.cn
   URI:   http://www.biigroup.com/

   Runxia Wan
   Beijing Internet Institute
   2508 Room, 25th Floor, Tower A, Time Fortune
   Beijing  100028
   P. R. China
   Antoon Coolenlaan 41
   Uithoorn  1422 GN
   NL

   Email: rxwan@biigroup.cn
   URI:   http://www.biigroup.com/ shane@time-travellers.org