idnits 2.17.1 draft-mohan-dns-query-xml-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 27, 2011) is 4594 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 informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Parthasarathy, Ed. 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track P. Vixie 5 Expires: March 30, 2012 ISC 6 September 27, 2011 8 draft-mohan-dns-query-xml-00 10 Abstract 12 This memo presents a technique for representing DNS messages using 13 XML. This enables DNS query transactions to be transported over 14 HTTP/HTTPS. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 30, 2012. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 53 3. DNS XML Query . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. XML Representation of DNS Message . . . . . . . . . . . . . . 4 55 5. DNS Message Format . . . . . . . . . . . . . . . . . . . . . . 4 56 6. DNS Resource Record Format . . . . . . . . . . . . . . . . . . 7 57 7. Message Compression . . . . . . . . . . . . . . . . . . . . . 8 58 8. Message Update . . . . . . . . . . . . . . . . . . . . . . . . 8 59 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 60 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 12.1. Normative References . . . . . . . . . . . . . . . . . . . 9 64 12.2. Informative References . . . . . . . . . . . . . . . . . . 9 65 Appendix A. Appendix A . . . . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 Domain Name System (DNS) is specified in RFC 1035 [RFC1035] and its 71 security extensions (DNSSEC) are specified in RFC 4034 [RFC4034] and 72 RFC 4035 [RFC4035]. DNSSEC provides origin authentication and 73 integrity protection for DNS data. While signing the authority data 74 and verifying such signatures in recursive or stub validators are 75 well understood and well solved problems, the channel between 76 authority servers and validators is commonly unusable for DNSSEC- 77 secured transactions due to overreach in customer premises equipment, 78 firewalls, intrusion detection systems, and non-DNSSEC-aware 79 recursive name servers operated by enterprises or service providers. 80 HTTP [RFC2616] is known to work in such environments and has become 81 the de facto tunneling protocol in the Internet. To facilitate 82 tunneling DNS messages over HTTP, this document describes a method of 83 encoding a DNS message, including the resource records, as an XML 84 object [XML]. 86 1.1. Requirements Language 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 2. Protocol Overview 94 In traditional DNS communication, the DNS stub resolver communicates 95 with a recursive server which in turn communicates with the 96 authoritative servers to fetch the DNS data. To fetch the DNS XML 97 data, the resolver communicates with a web server using HTTP/HTTPS. 98 It issues a GET request with parameters using the URI format in 99 [RFC2396] indicating the attributes of the query as it would do in a 100 normal DNS query. The web server on receiving the request retrieves 101 the DNS data and formats in XML before sending it back to the 102 resolver. The resolver may issue multiple DNS queries either using a 103 single or multiple TCP connection to the server whose details are 104 beyond the scope of this document. 106 3. DNS XML Query 108 The resolver issues a HTTP GET request with parameters to fetch the 109 DNS XML data. The structure of the query is as follows: 111 https://server_address/dns_service/ 112 query?name=NAME&type=TYPE&ID=VALUE&RD=VALUE&CD=VALUE&DO=VALUE 114 dns_service - tells the web server that the GET request is to 115 fetch the DNS records 117 query - indicates that this GET request is a DNS query and it 118 should return the DNS Response formatted in XML 120 name - The domain name being looked up 122 type - Type of the query as specified under "TYPE" field in the 123 RRTYPE registry in [IANA_DNS]. 125 ID - Corresponds to the ID value in the DNS query. When there 126 are multiple queries in flight, the ID in the response can be 127 used to match the request. 129 RD - Corresponds to the "RD" bit in the DNS query. Set to 1 if 130 recursion is desired or 0 otherwise. 132 CD - Corresponds to the "CD" bit in the DNS query. Set to 1 if 133 validation will be done by the end host or 0 otherwise. 135 DO - Corresponds to the "DNSSEC OK" bit in the DNS query. It 136 reflects the setting of the DNSSEC OK bit in EDNS0 option. 138 4. XML Representation of DNS Message 140 The XML representation of the DNS message maps the DNS header 141 specified in section 4.1.1 of [RFC1035] to XML representation. 143 5. DNS Message Format 145 The DNS message is enclosed under the root element "response", under 146 which all the other elements appear. 148 150 All the other elements are enclosed within this element. 152 154 The XML representation of the DNS header does not represent all the 155 fields. Only RCODE, the AA bit and the CD bit of the second sixteen 156 bit field (that follows the ID field) is represented. The fields 157 QDCOUNT and the question section are omitted. If the resolver 158 converts the XML representation into binary format for processing, 159 the omitted fields should be inferred appropriately. Rest of the 160 fields are described below. 162 164 The value of this field is copied from the HTTP request 165 parameters. It is used by the resolver to match the response 166 to the request. 168 170 172 Corresponds to the AA bit in the header. If AA is set, this 173 element is set to 1 and otherwise 0. 175 177 179 Corresponds to the AD bit in the header. If AD is set, this 180 element is set to 1 and otherwise 0. 182 184 186 Corresponds to the CD bit in the header. If CD is set, this 187 element is set to 1 and otherwise 0. 189 191 193 RCODE of the response represented as specified under "Name" 194 field of the RCODE registry in [IANA_DNS]. 196 198 200 Number of answers in the answers element described below 202 204 205 This section contains all the records in the answer section of the 206 response with each resource record in the answer element. 208 210 Each answer element contains a resource record 212 214 216 218 Number of authorities in the authorities element described 219 below 221 223 225 This section contains all the records in the authority section of 226 the response with each resource record in the authority element. 228 230 Each authority element contains a resource record 232 234 236 238 Number of additional records in the additionals element given 239 below 241 243 245 This section contains all the records in the additional section of 246 the response with each resource record in the additional element. 248 249 Each additional element contains a resource record 251 253 255 6. DNS Resource Record Format 257 Every DNS resource record contains a name, type, class, ttl, rdlength 258 and type specific rdata. The XML elements for each of these are 259 described below. 261 263 Textual representation of the domain name to which this 264 resource record pertains as it appears in the master file 266 268 270 Type of the RDATA field as specified under "TYPE" field in the 271 RRTYPE registry in [IANA_DNS]. 273 275 277 Class of the RDATA field as specified under "Name" field in the 278 Class registry in [IANA_DNS]. 280 282 284 Time to live value of this resource record in seconds 286 288 290 Length of the RDATA field 292 294 295 RDATA is represented as zero or more words of hexadecimal data 296 described in RFC 3597 [RFC3597]. The special token \# and 297 RDATA length are not included. 299 301 7. Message Compression 303 Message compression is not supported. All names should be fully 304 expanded. 306 8. Message Update 308 DNS Update RFC 2136 [RFC2136] is not supported. 310 9. Acknowledgements 312 TBD 314 10. IANA Considerations 316 This memo includes no request to IANA. 318 11. Security Considerations 320 In the current DNS system, there is no trust relationship between the 321 stub resolver and the rest of the system. When the users connect to 322 the Internet using their ISP that provides the Internet service, they 323 expect the ISP to provide trustworthy DNS service. When they connect 324 to the Internet from hotspots and other places, there is no trust 325 whatsoever. There are also many popular open recursive resolvers 326 that are available in the Internet today that provide DNS resolution. 327 Similarly, the DNS service described in this document may be provided 328 via both HTTP and HTTPS. Depending on the stub resolver's trust 329 relationship with the DNS service provider, it can use HTTP or HTTPS. 330 When DNSSEC is used, the DNS data can be authenticated independently. 332 DNSSEC itself cannot be used to validate the IP address of the server 333 that is providing the DNS service using the method described in this 334 document. 336 12. References 337 12.1. Normative References 339 [RFC1035] Mockapetris, P., "Domain names - implementation and 340 specification", STD 13, RFC 1035, November 1987. 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, March 1997. 345 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 346 (RR) Types", RFC 3597, September 2003. 348 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 349 Rose, "Resource Records for the DNS Security Extensions", 350 RFC 4034, March 2005. 352 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 353 Rose, "Protocol Modifications for the DNS Security 354 Extensions", RFC 4035, March 2005. 356 12.2. Informative References 358 [IANA_DNS] 359 "Domain Name System Parameters", 360 . 362 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 363 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 364 RFC 2136, April 1997. 366 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 367 Resource Identifiers (URI): Generic Syntax", RFC 2396, 368 August 1998. 370 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 371 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 372 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 374 [XML] T, Bray., J, Paoli., and Sperberg-McQueen. C.M., 375 "Extensible Markup Language (XML)", 1998. 377 Appendix A. Appendix A 379 This section provides a few sample queries and responses 380 QUERY: https://server_address/dns_service/ 381 query?name=www.isc.org&type=A&ID=2345&RD=1 383 RESPONSE: 385 387 389 2345 391 1 393 0 395 1 397 399 9514402A 401 403 405 Authors' Addresses 407 Mohan Parthasarathy (editor) 408 Apple Inc. 409 1 Infinite loop 410 Cupertino, 95014 411 USA 413 Phone: +1 408 862 7901 414 Email: mparthasarathy@apple.com 416 Paul Vixie 417 ISC 418 950 Charter Street 419 Redwood City, 94063 420 USA 422 Phone: +1 650 423 1300 423 Email: vixie@isc.org