idnits 2.17.1 draft-ietf-urn-uri-res-ddds-00.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 are 22 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([8], [9], [10], [12]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 17 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The abstract seems to indicate that this document obsoletes RFC2168, but the header doesn't have an 'Obsoletes:' line to match this. -- The abstract seems to indicate that this document updates RFC2276, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 74 has weird spacing: '..., their britt...' == Line 412 has weird spacing: '...service reg...' == Line 450 has weird spacing: '... order pref...' == Line 464 has weird spacing: '...f flags serv...' == Line 475 has weird spacing: '...cedures for U...' -- 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 (July 14, 2000) is 8686 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: '0' is mentioned on line 649, but not defined == Unused Reference: '2' is defined on line 568, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 597, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1737 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2141 (ref. '3') (Obsoleted by RFC 8141) ** Downref: Normative reference to an Historic RFC: RFC 2169 (ref. '5') ** Downref: Normative reference to an Experimental RFC: RFC 2483 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 2276 (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' == Outdated reference: A later version (-09) exists of draft-ietf-urn-dns-ddds-database-00 -- No information found for draft-ietf-uri - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2168 (ref. '12') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2396 (ref. '13') (Obsoleted by RFC 3986) Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M.M. Mealling 2 Internet-Draft Network Solutions, Inc. 3 Expires: January 12, 2001 July 14, 2000 5 URI Resolution using the Dynamic Delegation Discovery System 6 draft-ietf-urn-uri-res-ddds-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on January 12, 2001. 31 Copyright Notice 33 Copyright (C) The Internet Society (2000). All Rights Reserved. 35 Abstract 37 A specification for taking a URI and locating an authoritative 38 server for information about that URI. The method used to locate 39 that authoritative server is the Dynamic Delegation Discovery 40 System. 42 This document, along with [10] and [9], obsoletes RFC 2168[12] and 43 updates RFC 2276[8]. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. The Distinction between URNs and URLs . . . . . . . . . . . 5 50 4. The URI and URN Resolution Application Specifications . . . 6 51 4.1 Application Unique String . . . . . . . . . . . . . . . . . 6 52 4.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 6 53 4.3 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4.4 Services Parameters . . . . . . . . . . . . . . . . . . . . 7 55 4.4.1 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 4.4.2 protocols . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.5 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 8 58 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5.1 An example using a URN . . . . . . . . . . . . . . . . . . . 9 60 5.2 CID URI Scheme Example . . . . . . . . . . . . . . . . . . . 10 61 5.3 Resolving an HTTP URI Scheme . . . . . . . . . . . . . . . . 12 62 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 64 8. Security Considerations . . . . . . . . . . . . . . . . . . 16 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 66 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . 19 68 A. Pseudo Code . . . . . . . . . . . . . . . . . . . . . . . . 20 69 Full Copyright Statement . . . . . . . . . . . . . . . . . . 23 71 1. Introduction 73 Uniform Resource Locators have been a significant advance in 74 retrieving Internet-accessible resources. However, their brittle 75 nature over time has been recognized for several years. The Uniform 76 Resource Identifier working group proposed the development of 77 Uniform Resource Names[3] to serve as persistent, 78 location-independent identifiers for Internet resources in order to 79 overcome most of the problems with URLs. RFC 1737[1] sets forth 80 requirements on URNs. 82 During the lifetime of the URI-WG, a number of URN proposals were 83 generated. The developers of several of those proposals met in a 84 series of meetings, resulting in a compromise known as the Knoxville 85 framework. The major principle behind the Knoxville framework is 86 that the resolution system must be separate from the way names are 87 assigned. This is in marked contrast to most URLs, which identify 88 the host to contact and the protocol to use. Readers are referred to 89 [2]for background on the Knoxville framework and for additional 90 information on the context and purpose of this proposal. 92 Separating the way names are resolved from the way they are 93 constructed provides several benefits. It allows multiple naming 94 approaches and resolution approaches to compete, as it allows 95 different protocols and resolvers to be used. There is just one 96 problem with such a separation - how do we resolve a name when it 97 can't give us directions to its resolver? 99 For the short term, DNS is the obvious candidate for the resolution 100 framework, since it is widely deployed and understood. However, it 101 is not appropriate to use DNS to maintain information on a 102 per-resource basis. First of all, DNS was never intended to handle 103 that many records. Second, the limited record size is inappropriate 104 for catalog information. Third, domain names are not appropriate as 105 URNs. 107 Therefore our approach is to use the DDDS to locate "resolvers" that 108 can provide information on individual resources, potentially 109 including the resource itself. To accomplish this, we "rewrite" the 110 URI into a Key following the rules found in the Dynamic Delegation 111 Discovery System (DDDS). This document describes URI Resolution as 112 an application of the DDDS and specifies the use of at least one 113 Database based on DNS. 115 This document, along with [10] and [9], obsoletes RFC 2168[12] and 116 updates RFC 2276[8]. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 122 this document are to be interpreted as described in RFC 2119. 124 All capitalized terms are taken from the vocabulary found in the 125 DDDS algorithm specification found in [9]. 127 3. The Distinction between URNs and URLs 129 From the point of view of this system, there is no theoretical 130 difference between resolving URIs in the general case and URNs in 131 the specific case. Operationally however, there is a difference that 132 stems from URI resolution possibly not becoming of widespread use. 133 If URN resolution is collapsed into generic URI resolution, URNs may 134 suffer by the lack of adoption of URI resolution. 136 The solution is to allow for shortcutting for URN resolution. In the 137 following specification generic URI resolution starts by inserting 138 rules for known URI schemes into the 'uri.arpa' registry. For the 139 'URN:' URI scheme, one of the rules found in 'uri.arpa' would be for 140 the 'urn' URI scheme. This rule would simply delegate to the 141 'urn.arpa' zone for additional NAPTRs based on the URN namespace. 142 Essentially, the URI Resolution Rewrite Rule for 'URN:' is the URN 143 Resolution Application's First Well Known Rule. 145 Therefore, this document specifies two DDDS Applications. One is for 146 URI Resolution and the other is for URN Resolution. Both are 147 technically identical but by separating the two URN Resolution can 148 still proceed without the dependency. 150 4. The URI and URN Resolution Application Specifications 152 4.1 Application Unique String 154 The Application Unique String is the Uniform Resource Identifier or 155 Uniform Resource Name for which an authoritative server is being 156 located. This URI or URN MUST be canonicalized and hex encoded 157 according to the "absolute-uri" production found in the Collected 158 ABNF from RFC 2396[13]. 160 4.2 First Well Known Rule 162 In the URI case, the first known key is created by taking the URI 163 scheme. In the URN case, the first known key is the Namespace 164 Identifier. For example, the URI 'http://www.foo.com/' would have a 165 'http' as its Key. The URN 'urn:foo:foospace' would have 'foo' as 166 its first Key. 168 4.3 Flags 170 At this time only four flags, "S", "A", "U", and "P", are defined. 171 The "S", "A" and "U" flags are for a terminal lookup. This means 172 that the Rule is the last one and that the flag determines what the 173 next stage should be. The "S" flag means that the output of this 174 Rule is a domain-name for which one or more SRV[4] records exist. 175 See Section 5 for additional information on how URI and URN 176 Resolution use the SRV record type. "A" means that the output of the 177 Rule is a domain-name and should be used to lookup A records for 178 that domain. The "U" flag means that the output of the Rule is a 179 URL[13]. 181 The "P" flag says that the remainder of the DDDS Algorithm is 182 ignored and that the rest of the process is application specific and 183 outside the scope of this document. An application can use the 184 Protocol part found in the Services field to identify which 185 Application specific set of rules that should be followed next. The 186 record that contains the 'P' flag is the last record that is 187 interpreted by the rules in this document. 189 The remaining alphabetic flags are reserved for future versions of 190 this specification. The numeric flags may be used for local 191 experimentation. The S, A, U and P flags are all mutually exclusive, 192 and resolution libraries MAY signal an error if more than one is 193 given. (Experimental code and code for assisting in the creation of 194 Rewrite Rules would be more likely to signal such an error than a 195 client such as a browser). It is anticipated that multiple flags 196 will be allowed in the future, so implementers MUST NOT assume that 197 the flags field can only contain 0 or 1 characters. Finally, if a 198 client encounters a record with an unknown flag, it MUST ignore it 199 and move to the next Rule. This test takes precedence over any 200 ordering since flags can control the interpretation placed on 201 fields. A novel flag might change the interpretation of the regexp 202 and/or replacement fields such that it is impossible to determine if 203 a record matched a given target. 205 The "S", "A", and "U" flags are called 'terminal' flags since they 206 halt the looping rewrite algorithm. If those flags are not present, 207 clients may assume that another Rule exists at the Key produced by 208 the current Rewrite Rule. 210 4.4 Services Parameters 212 Service Parameters for this Application take the form of a string of 213 characters that follow this ABNF: 215 service_field = [ [protocol] *("+" rs)] 216 protocol = ALPHA *31ALPHANUM 217 rs = ALPHA *31ALPHANUM 218 ; The protocol and rs fields are limited to 32 219 ; characters and must start with an alphabetic. 221 In other words, an optional protocol specification followed by 0 or 222 more resolution services. Each resolution service is indicated by an 223 initial '+' character. 225 The empty string is also valid. This will typically be seen at the 226 beginning of a series of Rules, when it is impossible to know what 227 services and protocols will be offered at the end of a particular 228 delegation path. 230 4.4.1 Services 232 The service identifiers that make up the 'rs' production are generic 233 for both URI and URN resolution since the input value types itself 234 based on the URI scheme. The list of valid services are defined in 235 [6]. 237 Examples of some of these services are: 239 I2L: given a URI return one URL that identifies a location where the 240 original URI can be found 242 I2Ls: given a URI return one or more URLs that identify multiple 243 locations where the original URI can be found 245 I2R: given a URI return one instance of the resource identified by 246 that URI. 248 I2Rs: given a URI return one or more instances of the resources 249 identified by that URI. 251 I2C: given a URI return one instance of a description of that 252 resource. 254 I2N: given a URI return one URN that names the resource (Caution: 255 equality with respect to URNs is non-trivial. See [1]for examples 256 of why.) 258 4.4.2 protocols 260 The protocol identifiers that are valid for the 'protocol' 261 production are defined by the protocol specifications themselves. At 262 present the THTTP[5] protocol is the only such specification. Simply 263 specifying any protocol in the services field is insufficient since 264 there are additional semantics surrounding URI resolution that are 265 not defined within the protocols. 267 For example, if Z39.50 were to be specified as a valid protocol it 268 would have to define how it would encode requests for specific 269 services, how the URI is encoded, and what information is returned. 271 4.5 Valid Databases 273 At present only one DDDS Database is specified for this Application. 274 "A DDDS Database Using The Domain Name System"[10] specifies a DDDS 275 Database that uses the NAPTR DNS resource record to contain the 276 rewrite rules. The Keys for this database are encoded as 277 domain-names. 279 The output of the First Well Known Rule for the URI Resolution 280 Application is the URI's scheme. In order to convert this to a 281 unique key in this Database the string 'uri.arpa.' is appended to 282 the end. This domain-name is used to request NAPTR records which 283 produces new keys in the form of domain-names. 285 The output of the First Well Known Rule of the URN Resolution 286 Application is the URN's namespace id. In order to convert this to a 287 unique key in this Database the string 'urn.arpa.' is appended to 288 the end. This domain-name is used to request NAPTR records which 289 produces new keys in the form of domain-names. 291 DNS servers MAY interpret Flag values and use that information to 292 include appropriate SRV and A records in the Additional Information 293 portion of the DNS packet. Clients are encouraged to check for 294 additional information but are not required to do so. 296 5. Examples 298 5.1 An example using a URN 300 Consider a URN that uses the hypothetical DUNS namespace. DUNS 301 numbers are identifiers for approximately 30 million registered 302 businesses around the world, assigned and maintained by Dunn and 303 Bradstreet. The URN might look like: 305 urn:duns:002372413:annual-report-1997 307 The first step in the resolution process is to find out about the 308 DUNS namespace. The namespace identifier[3], "duns", is extracted 309 from the URN and prepended to 'urn.arpa', producing 'duns.urn.arpa'. 310 The DNS is queried for NAPTR records for this domain which produces 311 the following results: 313 duns.urn.arpa. 314 ;; order pref flags service regexp replacement 315 IN NAPTR 100 10 "s" "dunslink+I2L+I2C" "" dunslink.udp.dandb.com. 316 IN NAPTR 100 20 "s" "rcds+I2C" "" rcds.udp.dandb.com. 317 IN NAPTR 100 30 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.dandb.com. 319 The order field contains equal values, indicating that no order has 320 to be followed. The preference field indicates that the provider 321 would like clients to use the special 'dunslink' protocol, followed 322 by the RCDS protocol, and that THTTP is offered as a last resort. 323 All the records specify the "s" flag which means that the record is 324 terminal and that the next step is to retrieve an SRV record from 325 DNS for the given domain-name. 327 The service fields say that if we speak dunslink, we will be able to 328 issue either the I2L or I2C requests to obtain a URL or ask some 329 complicated questions about the resource. The Resource Cataloging 330 and Distribution Service (RCDS)[7] could be used to get some 331 metadata for the resource, while THTTP could be used to get a URL 332 for the current location of the resource. 334 Assuming our client does not know the dunslink protocol but does 335 know the RCDS protocol, our next action is to lookup SRV RRs for 336 rcds.udp.dandb.com, which will tell us hosts that can provide the 337 necessary resolution service. That lookup might return: 339 ;; Pref Weight Port Target 340 rcds.udp.dandb.com IN SRV 0 0 1000 defduns.dandb.com. 341 IN SRV 0 0 1000 dbmirror.com.au. 342 IN SRV 0 0 1000 ukmirror.com.uk. 344 telling us three hosts that could actually do the resolution, and 345 giving us the port we should use to talk to their RCDS server. (The 346 reader is referred to the SRV specification[4] for the 347 interpretation of the fields above). 349 There is opportunity for significant optimization here. We can 350 return the SRV records as additional information for terminal NAPTRs 351 (and the A records as additional information for those SRVs). While 352 this recursive provision of additional information is not explicitly 353 blessed in the DNS specifications, it is not forbidden, and BIND 354 does take advantage of it. This is a significant optimization. In 355 conjunction with a long TTL for *.urn.arpa records, the average 356 number of probes to DNS for resolving DUNS URNs would approach one. 357 Therefore, DNS server implementors SHOULD provide additional 358 information with NAPTR responses. The additional information will be 359 either SRV or A records. If SRV records are available, their A 360 records should be provided as recursive additional information. 362 Note that the example NAPTR records above are intended to represent 363 the reply the client will see. They are not quite identical to what 364 the domain administrator would put into the zone files. 366 Also note that there could have been an additional first step where 367 the URN was resolved as a generic URI by looking up urn.uri.arpa. 368 The resulting rule would have specified that the NID be extracted 369 from the URN and 'urn.arpa' appended to it resulting in the new key 370 'duns.urn.arpa' which is the first step from above. 372 5.2 CID URI Scheme Example 374 Consider a URI scheme based on MIME Content-Ids. The URI might look 375 like this: 377 cid:199606121851.1@mordred.gatech.edu 379 (Note that this example is chosen for pedagogical purposes, and 380 does not conform to the CID URL scheme.) 382 The first step in the resolution process is to find out about the 383 CID scheme. The schem is extracted from the URI, prepended to 384 'uri.arpa', and the NAPTR for 'cid.uri.arpa' looked up in the DNS. 386 It might return records of the form: 388 cid.uri.arpa. 389 ;; order pref flags service regexp replacement 390 IN NAPTR 100 10 "" "" "!cid:.+@([^\.]+\.)(.*)$!\2!i" . 392 We have only one NAPTR response, so ordering the responses is not a 393 problem. The replacement field is empty, so we check the regexp 394 field and use the pattern provided there. We apply that regexp to 395 the entire URI to see if it matches, which it does. The \2 part of 396 the substitution expression returns the string "gatech.edu". Since 397 the flags field does not contain "s" or "a", the lookup is not 398 terminal and our next probe to DNS is for more NAPTR records at the 399 domain-name 'gatech.edu'. 401 Note that the rule does not extract the full domain name from the 402 CID, instead it assumes the CID comes from a host and extracts its 403 domain. While all hosts, such as 'mordred', could have their very 404 own NAPTR, maintaining those records for all the machines at a site 405 that large would be an intolerable burden. Wildcards are not 406 appropriate here since they only return results when there is no 407 exactly matching names already in the system. 409 The record returned from the query on "gatech.edu" might look like: 411 gatech.edu. 412 ;; order pref flags service regexp replacement 413 IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" z3950.tcp.gatech.edu. 414 IN NAPTR 100 50 "s" "rcds+I2C" "" rcds.udp.gatech.edu. 415 IN NAPTR 100 50 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.gatech.edu. 417 Continuing with our example, we note that the values of the order 418 and preference fields are equal in all records, so the client is 419 free to pick any record. The flags field tells us that these are the 420 last NAPTR patterns we should see, and after the rewrite (a simple 421 replacement in this case) we should look up SRV records to get 422 information on the hosts that can provide the necessary service. 424 Assuming we prefer the Z39.50 protocol, our lookup might return: 426 ;; Pref Weight Port Target 427 z3950.tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu. 428 IN SRV 0 0 1000 z3950.cc.gatech.edu. 429 IN SRV 0 0 1000 z3950.uga.edu. 431 telling us three hosts that could actually do the resolution, and 432 giving us the port we should use to talk to their Z39.50 server. 434 5.3 Resolving an HTTP URI Scheme 436 Even if URN systems were in place now, there would still be a 437 tremendous number of URLs. It should be possible to develop a URI 438 resolution system that can also provide location independence for 439 those URLs. 441 Assume we have the URL for a very popular piece of software that the 442 publisher wishes to mirror at multiple sites around the world: 444 http://www.foo.com/software/latest-beta.exe 446 We extract the prefix, "http", and lookup NAPTR records for 447 'http.uri.arpa'. This might return a record of the form: 449 http.uri.arpa. IN NAPTR 450 ;; order pref flags service regexp replacement 451 100 90 "" "" "!http://([^/:]+)!\1!i" . 453 This expression returns everything after the first double slash and 454 before the next slash or colon. (We use the '!' character to delimit 455 the parts of the substitution expression. Otherwise we would have to 456 use backslashes to escape the forward slashes, and would have a 457 regexp in the zone file that looked like this: 458 "/http:\\/\\/([^\\/:]+)/\\1/i"). 460 Applying this pattern to the URL extracts "www.foo.com". Looking up 461 NAPTR records for that might return: 463 www.foo.com. 464 ;; order pref flags service regexp replacement 465 IN NAPTR 100 100 "s" "thttp+L2R" "" thttp._tcp.foo.com. 466 IN NAPTR 100 100 "s" "ftp+L2R" "" ftp._tcp.foo.com. 468 Looking up SRV records for thttp.tcp.foo.com would return 469 information on the hosts that foo.com has designated to be its 470 mirror sites. The client can then pick one for the user. 472 6. Notes 474 o Registration procedures for the 'urn.arpa' and 'uri.arpa' DNS 475 zones are specified in "Assignment Procedures for URI Resolution 476 using DNS"[11]. 478 o If a record at a particular order matches the URI, but the client 479 doesn't know the specified protocol and service, the client 480 SHOULD continue to examine records that have the same order. The 481 client MUST NOT consider records with a higher value of order. 482 This is necessary to make delegation of portions of the namespace 483 work. The order field is what lets site administrators say "all 484 requests for URIs matching pattern x go to server 1, all others 485 go to server 2". A match is defined as: 487 1. The NAPTR provides a replacement domain name 489 2. or the regular expression matches the URI 491 o When multiple RRs have the same "order", the client should use 492 the value of the preference field to select the next NAPTR to 493 consider. However, because of preferred protocols or services, 494 estimates of network distance and bandwidth, etc. clients may use 495 different criteria to sort the records. 497 o If the lookup after a rewrite fails, clients are strongly 498 encouraged to report a failure, rather than backing up to pursue 499 other rewrite paths. 501 o When a namespace is to be delegated among a set of resolvers, 502 regexps must be used. Each regexp appears in a separate NAPTR RR. 503 Administrators should do as little delegation as possible, 504 because of limitations on the size of DNS responses. 506 o Note that SRV RRs impose additional requirements on clients. 508 7. IANA Considerations 510 The use of the "urn.arpa" and "uri.arpa" zones requires registration 511 policies and procedures to be followed and for the operation of 512 those DNS zones to be maintained. These policies and procedures are 513 spelled out in a "Assignment Procedures for the URI Resolution using 514 DNS"[11]. The operation of those zones imposes operational and 515 administrative responsibilities on the IANA. 517 The registration methods used for specifying values for the Services 518 (both protocols and services) and Flags fields that are specific to 519 URI resolution is for a specification to be published as an RFC and 520 approved by the IESG. 522 The registration policies for URLs and URNs are also specified 523 elsewhere and thus those impacts on the IANA are spelled out there. 525 8. Security Considerations 527 The use of "urn.arpa" and "uri.arpa" as the registry for namespaces 528 is subject to denial of service attacks, as well as other DNS 529 spoofing attacks. The interactions with DNSSEC are currently being 530 studied. It is expected that NAPTR records will be signed with SIG 531 records once the DNSSEC work is deployed. 533 The rewrite rules make identifiers from other namespaces subject to 534 the same attacks as normal domain names. Since they have not been 535 easily resolvable before, this may or may not be considered a 536 problem. 538 Regular expressions should be checked for sanity, not blindly passed 539 to something like PERL. 541 This document has discussed a way of locating a resolver, but has 542 not discussed any detail of how the communication with the resolver 543 takes place. There are significant security considerations attached 544 to the communication with a resolver. Those considerations are 545 outside the scope of this document, and must be addressed by the 546 specifications for particular resolver communication protocols. 548 9. Acknowledgments 550 The editors would like to thank Keith Moore for all his 551 consultations during the development of this draft. We would also 552 like to thank Paul Vixie for his assistance in debugging our 553 implementation, and his answers on our questions. Finally, we would 554 like to acknowledge our enormous intellectual debt to the 555 participants in the Knoxville series of meetings, as well as to the 556 participants in the URI and URN working groups. 558 Specific recognition is given to Ron Daniel who was co-author on the 559 original versions of these documents. His early implementations and 560 clarity of thinking was invaluable in clearing up many of the 561 potential boundary cases. 563 References 565 [1] Sollins, K. and L. Masinter, "Functional Requirements for 566 Uniform Resource Names", RFC 1737, December 1994. 568 [2] Arms, B., "The URN Implementors, Uniform Resource Names: A 569 Progress Report", D-Lib Magazine, February 1996. 571 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 573 [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 574 specifying the location of services (DNS SRV)", RFC 2782, 575 February 2000. 577 [5] Danie1, R., "A Trivial Convention for using HTTP in URN 578 Resolution", RFC 2169, June 1997. 580 [6] Mealling, M., "URI Resolution Services Necessary for URN 581 Resolution", RFC 2483, January 1999. 583 [7] Moore, K., Browne, S., Cox, J. and J. Gettler, "Resource 584 Cataloging and Distribution System", Technical Report 585 CS-97-346, December 1996. 587 [8] Sollins, K., "Architectural Principles of Uniform Resource Name 588 Resolution", RFC 2276, January 1998. 590 [9] Mealling, M.M., "Dynamic Delegation Discovery System (DDDS)", , 591 May 2000. 593 [10] Mealling, M.M., "A DDDS Database Using The Domain Name 594 System", Internet-Draft 595 draft-ietf-urn-dns-ddds-database-00.txt, May 2000. 597 [11] Mealling, M., "Assignment Procedures for DDDS Rules in 598 URI.ARPA and URN.ARPA", Internet-Draft 599 draft-ietf-uri.arpa-procedures-03.txt, February 2000. 601 [12] Danie1, R. and M. Mealling, "Resolution of Uniform Resource 602 Identifiers using the Domain Name System", RFC 2168, June 1997. 604 [13] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform 605 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 606 1998. 608 Author's Address 610 Michael Mealling 611 Network Solutions, Inc. 612 505 Huntmar Park Drive 613 Herndon, VA 22070 614 US 616 Phone: +1 770 935 5492 617 EMail: michaelm@netsol.com 618 URI: http://www.netsol.com 620 Appendix A. Pseudo Code 622 For the edification of implementers, pseudocode for a client routine 623 using NAPTRs is given below. This code is provided merely as a 624 convenience, it does not have any weight as a standard way to 625 process NAPTR records. Also, as is the case with pseudocode, it has 626 never been executed and may contain logical errors. You have been 627 warned. 629 // 630 // findResolver(URN) 631 // Given a URN, find a host that can resolve it. 632 // 633 findResolver(string URN) { 634 // prepend prefix to urn.arpa 635 sprintf(key, "%s.urn.arpa", extractNS(URN)); 636 do { 637 rewrite_flag = false; 638 terminal = false; 639 if (key has been seen) { 640 quit with a loop detected error 641 } 642 add key to list of "seens" 643 records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' 645 discard any records with an unknown value in the "flags" field. 646 sort NAPTR records by "order" field and "preference" field 647 (with "order" being more significant than "preference"). 648 n_naptrs = number of NAPTR records in response. 649 curr_order = records[0].order; 650 max_order = records[n_naptrs-1].order; 652 // Process current batch of NAPTRs according to "order" field. 653 for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { 654 if (unknown_flag) // skip this record and go to next one 655 continue; 656 newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); 657 if (!newkey) // Skip to next record if the rewrite didn't 658 match continue; 659 // We did do a rewrite, shrink max_order to current value 660 // so that delegation works properly 661 max_order = naptr[j].order; 662 // Will we know what to do with the protocol and services 663 // specified in the NAPTR? If not, try next record. 664 if(!isKnownProto(naptr[j].services)) { 665 continue; 666 } 667 if(!isKnownService(naptr[j].services)) { 668 continue; 669 } 671 // At this point we have a successful rewrite and we will 672 // know how to speak the protocol and request a known 673 // resolution service. Before we do the next lookup, check 674 // some optimization possibilities. 675 if (strcasecmp(flags, "S") 676 || strcasecmp(flags, "P")) 677 || strcasecmp(flags, "A")) { 678 terminal = true; 679 services = naptr[j].services; 680 addnl = any SRV and/or A records returned as additional 681 info for naptr[j]. 682 } 683 key = newkey; 684 rewriteflag = true; 685 break; 686 } 687 } while (rewriteflag && !terminal); 689 // Did we not find our way to a resolver? 690 if (!rewrite_flag) { 691 report an error 692 return NULL; 693 } 695 // Leave rest to another protocol? 696 if (strcasecmp(flags, "P")) { 697 return key as host to talk to; 698 } 700 // If not, keep plugging 701 if (!addnl) { // No SRVs came in as additional info, look them up 702 srvs = lookup(type=SRV, key); 703 } 705 sort SRV records by preference, weight, ... 706 foreach (SRV record) { // in order of preference 707 try contacting srv[j].target using the protocol and one of the 708 resolution service requests from the "services" field of the 709 last NAPTR record. 710 if (successful) 711 return (target, protocol, service); 712 // Actually we would probably return a result, but this 713 // code was supposed to just tell us a good host to talk to. 714 } 715 die with an "unable to find a host" error; 717 } 719 Full Copyright Statement 721 Copyright (C) The Internet Society (2000). All Rights Reserved. 723 This document and translations of it may be copied and furnished to 724 others, and derivative works that comment on or otherwise explain it 725 or assist in its implmentation may be prepared, copied, published 726 and distributed, in whole or in part, without restriction of any 727 kind, provided that the above copyright notice and this paragraph 728 are included on all such copies and derivative works. However, this 729 document itself may not be modified in any way, such as by removing 730 the copyright notice or references to the Internet Society or other 731 Internet organizations, except as needed for the purpose of 732 developing Internet standards in which case the procedures for 733 copyrights defined in the Internet Standards process must be 734 followed, or as required to translate it into languages other than 735 English. 737 The limited permissions granted above are perpetual and will not be 738 revoked by the Internet Society or its successors or assigns. 740 This document and the information contained herein is provided on an 741 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 742 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 743 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 744 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 745 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 747 Acknowledgement 749 Funding for the RFC editor function is currently provided by the 750 Internet Society.