idnits 2.17.1 draft-song-dns-wireformat-http-04.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 212: '... SHOULD be '/.well-known/dns-wirefor...' RFC 2119 keyword, line 272: '... The client MUST include this option...' RFC 2119 keyword, line 288: '...age over TCP, it MUST NOT include the ...' RFC 2119 keyword, line 290: '...f the DNS message itself, and MUST NOT...' RFC 2119 keyword, line 306: '...vers and clients SHOULD use TLS for co...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2016) is 2859 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC7231' is defined on line 382, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-5966bis-04 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 7 errors (**), 0 flaws (~~), 3 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: December 23, 2016 TISF 6 S. Kerr 7 R. Wan 8 Beijing Internet Institute 9 June 21, 2016 11 DNS wire-format over HTTP 12 draft-song-dns-wireformat-http-04 14 Abstract 16 This memo introduces a way to tunnel DNS data over HTTP. This may be 17 useful in any situation where DNS is not working properly, such as 18 when there is middlebox misbehavior. 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 http://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 December 23, 2016. 37 Copyright Notice 39 Copyright (c) 2016 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 (http://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. Methodology and Configuration . . . . . . . . . . . . . . . . 3 56 3. DNS-over-HTTP Message Format . . . . . . . . . . . . . . . . 4 57 3.1. Request Method . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Response Status Code . . . . . . . . . . . . . . . . . . 5 59 3.3. Header Fields . . . . . . . . . . . . . . . . . . . . . . 6 60 3.4. Message Body . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 RFC 1035 [RFC1035] specifies the wire format for DNS messages. It 70 also specifies DNS transport on UDP and TCP on port 53, which is 71 still used today. However, there are other ways to access DNS 72 database, for example in a different data format or via alternative 73 DNS transport. These approaches are summarized in [draft-shane- 74 review-DNS-over-http]. 76 One of alternative way of using DNS described in that document is to 77 transport DNS binary data inside HTTP, with the goal of improving DNS 78 service availability. The DNS traffic is simply sent as web traffic 79 using port 80/443 over HTTP. It can bypass badly behaving middle 80 boxes like firewalls, proxies or traffic shaping devices on path 81 which might interfere with normal DNS traffic [RFC5625] [DOTSE] 82 [SAC035]. 84 This approach has the advantage that HTTP usually makes it through 85 even the worst coffee shop or hotel room firewalls, as Internet users 86 expect web browsing to always work. It also benefits from HTTP's 87 support for persistent TCP connections (see section 6.3 in 88 [RFC7230]). Note that 5966bis [I-D.ietf-dnsop-5966bis] specifies the 89 persistent feature for DNS on TCP port 53, but current DNS software 90 does not generally support this mode of operation. Finally, HTTPS 91 provides data integrity and privacy. 93 One alternative idea is to simply use a VPN, rather than a custom 94 protocol for this purpose. While this is possible, the DNS over HTTP 95 wire format protocol presented here works on an actual HTTP server, 96 so it can be hosted on a machine that also serves web pages. This 97 means that DNS over HTTP is slightly more "stealthy" than a VPN, in 98 that it can be indistinguishable from normal web traffic. 100 Unlike a REST DNS API using JSON [I-D.bortzmeyer-dns-json] or XML 101 [I-D.mohan-dns-query-xml] encoding for DNS data, in this approach 102 wire-format data is wrapped with a HTTP header and transmitted on 103 port 80 or 443. The protocol is intended to serve as a sort of DNS 104 VPN, and does not introduce another format of DNS data. It is also 105 possible as a new DNS APIs for advanced usage in application 106 development. For example, web developers can create arbitrary HTTP/ 107 HTTPS queries and get DNS responses in their JavaScript apps. 109 This memo aims to describe how the DNS binary over HTTP concept 110 works. Hopefully implementations by different developers following 111 this memo can speak with each other. 113 This mechanism is designed for client stub resolver to recursive 114 server. DNS zone transfer, DNS updates, and anything other than 115 simple DNS queries are out-of-scope for this document. 117 2. Methodology and Configuration 119 As mentioned in introduction, the basic methodology is wrapping the 120 DNS wire-format data into an HTTP header and transmitting on port 80 121 or 443. However, there are two different scenarios for 122 implementation. 124 Scenario 1: 126 The DNS server implementation handles DNS queries and responses via 127 both UDP and TCP on port 53, and HTTP on port 80 or 443. It works as 128 follows: 130 1. The client creates a DNS query message. 132 2. The client encapsulates the DNS message in a HTTP message body 133 and assigns parameters with the HTTP header. 135 3. The client connects to the server and issues an HTTP POST request 136 method. This may re-use an existing HTTP connection. 138 4. The server decapsulates the HTTP packet to get the DNS query, and 139 resolves the DNS query. 141 5. The server encapsulates the DNS response in HTTP and sends it 142 back via the HTTP session. 144 Scenario 2: 146 In this scenario there is a DNS-HTTP proxy sitting between stub- 147 resolver and the recursive server. The stub uses a client proxy and 148 the recursive server uses a server proxy. This works like a DNS VPN 149 and transmits wire-format DNS messages over HTTP between the proxy 150 client and a server, as follows: 152 1. The stub-resolver sends a DNS query (over UDP or TCP) to the 153 proxy client. 155 2. The proxy client encapsulates the DNS message in an HTTP message 156 body and assigns parameters with the HTTP header. 158 3. The proxy client connects to the proxy server and issues an HTTP 159 POST request method. This may re-use an existing HTTP 160 connection. 162 4. The proxy server decapsulates the HTTP packet to get the DNS 163 query, and sends it to a real DNS server over UDP/TCP. 165 5. The proxy server encapsulates the DNS response in HTTP and sends 166 it back via the HTTP session. 168 6. The proxy client decapsulates the DNS message from the HTTP 169 response and sends it back to the stub-resolver via previous DNS 170 session (either UDP or TCP). 172 It is possible that these scenarios are mixed. The server may speak 173 DNS over HTTP directly and the client use a proxy, or the other way 174 around. 176 Note that the proxy client can be implemented listening to a loop- 177 back address in the same host with stub-resolver. The proxy server 178 can be implemented as a caching server as well. It is also possible 179 to use the proxy server as a regular web server at the same time that 180 is acting as a proxy server. 182 3. DNS-over-HTTP Message Format 184 DNS over HTTP is not tied to a specific version of HTTP, and should 185 work with HTTP 1.1 [RFC7230] and HTTP/2 [RFC7540]. This section 186 describes the details of the DNS over HTTP message format. 188 3.1. Request Method 190 A DNS message is sent over HTTP from the client to the server via a 191 properly-formed HTTP request. This is a POST method request [section 192 4.3.3 in RFC 7231 [RFC7231]]. If a GET method request is sent to the 193 server, it optionally returns a human-readable page showing 194 information targeted at users. 196 Note that choosing POST (and not GET) as the request method for DNS 197 wire-format over HTTP is mainly based on two reasons. One is that 198 the protocol is designed using HTTP as a tunnel-like technology 199 carrying data from one side to another, not a web service with 200 RESTful framework. Another is that from the view of implementation 201 some servers or middleboxes may ignore an undefined entity-body if 202 using GET; and HTTP libraries have varying support for using GET with 203 a payload. 205 The target URI is provided explicitly by the services provider. 206 Derived from the target URI, the request-target in request-line 207 identifies the target resource upon which to apply the request. To 208 avoid URI conflicts and enhance interoperability, DNS wire-format 209 over HTTP uses a well-known URI. As defined in RFC 5785 [RFC5785], 210 it begins with the characters "/.well-known/" and the name "dns- 211 wireformat". So the request-target for DNS wire-format over HTTP 212 SHOULD be '/.well-known/dns-wireformat'. 214 A DNS transaction over HTTP has no specific requirements for the 215 transport protocol; developers can use any version of HTTP to 216 accomplish the transaction. But developers should be aware that HTTP 217 1.1 [RFC7230] and HTTP/2 [RFC7540] do have differences in performance 218 regarding multiplexing. HTTP/2 is fully multiplexed, instead of 219 ordered and blocking. Because there is a general desire to achieve 220 similar performance with DNS over UDP, the modern HTTP/2 is preferred 221 for DNS over HTTP implementation. Note that there should be no 222 problem for advanced HTTP protocol in the future deployed for DNS 223 over HTTP. 225 3.2. Response Status Code 227 The status code [Section 6 of [RFC7231]], only reflects the status of 228 the HTTP connection. If the request has succeeded, the status code 229 is 200 (OK). 231 If the request fails, the proxy server will supply an appropriate 232 error code, typically 4xx (client error) if the client has provided a 233 query that the server cannot understand for some reasons, or 5xx 234 (server error) if some server-side problem prevented a query from 235 succeeding. 237 To be clear, a failure on the DNS side should result in a status code 238 of 200 (OK) as long as the HTTP request is valid and can be answered. 239 The DNS error will be returned via the encapsulated DNS message. 241 3.3. Header Fields 243 By definition header fields are key:value pairs that can be used to 244 communicate data about the message, its payload, the target resource, 245 or the connection (for example control data). 247 The Content-Type: header field should be set to "application/dns- 248 wireformat". 250 We add one a new header field: 252 Proxy-DNS-Transport: xyz 254 Where xyz is either UDP or TCP, which is the client's indication of 255 how it received the underlying DNS query, and which the server will 256 use when sending the query to the far-end DNS server. This means if 257 a stub DNS client asks for TCP, then that's what the far-end DNS 258 server will see, and likewise for UDP. 260 Exposing the transport protocol of the query allows the HTTP server 261 proxy to send DNS queries to the recursive resolver that look like 262 those that the DNS client is sending to the client proxy. If the 263 stub resolver sent a UDP packet, then this allows the recursive 264 resolver to implement the logic of truncating the packet properly, 265 instead of requiring that the HTTP client proxy somehow manage that 266 functionality. 268 For a stub resolver that connects directly via HTTP to the HTTP 269 server proxy then this flag should be set to TCP, as the entire 270 response can always be delivered so truncation is never required. 272 The client MUST include this option. If it is missing then it is an 273 error and the server should respond with HTTP code 400 (bad request). 275 3.4. Message Body 277 As mentioned, the message body is DNS wire-format data. It is worth 278 mentioning that DNS messages sent over TCP connections is prefixed 279 with a two-byte length field which gives the message length [section 280 4.2.2 in RFC 1035 [RFC1035]], excluding the two-byte length field. 281 This length field allows the low-level processing to assemble a 282 complete message before beginning to parse it. In the context of 283 HTTP, there is content-length header field [section 3.3.2 in 284 [RFC7230]]in which the field-value is the same with two bytes length 285 field in DNS over TCP. 287 Since this two-byte length field is redundant, when the client proxy 288 receives a DNS message over TCP, it MUST NOT include the length field 289 in the message sent to the server. The length in the content-length 290 header is only the size of the DNS message itself, and MUST NOT 291 include this two-byte length header. 293 4. Security Considerations 295 This protocol does not introduce any new security considerations 296 since it is built on the DNS and HTTP protocols. 298 Since this protocol transmits DNS messages, all of the security 299 concerns that stub resolvers and recursive resolvers have with DNS 300 messages apply. However, since HTTP uses TCP as the underlying 301 protocol, DNS reflection or amplification attacks are not possible. 303 Since HTTP is used, all of the security concerns of HTTP are also 304 present. 306 Servers and clients SHOULD use TLS for communication. It provides 307 privacy and integrity for HTTP sessions. If TLS is used, then all of 308 the security concerns of TLS are also present. 310 As specified in RFC 5246 [RFC5246], both the HTTP server and client 311 can be authenticated or not authenticated. Clients SHOULD 312 authenticate the certificate of the HTTP server they connect to. The 313 DNS service providers can decide whether to authenticate the client 314 side based on their own requirement for security and privacy. For 315 example, clients of an open resolver do not require authentication. 317 Note that the ability to perform DNS queries in this way may allow 318 users to bypass local DNS policy. This is problematic in any 319 environment where administrators need to enforce specific DNS 320 behavior, such as an enterprise environment. The protocol outlined 321 here does not introduce any new capabilities in this area, but by 322 creating a more standardized way of doing this it may cause 323 operational problems for enterprise administrators. 325 5. IANA considerations 327 Registration for a new Media Type: dns-wireformat 329 Registration for a new HTTP header field: Proxy-DNS-Transport 331 Registration for a new Well-Known URI: "dns-wireformat" 333 6. Acknowledgments 335 Thanks to Bob Harold, Paul Hoffman, and Julian Reschke for review. 337 7. References 339 [DOTSE] and , "DNSSEC Tests of Consumer Broadband Routers", 340 February 2008, 341 . 343 [I-D.bortzmeyer-dns-json] 344 Bortzmeyer, S., "JSON format to represent DNS data", 345 draft-bortzmeyer-dns-json-01 (work in progress), February 346 2013. 348 [I-D.ietf-dnsop-5966bis] 349 Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 350 D. Wessels, "DNS Transport over TCP - Implementation 351 Requirements", draft-ietf-dnsop-5966bis-04 (work in 352 progress), November 2015. 354 [I-D.mohan-dns-query-xml] 355 Parthasarathy, M. and P. Vixie, "Representing DNS messages 356 using XML", draft-mohan-dns-query-xml-00 (work in 357 progress), September 2011. 359 [RFC1035] Mockapetris, P., "Domain names - implementation and 360 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 361 November 1987, . 363 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 364 (TLS) Protocol Version 1.2", RFC 5246, 365 DOI 10.17487/RFC5246, August 2008, 366 . 368 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 369 BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 370 . 372 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 373 Uniform Resource Identifiers (URIs)", RFC 5785, 374 DOI 10.17487/RFC5785, April 2010, 375 . 377 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 378 Protocol (HTTP/1.1): Message Syntax and Routing", 379 RFC 7230, DOI 10.17487/RFC7230, June 2014, 380 . 382 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 383 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 384 DOI 10.17487/RFC7231, June 2014, 385 . 387 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 388 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 389 DOI 10.17487/RFC7540, May 2015, 390 . 392 [SAC035] ICANN Security and Stability Advisory Committee, "DNSSEC 393 Impact on Broadband Routers and Firewalls", 2008. 395 Authors' Addresses 397 Linjian Song 398 Beijing Internet Institute 399 2508 Room, 25th Floor, Tower A, Time Fortune 400 Beijing 100028 401 P. R. China 403 Email: songlinjian@gmail.com 404 URI: http://www.biigroup.com/ 406 Paul Vixie 407 TISF 408 11400 La Honda Road 409 Woodside, California 94062 410 US 412 Email: vixie@tisf.net 413 URI: http://www.redbarn.org/ 415 Shane Kerr 416 Beijing Internet Institute 417 2/F, Building 5, No.58 Jinghai Road, BDA 418 Beijing 100176 419 CN 421 Email: shane@biigroup.cn 422 URI: http://www.biigroup.com/ 423 Runxia Wan 424 Beijing Internet Institute 425 2508 Room, 25th Floor, Tower A, Time Fortune 426 Beijing 100028 427 P. R. China 429 Email: rxwan@biigroup.cn 430 URI: http://www.biigroup.com/