draft-ietf-dnsop-dns-wireformat-http-02.txt   draft-ietf-dnsop-dns-wireformat-http-03.txt 
Internet Engineering Task Force L. Song Internet Engineering Task Force L. Song
Internet-Draft Beijing Internet Institute Internet-Draft Beijing Internet Institute
Intended status: Experimental P. Vixie Intended status: Experimental P. Vixie
Expires: September 22, 2018 TISF Expires: January 3, 2019 TISF
S. Kerr S. Kerr
March 21, 2018 July 2, 2018
An Proxy Use Case of DNS over HTTPS An Proxy Use Case of DNS over HTTPS
draft-ietf-dnsop-dns-wireformat-http-02 draft-ietf-dnsop-dns-wireformat-http-03
Abstract Abstract
This memo introduces a DNS proxy use case to tunnel DNS query and This memo introduces a DNS proxy use case to tunnel DNS query and
response over HTTPs using DOH, a newly proposed DNS transport. This response using DNS over HTTPs (DOH) protocol, a newly proposed DNS
is useful in some situation where DNS is not working properly and DOH transport. The proxy use case is useful as a incremental adoption
is not widely available for many stub-resolvers. tool when DOH is not widely available in old-transport client and
server.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2018. This Internet-Draft will expire on January 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use case description . . . . . . . . . . . . . . . . . . . . 3 2. Use case description . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 3. Original transport indicator in DOH proxy . . . . . . . . . . 4
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Implementation considerations . . . . . . . . . . . . . . . . 4
4.1. Registration of application/dns-tcpwireformat Media Type 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
RFC 1035 [RFC1035] specifies the wire format for DNS messages. It RFC 1035 [RFC1035] specifies the wire format for DNS messages. It
also specifies DNS transport on UDP and TCP on port 53, which is also specifies DNS transport on UDP and TCP on port 53, which is
still used today. To enhance the availability of honest DNS, a new still used today. To enhance the availability of honest DNS, a new
DNS transport DOH is proposed which transport DNS over HTTPs DNS transport: DNS over HTTPs (DOH) [I-D.ietf-doh-dns-over-https] is
[I-D.ietf-doh-dns-over-https], in a way to cure DNS's long-time proposed which transport DNS over HTTPs , in a way to cure DNS's
suffering from on-path attack by spoofing and blocking. long-time suffering from on-path attack by spoofing and blocking.
This memo introduces a DNS proxy use case to leverage the DOH This memo introduces a DNS proxy use case to leverage the DOH
protocol as a substrate to tunnel DNS data over HTTPs which is called protocol as a substrate to tunnel DNS data over HTTPs which is called
called DOH proxy in the rest of the document. It is useful DOH proxy in the rest of the document. It is useful especially when
especially when most DNS stub-resolvers and servers are not aware the most DNS stub-resolvers and far-end servers are not aware the new DOH
new DOH protocol, but a public or private proxy using DOH can be protocol, but a public or private proxy using DOH can be deployed and
deployed and offer DOH capacity to users to bypass the networks where offer DOH capacity to users to bypass the networks where DNS is not
DNS is not working properly. working properly.
Just as a normal DNS proxy described in [RFC5625], DOH proxy works as Just as a normal DNS proxy described in [RFC5625], DOH proxy works as
a simple DNS forwarder keeping the transparency principle, so any a simple DNS forwarder keeping the transparency principle, so any
"hop-by-hop" mechanisms or newly introduced protocol extensions "hop-by-hop" mechanisms or newly introduced protocol extensions
operate as if the proxy were not there. The only difference is DOH operate as if the proxy were not there.
proxy consist two part, a proxy client as a initiator of DOH tunnel
and a proxy server as a terminator.
In order to keep the transparency of DOH proxy, a new media type is In order to keep the transparency of DOH proxy, a new variable
required in DOH proxy use case to allow the proxy client and proxy "proto" in URI Template is defined for DOH proxy use case. It allows
server use the same transport (UDP or TCP) connecting sub-resolver the proxy server use the same transport protocol (UDP or TCP) to
and far-end server. forward DNS query to far-end server just as the stub-client does
without DOH proxy.
May REMOVE BEFORE PUBLICATION: Comparing using a general VPN, the DOH May REMOVE BEFORE PUBLICATION: Comparing using a general VPN, the DOH
proxy can work on an actual HTTP server, so it can be hosted on a 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 machine that also serves web pages. This means that DNS over HTTP is
slightly more "stealthy" than a VPN, in that it can be slightly more "stealthy" than a VPN, in that it can be
indistinguishable from normal web traffic. indistinguishable from normal web traffic.
2. Use case description 2. Use case description
As mentioned in introduction, DOH proxy is a special use case to
provide to end users with better DNS availability by leveraging the
DOH protocol. The proxy client and proxy server speak DOH which
served as a tunnel for DNS query and response.
The typical scenario is that a DOH proxy sitting between stub- The typical scenario is that a DOH proxy sitting between stub-
resolver and the recursive server. The stub-resolver is configured resolver and the recursive server. The stub-resolver is configured
sending DNS query to a proxy client and expected reply from the same sending DNS query to a DOH proxy and expects reply from the same DOH
proxy client. If proxy client receives the query via UDP, then it proxy . Just as a normal DNS proxy described in [RFC5625], DOH proxy
will carry the media type "application/dns-udpwireformat" in the HTTP works as a simple DNS forwarder keeping the transparency principle.
request and includes the DNS query as the message body as defined in The only difference is DOH proxy consist two part, a proxy client as
DOH protocol. If proxy client receives the query via TCP, then it a initiator of DOH tunnel and a proxy server as a terminator. The
will carry a new media type defined in this document "application/ proxy client speaks DOH with proxy server carrying the same DNS query
dns-tcpwireformat" and speak DOH with proxy server with the same DNS received from stub-resolver.The proxy server will forward the exact
query without the two-byte length field defined in DNS over TCP DNS query received from stub-resolver to the configued recursive
[section 4.2.2 in [RFC1035]]. server.
The proxy server MUST be able to process both "application/dns- To keep the transparency principle of DOH proxy, any "hop-by-hop"
udpwireformat" and "application/dns-tcpwireformat" request messages mechanisms or newly introduced protocol extensions operate as if the
and forward the query to a configured recursive server using the same DOH proxy were not there. Different from the native DOH protocol, in
transport between sub-resolver and proxy client. The response will DOH proxy use case, there should be a indication introduced for proxy
be delivered back to sub-resolver accordingly. In DOH proxy use client to tell the proxy server original transport (UDP or TCP) the
case, each DNS query-response pair is mapped into a DOH query- stub-resolver uses to send DNS query to proxy client.
response pair. And the transport for DNS query and response MUST be
the same. For example if the proxy client receives the query via UDP, then it
will notify the proxy server with a "proto=udp" indicator which is
defined in Section 3. If proxy client receives the query via TCP,
then it will carry a "proto=tcp" indicator with the same DNS query
without the two-byte length field defined in DNS over TCP [section
4.2.2 in [RFC1035]].
Besides the original transport indicator, as specified in DOH
document, the proxy server MUST be able to process both "application/
dns-message"request messages and forward the query to a configured
recursive server using the same transport between sub-resolver and
proxy client. The response will be delivered back to sub-resolver
accordingly. In DOH proxy use case, each DNS query-response pair is
mapped into a DOH query-response pair. And the transport for DNS
query and response MUST be the same.
It is possible that a proxy client as a module can be deployed in the It is possible that a proxy client as a module can be deployed in the
same host with the sub-client listening to a loop-back address. A same host with the sub-client listening to a loop-back address. A
proxy server can be implemented that way to host a recursive DNS proxy server can be implemented that way to host a recursive DNS
process as well. The can be combined to form four deployment process as well. The can be combined to form four deployment
scenarios of DOH proxy use case. scenarios of DOH proxy use case.
It is also possible to use the proxy server as a regular web server 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. at the same time that is acting as a proxy server.
Note that the proxy client will face the same bootstrapping problem Note that the proxy client will face the same bootstrapping problem
described in DOH when the HTTPs request needs to resolve the name of described in DOH when the HTTPs request needs to resolve the name of
server and send the request to on IP address. The strategy is either server and send the request to on IP address. The strategy is either
use the IP directly or use another resolver (like the normal DHCP- use the IP directly or use another resolver (like the normal DHCP-
supplied resolver) to lookup the IP of the server. supplied resolver) to lookup the IP of the server.
3. Security Considerations 3. Original transport indicator in DOH proxy
In DOH document[I-D.ietf-doh-dns-over-https], the HTTP request uses a
URI defined by the DOH server through the use of a URI Template in
which no variables is defined. In this document, a new variable
"proto" is defined as the indicator of original transport. For
example, The URI "https://example.com/proxy_dns?proto=tcp" will cause
the server to make a request using TCP. And the URL
"https://example.com/proxy_dns?proto=udp" will cause the server to
make a request using UDP.
4. Implementation considerations
The DOH proxy may return TC bit to the sub-resolver which will cause
TCP fallback starting from the sub-resolver. An alternative advised
is that the proxy has to have sufficient smarts to recognize the
returned TC bit and re-issue the request over TCP to the back-end DNS
server.
Another implementation is suggested that DOH proxy server has a pool
of TCP connections from the proxy to the back-end DNS server(s), over
which incoming requests can be multiplexed.
5. Security Considerations
The DOH proxy use case does not introduce new protocol and any new The DOH proxy use case does not introduce new protocol and any new
security considerations since it is built on the DNS over HTTPS security considerations since it is built on the DNS over HTTPS
protocols. All security considerations and recommendations apply in protocols. All security considerations and recommendations apply in
DOH proxy use case. DOH proxy use case.
Since DOH proxy is a also a special DNS proxy, the security Since DOH proxy is a also a special DNS proxy, the security
recommendations of DNS proxy RFC 5625 [RFC5625] also apply in DOH recommendations of DNS proxy RFC 5625 [RFC5625] also apply in DOH
proxy use case. proxy use case.
Note that the ability to perform DNS queries in this way may allow Note that the ability to perform DNS queries in this way may allow
users to bypass local DNS policy. This may be problematic in any users to bypass local DNS policy. This may be problematic in any
environment where administrators need to enforce specific DNS environment where administrators need to enforce specific DNS
behavior, such as an enterprise environment. The protocol outlined behavior, such as an enterprise environment. The protocol outlined
here does not introduce any new capabilities in this area, but by here does not introduce any new capabilities in this area, but by
creating a more standardized way of doing this it may cause creating a more standardized way of doing this it may cause
operational problems for enterprise administrators. operational problems for enterprise administrators.
4. IANA considerations 6. IANA considerations
4.1. Registration of application/dns-tcpwireformat Media Type
To: ietf-types@iana.org
Subject: Registration 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 binary format. The contents are a
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 No IANA considerations for DOH proxy
5. Acknowledgments 7. Acknowledgments
Thanks to Bob Harold, Paul Hoffman, Julian Reschke, and Erik Kline Thanks to Bob Harold, Paul Hoffman, Julian Reschke, Martin Thomson,
for review. Tony Finch ,Ray Bellis and Erik Kline for their review and comments.
6. References 8. References
[I-D.ietf-doh-dns-over-https] [I-D.ietf-doh-dns-over-https]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS", Hoffman, P. and P. McManus, "DNS Queries over HTTPS
draft-ietf-doh-dns-over-https-03 (work in progress), (DoH)", draft-ietf-doh-dns-over-https-12 (work in
February 2018. progress), June 2018.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009,
<https://www.rfc-editor.org/info/rfc5625>. <https://www.rfc-editor.org/info/rfc5625>.
Authors' Addresses Authors' Addresses
 End of changes. 20 change blocks. 
104 lines changed or deleted 93 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/