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