idnits 2.17.1 draft-faltstrom-uri-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3404, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3959, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: One SHOULD not include userinfo (see User Information, Section 3.2.1, in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record as DNS data must be viewed as publicly available information. (Using the creation date from RFC3404, updated by this document, for RFC5378 checks: 2000-07-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 23, 2009) is 5449 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) == Missing Reference: 'RFCXXXX' is mentioned on line 303, but not defined == Missing Reference: 'X' is mentioned on line 344, but not defined == Missing Reference: 'RFC3597' is mentioned on line 427, but not defined == Unused Reference: 'E164' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'RFC4848' is defined on line 479, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Faltstrom 3 Internet-Draft Cisco 4 Updates: 3404, 3959 O. Kolkman 5 (if approved) NLNet 6 Intended status: Standards Track May 23, 2009 7 Expires: November 24, 2009 9 The Uniform Resource Identifier (URI) DNS Resource Record 10 draft-faltstrom-uri-04.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 24, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document defines a new DNS resource record, called the Uniform 49 Resource Identifier (URI) RR, for publishing mappings from hostnames 50 to URIs. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 56 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 4 57 4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 4 58 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4 59 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 63 5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 6 64 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6.1. Homepage at one domain, but two domains in use . . . . . . 6 66 7. Relation to U-NAPTR . . . . . . . . . . . . . . . . . . . . . 7 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Registration of the URI Resource Record Type . . . . . . . 7 69 8.2. Registration of services . . . . . . . . . . . . . . . . . 8 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 72 Appendix A. RRTYPE Allocation Request . . . . . . . . . . . . . . 8 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 75 11.2. Non-normative references . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 This document explains the use of the Domain Name System (DNS) for 81 the storage of URIs, and how to resolve hostnames to such URIs that 82 can be used by various applications. For resolution the application 83 need to know both the hostname and the protocol that the URI is to be 84 used for. The protocol is registered by IANA. 86 Currently, looking up URIs given a hostname uses the DDDS [RFC3401] 87 application framework with the DNS as a database as specified in RFC 88 3404 [RFC3404]. This has a number of implications such as the 89 inability to select what NAPTR records that match the query are 90 interesting. The RRSet returned will always consist of all URIs 91 "connected" with the domain in question. 93 The URI resource record specified in this document enables the 94 querying party to select which ones of the NAPTR records one is 95 interested in. This because data in the service field of the NAPTR 96 record is included in the owner part of the URI resource record type. 98 Querying for URI resource records is not replacing querying for NAPTR 99 resource records (or use of S-NAPTR [RFC3958]). Instead, the URI 100 resource record type provides a complementary mechanism to use when 101 one already knows what service field is interesting. With it, one 102 can directly query for the specific subset of the otherwise possibly 103 large RRSet given back when querying for NAPTR resource records. 105 This document updates RFC 3958 and RFC 3404 by adding the flag "D" to 106 the list of defined terminal flags in section 2.2.3 of RFC 3958 and 107 4.3 of RFC 3404. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in BCP 14, RFC 2119 112 [RFC2119]. 114 2. Applicability Statement 116 In general, it is expected that URI records will be used by clients 117 for applications where the relevant protocol to be used is known, 118 but, for example, an extra abstraction is needed in order to separate 119 a domain name from a point of service (as addressed by the URI). One 120 example of such a situation is when an organisation has many domain 121 names, but only one official web page. 123 Applications MUST know the specific service fields to prepend the 124 hostname with. Using repetitive queries for URI records MUST NOT be 125 a replacement for querying for NAPTR records according to the NAPTR 126 (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose to 127 discover the various services and URIs for looking up access points 128 for a given service. Those are two very different kinds of needs. 130 3. DNS considerations 132 Using prefix labels, such as underscored service tags, prevents the 133 use of wildcards, as constructs as _s2._s1.*.example.net. are not 134 possible in the DNS, see RFC 4592 [RFC4592]. Besides, underscored 135 service tags used for the URI RR (based on the NAPTR service 136 descriptions) may have slightly different semantics than service tags 137 used for underscored prefix labels that are used in combination with 138 other (yet unspecified) RR types. This may cause subtle management 139 problems when delegation structure that has developed within the 140 context of URI RRs is also to be used for other RR types. Since the 141 service labels might be overloaded, applications should carefully 142 check that the application level protocol is indeed the protocol they 143 expect. 145 Subtle management issues may also arise when the delegations from 146 service to sub service label involves several parties and different 147 stake holders. 149 4. The format of the URI RR 151 This is the presentation format of the URI RR: 153 Ownername TTL Class URI Priority Weight Target 155 The URI RR does not cause any kind of Additional Section processing. 157 4.1. Ownername, class and type 159 The URI ownername is subject to special conventions. 161 Just like the SRV RR [RFC2782] the URI RR has service information 162 encoded in its ownername. In order to encode the service for a 163 specific owner name one uses service parameters. Valid service 164 parameters used are those used for SRV resource records, or 165 registered by IANA for Enumservice Registrations. The Enumservice 166 Registration parameters are reversed (subtype(s) before type), 167 prepended with an underscore (_) and prepended to the owner name in 168 separate labels. The underscore is prepended to the service 169 parameters to avoid collisions with DNS labels that occur in nature, 170 and the order is reversed to make it possible to do delegations, if 171 needed, to different zones (and therefore providers of DNS). 173 For example, suppose we are looking for the URI for a service with 174 Service Parameter "A:B:C" for host example.com.. Then we would query 175 for (QNAME,QTYPE)=("_C._B._A.example.com","URI") 177 The type number for the URI record is TBD1 (to be assigned by IANA). 179 The URI resource record is class independent. 181 The URI RR has no special TTL requirements. 183 4.2. Priority 185 The priority of the target URI in this RR. Its range is 0-65535. A 186 client MUST attempt to contact the URI with the lowest-numbered 187 priority it can reach; URIs with the same priority SHOULD be tried in 188 the order defined by the weight field. 190 4.3. Weight 192 A server selection mechanism. The weight field specifies a relative 193 weight for entries with the same priority. Larger weights SHOULD be 194 given a proportionately higher probability of being selected. The 195 range of this number is 0-65535. 197 4.4. Target 199 The URI of the target, enclosed in double-quote characters ('"'). 200 Resolution of the URI is according to the definitions for the Scheme 201 of the URI. 203 The URI is encoded as one or more RFC1035 section 204 3.3 [RFC1035]. 206 4.5. URI RDATA Wire Format 208 The RDATA for a URI RR consists of a 2 octet Priority field, a two 209 octet Weight field, and a variable length target field. 211 Priority and Weight are unsigned integers in network byte order. 213 The Target field contains the URI (without the enclosing double- 214 quote characters used in the presentation format), encoded as a 215 sequence of one or more (as specified in section 216 3.3 of RFC 1035 [RFC1035]), where all but the last 217 are filled up to the maximum length of 255 octets. 219 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Priority | Weight | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 / / 225 / Target / 226 / / 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 5. Definition of the flag 'D' for NAPTR records 231 This document specifies the flag "D" for use as a flag in NAPTR 232 records. The flag indicate a terminal NAPTR record because it 233 denotes the end of the DDDS/NAPTR processing rules. In the case of a 234 "D" flag, the Replacement field in the NAPTR record, prepended with 235 the service flags, is used as the Owner of a DNS query for URI 236 records, and normal URI processing as defined in this document is 237 applied. 239 The replacement field MUST NOT include any of the service parameters. 240 Those are to be prepended (together with underscore) as described in 241 other places in this document. 243 The Regexp field in the NAPTR record MUST be empty when the 'D' flag 244 is in use. 246 6. Examples 248 6.1. Homepage at one domain, but two domains in use 250 An organisation has the domain names example.com and example.net, but 251 the official URI http://www.example.com/. Given the service type 252 "web" and subtype "http" (from the IANA registry), the following URI 253 Resource Records could be made available in the respective zones 254 (example.com and example.net): 256 $ORIGIN example.com. 257 _http._web IN URI 10 1 "http://www.example.com/" 259 $ORIGIN example.net. 261 _http._web IN URI 10 1 "http://www.example.com/" 263 7. Relation to U-NAPTR 265 The URI Resource Record Type is not a replacement for the U-NAPTR. 266 It is instead an extension and more powerful second step in the 267 resolution than the SRV record. As such, it could be referred to as 268 the target in a terminal rule in any of the NAPTR specifications. 270 If one knows exactly what service type one is looking for, one can do 271 a direct lookup of the URI record without first looking up the NAPTR. 272 In the example below, if one where looking for EM:protA service in 273 the example.com domain, one could look for the URI Resource Record 274 Type with the owner _protA._EM.example.com directly. 276 Example from U-NAPTR (URI resolution is not included): 278 $ORIGIN example.com. 279 IN NAPTR 200 10 "u" "EM:protA" ( ; service 280 "!.*!prota://someisp.example.com!" ; regexp 281 "" ) ; replacement 283 With URI records, and the use of the new flag 'D': 285 $ORIGIN example.com. 286 IN NAPTR 200 10 "D" "EM:protA" ( ; service 287 "" ; regexp 288 "example.com." ) ; replacement 289 _protA._EM IN URI "prota://somehost.example.com/" 291 8. IANA Considerations 293 8.1. Registration of the URI Resource Record Type 295 IANA has assigned Resource Record Type TBD1 for the URI Resource 296 Record Type and added the line depicted below to the registry named 297 Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42 RFC 5395 298 [RFC5395] and located at 299 http://www.iana.org/assignments/dns-parameters. 301 TYPE Value and meaning Reference 302 ----------- --------------------------------------------- --------- 303 URI TBD1 a URI for a service (per the owner name) [RFCXXXX] 305 8.2. Registration of services 307 No new registry is needed for the registration of services as the 308 Enumservice Registrations registry is used also for the URI resource 309 record type. 311 9. Security Considerations 313 The authors do not believe this resource record cause any new 314 security problems. Deployment must though be done in a proper way as 315 misconfiguration of this resource record might make it impossible to 316 reach the service that was originally intended to be accessed. 318 For example, if the URI in the resource record type has errors in it, 319 applications using the URI resource record type for resolution should 320 behave similarly as if the user typed (or copy and pasted) the URI. 321 At least it must be clear to the user that the error is not due to 322 any error from his side. 324 One SHOULD not include userinfo (see User Information, Section 3.2.1, 325 in RFC 3986 [RFC3986]) in a URI that is used in a URI resource record 326 as DNS data must be viewed as publicly available information. 328 10. Acknowledgements 330 Ideas on how to split the two different kind of queries "What 331 services exists for this domain name" and "What is the URI for this 332 service" came from Scott Bradner and Lawrence Conroy. Other people 333 that have contributed to this document include Leslie Daigle, Olafur 334 Gudmundsson, Ted Hardie, Peter Koch and Penn Pfautz. 336 Appendix A. RRTYPE Allocation Request 338 A. Submission Date: 340 May 23, 2009 342 B. Submission Type: 344 [X] New RRTYPE 345 [ ] Modification to existing RRTYPE 347 C. Contact Information for submitter: 349 Name: Patrik Faltstrom 350 Email Address: paf@cisco.com 351 International telephone number: +46-8-6859131 352 Other contact handles: 353 (Note: This information will be publicly posted.) 355 D. Motivation for the new RRTYPE application? 357 There is no easy way to get from a domain name to a URI. Some 358 mechanisms exists via use of the NAPTR [RFC3403] resource 359 record. That implies quite complicated rules that are 360 simplified via the S-NAPTR [RFC3958] specification. But, the 361 ability to directly look up a URI still exists. This 362 specification uses a prefix based naming mechanism originated in 363 the definition of the SRV [RFC2782] resource record, and the 364 RDATA is a URI, encoded as one text field. 366 See also above (Section 1). 368 E. Description of the proposed RR type. 370 The format of the URI resource record is as follows: 372 Ownername TTL Class URI Priority Weight Target 374 The URI RR has service information encoded in its ownername. In 375 order to encode the service for a specific owner name one uses 376 service parameters. Valid service parameters used are either 377 Enumservice Registrations registered by IANA, or prefixes used 378 for the SRV resource record. 380 The wire format of the RDATA is as follows: 382 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Priority | Weight | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 / / 388 / Target / 389 / / 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 F. What existing RRTYPE or RRTYPEs come closest to filling that 393 need and why are they unsatisfactory? 395 The RRTYPE that come closest is the NAPTR resource record. It 396 is for example used in the DDDS and S-NAPTR algorithms. The 397 main problem with the NAPTR is that selection of what record (or 398 records) one is interested in is based on data stored in the 399 RDATA portion of the NAPTR resource record. This, as explained 400 in RFC 5507 [RFC5507], is not optimal for DNS lookups. Further, 401 most applications using NAPTR resource records uses regular 402 expression based rewrite rules for creation of the URI, and that 403 has shown be complicated to implement. 405 The second closest RRTYPE is the SRV record that given a 406 prefixed based naming just like is suggested for the URI 407 resource record, one get back a port number and domain name. 408 This can also be used for creation of a URI, but, only URIs 409 without path components. 411 G. What mnemonic is requested for the new RRTYPE (optional)? 413 URI 415 H. Does the requested RRTYPE make use of any existing IANA Registry 416 or require the creation of a new IANA sub-registry in DNS 417 Parameters? 419 Yes, partially. 421 One of the mechanisms to select a service is to use the 422 Enumservice Registry managed by IANA. Another is to use 423 services and protocols used for SRV records. 425 I. Does the proposal require/expect any changes in DNS servers/ 426 resolvers that prevent the new type from being processed as an 427 unknown RRTYPE (see [RFC3597])? 429 No 431 J. Comments: 433 None 435 11. References 437 11.1. Normative References 439 [E164] ITU-T, "The International Public Telecommunication Number 440 Plan", Recommendation E.164, May 1997. 442 [RFC1035] Mockapetris, P., "Domain names - implementation and 443 specification", STD 13, RFC 1035, November 1987. 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, March 1997. 448 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 449 Service Location Using SRV RRs and the Dynamic Delegation 450 Discovery Service (DDDS)", RFC 3958, January 2005. 452 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 453 Considerations", BCP 42, RFC 5395, November 2008. 455 11.2. Non-normative references 457 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 458 specifying the location of services (DNS SRV)", RFC 2782, 459 February 2000. 461 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 462 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 464 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 465 Part Three: The Domain Name System (DNS) Database", 466 RFC 3403, October 2002. 468 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 469 Part Four: The Uniform Resource Identifiers (URI)", 470 RFC 3404, October 2002. 472 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 473 Resource Identifier (URI): Generic Syntax", STD 66, 474 RFC 3986, January 2005. 476 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 477 System", RFC 4592, July 2006. 479 [RFC4848] Daigle, L., "Domain-Based Application Service Location 480 Using URIs and the Dynamic Delegation Discovery Service 481 (DDDS)", RFC 4848, April 2007. 483 [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design 484 Choices When Expanding the DNS", RFC 5507, April 2009. 486 Authors' Addresses 488 Patrik Faltstrom 489 Cisco Systems 491 Email: paf@cisco.com 493 Olaf Kolkman 494 NLnet Labs 496 Email: olaf@NLnetLabs.nl