idnits 2.17.1 draft-ietf-dnsop-dns-wireformat-http-03.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 127: '...the proxy server MUST be able to proce...' RFC 2119 keyword, line 133: '... query and response MUST be the same....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2018) is 2125 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-12 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: January 3, 2019 TISF 6 S. Kerr 7 July 2, 2018 9 An Proxy Use Case of DNS over HTTPS 10 draft-ietf-dnsop-dns-wireformat-http-03 12 Abstract 14 This memo introduces a DNS proxy use case to tunnel DNS query and 15 response using DNS over HTTPs (DOH) protocol, a newly proposed DNS 16 transport. The proxy use case is useful as a incremental adoption 17 tool when DOH is not widely available in old-transport client and 18 server. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 3, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Use case description . . . . . . . . . . . . . . . . . . . . 3 56 3. Original transport indicator in DOH proxy . . . . . . . . . . 4 57 4. Implementation considerations . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 60 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 64 1. Introduction 66 RFC 1035 [RFC1035] specifies the wire format for DNS messages. It 67 also specifies DNS transport on UDP and TCP on port 53, which is 68 still used today. To enhance the availability of honest DNS, a new 69 DNS transport: DNS over HTTPs (DOH) [I-D.ietf-doh-dns-over-https] is 70 proposed which transport DNS over HTTPs , in a way to cure DNS's 71 long-time suffering from on-path attack by spoofing and blocking. 73 This memo introduces a DNS proxy use case to leverage the DOH 74 protocol as a substrate to tunnel DNS data over HTTPs which is called 75 DOH proxy in the rest of the document. It is useful especially when 76 most DNS stub-resolvers and far-end servers are not aware the new DOH 77 protocol, but a public or private proxy using DOH can be deployed and 78 offer DOH capacity to users to bypass the networks where DNS is not 79 working properly. 81 Just as a normal DNS proxy described in [RFC5625], DOH proxy works as 82 a simple DNS forwarder keeping the transparency principle, so any 83 "hop-by-hop" mechanisms or newly introduced protocol extensions 84 operate as if the proxy were not there. 86 In order to keep the transparency of DOH proxy, a new variable 87 "proto" in URI Template is defined for DOH proxy use case. It allows 88 the proxy server use the same transport protocol (UDP or TCP) to 89 forward DNS query to far-end server just as the stub-client does 90 without DOH proxy. 92 May REMOVE BEFORE PUBLICATION: Comparing using a general VPN, the DOH 93 proxy can work on an actual HTTP server, so it can be hosted on a 94 machine that also serves web pages. This means that DNS over HTTP is 95 slightly more "stealthy" than a VPN, in that it can be 96 indistinguishable from normal web traffic. 98 2. Use case description 100 The typical scenario is that a DOH proxy sitting between stub- 101 resolver and the recursive server. The stub-resolver is configured 102 sending DNS query to a DOH proxy and expects reply from the same DOH 103 proxy . Just as a normal DNS proxy described in [RFC5625], DOH proxy 104 works as a simple DNS forwarder keeping the transparency principle. 105 The only difference is DOH proxy consist two part, a proxy client as 106 a initiator of DOH tunnel and a proxy server as a terminator. The 107 proxy client speaks DOH with proxy server carrying the same DNS query 108 received from stub-resolver.The proxy server will forward the exact 109 DNS query received from stub-resolver to the configued recursive 110 server. 112 To keep the transparency principle of DOH proxy, any "hop-by-hop" 113 mechanisms or newly introduced protocol extensions operate as if the 114 DOH proxy were not there. Different from the native DOH protocol, in 115 DOH proxy use case, there should be a indication introduced for proxy 116 client to tell the proxy server original transport (UDP or TCP) the 117 stub-resolver uses to send DNS query to proxy client. 119 For example if the proxy client receives the query via UDP, then it 120 will notify the proxy server with a "proto=udp" indicator which is 121 defined in Section 3. If proxy client receives the query via TCP, 122 then it will carry a "proto=tcp" indicator with the same DNS query 123 without the two-byte length field defined in DNS over TCP [section 124 4.2.2 in [RFC1035]]. 126 Besides the original transport indicator, as specified in DOH 127 document, the proxy server MUST be able to process both "application/ 128 dns-message"request messages and forward the query to a configured 129 recursive server using the same transport between sub-resolver and 130 proxy client. The response will be delivered back to sub-resolver 131 accordingly. In DOH proxy use case, each DNS query-response pair is 132 mapped into a DOH query-response pair. And the transport for DNS 133 query and response MUST be the same. 135 It is possible that a proxy client as a module can be deployed in the 136 same host with the sub-client listening to a loop-back address. A 137 proxy server can be implemented that way to host a recursive DNS 138 process as well. The can be combined to form four deployment 139 scenarios of DOH proxy use case. 141 It is also possible to use the proxy server as a regular web server 142 at the same time that is acting as a proxy server. 144 Note that the proxy client will face the same bootstrapping problem 145 described in DOH when the HTTPs request needs to resolve the name of 146 server and send the request to on IP address. The strategy is either 147 use the IP directly or use another resolver (like the normal DHCP- 148 supplied resolver) to lookup the IP of the server. 150 3. Original transport indicator in DOH proxy 152 In DOH document[I-D.ietf-doh-dns-over-https], the HTTP request uses a 153 URI defined by the DOH server through the use of a URI Template in 154 which no variables is defined. In this document, a new variable 155 "proto" is defined as the indicator of original transport. For 156 example, The URI "https://example.com/proxy_dns?proto=tcp" will cause 157 the server to make a request using TCP. And the URL 158 "https://example.com/proxy_dns?proto=udp" will cause the server to 159 make a request using UDP. 161 4. Implementation considerations 163 The DOH proxy may return TC bit to the sub-resolver which will cause 164 TCP fallback starting from the sub-resolver. An alternative advised 165 is that the proxy has to have sufficient smarts to recognize the 166 returned TC bit and re-issue the request over TCP to the back-end DNS 167 server. 169 Another implementation is suggested that DOH proxy server has a pool 170 of TCP connections from the proxy to the back-end DNS server(s), over 171 which incoming requests can be multiplexed. 173 5. Security Considerations 175 The DOH proxy use case does not introduce new protocol and any new 176 security considerations since it is built on the DNS over HTTPS 177 protocols. All security considerations and recommendations apply in 178 DOH proxy use case. 180 Since DOH proxy is a also a special DNS proxy, the security 181 recommendations of DNS proxy RFC 5625 [RFC5625] also apply in DOH 182 proxy use case. 184 Note that the ability to perform DNS queries in this way may allow 185 users to bypass local DNS policy. This may be problematic in any 186 environment where administrators need to enforce specific DNS 187 behavior, such as an enterprise environment. The protocol outlined 188 here does not introduce any new capabilities in this area, but by 189 creating a more standardized way of doing this it may cause 190 operational problems for enterprise administrators. 192 6. IANA considerations 194 No IANA considerations for DOH proxy 196 7. Acknowledgments 198 Thanks to Bob Harold, Paul Hoffman, Julian Reschke, Martin Thomson, 199 Tony Finch ,Ray Bellis and Erik Kline for their review and comments. 201 8. References 203 [I-D.ietf-doh-dns-over-https] 204 Hoffman, P. and P. McManus, "DNS Queries over HTTPS 205 (DoH)", draft-ietf-doh-dns-over-https-12 (work in 206 progress), June 2018. 208 [RFC1035] Mockapetris, P., "Domain names - implementation and 209 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 210 November 1987, . 212 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 213 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 214 . 216 Authors' Addresses 218 Linjian Song 219 Beijing Internet Institute 220 2nd Floor, Building 5, No.58 Jing Hai Wu Lu, BDA 221 Beijing 100176 222 P. R. China 224 Email: songlinjian@gmail.com 225 URI: http://www.biigroup.com/ 227 Paul Vixie 228 TISF 229 11400 La Honda Road 230 Woodside, California 94062 231 US 233 Email: vixie@tisf.net 234 URI: http://www.redbarn.org/ 235 Shane Kerr 236 Antoon Coolenlaan 41 237 Uithoorn 1422 GN 238 NL 240 Email: shane@time-travellers.org