idnits 2.17.1 draft-ietf-dnsop-dns-wireformat-http-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 116: '...The proxy server MUST be able to proce...' RFC 2119 keyword, line 122: '...ort for DNS query and response MUST be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2018) is 2228 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-doh-dns-over-https-03 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Song 3 Internet-Draft Beijing Internet Institute 4 Intended status: Experimental P. Vixie 5 Expires: September 22, 2018 TISF 6 S. Kerr 7 March 21, 2018 9 An Proxy Use Case of DNS over HTTPS 10 draft-ietf-dnsop-dns-wireformat-http-02 12 Abstract 14 This memo introduces a DNS proxy use case to tunnel DNS query and 15 response over HTTPs using DOH, a newly proposed DNS transport. This 16 is useful in some situation where DNS is not working properly and DOH 17 is not widely available for many stub-resolvers. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 22, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Use case description . . . . . . . . . . . . . . . . . . . . 3 55 3. Security Considerations . . . . . . . . . . . . . . . . . . . 3 56 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. Registration of application/dns-tcpwireformat Media Type 4 58 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 RFC 1035 [RFC1035] specifies the wire format for DNS messages. It 65 also specifies DNS transport on UDP and TCP on port 53, which is 66 still used today. To enhance the availability of honest DNS, a new 67 DNS transport DOH is proposed which transport DNS over HTTPs 68 [I-D.ietf-doh-dns-over-https], in a way to cure DNS's long-time 69 suffering from on-path attack by spoofing and blocking. 71 This memo introduces a DNS proxy use case to leverage the DOH 72 protocol as a substrate to tunnel DNS data over HTTPs which is called 73 called DOH proxy in the rest of the document. It is useful 74 especially when most DNS stub-resolvers and servers are not aware the 75 new DOH protocol, but a public or private proxy using DOH can be 76 deployed and offer DOH capacity to users to bypass the networks where 77 DNS is not working properly. 79 Just as a normal DNS proxy described in [RFC5625], DOH proxy works as 80 a simple DNS forwarder keeping the transparency principle, so any 81 "hop-by-hop" mechanisms or newly introduced protocol extensions 82 operate as if the proxy were not there. The only difference is DOH 83 proxy consist two part, a proxy client as a initiator of DOH tunnel 84 and a proxy server as a terminator. 86 In order to keep the transparency of DOH proxy, a new media type is 87 required in DOH proxy use case to allow the proxy client and proxy 88 server use the same transport (UDP or TCP) connecting sub-resolver 89 and far-end server. 91 May REMOVE BEFORE PUBLICATION: Comparing using a general VPN, the DOH 92 proxy can work on an actual HTTP server, so it can be hosted on a 93 machine that also serves web pages. This means that DNS over HTTP is 94 slightly more "stealthy" than a VPN, in that it can be 95 indistinguishable from normal web traffic. 97 2. Use case description 99 As mentioned in introduction, DOH proxy is a special use case to 100 provide to end users with better DNS availability by leveraging the 101 DOH protocol. The proxy client and proxy server speak DOH which 102 served as a tunnel for DNS query and response. 104 The typical scenario is that a DOH proxy sitting between stub- 105 resolver and the recursive server. The stub-resolver is configured 106 sending DNS query to a proxy client and expected reply from the same 107 proxy client. If proxy client receives the query via UDP, then it 108 will carry the media type "application/dns-udpwireformat" in the HTTP 109 request and includes the DNS query as the message body as defined in 110 DOH protocol. If proxy client receives the query via TCP, then it 111 will carry a new media type defined in this document "application/ 112 dns-tcpwireformat" and speak DOH with proxy server with the same DNS 113 query without the two-byte length field defined in DNS over TCP 114 [section 4.2.2 in [RFC1035]]. 116 The proxy server MUST be able to process both "application/dns- 117 udpwireformat" and "application/dns-tcpwireformat" request messages 118 and forward the query to a configured recursive server using the same 119 transport between sub-resolver and proxy client. The response will 120 be delivered back to sub-resolver accordingly. In DOH proxy use 121 case, each DNS query-response pair is mapped into a DOH query- 122 response pair. And the transport for DNS query and response MUST be 123 the same. 125 It is possible that a proxy client as a module can be deployed in the 126 same host with the sub-client listening to a loop-back address. A 127 proxy server can be implemented that way to host a recursive DNS 128 process as well. The can be combined to form four deployment 129 scenarios of DOH proxy use case. 131 It is also possible to use the proxy server as a regular web server 132 at the same time that is acting as a proxy server. 134 Note that the proxy client will face the same bootstrapping problem 135 described in DOH when the HTTPs request needs to resolve the name of 136 server and send the request to on IP address. The strategy is either 137 use the IP directly or use another resolver (like the normal DHCP- 138 supplied resolver) to lookup the IP of the server. 140 3. Security Considerations 142 The DOH proxy use case does not introduce new protocol and any new 143 security considerations since it is built on the DNS over HTTPS 144 protocols. All security considerations and recommendations apply in 145 DOH proxy use case. 147 Since DOH proxy is a also a special DNS proxy, the security 148 recommendations of DNS proxy RFC 5625 [RFC5625] also apply in DOH 149 proxy use case. 151 Note that the ability to perform DNS queries in this way may allow 152 users to bypass local DNS policy. This may be problematic in any 153 environment where administrators need to enforce specific DNS 154 behavior, such as an enterprise environment. The protocol outlined 155 here does not introduce any new capabilities in this area, but by 156 creating a more standardized way of doing this it may cause 157 operational problems for enterprise administrators. 159 4. IANA considerations 161 4.1. Registration of application/dns-tcpwireformat Media Type 162 To: ietf-types@iana.org 163 Subject: Registration of MIME media type 164 application/dns-tcpwireformat 166 MIME media type name: application 168 MIME subtype name: dns-tcpwireformat 170 Required parameters: n/a 172 Optional parameters: n/a 174 Encoding considerations: This is a binary format. The contents are a 175 DNS message as defined in RFC 1035. The format used here is for DNS 176 over UDP, which is the format defined in the diagrams in RFC 1035. 178 Security considerations: The security considerations for carrying 179 this data are the same for carrying DNS without encryption. 181 Interoperability considerations: None. 183 Published specification: This document. 185 Applications that use this media type: 186 Systems that want to ship DNS messages via HTTP. 188 Additional information: 190 Magic number(s): n/a 192 File extension(s): n/a 194 Macintosh file type code(s): n/a 196 Person & email address to contact for further information: 197 Linjian Song, songlinjian@gmail.com 199 Intended usage: COMMON 201 Restrictions on usage: n/a 203 Author: Linjian Song, songlinjian@gmail.com 205 Change controller: IESG 207 5. Acknowledgments 209 Thanks to Bob Harold, Paul Hoffman, Julian Reschke, and Erik Kline 210 for review. 212 6. References 214 [I-D.ietf-doh-dns-over-https] 215 Hoffman, P. and P. McManus, "DNS Queries over HTTPS", 216 draft-ietf-doh-dns-over-https-03 (work in progress), 217 February 2018. 219 [RFC1035] Mockapetris, P., "Domain names - implementation and 220 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 221 November 1987, . 223 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 224 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 225 . 227 Authors' Addresses 229 Linjian Song 230 Beijing Internet Institute 231 2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA 232 Beijing 100176 233 P. R. China 235 Email: songlinjian@gmail.com 236 URI: http://www.biigroup.com/ 238 Paul Vixie 239 TISF 240 11400 La Honda Road 241 Woodside, California 94062 242 US 244 Email: vixie@tisf.net 245 URI: http://www.redbarn.org/ 247 Shane Kerr 248 Antoon Coolenlaan 41 249 Uithoorn 1422 GN 250 NL 252 Email: shane@time-travellers.org