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