idnits 2.17.1 draft-hoffman-dns-over-http-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 15, 2016) is 2747 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'HTMLSPEC' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) == Outdated reference: A later version (-16) exists of draft-hoffman-dns-in-json-09 == Outdated reference: A later version (-06) exists of draft-nottingham-json-home-04 -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft ICANN 4 Intended status: Standards Track J. Hildebrand 5 Expires: April 18, 2017 October 15, 2016 7 DNS Queries over HTTPS 8 draft-hoffman-dns-over-http-01 10 Abstract 12 This document describes how to make DNS queries and get DNS responses 13 over HTTPS. The main driver for this document is to allow clients 14 who want to send DNS queries over HTTP transport to be able to do in 15 a secure and interoperable fashion, regardless of the format of the 16 responses. 18 Comments on this draft can be sent to the dnsoverhttp mailing list at 19 https://www.ietf.org/mailman/listinfo/dnsoverhttp . 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 18, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Protocol Requirements . . . . . . . . . . . . . . . . . . 3 58 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Template . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. PREFIX . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. QNAME . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. QTYPE . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.4. Additional Parameters . . . . . . . . . . . . . . . . . . 6 64 3. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. Use in HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 9.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Appendix A. Previous Work on DNS over HTTP or in Other Formats . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 Over time, there have been many proposals for using HTTP and HTTPS as 79 a substrate for DNS queries and responses. To date, none of those 80 proposals have made it beyond early discussion, partially due to 81 disagreement about what is the "best" method to do so. In 82 particular, there has been disagreement about what the best format 83 for the responses should be. Also, some early proposals have not 84 followed best practices for using HTTP. 86 This document defines a specific protocol for sending DNS [RFC1035] 87 queries and getting DNS responses over HTTP [RFC7230] that is running 88 over TLS [RFC5246]. Although there might be a desire to run this 89 protocol over an insecure transport such as bare HTTP, this document 90 only defines the protocol as HTTP over TLS. 92 This design focuses on DNS stub-to-resolver communication, but DNS 93 resolver-to-authoritative communication should work just as well. 95 A server that supports this protocol is called a "DNS API server" to 96 differentiate it from a "DNS server" (one that uses the regular DNS 97 protocol). Similarly, a client supports this protocol is called a 98 "DNS API client". 100 1.1. Use Cases 102 Earlier proposals for DNS over HTTP have had many different use 103 cases. The primary use case is an application that wants to avoid 104 network path involvement with DNS. The protocol can be implemented 105 in the application such as a browser if the location of the DNS API 106 server can be configured, hard-coded, or discoverable such as through 107 DHCP. 109 Another use case is an operating system that wants to help 110 applications when the OS detects broken DNS in its operations. The 111 OS can still respond to calls such as getaddrinfo() and 112 gethostbyname() by using this protocol without the applications 113 needing to do anything. 115 A more recent use case is a small ("IoT") device that already runs 116 COAP [RFC7252] and has a JSON [RFC7159] or CBOR [RFC7049] parser and 117 wants to make DNS queries beyond what are supported by the device's 118 operating system. 120 An eventual use case might be editing of DNS zones by end users, such 121 as described in [I-D.hildebrand-deth]. Such editing could easily be 122 done using existing HTTP semantics. 124 As HTTP/2 [RFC7540] and QUIC [I-D.hamilton-early-deployment-quic] 125 become more widely deployed, this protocol might become more 126 important because an HTTP/2 or QUIC server might push DNS responses 127 to a client that the HTTP/2 server expects the client to look up. 128 This will be covered in Section 5. TODO: this discussion of H2 push 129 needs to be expanded by people with this use case. 131 These use cases assume that the server is a resolver, but this 132 protocol can certainly be used in use cases where the server is an 133 authoritative server. Such use cases may be added to this document, 134 or may be documented later. 136 1.2. Protocol Requirements 138 The protocol described here bases its design on the following 139 protocol requirements: 141 o The protocol must use HTTP semantics the way that they are 142 commonly used in other protocols; there is nothing special about 143 the DNS use case. 145 o The protocol must run over secure transport. 147 o The query format must be able to be flexible enough to express 148 every normal DNS query. 150 o The response must be able to be in different formats that can be 151 described by different documents. 153 o Both the query format and the response formats must be extensible. 154 In specific, a query must be able to contain one or more EDNS 155 extensions, including those not yet defined. Further, it must be 156 easy to define different response formats and to extend already- 157 defined formats. 159 Non-requirements: 161 o Supporting network-specific DNS64 [RFC6147] 163 o Supporting other network-specific inferences from plaintext DNS 164 queries 166 1.3. Terminology 168 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 169 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 170 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 171 [RFC2119]. 173 2. Template 175 The URI template (see [RFC6570]) for DNS API queries is: 177 {PREFIX}{QNAME}/{QTYPE} 179 [I-D.nottingham-json-home] will be evaluated in the future to see if 180 the added complexity of including it in the discovery process would 181 make for an interesting increase in deployment flexibility. 183 The following variables are used to expand the URI template. 185 2.1. PREFIX 187 "PREFIX" will be a URI fragment, such as "https://example.net/api/". 188 The URI protocol MUST be "https:" or "coaps:". The prefix MUST NOT 189 contain the character "?", and MUST be suitable for processing using 190 the above template. Often, this will mean that the template should 191 end with a "/" (U+002F: SOLIDUS). 193 The DNS API client discovers the PREFIX for the DNS API through the 194 same mechanism as for a DNS resolver: DHCPv4, DHCPv6, IPv6 RA, and 195 configuration. Specific PREFIX discovery mechanisms will be defined 196 later, but imagine a new DHCP or RA option that gives a PREFIX. 198 If no PREFIX is configured as above, the client MAY query a DNS 199 resolver for which they have an IP address. The query is 201 https:///.well_known/TBD1 203 If the DNS server knows about API support, the returned URI will be 204 the PREFIX. 206 The response to this discovery might be multiple PREFIXes. In that 207 case, some of the URI types might not be supported by the resolver; 208 this is fine as long as at least one type is. For example, if a 209 discovery query returns both https: and coaps: URI templates, but the 210 DNS API client can only generate https: queries, the other URI 211 templates are ignored. 213 TODO: there are several concerns to be worked out with respect to the 214 PREFIX, including how to bootstrap PREFIXes that contain domain 215 names, and how to trust TLS connections to PREFIXes that contain only 216 IP addresses in a deployable way. Some ideas might come from RFC 217 7858. 219 Note: The discovery response may give hints that the DNS API server 220 requires a form of HTTP authorization. The configuration of that 221 authorization is out of scope for the DNS API protocol. TODO: Need 222 to think about HTTP authorization mechanisms. This would allow user 223 tracking, but could also free resolvers from having to use IP address 224 ranges for filtering. Several bad ideas are likely here, so let's 225 think about it early. 227 2.2. QNAME 229 The QNAME is adopted from [RFC1035]. 231 TODO: how to encode non-ASCII domain names. For IDNs, there are 232 several options: 234 o Punycode all labels before sending 236 o Send the UTF8-encoded version after normalization, but before 237 Punycoding 239 o Send generic UTF8-encoded labels, and make the server do 240 normalization 242 TODO: domain names (not host names) that have values that might cause 243 problems in the URI format, such as values that are control 244 characters in ASCII, and values greater than 127. 246 2.3. QTYPE 248 The numerical QTYPE is adopted from [RFC1035]. 250 TODO: there are some people that want to use the string forms, such 251 as "AAAA", perhaps in addition to the numerical form. To be 252 discussed. 254 2.4. Additional Parameters 256 The following are the names and descriptions of parameters for DNS 257 API queries. All parameters are optional. DNS header values and 258 extensions that are not appropriate for queries are not defined. 259 Each parameter in the list below will need to include a use case in a 260 later version of this document; this list is a first approximation of 261 what may be needed. 263 Each of these parameters may be used in a query component of the URI 264 sent to the API, to modify the request. 266 qc: QCLASS from [RFC1035] - if omitted, server assumes 1 (IN). 267 Might be needed to support legacy DNS classes, or to access 268 interesting new DNS capabilities. 270 id: ID from [RFC1035] - if omitted, there is no default value. 271 Could be used to track responses. 273 opcode: Opcode from [RFC1035] - if omitted, server assumes 0 274 (standard query) 276 rd: RD from [RFC1035] - if omitted, server assumes 1 (recursion 277 desired) 279 cd: CD from [RFC4035] - if omitted, server assumes 1 (DNSSec 280 checking by the resolver disabled) 282 do: DO from [RFC4035] - if omitted, server assumes 1 (include RRSIG 283 RDATA in the response) 285 The following are EDNS0 [RFC6891] extensions. If an extension is 286 omitted, the server assumes that the extension was not given in the 287 request. 289 nsid: Request the server's NSID, based on [RFC5001]. Set to "1" to 290 enable. 292 dau: Specify the list of signing algorithms understood, based on 293 [RFC6975]. The value is a list of integers separated by commas 294 (with no spaces). 296 dhu: Specify the list of hash algorithms understood, based on 297 [RFC6975]. The value is a list of integers separated by commas 298 (with no spaces). 300 n3u: Specify the list of NSEC3 hash algorithms understood, based on 301 [RFC6975]. The value is a list of integers separated by commas 302 (with no spaces). 304 ecs: Specify the client subnet, based on [RFC7871]. The value is 305 the bytes of the ECS option, starting with byte 4, encoded in 306 lowercase hexadecimal. 308 pad: Optional padding, used for the same purposes as described in 309 [RFC7830]. This can be used to normalize the length of queries. 311 See Section 6 for a registry for additional names for queries. 313 3. Queries 315 To send a DNS query, the DNS API client prepares an HTTP/CoAP GET 316 request using the template (see Section 2). If any additional 317 parameters (see Section 2.4) are desired, they are appended to the 318 template as if they are HTML form data. (See Sections 4.10.22.3 and 319 4.10.22.4 of [HTMLSPEC] for the full specification of form data.) 320 Typically, this is done using a "?" (U+003F: QUESTION MARK), then 321 each parameter specified as a name, "=" (U+003D: EQUALS SIGN), and 322 value, each name=value pair separated by a "&" (U+0026: AMPERSAND). 323 Each value should be percent-encoded as needed. The client MUST 324 ensure that the resulting URI is valid. 326 The HTTP-related requirements include: 328 o The HTTP GET request MUST have no body. 330 o The HTTP GET request SHOULD be sent with an HTTP "Accept:" header 331 to say what type of content can be returned; of course, a server 332 can return whatever type of content it wants. If the request does 333 not have an HTTP "Accept:" header, the DNS API server might return 334 a content type that the DNS API client does not understand. 336 o The HTTP GET request SHOULD use If-None-Match headers if earlier 337 responses to the same query used HTTP ETag headers as described in 338 [RFC7232]. 340 For example, assume that the server's PREFIX is: 342 https://dnsserver.example.net/api/v1/ 344 A query for the A records for "www.example.com" with recursion turned 345 off would be: 347 https://dnsserver.example.net/api/v1/www.example.com/1?rd=0 349 The HTTP request might look like: 351 GET api/v1/www.example.com/1?rd=0 HTTP/1.1 352 User-Agent: curl/7.16.3 libcurl/7.16.3 353 Host: dnsserver.example.net 354 Accept: application/dns+json 356 This document only defines the semantics of the HTTP/CoAP GET command 357 for normal DNS queries and responses. Other verbs will be defined in 358 the future. Other verbs will likely need different authorization 359 semantics. For example, see [I-D.hildebrand-deth]. 361 4. Responses 363 Different response formats will provide more or less information from 364 a DNS response. For example, one response type might include the 365 information from the DNS header bytes while another might omit it. 366 The amount and type of information that a response format gives is 367 solely up to the format, and not defined in this protocol. 369 At the time this is published, the response types are works in 370 progress. The know response types include: 372 o [I-D.hoffman-dns-in-json] describes a response type in JSON 374 o [I-D.song-dns-wireformat-http] describes a response type in DNS 375 wire format 377 In the HTTP responses, the HTTP cache headers are set to shortest DNS 378 TTL in the response. The HTTP responses SHOULD set the HTTP ETag 379 headers as described in [RFC7232]. 381 TODO: Add more detail about setting the HTTP cache headers. 383 TODO: Add examples of creating these ETag headers. 385 Servers conforming to this protocol MUST implement responding with 386 messages formatted with [I-D.hoffman-dns-in-json]. 388 5. Use in HTTP/2 390 TODO: Full discussion about using this protocol in HTTP/2 for server 391 push. This will also hopefully cover caching and DNS TTLs. 393 6. IANA Considerations 395 TODO: Create a new registry for option names for DNS queries. This 396 will be a simple registry for new option names, probably with a 397 designated expert. 399 TODO: Replace TBD1 in the body with a string from the .well_known 400 registry. Reference [RFC5785]. 402 7. Security Considerations 404 This protocol requires the use of TLS for communication. If a client 405 does not enforce authentication of the TLS server, the communication 406 channel will be susceptible to many security problems. See [RFC7435] 407 for a fuller description of non-authenticated TLS. 409 TODO: Think about whether cross-origin resource sharing (CORS) 410 applies to this protocol and, if so, how to specify it. 412 8. Acknowledgements 414 Early input to this document came from Mark Nottingham and and 415 Patrick McManus. 417 9. References 419 9.1. Normative References 421 [HTMLSPEC] 422 W3C, "HTML5, A vocabulary and associated APIs for HTML and 423 XHTML", 2016, . 425 [RFC1035] Mockapetris, P., "Domain names - implementation and 426 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 427 November 1987, . 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, 431 DOI 10.17487/RFC2119, March 1997, 432 . 434 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 435 Rose, "Protocol Modifications for the DNS Security 436 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 437 . 439 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 440 (TLS) Protocol Version 1.2", RFC 5246, 441 DOI 10.17487/RFC5246, August 2008, 442 . 444 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 445 and D. Orchard, "URI Template", RFC 6570, 446 DOI 10.17487/RFC6570, March 2012, 447 . 449 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 450 Protocol (HTTP/1.1): Message Syntax and Routing", 451 RFC 7230, DOI 10.17487/RFC7230, June 2014, 452 . 454 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 455 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, 456 DOI 10.17487/RFC7232, June 2014, 457 . 459 9.2. Informative References 461 [I-D.hamilton-early-deployment-quic] 462 Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: 463 A UDP-Based Secure and Reliable Transport for HTTP/2", 464 draft-hamilton-early-deployment-quic-00 (work in 465 progress), July 2016. 467 [I-D.hildebrand-deth] 468 Hildebrand, J. and P. Hoffman, "DNS Editing Through HTTPS 469 (DETH)", draft-hildebrand-deth-00 (work in progress), 470 March 2016. 472 [I-D.hoffman-dns-in-json] 473 Hoffman, P., "Representing DNS Messages in JSON", draft- 474 hoffman-dns-in-json-09 (work in progress), October 2016. 476 [I-D.nottingham-json-home] 477 Nottingham, M., "Home Documents for HTTP APIs", draft- 478 nottingham-json-home-04 (work in progress), May 2016. 480 [I-D.song-dns-wireformat-http] 481 Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire- 482 format over HTTP", draft-song-dns-wireformat-http-04 (work 483 in progress), June 2016. 485 [RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option", 486 RFC 5001, DOI 10.17487/RFC5001, August 2007, 487 . 489 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 490 Uniform Resource Identifiers (URIs)", RFC 5785, 491 DOI 10.17487/RFC5785, April 2010, 492 . 494 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 495 Beijnum, "DNS64: DNS Extensions for Network Address 496 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 497 DOI 10.17487/RFC6147, April 2011, 498 . 500 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 501 for DNS (EDNS(0))", STD 75, RFC 6891, 502 DOI 10.17487/RFC6891, April 2013, 503 . 505 [RFC6975] Crocker, S. and S. Rose, "Signaling Cryptographic 506 Algorithm Understanding in DNS Security Extensions 507 (DNSSEC)", RFC 6975, DOI 10.17487/RFC6975, July 2013, 508 . 510 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 511 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 512 October 2013, . 514 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 515 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 516 2014, . 518 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 519 Application Protocol (CoAP)", RFC 7252, 520 DOI 10.17487/RFC7252, June 2014, 521 . 523 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 524 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 525 December 2014, . 527 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 528 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 529 DOI 10.17487/RFC7540, May 2015, 530 . 532 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 533 DOI 10.17487/RFC7830, May 2016, 534 . 536 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 537 Kumari, "Client Subnet in DNS Queries", RFC 7871, 538 DOI 10.17487/RFC7871, May 2016, 539 . 541 Appendix A. Previous Work on DNS over HTTP or in Other Formats 543 The following is a list of earlier work that related to DNS over HTTP 544 or representing DNS data in other formats. It is very likely 545 incomplete, but will be expanded as this document progresses. 547 The list includes links to the tools.ietf.org site (because these 548 documents are all expired) and web sites of software. 550 o https://tools.ietf.org/html/draft-mohan-dns-query-xml 552 o https://tools.ietf.org/html/draft-daley-dnsxml 554 o https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof 556 o https://tools.ietf.org/html/draft-bortzmeyer-dns-json 558 o https://www.nlnetlabs.nl/projects/dnssec-trigger/ 560 Authors' Addresses 562 Paul Hoffman 563 ICANN 565 Email: paul.hoffman@icann.org 567 Joe Hildebrand 569 Email: hildjj@cursive.net