1 Network Working Group S. Josefsson
2 Request for Comments: 4501 SJD
3 Category: Standards Track May 2006
4
5
6 Domain Name System Uniform Resource Identifiers
7
8 Status of This Memo
9
10 This document specifies an Internet standards track protocol for the
11 Internet community, and requests discussion and suggestions for
12 improvements. Please refer to the current edition of the "Internet
13 Official Protocol Standards" (STD 1) for the standardization state
14 and status of this protocol. Distribution of this memo is unlimited.
15
16 Copyright Notice
17
18 Copyright (C) The Internet Society (2006).
19
20 Abstract
21
22 This document defines Uniform Resource Identifiers for Domain Name
23 System resources.
24
25 Table of Contents
26
27 1. Introduction and Background . . . . . . . . . . . . . . . . . 2
28 2. Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . 2
29 3. DNS URI Registration . . . . . . . . . . . . . . . . . . . . . 3
30 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
31 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
34 8. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 8
35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
36 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
37 9.2. Informative References . . . . . . . . . . . . . . . . . 8
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Josefsson Standards Track [Page 1]
53 RFC 4501 DNS URI May 2006
54
55
56 1. Introduction and Background
57
58 The Domain Name System (DNS) [1] [2] is a widely deployed system
59 used, among other things, to translate host names into IP addresses.
60 Several protocols use Uniform Resource Identifiers (URIs) to refer to
61 data. By defining a URI scheme for DNS data, the gap between these
62 two worlds is bridged. The DNS URI scheme defined here can be used
63 to reference any data stored in the DNS.
64
65 Data browsers may support DNS URIs by forming DNS queries and
66 rendering DNS responses using HTML [12], which is similar to what is
67 commonly done for FTP [6] resources. Applications that are
68 Multipurpose Internet Mail Extensions (MIME) [7] aware may tag DNS
69 data retrieved using this scheme with the text/dns or application/dns
70 types as specified in [15].
71
72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
74 document are to be interpreted as described in RFC 2119 [3].
75
76 2. Usage Model
77
78 Refer to section 1 of [5] for an in-depth discussion of URI
79 classifications. In particular, the reader is assumed to be familiar
80 with the distinction between "name" and "locator". This section
81 describes how the DNS URI scheme is intended to be used and outlines
82 future work that may be required to use URIs with the DNS for some
83 applications.
84
85 The URI scheme described in this document focuses on the data stored
86 in the DNS. As such, there is no provision to specify any of the
87 fields in the actual DNS protocol. This is intended so that the URI
88 may be used even in situations where the DNS protocol is not used
89 directly. Two examples for this are zone file editors and DNS-
90 related configuration files, which may use this URI scheme to
91 identify data. The application would not use the DNS protocol to
92 resolve the URIs.
93
94 A limitation of this design is that it does not accommodate all
95 protocol parameters within the DNS protocol. It is expected that,
96 for certain applications, a more detailed URI syntax that maps more
97 closely to the DNS protocol may be required. However, such a URI
98 definition is not included in this document. This document specifies
99 a URI that is primarily intended to name DNS resources, but it can
100 also be used to locate said resources for simple, yet common,
101 applications.
102
103
104
105
106
107 Josefsson Standards Track [Page 2]
108 RFC 4501 DNS URI May 2006
109
110
111 3. DNS URI Registration
112
113 This section contains the registration template for the DNS URI
114 scheme in accordance with [11].
115
116 URL scheme name: "dns".
117
118 URL scheme syntax: A DNS URI designates a DNS resource record set,
119 referenced by domain name, class, type, and, optionally, the
120 authority. The DNS URI follows the generic syntax from RFC 3986 [5]
121 and is described using ABNF [4]. Strings are not case sensitive, and
122 free insertion of linear-white-space is not permitted.
123
124 dnsurl = "dns:" [ "//" dnsauthority "/" ]
125 dnsname ["?" dnsquery]
126
127 dnsauthority = host [ ":" port ]
128 ; See RFC 3986 for the
129 ; definition of "host" and "port".
130
131 dnsname = *pchar
132 ; See RFC 3986 for the
133 ; definition of "pchar".
134
135 ; The "dnsname" field may be a
136 ; "relative" or "absolute" name,
137 ; as per RFC 1034, section 3.1.
138
139 ; Note further that an empty
140 ; "dnsname" value is to be
141 ; interpreted as the root itself.
142 ; See below on relative dnsnames.
143
144 dnsquery = dnsqueryelement [";" dnsquery]
145
146 dnsqueryelement = ( "CLASS=" dnsclassval ) / ( "TYPE=" dnstypeval )
147 ; Each clause MUST NOT be used more
148 ; than once.
149
150 dnsclassval = 1*digit / "IN" / "CH" /
151 <Any IANA registered DNS class mnemonic>
152
153 dnstypeval = 1*digit / "A" / "NS" / "MD" /
154 <Any IANA registered DNS type mnemonic>
155
156 Unless specified in the URI, the authority ("dnsauthority") is
157 assumed to be locally known, the class ("dnsclassval") to be the
158 Internet class ("IN"), and the type ("dnstypeval") to be the Address
159
160
161
162 Josefsson Standards Track [Page 3]
163 RFC 4501 DNS URI May 2006
164
165
166 type ("A"). These default values match the typical use of DNS: to
167 look up addresses for host names.
168
169 A dnsquery element MUST NOT contain more than one occurrence of the
170 "CLASS" and "TYPE" fields. For example, both "dns:
171 example?TYPE=A;TYPE=TXT" and "dns:example?TYPE=A;TYPE=A" are invalid.
172 However, the fields may occur in any order, so that both "dns:
173 example?TYPE=A;CLASS=IN" and "dns:example?CLASS=IN;TYPE=A" are valid.
174
175 The digit representation of types and classes MAY be used when a
176 mnemonic for the corresponding value is not well known (e.g., for
177 newly introduced types or classes), but it SHOULD NOT be used for the
178 types or classes defined in the DNS specification [2]. All
179 implementations MUST recognize the mnemonics defined in [2].
180
181 To avoid ambiguity, relative "dnsname" values (i.e., those not ending
182 with ".") are assumed to be relative to the root. For example, "dns:
183 host.example" and "dns:host.example." both refer to the same owner
184 name; namely, "host.example.". Further, an empty "dnsname" value is
185 considered a degenerative form of a relative name, which refers to
186 the root (".").
187
188 To resolve a DNS URI using the DNS protocol [2], a query is created,
189 using as input the dnsname, dnsclassval, and dnstypeval from the URI
190 string (or the appropriate default values). If an authority
191 ("dnsauthority") is given in the URI string, this indicates the
192 server that should receive the DNS query. Otherwise, the default DNS
193 server should receive it.
194
195 Note that DNS URIs could be resolved by other protocols than the DNS
196 protocol, or by using the DNS protocol in some other way than as
197 described above (e.g., multicast DNS). DNS URIs do not require the
198 use of the DNS protocol, although it is expected to be the typical
199 usage. The previous paragraph only illustrates how DNS URIs are
200 resolved using the DNS protocol.
201
202 A client MAY want to check that it understands the dnsclassval and
203 dnstypeval before sending a query, so that it will be able to
204 understand the response. However, a typical example of a client that
205 would not need to check dnsclassval and dnstypeval would be a proxy
206 that would just treat the received answer as opaque data.
207
208 Character encoding considerations: Characters are encoded as per RFC
209 3986 [5]. The DNS protocol does not consider character sets; it
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
210 simply transports opaque data. In particular, the "dnsname" field of
211 the DNS URI is to be considered an internationalized domain name
212 (IDN) unaware domain name slot, in the terminology of RFC 3940 [14].
213 The considerations for "host" and "port" are discussed in [5].
214
215
216
217 Josefsson Standards Track [Page 4]
218 RFC 4501 DNS URI May 2006
219
220
221 Because "." is used as the DNS label separator, an escaping mechanism
222 is required to encode a "." that is part of a DNS label. The
223 escaping mechanism is described in section 5.1 of RFC 1035 [2]. For
224 example, a DNS label of "exa.mple" can be escaped as "exa\.mple" or
225 "exa\046mple". However, the URI specification disallows the "\"
226 character from occurring directly in URIs, so it must be escaped as
227 "%5c". The single DNS label "exa.mple" is thus encoded as "exa%
228 5c.mple". The same mechanism can be used to encode other characters,
229 for example, "?" and ";". Note that "." and "%2e" are equivalent
230 within dnsname and are interchangeable.
231
232 This URI specification allows all possible domain names to be
233 encoded, provided the encoding rules are observed per [5]). However,
234 certain applications may restrict the set of valid characters. Care
235 should be taken so that invalid characters in these contexts do not
236 cause harm. In particular, host names in the DNS have certain
237 restrictions. It is up to these applications to limit this subset;
238 this URI scheme places no restrictions.
239
240 Intended usage: Whenever it is useful for DNS resources to be
241 referenced by protocol-independent identifiers. Often, this occurs
242 when the data is more important than the access method. Since
243 software in general has coped without this so far, it is not
244 anticipated to be implemented widely, nor migrated to by existing
245 systems, but specific solutions (especially security-related) may
246 find this appropriate.
247
248 Applications and/or protocols that use this scheme include
249 Security-related software, DNS administration tools, and network
250 programming packages.
251
252 Interoperability considerations: The data referenced by this URI
253 scheme might be transferred by protocols that are not URI aware (such
254 as the DNS protocol). This is not anticipated to have any serious
255 interoperability impact.
256
257 Interoperability problems may occur if one entity understands a new
258 DNS class/type mnemonic that another entity does not. This is an
259 interoperability problem for DNS software in general, although it is
260 not a major practical problem for current DNS deployments, as the DNS
261 types and classes are fairly static. To guarantee interoperability,
262 implementations can use integers for all mnemonics not defined in
263 [2].
264
265 Interaction with Binary Labels [10] or other extended label types has
266 not been analyzed. However, binary labels appear to be infrequently
267 used in practice.
268
269
270
271
272 Josefsson Standards Track [Page 5]
273 RFC 4501 DNS URI May 2006
274
275
276 Contact: simon@josefsson.org
277
278 Author/Change Controller: simon@josefsson.org
279
280 4. Examples
281
282 A DNS URI is of the following general form. This is intended to
283 illustrate, not define, the scheme:
284
285 dns:[//authority/]domain[?CLASS=class;TYPE=type]
286
287 The following illustrates a URI for a resource with the absolute name
288 "www.example.org.", the Internet (IN) class, and the Address (A)
289 type:
290
291 dns:www.example.org.?clAsS=IN;tYpE=A
292
293 Since the default class is IN and the default type is A, the same
294 resource can be identified by a shorter URI using a relative name:
295
296 dns:www.example.org
297
298 The following illustrates a URI for a resource with the name
299 "simon.example.org" for the CERT type in the Internet (IN) class:
300
301 dns:simon.example.org?type=CERT
302
303 The following illustrates a URI for a resource with the name
304 "ftp.example.org", in the Internet (IN) class and the address (A)
305 type, but from the DNS authority 192.168.1.1 instead of the default
306 authority:
307
308 dns://192.168.1.1/ftp.example.org?type=A
309
310 The following illustrates various escaping techniques. The owner
311 name would be "world wide web.example\.domain.org", where "\."
312 denotes the character "." as part of a label, and "." denotes the
313 label separator:
314
315 dns:world%20wide%20web.example%5c.domain.org?TYPE=TXT
316
317 The following illustrates a strange but valid DNS resource:
318
319 dns://fw.example.org/*.%20%00.example?type=TXT
320
321
322
323
324
325
326
327 Josefsson Standards Track [Page 6]
328 RFC 4501 DNS URI May 2006
329
330
331 5. Acknowledgements
332
333 Thanks to Stuart Cheshire, Donald Eastlake, Pasi Eronen, Bill Fenner,
334 Ted Hardie, Russ Housley, Peter Koch, Andrew Main, Larry Masinter,
335 Michael Mealling, Steve Mattson, Marcos Sanz, Jason Sloderbeck, Paul
336 Vixie, Sam Weiler, and Bert Wijnen for comments and suggestions. The
337 author acknowledges RSA Laboratories for supporting the work that led
338 to this document.
339
340 6. Security Considerations
341
342 If a DNS URI references domains in the Internet DNS environment, both
343 the URI itself and the information referenced by the URI is public
344 information. If a DNS URI is used within an "internal" DNS
345 environment, both the DNS URI and the data referenced should be
346 handled using the same considerations that apply to DNS data in the
347 "internal" environment.
348
349 If information referenced by DNS URIs are used to make security
350 decisions (such data includes, but is not limited to, certificates
351 stored in the DNS [9]), implementations may need to employ security
352 techniques such as Secure DNS [16], CMS [13], or OpenPGP [8], to
353 protect the data during transport. How to implement this will depend
354 on the usage scenario, and it is not up to this URI scheme to define
355 how the data referenced by DNS URIs should be protected.
356
357 If applications accept unknown dnsqueryelement values in a URI (e.g.,
358 URI "dns:www.example.org?secret=value") without knowing what the
359 "secret=value" dnsqueryelement means, a covert channel used to "leak"
360 information may be enabled. The implications of covert channels
361 should be understood by applications that accept unknown
362 dnsqueryelement values.
363
364 Slight variations, such as the difference between upper and lower
365 case in the dnsname field, can be used as a covert channel to leak
366 information.
367
368 7. IANA Considerations
369
370 The IANA has registered the DNS URI scheme, using the template in
371 section 3, in accordance with RFC 2717 [11].
372
373
374
375
376
377
378
379
380
381
382 Josefsson Standards Track [Page 7]
383 RFC 4501 DNS URI May 2006
384
385
386 8. Copying Conditions
387
388 Copyright (c) 2000, 2001, 2002, 2003, 2004, 2005, 2006 Simon
389 Josefsson
390
391 Regarding this entire document or any portion of it, the author makes
392 no guarantees and is not responsible for any damage resulting from
393 its use. The author grants irrevocable permission to anyone to use,
394 modify, and distribute it in any way that does not diminish the
395 rights of anyone else to use, modify, and distribute it, provided
396 that redistributed derivative works do not contain misleading author
397 or version information. Derivative works need not be licensed under
398 similar terms.
399
400 9. References
401
402 9.1. Normative References
403
404 [1] Mockapetris, P., "Domain names - concepts and facilities", STD
405 13, RFC 1034, November 1987.
406
407 [2] Mockapetris, P., "Domain names - implementation and
408 specification", STD 13, RFC 1035, November 1987.
409
410 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
411 Levels", BCP 14, RFC 2119, March 1997.
412
413 [4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
414 Specifications: ABNF", RFC 4234, October 2005.
415
416 [5] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
417 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
418 January 2005.
419
420 9.2. Informative References
421
422 [6] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
423 959, October 1985.
424
425 [7] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
426 Mail Extensions (MIME) Part Four: Registration Procedures", BCP
427 13, RFC 2048, November 1996.
428
429 [8] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP
430 Message Format", RFC 2440, November 1998.
431
432 [9] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates in
433 the Domain Name System (DNS)", RFC 2538, March 1999.
434
435
436
437 Josefsson Standards Track [Page 8]
438 RFC 4501 DNS URI May 2006
439
440
441 [10] Crawford, M., "Binary Labels in the Domain Name System", RFC
442 2673, August 1999.
443
444 [11] Petke, R. and I. King, "Registration Procedures for URL Scheme
445 Names", BCP 35, RFC 2717, November 1999.
446
447 [12] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC
448 2854, June 2000.
449
450 [13] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
451 July 2004.
452
453 [14] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing
454 Domain Names in Applications (IDNA)", RFC 3490, March 2003.
455
456 [15] Josefsson, S., "Domain Name System Media Types", RFC 4027, April
457 2005.
458
459 [16] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
460 "DNS Security Introduction and Requirements", RFC 4033, March
461 2005.
462
463 Author's Address
464
465 Simon Josefsson
466 SJD
467
468 EMail: simon@josefsson.org
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492 Josefsson Standards Track [Page 9]
493 RFC 4501 DNS URI May 2006
494
495
496 Full Copyright Statement
497
498 Copyright (C) The Internet Society (2006).
499
500 This document is subject to the rights, licenses and restrictions
501 contained in BCP 78, and except as set forth therein, the authors
502 retain all their rights.
503
504 This document and the information contained herein are provided on an
505 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
506 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
507 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
508 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
509 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
511
512 Intellectual Property
513
514 The IETF takes no position regarding the validity or scope of any
515 Intellectual Property Rights or other rights that might be claimed to
516 pertain to the implementation or use of the technology described in
517 this document or the extent to which any license under such rights
518 might or might not be available; nor does it represent that it has
519 made any independent effort to identify any such rights. Information
520 on the procedures with respect to rights in RFC documents can be
521 found in BCP 78 and BCP 79.
522
523 Copies of IPR disclosures made to the IETF Secretariat and any
524 assurances of licenses to be made available, or the result of an
525 attempt made to obtain a general license or permission for the use of
526 such proprietary rights by implementers or users of this
527 specification can be obtained from the IETF on-line IPR repository at
528 http://www.ietf.org/ipr.
529
530 The IETF invites any interested party to bring to its attention any
531 copyrights, patents or patent applications, or other proprietary
532 rights that may cover technology that may be required to implement
533 this standard. Please address the information to the IETF at
534 ietf-ipr@ietf.org.
535
536 Acknowledgement
537
538 Funding for the RFC Editor function is provided by the IETF
539 Administrative Support Activity (IASA).
540
541
542
543
544
545
546
547 Josefsson Standards Track [Page 10]
548
In particular, the "dnsname" field of the DNS URI is to be considered an internationalized domain name (IDN) unaware domain name slot, in the terminology of RFC 3940 [14].
In particular, the "dnsname" field of the DNS URI is to be considered an internationalized domain name (IDN) unaware domain name slot, in the terminology of RFC39403490 [14].