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