idnits 2.17.1 draft-ietf-doh-dns-over-https-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 : ---------------------------------------------------------------------------- == 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 (November 28, 2017) is 2338 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) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6961 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-03) exists of draft-ietf-dnsop-dns-wireformat-http-01 -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 2 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 P. McManus 5 Expires: June 1, 2018 Mozilla 6 November 28, 2017 8 DNS Queries over HTTPS 9 draft-ietf-doh-dns-over-https-02 11 Abstract 13 DNS queries sometimes experience problems with end to end 14 connectivity at times and places where HTTPS flows freely. 16 HTTPS provides the most practical mechanism for reliable end to end 17 communication. Its use of TLS provides integrity and confidentiality 18 guarantees and its use of HTTP allows it to interoperate with 19 proxies, firewalls, and authentication systems where required for 20 transit. 22 This document describes how to run DNS service over HTTP using 23 https:// URIs. 25 [[ There is a repository for this draft at https://github.com/dohwg/ 26 draft-ietf-doh-dns-over-https ]]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 1, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Non-requirements . . . . . . . . . . . . . . . . . . . . 5 67 5. The HTTP Request . . . . . . . . . . . . . . . . . . . . . . 5 68 5.1. DNS Wire Format . . . . . . . . . . . . . . . . . . . . . 6 69 5.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. The HTTP Response . . . . . . . . . . . . . . . . . . . . . . 7 71 6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 8 73 7.1. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Registration of Well-Known URI . . . . . . . . . . . . . 9 76 8.2. Registration of application/dns-udpwireformat Media Type 9 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 10. Operational Considerations . . . . . . . . . . . . . . . . . 12 79 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 12.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Appendix A. Previous Work on DNS over HTTP or in Other Formats . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 The Internet does not always provide end to end reachability for 89 native DNS. On-path network devices may spoof DNS responses, block 90 DNS requests, or just redirect DNS queries to different DNS servers 91 that give less-than-honest answers. 93 Over time, there have been many proposals for using HTTP and HTTPS as 94 a substrate for DNS queries and responses. To date, none of those 95 proposals have made it beyond early discussion, partially due to 96 disagreement about what the appropriate formatting should be and 97 partially because they did not follow HTTP best practices. 99 This document defines a specific protocol for sending DNS [RFC1035] 100 queries and getting DNS responses over HTTP [RFC7540] using https:// 101 (and therefore TLS [RFC5246] security for integrity and 102 confidentiality). Each DNS query-response pair is mapped into a HTTP 103 request-response pair. 105 The described approach is more than a tunnel over HTTP. It 106 establishes default media formatting types for requests and responses 107 but uses normal HTTP content negotiation mechanisms for selecting 108 alternatives that endpoints may prefer in anticipation of serving new 109 use cases. In addition to this media type negotiation, it aligns 110 itself with HTTP features such as caching, proxying, and compression. 112 The integration with HTTP provides a transport suitable for both 113 traditional DNS clients and native web applications seeking access to 114 the DNS. 116 2. Terminology 118 A server that supports this protocol is called a "DNS API server" to 119 differentiate it from a "DNS server" (one that uses the regular DNS 120 protocol). Similarly, a client that supports this protocol is called 121 a "DNS API client". 123 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 124 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 125 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 126 [RFC2119]. 128 3. Use Cases 130 There are two initial use cases for this protocol. 132 The primary use case is to prevent on-path network devices from 133 interfering with DNS operations. This interference includes, but is 134 not limited to, spoofing DNS responses, blocking DNS requests, and 135 tracking. 137 In this use, clients - whether operating systems or individual 138 applications - will be explicitly configured to use a DOH server as a 139 recursive resolver by its user (or administrator). They might use 140 the DOH server for all queries, or only for a subset of them. The 141 specific configuration mechanism is out of scope for this document. 143 A secondary use case is allowing web applications to access DNS 144 information, by using existing APIs in browsers to access it over 145 HTTP in a safe way consistent with Cross Origin Resource Sharing 146 (CORS) [CORS]. 148 This is technically already possible (since the server controls both 149 the HTTP resources it exposes and the use of browser APIs by its 150 content), but standardisation might make this easier to accomplish. 152 Note that in this second use, the browser does not consult the DOH 153 server or use its responses for any DNS lookups outside the scope of 154 the application using them; i.e., there is (currently) no API that 155 allows a Web site to poison DNS for others. 157 [[ This paragraph is to be removed when this document is published as 158 an RFC ]] Note that these use cases are different than those in a 159 similar protocol described at [I-D.ietf-dnsop-dns-wireformat-http]. 160 The use case for that protocol is proxying DNS queries over HTTP 161 instead of over DNS itself. The use cases in this document all 162 involve query origination instead of proxying. 164 4. Protocol Requirements 166 The protocol described here bases its design on the following 167 protocol requirements: 169 o The protocol must use normal HTTP semantics. 171 o The queries and responses must be able to be flexible enough to 172 express every normal DNS query. 174 o The protocol must allow implementations to use HTTP's content 175 negotiation mechanism. 177 o The protocol must ensure interoperable media formats through a 178 mandatory to implement format wherein a query must be able to 179 contain one or more EDNS extensions, including those not yet 180 defined. 182 o The protocol must use a secure transport that meets the 183 requirements for modern HTTPS. 185 4.1. Non-requirements 187 o Supporting network-specific DNS64 [RFC6147] 189 o Supporting other network-specific inferences from plaintext DNS 190 queries 192 o Supporting insecure HTTP 194 o Supporting legacy HTTP versions 196 5. The HTTP Request 198 To make a DNS API query, a DNS API client sends an HTTP request to 199 the URI of the DNS API. 201 The URI scheme MUST be https. 203 A client can be configured with a DNS API URI, or it can discover the 204 URI. This document defines a well-known URI path of "/.well-known/ 205 dns-query" so that a discovery process that produces a domain name or 206 domain name and port can be used to construct the DNS API URI. (See 207 Section 8 for the registration of this in the well-known URI 208 registry.) DNS API servers SHOULD use this well-known path to help 209 contextualize DNS Query requests that use server push [RFC7540]. 211 A DNS API Client encodes a single DNS query into the HTTP request 212 using either the HTTP GET or POST methods. 214 When using the POST method the DNS query is included as the message 215 body of the HTTP request and the Content-Type request header 216 indicates the media type of the message. POST-ed requests are 217 smaller than their GET equivalents. 219 When using the GET method the URI path MUST contain a query parameter 220 with the name of ct and a value indicating the media-format used for 221 the body parameter. The value may either be an explicit media type 222 (e.g. ct=application/dns-udpwireformat&body=...) or it may be empty. 223 An empty value indicates the default application/dns-udpwireformat 224 type (e.g. ct&body=...). 226 When using the GET method the URI path MUST contain a query parameter 227 with the name of body. The value of the parameter is the content of 228 the request encoded with base64url [RFC4648]. Using the GET method 229 is friendlier to many HTTP cache implementations. 231 The DNS API Client SHOULD include an HTTP "Accept:" request header to 232 say what type of content can be understood in response. The client 233 MUST be prepared to process "application/dns-udpwireformat" 234 Section 5.1 responses but MAY process any other type it receives. 236 In order to maximize cache friendliness, DNS API clients using media 237 formats that include DNS ID, such as application/dns-udpwireformat, 238 SHOULD use a DNS ID of 0 in every DNS request. HTTP correlates 239 request and response, thus eliminating the need for the ID in a media 240 type such as application/dns-udpwireformat and the use of a varying 241 DNS ID can cause semantically equivalent DNS queries to be cached 242 separately. 244 DNS API clients can use HTTP/2 padding and compression in the same 245 way that other HTTP/2 clients use (or don't use) them. 247 5.1. DNS Wire Format 249 The media type is "application/dns-udpwireformat". The body is the 250 DNS on-the-wire format is defined in [RFC1035]. 252 When using the GET method, the body MUST be encoded with base64url 253 [RFC4648]. Padding characters for base64url MUST NOT be included. 255 When using the POST method, the body is not encoded. 257 DNS API clients using the DNS wire format MAY have one or more 258 EDNS(0) extensions [RFC6891] in the request. 260 5.2. Examples 262 These examples use HTTP/2 style formatting from [RFC7540]. 264 For this example assume a DNS API server is following this 265 specification on origin https://dnsserver.example.net/ and the well- 266 known path. The DNS API client chooses to send its requests in 267 application/dns-udpwirefomat but indicates it can parse replies in 268 that format or as a hypothetical JSON-based content type. The 269 application/simpledns+json type used by this example is currently 270 fictitious. 272 :method = GET 273 :scheme = https 274 :authority = dnsserver.example.net 275 :path = /.well-known/dns-query?ct& (no CR) 276 body=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB 277 accept = application/dns-udpwireformat, application/simpledns+json 279 The same DNS query, using the POST method would be: 281 :method = POST 282 :scheme = https 283 :authority = dnsserver.example.net 284 :path = /.well-known/dns-query 285 accept = application/dns-udpwireformat, application/simpledns+json 286 content-type = application/dns-udpwireformat 287 content-length = 33 289 <33 bytes represented by the following hex encoding> 290 abcd 0100 0001 0000 0000 0000 0377 7777 291 0765 7861 6d70 6c65 0363 6f6d 0000 0100 292 01 294 6. The HTTP Response 296 Different response media types will provide more or less information 297 from a DNS response. For example, one response type might include 298 the information from the DNS header bytes while another might omit 299 it. The amount and type of information that a media type gives is 300 solely up to the format, and not defined in this protocol. 302 At the time this is published, the response types are works in 303 progress. The only known response type is "application/dns- 304 udpwireformat", but it is possible that at least one JSON-based 305 response format will be defined in the future. 307 The DNS response for "application/dns-udpwireformat" in Section 5.1 308 MAY have one or more EDNS(0) extensions, depending on the extension 309 definition of the extensions given in the DNS request. 311 Native HTTP methods are used to correlate requests and responses. 312 Responses may be returned in a different temporal order than requests 313 were made using the protocols native multi-streaming functionality. 315 The Answer section of a DNS response contains one or more RRsets. 316 (RRsets are defined in [RFC7719].) According to [RFC2181], each 317 resource record in an RRset is supposed to have the Time To Live 318 (TTL) freshness information. Different RRsets in the Answer section 319 can have different TTLs, though it is only possible for the HTTP 320 response to have a single freshness lifetime. The HTTP response 321 freshness lifetime ([RFC7234] Section 4.2) should be coordinated with 322 the Resource Record bearing the smallest TTL in the Answer section of 323 the response. The HTTP freshness lifetime SHOULD be set to expire at 324 the same time any of the DNS Records reach a 0 TTL. The response 325 freshness lifetime MUST NOT be greater than that indicated by the DNS 326 Record with the smallest TTL in the response. 328 A DNS API Client that receives a response without an explicit 329 freshness lifetime MUST NOT assign that response a heuristic 330 freshness ([RFC7234] Section 4.2.2.) greater than that indicated by 331 the DNS Record with the smallest TTL in the response. 333 A DNS API Server MUST be able to process application/dns- 334 udpwireformat request messages. 336 A DNS API Server SHOULD respond with HTTP status code 415 upon 337 receiving a media type it is unable to process. 339 This document does not change the definition of any HTTP response 340 codes or otherwise proscribe their use. 342 HTTP revalidation of cached DNS information may be of limited value 343 as revalidation provides only a bandwidth benefit and DNS 344 transactions are normally latency bound instead. Furthermore, the 345 HTTP response headers that enable revalidation (such as "Last- 346 Modified" and "Etag") are often fairly large when compared to the 347 overall DNS response size, and have a variable nature that creates 348 constant pressure on the HTTP/2 compression dictionary [RFC7541]. 349 Other types of DNS data, such as zone transfers, may be larger and 350 benefit more from revalidation. DNS API servers may wish to consider 351 whether providing these optional response headers is worthwhile. 353 6.1. Example 355 This is an example response for a query for the IN A records for 356 "www.example.com" with recursion turned on. The response bears one 357 record with an address of 93.184.216.34 and a TTL of 128 seconds. 359 :status = 200 360 content-type = application/dns-udpwireformat 361 content-length = 64 362 cache-control = max-age=128 364 <64 bytes represented by the following hex encoding> 365 abcd 8180 0001 0001 0000 0000 0377 7777 366 0765 7861 6d70 6c65 0363 6f6d 0000 0100 368 0103 7777 7707 6578 616d 706c 6503 636f 369 6d00 0001 0001 0000 0080 0004 5db8 d822 371 7. HTTP Integration 373 This protocol MUST be used with https scheme URI [RFC7230]. 375 7.1. HTTP/2 377 The minimum version of HTTP used by DOH SHOULD be HTTP/2 [RFC7540]. 379 The messages in classic UDP based DNS [RFC1035] are inherently 380 unordered and have low overhead. A competitive HTTP transport needs 381 to support reordering, parallelism, priority, and header compression 382 to acheive similar performance. Those features were introduced to 383 HTTP in HTTP/2 [RFC7540]. Earlier versions of HTTP are capable of 384 conveying the semantic requirements of DOH but would result in very 385 poor performance for many uses cases. 387 8. IANA Considerations 389 8.1. Registration of Well-Known URI 391 This specification registers a Well-Known URI [RFC5785]: 393 o URI Suffix: dns-query 395 o Change Controller: IETF 397 o Specification Document(s): [this specification] 399 8.2. Registration of application/dns-udpwireformat Media Type 400 To: ietf-types@iana.org 401 Subject: Registration of MIME media type 402 application/dns-udpwireformat 404 MIME media type name: application 406 MIME subtype name: dns-udpwireformat 408 Required parameters: n/a 410 Optional parameters: n/a 412 Encoding considerations: This is a binary format. The contents are a 413 DNS message as defined in RFC 1035. The format used here is for DNS 414 over UDP, which is the format defined in the diagrams in RFC 1035. 416 Security considerations: The security considerations for carrying 417 this data are the same for carrying DNS without encryption. 419 Interoperability considerations: None. 421 Published specification: This document. 423 Applications that use this media type: 424 Systems that want to exchange full DNS messages. 426 Additional information: 428 Magic number(s): n/a 430 File extension(s): n/a 432 Macintosh file type code(s): n/a 434 Person & email address to contact for further information: 435 Paul Hoffman, paul.hoffman@icann.org 437 Intended usage: COMMON 439 Restrictions on usage: n/a 441 Author: Paul Hoffman, paul.hoffman@icann.org 443 Change controller: IESG 445 9. Security Considerations 447 Running DNS over HTTPS relies on the security of the underlying HTTP 448 transport. Implementations utilizing HTTP/2 benefit from the TLS 449 profile defined in [RFC7540] Section 9.2. 451 Session level encryption has well known weaknesses with respect to 452 traffic analysis which might be particularly acute when dealing with 453 DNS queries. Sections 10.6 (Compression) and 10.7 (Padding) of 454 [RFC7540] provide some further advice on mitigations within an HTTP/2 455 context. 457 The HTTPS connection provides transport security for the interaction 458 between the DNS API server and client, but does not inherently ensure 459 the authenticity of DNS data. A DNS API client may also perform full 460 DNSSEC validation of answers received from a DNS API server or it may 461 choose to trust answers from a particular DNS API server, much as a 462 DNS client might choose to trust answers from its recurvise DNS 463 resolver. 465 [[ From the WG charter: 467 The working group will analyze the security and privacy issues that 468 could arise from accessing DNS over HTTPS. In particular, the 469 working group will consider the interaction of DNS and HTTP caching. 471 ]] 473 A server that is acting both as a normal web server and a DNS API 474 server is in a position to choose which DNS names it forces a client 475 to resolve (through its web service) and also be the one to answer 476 those queries (through its DNS API service). An untrusted DNS API 477 server can thus easily cause damage by poisoning a client's cache 478 with names that the DNS API server chooses to poison. A client MUST 479 NOT trust a DNS API server simply because it was discovered, or 480 because the client was told to trust the DNS API server by an 481 untrusted party. Instead, a client MUST only trust DNS API server 482 that is configured as trustworthy. 484 [[ From the WG charter: 486 The working group may define mechanisms for discovery of DOH servers 487 similar to existing mechanisms for discovering other DNS servers if 488 the chairs determine that there is both sufficient interest and 489 working group consensus. 491 ]] 493 10. Operational Considerations 495 Local policy considerations and similar factors mean different DNS 496 servers may provide different results to the same query: for instance 497 in split DNS configurations [RFC6950]. It logically follows that the 498 server which is queried can influence the end result. Therefore a 499 client's choice of DNS server may affect the responses it gets to its 500 queries. 502 The HTTPS channel used by this specification establishes secure two 503 party communication between the DNS API Client and the DNS API 504 Server. Filtering or inspection systems that rely on unsecured 505 transport of DNS will not function in a DNS over HTTPS environment. 507 Many HTTPS implementations perform real time third party checks of 508 the revocation status of the certificates being used by TLS. If this 509 check is done as part of the DNS API server connection procedure and 510 the check itself requires DNS resolution to connect to the third 511 party a deadlock can occur. The use of an OCSP [RFC6960] server is 512 one example of how this can happen. DNS API servers SHOULD utilize 513 OCSP Stapling [RFC6961] to provide the client with certificate 514 revocation information that does not require contacting a third 515 party. 517 11. Acknowledgments 519 Joe Hildebrand contributed lots of material for a different iteration 520 of this document. Helpful early comments were given by Ben Schwartz 521 and Mark Nottingham. 523 12. References 525 12.1. Normative References 527 [RFC1035] Mockapetris, P., "Domain names - implementation and 528 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 529 November 1987, . 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, 533 DOI 10.17487/RFC2119, March 1997, . 536 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 537 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 538 . 540 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 541 (TLS) Protocol Version 1.2", RFC 5246, 542 DOI 10.17487/RFC5246, August 2008, . 545 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 546 Uniform Resource Identifiers (URIs)", RFC 5785, 547 DOI 10.17487/RFC5785, April 2010, . 550 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 551 Galperin, S., and C. Adams, "X.509 Internet Public Key 552 Infrastructure Online Certificate Status Protocol - OCSP", 553 RFC 6960, DOI 10.17487/RFC6960, June 2013, 554 . 556 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 557 Multiple Certificate Status Request Extension", RFC 6961, 558 DOI 10.17487/RFC6961, June 2013, . 561 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 562 Protocol (HTTP/1.1): Message Syntax and Routing", 563 RFC 7230, DOI 10.17487/RFC7230, June 2014, 564 . 566 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 567 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 568 RFC 7234, DOI 10.17487/RFC7234, June 2014, 569 . 571 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 572 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 573 DOI 10.17487/RFC7540, May 2015, . 576 [RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for 577 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, 578 . 580 12.2. Informative References 582 [CORS] "Cross-Origin Resource Sharing", n.d., 583 . 585 [I-D.ietf-dnsop-dns-wireformat-http] 586 Song, L., Vixie, P., Kerr, S., and R. Wan, "DNS wire- 587 format over HTTP", draft-ietf-dnsop-dns-wireformat-http-01 588 (work in progress), March 2017. 590 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 591 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 592 . 594 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 595 Beijnum, "DNS64: DNS Extensions for Network Address 596 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 597 DOI 10.17487/RFC6147, April 2011, . 600 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 601 for DNS (EDNS(0))", STD 75, RFC 6891, 602 DOI 10.17487/RFC6891, April 2013, . 605 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 606 "Architectural Considerations on Application Features in 607 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 608 . 610 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 611 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 612 2015, . 614 Appendix A. Previous Work on DNS over HTTP or in Other Formats 616 The following is an incomplete list of earlier work that related to 617 DNS over HTTP/1 or representing DNS data in other formats. 619 The list includes links to the tools.ietf.org site (because these 620 documents are all expired) and web sites of software. 622 o https://tools.ietf.org/html/draft-mohan-dns-query-xml 624 o https://tools.ietf.org/html/draft-daley-dnsxml 626 o https://tools.ietf.org/html/draft-dulaunoy-dnsop-passive-dns-cof 628 o https://tools.ietf.org/html/draft-bortzmeyer-dns-json 630 o https://www.nlnetlabs.nl/projects/dnssec-trigger/ 632 Authors' Addresses 634 Paul Hoffman 635 ICANN 637 Email: paul.hoffman@icann.org 639 Patrick McManus 640 Mozilla 642 Email: pmcmanus@mozilla.com