idnits 2.17.1 draft-ietf-urn-net-procedures-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '... scheme MUST be registered under the...' RFC 2119 keyword, line 127: '...cord for a URI scheme MUST NOT precede...' RFC 2119 keyword, line 143: '...RPA registration MAY accompany a reque...' RFC 2119 keyword, line 150: '... NAPTR record) MAY be submitted afte...' RFC 2119 keyword, line 161: '... record for a URN NID MUST NOT precede...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 237 has weird spacing: '...tration mecha...' -- 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 (October 28, 2001) is 8187 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) == Unused Reference: '3' is defined on line 351, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 359, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-urn-ddds-toc-00 ** Downref: Normative reference to an Informational draft: draft-ietf-urn-ddds-toc (ref. '1') == Outdated reference: A later version (-07) exists of draft-ietf-urn-ddds-05 == Outdated reference: A later version (-09) exists of draft-ietf-urn-dns-ddds-database-07 == Outdated reference: A later version (-07) exists of draft-ietf-urn-uri-res-ddds-05 == Outdated reference: A later version (-11) exists of draft-ietf-urn-net-procedures-09 ** Obsolete normative reference: RFC 2141 (ref. '6') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2048 (ref. '8') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 2611 (ref. '9') (Obsoleted by RFC 3406) ** Obsolete normative reference: RFC 2717 (ref. '10') (Obsoleted by RFC 4395) Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Mealling 3 Internet-Draft Verisign 4 Expires: April 28, 2002 October 28, 2001 6 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA 7 Assignment Procedures 8 draft-ietf-urn-net-procedures-09.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 28, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 RFCYYYY defines a how DNS is used as a DDDS database that contains 40 URI delegation rules (sometimes called resolution hints). That 41 document specifies that the first step in that algorithm is to append 42 'URI.ARPA' to the URI scheme and retrieve the NAPTR record for that 43 domain-name. I.e., the first step in resolving "http://foo.com/" 44 would be to look up a NAPTR record for the domain "http.URI.ARPA". 45 URN resolution also follows a similar procedure but uses the 46 'URN.ARPA' zone as its root. This document describes the procedures 47 for inserting a new rule into the 'URI.ARPA' and 'URN.ARPA' zones. 49 This document is fifth in a series that is completely specified in 50 "Dynamic Delegation Discovery System (DDDS) Part One: The 51 Comprehensive DDDS Standard" (RFC WWWW). It is very important to 52 note that it is impossible to read and understand any document in 53 this series without reading the others. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. URI Resolution vs URN Resolution . . . . . . . . . . . . . . 3 59 3. Registration Policies . . . . . . . . . . . . . . . . . . . 3 60 3.1 URI.ARPA Registration . . . . . . . . . . . . . . . . . . . 3 61 3.1.1 Only Schemes in the IETF Tree Allowed . . . . . . . . . . . 3 62 3.1.2 Scheme Registration Takes Precedence . . . . . . . . . . . . 3 63 3.1.3 NAPTR Registration May Accompany Scheme Registration . . . . 4 64 3.1.4 Registration or Changes after Scheme Registration . . . . . 4 65 3.2 URN.ARPA Registration . . . . . . . . . . . . . . . . . . . 4 66 3.2.1 NID Registration Takes Precedence . . . . . . . . . . . . . 4 67 3.2.2 NAPTR Registration May Accompany NID Registration . . . . . 4 68 3.2.3 Registration or Changes after Scheme Registration . . . . . 4 69 4. Requirements on hints . . . . . . . . . . . . . . . . . . . 5 70 5. Submission Procedure . . . . . . . . . . . . . . . . . . . . 6 71 6. Registration Template . . . . . . . . . . . . . . . . . . . 6 72 6.1 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 6.2 Authority . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 6.3 Records . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 7. Example Template . . . . . . . . . . . . . . . . . . . . . . 7 76 8. The URN Registration in the URI.ARPA zone . . . . . . . . . 7 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 78 10. Security Considerations . . . . . . . . . . . . . . . . . . 8 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 80 References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 82 Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 This document defines the policies and procedures for inserting NAPTR 87 records into the 'URI.ARPA' and 'URN.ARPA' zones for the purpose of 88 resolving URIs according to "Dynamic Delegation Discovery System 89 (DDDS) Part Four: The URI Resolution Application" (RFCXXXX) [2], 90 which is an Application that uses the DNS based DDDS Database. All 91 of these concepts are defined in RFC WWWW [1]. It is very important 92 to note that it is impossible to correctly understand this document 93 without reading RFC WWWW and the documents it specifies. 95 2. URI Resolution vs URN Resolution 97 RFCXXXX [2] defines how both URI [7] resolution and URN [6] 98 resolution work when DNS is used as the delegation rule (or hint) 99 database. Specifically it says that the initial instructions 100 ('hints') for DNS-based resolution of URIs are stored as resource 101 records in the 'URI.ARPA' DNS zone. 103 Since a URN is a URI scheme, a hint for resolution of the URI prefix 104 'urn:' will also be stored in the 'URI.ARPA' zone. This rule states 105 that the namespace id [6] is extracted, 'URN.ARPA' is appended to the 106 end of the namespace id, and the result is used as the key for 107 retrieval of a subsequent NAPTR record [4]. 109 3. Registration Policies 111 The creation of a given URI scheme or URN namespace id (NID) follows 112 the appropriate registration documents for those spaces. URI schemes 113 follow "Registration Procedures for URL Scheme Names" (RFC 2717) 114 [10]. URN namespace ids follow "URN Namespace Definition Mechanisms" 115 (RFC 2611) (or updates thereto) [9]. 117 3.1 URI.ARPA Registration 119 3.1.1 Only Schemes in the IETF Tree Allowed 121 In order to be inserted into the URI.ARPA zone, the subsequent URI 122 scheme MUST be registered under the IETF URI tree. The requirements 123 for this tree are specified in [10]. 125 3.1.2 Scheme Registration Takes Precedence 127 The registration of a NAPTR record for a URI scheme MUST NOT precede 128 proper registration of that scheme and publication of a stable 129 specification in accordance with [10]. The IESG or its designated 130 expert will review the request for 131 1. correctness and technical soundness 133 2. consistency with the published URI specification, and 135 3. to ensure that the NAPTR record for a DNS-based URI does not 136 delegate resolution of the URI to a party other than the holder 137 of the DNS name. This last rule is to insure that a given URI's 138 resolution hint doesn't hijack (inadvertently or otherwise) 139 network traffic for a given domain. 141 3.1.3 NAPTR Registration May Accompany Scheme Registration 143 A request for a URI.ARPA registration MAY accompany a request for a 144 URI scheme (in accordance with [10]), in which case both requests 145 will be reviewed simultaneously by IESG or its designated experts. 147 3.1.4 Registration or Changes after Scheme Registration 149 A request for a NAPTR record (or an request to change an existing 150 NAPTR record) MAY be submitted after the URI prefix has been 151 registered. If the specification for the URI prefix is controlled 152 by some other party than IETF, IESG will require approval from the 153 owner/maintainer of that specification before the registration will 154 be accepted. This is in addition to any technical review of the 155 NAPTR registration done by IESG or its designated experts. 157 3.2 URN.ARPA Registration 159 3.2.1 NID Registration Takes Precedence 161 The registration of a NAPTR record for a URN NID MUST NOT precede 162 proper registration of that NID and publication of a stable 163 specification in accordance with [9]. This is to prevent the 164 registration of a NAPTR record in URN.ARPA from circumventing the NID 165 registration process. 167 3.2.2 NAPTR Registration May Accompany NID Registration 169 A request for a URN.ARPA registration MAY accompany a request for a 170 NID (in accordance with [9]), in which case both requests will be 171 reviewed at the same time. 173 3.2.3 Registration or Changes after Scheme Registration 175 A request for a NAPTR record (or an request to change an existing 176 NAPTR record) MAY be submitted after the NID has been registered. 177 If the specification for the NID is controlled by some other party 178 than IETF, IESG will require approval from the owner/maintainer of 179 that specification before the registration will be accepted. This is 180 in addition to any technical review of the NAPTR registration done by 181 IESG or its designated experts. 183 Note that this applies to all NAPTR records for a particular NID, 184 even though a NAPTR record might affect only part of the URN space 185 assigned to an NID 187 4. Requirements on hints 189 Delegation of a namespace can happen in two ways. In the case of 190 most URIs, the key being delegated to is hard-coded into the 191 identifier itself (e.g. a hostname in an HTTP URL). The syntax of 192 where this new key is located is predetermined by the syntax of the 193 scheme. In other cases, the new key can be part of the hint itself. 194 This is the functional equivalent of saying, "if this rule matches 195 then this is always the key." 197 In order to minimize the query load on the URI.ARPA and URN.ARPA 198 zones, it is anticipated that the resource records in those zones 199 will have extremely long "times to live" (TTLs), perhaps measured in 200 years. 202 Thus, for any URI prefix or URN namespace for which the resolution 203 hints are likely to change, the actual rule should be stored in some 204 other (less stable) DNS zone, and within URI.ARPA or URN.ARPA a 205 stable NAPTR record should be used to delegate queries to that less 206 stable zone. 208 For example, the 'foo' URN namespace has flexible rules for how 209 delegation takes place. Instead of putting those rules in the 210 URN.ARPA zone, the entry instead punts those rules off to a 211 nameserver that has a shorter time to live. The record in URN.ARPA 212 would look like this: 214 foo IN NAPTR 100 10 "" "" "" urn-resolver.foo.com. 216 Thus, when the client starts out in the resolution process, the first 217 step will be to query foo.URN.ARPA to find the above record, the 218 second step is to begin asking 'urn-resolver.foo.com' for the NAPTR 219 records that contain the resolution rules. The TTL at the root is 220 very long. The TTL at the 'urn-resolver.foo.com' is much shorter. 222 Conversely, the 'http' URL scheme adheres to a particular syntax that 223 specifies that the host to ask is specified in the URL in question. 224 Since this syntax does not change, that rule can be specified in the 225 URI.ARPA zone. The record would look like this: 227 http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\2/i" . 229 Thus, the second step of resolution is to use the domain-name found 230 in the URL as the next key in the cycle. If, for example, that NAPTR 231 was terminal and contains some hostname in the replacement field, 232 then the client could contact that host in order to ask questions 233 about this particular URI. 235 5. Submission Procedure 237 Using the MIME Content-Type registration mechanism [8] as a model 238 for a successful registration mechanism, the 'URI.ARPA' and 239 'URN.ARPA' procedures consist of a request template submitted to an 240 open mailing list made up of interested parties. If no objections 241 are made within a two week period, a representative of the 242 registration authority considers the submission to be accepted and 243 enters that submission into the nameserver. 245 o Registrations for the 'URI.ARPA' zone are sent to 246 'register@URI.ARPA'. 248 o Registrations for the 'URN.ARPA' zone are sent to 249 'register@URN.ARPA'. 251 The registration authority is the Internet Assigned Numbers Authority 252 (IANA). 254 Objections are restricted to those that point out impacts on the zone 255 itself or to DNS in general. Objections to the URL scheme or to the 256 URN namespace-id are not allowed, as these should be raised in their 257 respective forums. The logical conclusion of this is that ANY 258 sanctioned URL scheme or URN namespace MUST be allowed to be 259 registered if it meets the requirements specified in this document as 260 regards times to live and general impact to the DNS. 262 6. Registration Template 264 The template to be sent to the appropriate list MUST contain the 265 following values: 267 6.1 Key 269 This is the URN NID or URL scheme, which is used as the domain 270 portion of the DNS entry. It must be valid according to the 271 procedures specified in the URN namespace-id assignment document and 272 any future standards for registering new URL schemes. 274 6.2 Authority 276 This is the individual or organization (entity) which has authority 277 for registering the record. It must be an authority recognized as 278 either the IESG or any authority defined in the URN NID [9] or URL 279 scheme registration [10] documents. 281 6.3 Records 283 The actual DNS records representing the rule set for the key. The 284 required values are Preference, Order, Flags, Services, Regex, and 285 Replacement as defined by RFCYYYY [4]. 287 7. Example Template 289 To: register@URN.ARPA 290 From: joe@foo.com 292 Key: foo 293 Authority: Foo Technology, Inc as specified in RFCFOO 294 Record: foo IN NAPTR 100 100 "" "" "" urn.foo.com. 296 8. The URN Registration in the URI.ARPA zone 298 Since this document discusses the URI.ARPA and URN.ARPA zones and the 299 URN rule that exists in the URI.ARPA zone, it makes sense for the 300 registration template for the URN URI rule to be specified here: 302 To: register@URI.ARPA 303 From: The IETF URN Working Group 305 Key: urn 306 Authority: RFC2141 307 Record: urn IN NAPTR 0 0 "" "" "/urn:([^:]+)/\\2/i" . 309 9. IANA Considerations 311 This memo requests that the IANA create the zones URN.ARPA and 312 URI.ARPA. The hierarchical name structure, and the only names to be 313 assigned within these zones, are the "keys" as described in Section 314 6.1 of this document. The administrative and operational management 315 of these zones are recommended to be undertaken by the IANA. The DNS 316 records to be inserted in these zones are subject to the review 317 process described in this document. 319 This memo also requires the creation of 2 discussion lists, 320 register@uri.arpa and register@urn.arpa, for the purposes described 321 in this document. It is recommended that IANA create and manage 322 these mailing lists." 324 10. Security Considerations 326 The 'uri.arpa' and 'urn.arpa' zones will be a common point of attack 327 both for Denial of Service and for spoofing entries in order to 328 redirect delegation paths. Any entity running nameservers that 329 contain these zones should take appropriate action for securing an 330 infrastructure level component of the Internet. When it becomes 331 possible for a nameserver to reliably sign the records in its zone it 332 should do so. 334 11. Acknowledgements 336 The author would like to thank Ron Daniel who was originally co- 337 author of these documents. Ron's original insite into the intricate 338 nature of delegation rules made these procedures and the DDDS itself 339 possible. 341 References 343 [1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 344 One: The Comprehensive DDDS Standard", RFC WWWW, draft-ietf- 345 urn-ddds-toc-00.txt (work in progress), October 2001. 347 [2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 348 Two: The Algorithm", RFC XXXX, draft-ietf-urn-ddds-05.txt (work 349 in progress), May 2000. 351 [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 352 Three: The DNS Database", RFC ZZZZ, draft-ietf-urn-dns-ddds- 353 database-07.txt (work in progress), May 2000. 355 [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 356 Four: The URI Resolution Application", RFC YYYY, draft-ietf- 357 urn-uri-res-ddds-05.txt (work in progress), October 2000. 359 [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part 360 Five: URI.ARPA Assignment Procedures", RFC VVVV, draft-ietf- 361 urn-net-procedures-09.txt (work in progress), October 2001. 363 [6] Moats, R., "URN Syntax", RFC 2141, November 1998. 365 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 366 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 367 1998. 369 [8] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 370 Mail Extensions (MIME) Part Four: Registration Procedures", RFC 371 2048, November 1996. 373 [9] Faltstrom, P., Iannella, R., Daigle, L. and D. van Gulik, "URN 374 Namespace Definition Mechanisms", RFC 2611, October 1998. 376 [10] Petke, R. and I. King, "Registration Procedures for URL Scheme 377 Names", RFC 2717, January 1999. 379 Author's Address 381 Michael Mealling 382 Verisign 383 505 Huntmar Park Drive 384 Herndon, VA 22070 385 US 387 Phone: (770) 721-2251 388 EMail: michael@research.netsol.com 390 Full Copyright Statement 392 Copyright (C) The Internet Society (2001). All Rights Reserved. 394 This document and translations of it may be copied and furnished to 395 others, and derivative works that comment on or otherwise explain it 396 or assist in its implementation may be prepared, copied, published 397 and distributed, in whole or in part, without restriction of any 398 kind, provided that the above copyright notice and this paragraph are 399 included on all such copies and derivative works. However, this 400 document itself may not be modified in any way, such as by removing 401 the copyright notice or references to the Internet Society or other 402 Internet organizations, except as needed for the purpose of 403 developing Internet standards in which case the procedures for 404 copyrights defined in the Internet Standards process must be 405 followed, or as required to translate it into languages other than 406 English. 408 The limited permissions granted above are perpetual and will not be 409 revoked by the Internet Society or its successors or assigns. 411 This document and the information contained herein is provided on an 412 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 413 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 414 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 415 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 416 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 418 Acknowledgement 420 Funding for the RFC Editor function is currently provided by the 421 Internet Society.