idnits 2.17.1 draft-faltstrom-uri-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 402. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 415. 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 Copyright Line does not match the current year -- 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 (November 3, 2008) is 5652 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 297, but not defined == Unused Reference: 'E164' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC4848' is defined on line 362, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' ** Obsolete normative reference: RFC 2929 (Obsoleted by RFC 5395) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 Intended status: Standards Track O. Kolkman 5 Expires: May 7, 2009 NLNet 6 November 3, 2008 8 The Uniform Resource Identifier (URI) DNS Resource Record 9 draft-faltstrom-uri-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 7, 2009. 36 Abstract 38 This document defines a new DNS resource record, called the Uniform 39 Resource Identifier (URI) RR, for publishing mappings from hostnames 40 to URIs. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 46 3. DNS considerations . . . . . . . . . . . . . . . . . . . . . . 4 47 4. The format of the URI RR . . . . . . . . . . . . . . . . . . . 4 48 4.1. Ownername, class and type . . . . . . . . . . . . . . . . 4 49 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 4.5. URI RDATA Wire Format . . . . . . . . . . . . . . . . . . 5 53 4.6. The URI RR Presentation Format . . . . . . . . . . . . . . 6 54 5. Definition of the flag 'D' for NAPTR records . . . . . . . . . 6 55 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 6.1. Homepage at one domain, but two domains in use . . . . . . 7 57 7. Relation to U-NAPTR . . . . . . . . . . . . . . . . . . . . . 7 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 8.1. Registration of the URI Resource Record Type . . . . . . . 8 60 8.2. Registration of services . . . . . . . . . . . . . . . . . 8 61 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 65 11.2. Non-normative references . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 11 69 1. Introduction 71 This document explains the use of the Domain Name System (DNS) for 72 storage of URIs, and how to resolve hostnames to such URIs that can 73 be used by various applications. For resolution the application need 74 to know both the hostname and the protocol that the URI is to be used 75 for. The protocol is registered by IANA. 77 Currently, looking up URIs given a hostname uses the DDDS [RFC3401] 78 application framework with the DNS as a database as specified in RFC 79 3404 [RFC3404]. This have a number of implications such as the 80 inability to select what NAPTR records that match the query is 81 interesting. The RRSet returned will always consist of all URIs 82 "connected" with the domain in question. 84 The URI resource record specified in this document create an ability 85 for the querying party to select which ones of the NAPTR records one 86 is interested in. This because data in the service field of the 87 NAPTR record is included in the owner part of the URI resource record 88 type. 90 Querying for the URI resource record type is not replacing querying 91 for the NAPTR (or S-NAPTR [RFC3958]) resource record type. Instead 92 it is a complementary mechanism to use when one know already what 93 service field is interesting. One can with the URI resource record 94 type directly query for the specific subset of the otherwise possibly 95 large RRSet given back when querying for NAPTR resource records. 97 This document updates RFC 3958 and RFC 3404 by adding the flag "D" to 98 the list of defined terminal flags in section 2.2.3 of RFC 3958 and 99 4.3 of RFC 3404. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in BCP 14, RFC 2119 104 [RFC2119]. 106 2. Applicability Statement 108 In general, it is expected that URI records will be used by clients 109 for applications where the relevant protocol to be used is known, but 110 for example extra abstraction given by separating a hostname from a 111 point of service (as address by the URI) is needed. Example of such 112 a situation is when an organisation have many domain names, but only 113 one official web page. 115 Applications MUST know the specific service fields to prepend the 116 hostname with. Using repetitive queries for URI records MUST NOT be 117 a replacement for querying for NAPTR or S-NAPTR records. NAPTR and 118 S-NAPTR records are for discovery of the various services and URI for 119 looking up access point for a given service. Those are two very 120 different kinds of needs. 122 3. DNS considerations 124 Using prefix labels, such as underscored service tags, prevents the 125 use of wildcards, as constructs as _s2._s1.*.example.net. are not 126 possible in the DNS, see RFC 4592 [RFC4592]. Besides, underscored 127 service tags used for the URI RR (based on the NAPTR service 128 descriptions) may have slightly different semantics than service tags 129 used for underscored prefix labels that are used in combination with 130 other (yet unspecified) RR types. This may cause subtle management 131 problems when delegation structure that has developed within the 132 context of URI RRs is also to be used for other RR types. Since the 133 service labels might be overloaded applications should carefully 134 check that the application level protocol is indeed the protocol they 135 expect. 137 Subtle management issues may also arise when the delegations from 138 service to sub service label involves several parties and different 139 stake holders. 141 4. The format of the URI RR 143 This is the format of the URI RR, whose DNS type code is TBD1 (to be 144 assigned by IANA). 146 Ownername TTL Class URI Priority Weight Target 148 4.1. Ownername, class and type 150 The URI ownername is subject to special conventions. 152 Just like the SRV RR [RFC2782] the URI RR has service information 153 encoded in its ownername. In order to encode the service for a 154 specific owner name one use service parameters. Valid service 155 parameters used are those as registered by IANA for Enumservice 156 Registrations. The service parameters are reversed (subtype(s) 157 before type), prepended with an underscore (_) and prepended to the 158 owner name in separate labels. The underscore is prepended to the 159 service parameters to avoid collisions with DNS labels that occur in 160 nature, and the order is reversed to make it possible to do 161 delegations, if needed, to different zones (and therefore providers 162 of DNS). 164 For example, suppose we are looking for the URI for a service with 165 Service Parameter "A:B:C" for host example.com.. Then we would query 166 for (QNAME,QTYPE)=("_C._B._A.example.com","URI") 168 The type number for the URI record is TBD1 (to be assigned by IANA). 170 The URI resource record is class independent. 172 The URI RR has no special TTL requirements. 174 4.2. Priority 176 The priority of this target URI. A client MUST attempt to contact 177 the URI with the lowest-numbered priority it can reach; URIs with the 178 same priority SHOULD be tried in an order defined by the weight 179 field. The range is 0-65535. This is a 16 bit unsigned integer in 180 network byte order. 182 4.3. Weight 184 A server selection mechanism. The weight field specifies a relative 185 weight for entries with the same priority. Larger weights SHOULD be 186 given a proportionately higher probability of being selected. The 187 range of this number is 0-65535. This is a 16 bit unsigned integer 188 in network byte order. 190 4.4. Target 192 The URI of the target. Resolution of the URI is according to the 193 definitions for the URI Scheme the URI consists of. 195 The URI is encoded as one or more RFC1035 section 196 3.3 [RFC1035]. 198 4.5. URI RDATA Wire Format 200 The RDATA for a URI RR consists of a 2 octet Priority field, a two 201 octet Weight field, and a variable length target field. 203 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Priority | Weight | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 / / 209 / Target / 210 / / 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 4.6. The URI RR Presentation Format 215 The presentation format of the RDATA portion is as follows: 217 Priority field MUST be represented as an unsigned decimal integer. 219 The Weight Type field MUST be represented as an unsigned decimal 220 integer. 222 The target URI is enclosed in double-quotes ("). If the total length 223 of the URI exceeds 255 characters the URI will be encoded in multiple 224 . 226 5. Definition of the flag 'D' for NAPTR records 228 This document specifies the flag "D" for use as a flag in NAPTR 229 records. The flag indicate a terminal NAPTR record because it 230 denotes the end of the DDDS/NAPTR processing rules. In the case of a 231 "D" flag, the Replacement field in the NAPTR record, prepended with 232 the service flags, is used as the Owner of a DNS query for URI 233 records, and normal URI processing as defined in this document is 234 applied. 236 The replacement field MUST NOT include any of the service parameters. 237 Those are to be prepended (together with underscore) as described in 238 other places in this document. 240 The Regexp field in the NAPTR record MUST be empty when the 'D' flag 241 is in use. 243 6. Examples 244 6.1. Homepage at one domain, but two domains in use 246 An organisation have the domain names example.com and example.net, 247 but the official URI http://www.example.com/. Given the service type 248 "web" and subtype "http" (from the IANA registry), the following URI 249 Resource Records could be made available in the respective zones 250 (example.com and example.net): 252 $ORIGIN example.com. 253 _http._web IN URI 10 1 "http://www.example.com/" 255 $ORIGIN example.net. 256 _http._web IN URI 10 1 "http://www.example.com/" 258 7. Relation to U-NAPTR 260 The URI Resource Record Type is not a replacement for the U-NAPTR. 261 It is instead an extension and more powerful second step in the 262 resolution than the SRV record. As such, it could be referred to as 263 the target in a terminal rule in any of the NAPTR specifications. 265 If one know exactly what service type one is looking for one can do a 266 direct lookup of the URI record without first looking up the NAPTR. 267 In the example below, if one where looking for EM:protA service in 268 the example.com domain, one could look for the URI Resource Record 269 Type with the owner _protA._EM.example.com directly. 271 Example from U-NAPTR (URI resolution is not included): 273 $ORIGIN example.com. 274 IN NAPTR 200 10 "u" "EM:protA" ( ; service 275 "!.*!prota://someisp.example.com!" ; regexp 276 "" ) ; replacement 278 With URI records, and the use of the new flag 'D': 280 $ORIGIN example.com. 281 IN NAPTR 200 10 "D" "EM:protA" ( ; service 282 "" ; regexp 283 "example.com." ) ; replacement 284 _protA._EM IN URI "prota://somehost.example.com/" 286 8. IANA Considerations 288 8.1. Registration of the URI Resource Record Type 290 IANA has assigned Resource Record Type TBD1 to the URI Resource 291 Record Type to be added to the registry named Resource Record (RR) 292 TYPEs and QTYPEs as defined in RFC 2929 [RFC2929] and RFC 1035 293 [RFC1035]. 295 TYPE Value and meaning Reference 296 ----------- --------------------------------------------- --------- 297 URI TBD1 a URI as RDATA [RFCXXXX] 299 8.2. Registration of services 301 No new registry is needed for the registration of services as the 302 Enumservice Registrations registry is used also for the URI resource 303 record type. 305 9. Security Considerations 307 The authors do not believe this resource record cause any new 308 security problems. Deployment must though be done in a proper way as 309 misconfiguration of this resource record might make it impossible to 310 reach the service that was originally intended to be accessed. 312 For example, if the URI in the resource record type has errors in it, 313 applications using the URI resource record type for resolution should 314 behave similarly as if the user typed (or copy and pasted) the URI. 315 At least it must be clear to the user that the error is not due to 316 any error from his side. 318 10. Acknowledgements 320 Ideas on how to split the two different kind of queries "What 321 services exists for this domain name" and "What is the URI for this 322 service" came from Scott Bradner and Lawrence Conroy. Other people 323 that have contributed to this document include Leslie Daigle, Olafur 324 Gudmundsson, Ted Hardie, Peter Koch and Penn Pfautz. 326 11. References 327 11.1. Normative References 329 [E164] ITU-T, "The International Public Telecommunication Number 330 Plan", Recommendation E.164, May 1997. 332 [RFC1035] Mockapetris, P., "Domain names - implementation and 333 specification", STD 13, RFC 1035, November 1987. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", BCP 14, RFC 2119, March 1997. 338 [RFC2929] Eastlake, D., Brunner-Williams, E., and B. Manning, 339 "Domain Name System (DNS) IANA Considerations", BCP 42, 340 RFC 2929, September 2000. 342 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 343 Part Four: The Uniform Resource Identifiers (URI)", 344 RFC 3404, October 2002. 346 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 347 Service Location Using SRV RRs and the Dynamic Delegation 348 Discovery Service (DDDS)", RFC 3958, January 2005. 350 11.2. Non-normative references 352 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 353 specifying the location of services (DNS SRV)", RFC 2782, 354 February 2000. 356 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 357 Part One: The Comprehensive DDDS", RFC 3401, October 2002. 359 [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name 360 System", RFC 4592, July 2006. 362 [RFC4848] Daigle, L., "Domain-Based Application Service Location 363 Using URIs and the Dynamic Delegation Discovery Service 364 (DDDS)", RFC 4848, April 2007. 366 Authors' Addresses 368 Patrik Faltstrom 369 Cisco Systems 371 Email: paf@cisco.com 372 Olaf Kolkman 373 NLnet Labs 375 Email: olaf@NLnetLabs.nl 377 Full Copyright Statement 379 Copyright (C) The IETF Trust (2008). 381 This document is subject to the rights, licenses and restrictions 382 contained in BCP 78, and except as set forth therein, the authors 383 retain all their rights. 385 This document and the information contained herein are provided on an 386 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 387 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 388 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 389 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 390 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 391 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 393 Intellectual Property 395 The IETF takes no position regarding the validity or scope of any 396 Intellectual Property Rights or other rights that might be claimed to 397 pertain to the implementation or use of the technology described in 398 this document or the extent to which any license under such rights 399 might or might not be available; nor does it represent that it has 400 made any independent effort to identify any such rights. Information 401 on the procedures with respect to rights in RFC documents can be 402 found in BCP 78 and BCP 79. 404 Copies of IPR disclosures made to the IETF Secretariat and any 405 assurances of licenses to be made available, or the result of an 406 attempt made to obtain a general license or permission for the use of 407 such proprietary rights by implementers or users of this 408 specification can be obtained from the IETF on-line IPR repository at 409 http://www.ietf.org/ipr. 411 The IETF invites any interested party to bring to its attention any 412 copyrights, patents or patent applications, or other proprietary 413 rights that may cover technology that may be required to implement 414 this standard. Please address the information to the IETF at 415 ietf-ipr@ietf.org.