idnits 2.17.1 draft-ietf-urn-naptr-rr-04.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 == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 6) being 60 lines 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 15 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 11 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 322 has weird spacing: '...im-char ere ...' == Line 511 has weird spacing: '... regexp repla...' == Line 563 has weird spacing: '... order pref...' == Line 577 has weird spacing: '...f flags serv...' -- 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 (August 3, 2000) is 8638 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) -- Looks like a reference, but probably isn't: 'A-Z0-9' on line 271 == Unused Reference: '2' is defined on line 747, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 762, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '3') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2234 (ref. '5') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Historic RFC: RFC 2169 (ref. '6') ** Obsolete normative reference: RFC 2168 (ref. '7') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2396 (ref. '9') (Obsoleted by RFC 3986) Summary: 8 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Mealling 2 Internet-Draft Network Solutions, Inc. 3 Expires: February 1, 2001 R.D. Daniel 4 DATAFUSION, Inc. 5 August 3, 2000 7 The Naming Authority Pointer (NAPTR) DNS Resource Record 8 draft-ietf-urn-naptr-rr-04 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on February 1, 2001. 33 Copyright Notice 35 Copyright (C) The Internet Society (2000). All Rights Reserved. 37 Abstract 39 This document describes a DNS resource record which specifies a 40 regular expression based rewrite rule that, when applied to an 41 existing string, will produce a new domain label or URI. Depending 42 on the value of the flags field of the resource record, the 43 resulting domain label or URI may be used in subsequent queries for 44 NAPTR resource records (to delegate the name lookup) or as the 45 output of the entire process for which this system is used (a 46 resolution server for URI resolution, a service URI for ENUM style 47 e.164 number to URI mapping, etc). 49 This allows the DNS to be used to lookup services for a wide variety 50 of resource names (inculding URIs) which are not in domain name 51 syntax. Reasons for doing this range from URN Resource Discovery 52 Systems to moving out-of-date services to new domains. 54 This document updates the portions of RFC2168 specifically dealing 55 with the definition of the NAPTR records and how other, non-URI 56 specific applications, might use NAPTR. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Substitution Expression Grammar . . . . . . . . . . . . . . . 9 63 4. The Basic NAPTR Algorithm . . . . . . . . . . . . . . . . . . 11 64 5. Concerning How NAPTR Uses SRV Records . . . . . . . . . . . . 12 65 6. Application Specifications . . . . . . . . . . . . . . . . . . 13 66 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 7.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 8. DNS Packet Format . . . . . . . . . . . . . . . . . . . . . . 18 71 9. Master File Format . . . . . . . . . . . . . . . . . . . . . . 19 72 10. Advice for DNS Administrators . . . . . . . . . . . . . . . . 20 73 11. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 74 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 75 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 76 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 77 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 79 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 27 81 1. Introduction 83 This RR was originally produced by the URN Working Group[3] as a way 84 to encode rule-sets in DNS so that the delegated sections of a URI 85 could be decomposed in such a way that they could be changed and 86 re-delegated over time. The result was a Resource Record that 87 included a regular expression that would be used by a client program 88 to rewrite a string into a domain name. Regular expressions were 89 chosen for their compactness to expressivity ratio allowing for a 90 great deal of information to be encoded in a rather small DNS 91 packet. 93 The function of rewriting a string according to the rules in a 94 record has usefulness in several different applications. This 95 document defines the basic assumptions to which all of those 96 applications must adhere to. It does not define the reasons the 97 rewrite is used, what the expected outcomes are, or what they are 98 used for. Those are specified by applications that define how they 99 use the NAPTR record and algorithms within their contexts. 101 Flags and other fields are also specified in the RR to control the 102 rewrite procedure in various ways or to provide information on how 103 to communicate with the host at the domain name that was the result 104 of the rewrite. 106 The final result is a RR that has several fields that interact in a 107 non-trivial but implementable way. This document specifies those 108 fields and their values. 110 This document does not define applications that utilizes this 111 rewrite functionality. Instead it specifies just the mechanics of 112 how it is done. Why its done, what the rules concerning the inputs, 113 and the types of rules used are reserved for other documents that 114 fully specify a particular application. This seperation is due to 115 several differrent applications all wanting to take advantage of the 116 rewrite rule lookup process. Each one has vastly different reasons 117 for why and how it uses the service, thus requiring that the 118 definition of the service be generic. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 121 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 RFC 2119. 125 All references to Uniform Resource Identifiers in this document 126 adhere to the 'absoluteURI' production of the "Collected ABNF" 127 found in RFC 2396[9]. Specifically, the semantics of URI 128 References do not apply since the concept of a Base makes no 129 sense here. 131 2. NAPTR RR Format 133 The format of the NAPTR RR is given below. The DNS type code[1] for 134 NAPTR is 35. 136 Domain TTL Class Order Preference Flags Service Regexp Replacement 138 Domain 139 The domain name to which this resource record refers. This is the 140 'key' for this entry in the rule database. This value will either 141 be the first well known key (.uri.arpa for example) or 142 a new key that is the output of a replacement or regexp rewrite. 143 Beyond this, it has the standard DNS requirements[1]. 145 TTL 146 Standard DNS meaning.[1] 148 Class 149 Standard DNS meaning.[1] 151 Order 152 A 16-bit unsigned integer specifying the order in which the NAPTR 153 records MUST be processed to ensure the correct ordering of 154 rules. Low numbers are processed before high numbers, and once a 155 NAPTR is found whose rule "matches" the target, the client MUST 156 NOT consider any NAPTRs with a higher value for order (except as 157 noted below for the Flags field). 159 Preference 160 A 16-bit unsigned integer that specifies the order in which NAPTR 161 records with equal "order" values SHOULD be processed, low 162 numbers being processed before high numbers. This is similar to 163 the preference field in an MX record, and is used so domain 164 administrators can direct clients towards more capable hosts or 165 lighter weight protocols. A client MAY look at records with 166 higher preference values if it has a good reason to do so such as 167 not understanding the preferred protocol or service. 169 The important difference between Order and Preference is that 170 once a match is found the client MUST NOT consider records with a 171 different Order but they MAY process records with the same Order 172 but different Preferences. I.e. Preference is used to give weight 173 to rules that are considered the same from an authority 174 standpoint but not from a simple load balancing standpoint. 176 Flags 177 A containing flags to control aspects of the 178 rewriting and interpretation of the fields in the record. Flags 179 are single characters from the set [A-Z0-9]. The case of the 180 alphabetic characters is not significant. 182 At this time only four flags, "S", "A", "U", and "P", are 183 defined. The "S", "A" and "U" flags denote a terminal lookup. 184 This means that this NAPTR record is the last one and that the 185 flag determines what the next stage should be. The "S" flag 186 means that the next lookup should be for SRV records[4]. See 187 Section 5 for additional information on how NAPTR uses the SRV 188 record type. "A" means that the next lookup should be for either 189 an A, AAAA, or A6 record. The "U" flag means that the next step 190 is not a DNS lookup but that the output of the Regexp field is an 191 URI that adheres to the 'absoluteURI' production found in the 192 ABNF of RFC 2396[9]. Since there may be applications that use 193 NAPTR to also lookup aspects of URIs, implementors should be 194 aware that this may cause loop conditions and should act 195 accordingly. 197 The "P" flag says that the remainder of the application side 198 algorithm shall be carried out in a Protocol-specific fashion. 199 The new set of rules is identified by the Protocol specified in 200 the Services field. The record that contains the 'P' flag is the 201 last record that is interpreted by the rules specified in this 202 document. The new rules are dependent on the application for 203 which they are being used and the protocol specified. For 204 example, if the application is a URI RDS and the protocol is WIRE 205 then the new set of rules are governed by the algorithms 206 surrounding the WIRE HTTP specification and not this document. 208 The remaining alphabetic flags are reserved for future versions 209 of the NAPTR specification. The numeric flags may be used for 210 local experimentation. The S, A, U and P flags are all mutually 211 exclusive, and resolution libraries MAY signal an error if more 212 than one is given. (Experimental code and code for assisting in 213 the creation of NAPTRs would be more likely to signal such an 214 error than a client such as a browser). It is anticipated that 215 multiple flags will be allowed in the future, so implementers 216 MUST NOT assume that the flags field can only contain 0 or 1 217 characters. Finally, if a client encounters a record with an 218 unknown flag, it MUST ignore it and move to the next record. This 219 test takes precedence even over the "order" field. Since flags 220 can control the interpretation placed on fields, a novel flag 221 might change the interpretation of the regexp and/or replacement 222 fields such that it is impossible to determine if a record 223 matched a given target. 225 The "S", "A", and "U" flags are called 'terminal' flags since 226 they halt the looping rewrite algorithm. If those flags are not 227 present, clients may assume that another NAPTR RR exists at the 228 domain name produced by the current rewrite rule. Since the "P" 229 flag specifies a new algorithm, it may or may not be 'terminal'. 230 Thus, the client cannot assume that another NAPTR exists since 231 this case is determined elsewhere. 233 DNS servers MAY interpret these flags and values and use that 234 information to include appropriate SRV and A,AAAA, or A6 records 235 in the additional information portion of the DNS packet. Clients 236 are encouraged to check for additional information but are not 237 required to do so. 239 Service 240 Specifies the service(s) available down this rewrite path. It may 241 also specify the particular protocol that is used to talk with a 242 service. A protocol MUST be specified if the flags field states 243 that the NAPTR is terminal. If a protocol is specified, but the 244 flags field does not state that the NAPTR is terminal, the next 245 lookup MUST be for a NAPTR. The client MAY choose not to perform 246 the next lookup if the protocol is unknown, but that behavior 247 MUST NOT be relied upon. 249 The service field may take any of the values below (using the 250 Augmented BNF of RFC 2234[5]): 252 service_field = [ [protocol] *("+" rs)] 253 protocol = ALPHA *31ALPHANUM 254 rs = ALPHA *31ALPHANUM 255 ; The protocol and rs fields are limited to 32 256 ; characters and must start with an alphabetic. 258 For example, an optional protocol specification followed by 0 or 259 more resolution services. Each resolution service is indicated by 260 an initial '+' character. 262 Note that the empty string is also a valid service field. This 263 will typically be seen at the beginning of a series of rules, 264 when it is impossible to know what services and protocols will be 265 offered by a particular service. 267 The actual format of the service request and response will be 268 determined by the resolution protocol, and is the subject for 269 other documents. Protocols need not offer all services. The 270 labels for service requests shall be formed from the set of 271 characters [A-Z0-9]. The case of the alphabetic characters is not 272 significant. 274 The list of "valid" protocols for any given NAPTR record is any 275 protocol that implements some or all of the services defined for 276 a NAPTR application. Currently, THTTP[6] is the only protocol 277 that is known to make that claim at the time of publication. Any 278 other protocol that is to be used must have documentation 279 specifying: 281 * how it implements the services of the application 283 * how it is to appear in the NAPTR record (i.e., the string id 284 of the protocol) 286 The list of valid Resolution Services is defined by the documents 287 that specify individual NAPTR based applications. 289 It is worth noting that the interpretation of this field is 290 subject to being changed by new flags, and that the current 291 specification is oriented towards telling clients how to talk 292 with a URN resolver. 294 Regexp 295 A STRING containing a substitution expression that is applied to 296 the original string held by the client in order to construct the 297 next domain name to lookup. The grammar of the substitution 298 expression is given in the next section. 300 The regular expressions MUST NOT be used in a cumulative fashion, 301 that is, they should only be applied to the original string held 302 by the client, never to the domain name produced by a previous 303 NAPTR rewrite. The latter is tempting in some applications but 304 experience has shown such use to be extremely fault sensitive, 305 very error prone, and extremely difficult to debug. 307 Replacement 308 The next NAME to query for NAPTR, SRV, or address records 309 depending on the value of the flags field. This MUST be a fully 310 qualified domain-name. Unless and until permitted by future 311 standards action, name compression is not to be used for this 312 field. 314 3. Substitution Expression Grammar 316 The content of the regexp field is a substitution expression. True 317 sed(1) and Perl style substitution expressions are not appropriate 318 for use in this application for a variety of reasons stemming from 319 internationalization requirements and backref limitations, therefore 320 the contents of the regexp field MUST follow the grammar below: 322 subst_expr = delim-char ere delim-char repl delim-char *flags 323 delim-char = "/" / "!" / ... 326 ere = POSIX Extended Regular Expression 327 repl = 1 * ( OCTET / backref ) 328 backref = "\" 1POS_DIGIT 329 flags = "i" 330 POS_DIGIT = %x31-39 ; 0 is not an allowed backref 332 The definition of a POSIX Extended Regular Expression can be found 333 in [8], section 2.8.4. 335 The result of applying the substitution expression to the original 336 URI MUST result in either a string that obeys the syntax for DNS 337 domain-names[1] or a URI[9] if the Flags field contains a 'u'. 338 Since it is possible for the regexp field to be improperly 339 specified, such that a non-conforming domain-name can be 340 constructed, client software SHOULD verify that the result is a 341 legal DNS domain-name before making queries on it. 343 Backref expressions in the repl portion of the substitution 344 expression are replaced by the (possibly empty) string of characters 345 enclosed by '(' and ')' in the ERE portion of the substitution 346 expression. N is a single digit from 1 through 9, inclusive. It 347 specifies the N'th backref expression, the one that begins with the 348 N'th '(' and continues to the matching ')'. For example, the ERE 350 (A(B(C)DE)(F)G) 352 has backref expressions: 354 \1 = ABCDEFG 355 \2 = BCDE 356 \3 = C 357 \4 = F 358 \5..\9 = error - no matching subexpression 360 The "i" flag indicates that the ERE matching SHALL be performed in a 361 case-insensitive fashion. Furthermore, any backref replacements MAY 362 be normalized to lower case when the "i" flag is given. 364 The first character in the substitution expression shall be used as 365 the character that delimits the components of the substitution 366 expression. There must be exactly three non-escaped occurrences of 367 the delimiter character in a substitution expression. Since escaped 368 occurrences of the delimiter character will be interpreted as 369 occurrences of that character, digits MUST NOT be used as 370 delimiters. Backrefs would be confused with literal digits were this 371 allowed. Similarly, if flags are specified in the substitution 372 expression, the delimiter character must not also be a flag 373 character. 375 4. The Basic NAPTR Algorithm 377 The behavior and meaning of the flags and services assume an 378 algorithm where the output of one rewrite is a new key that points 379 to another rule. This looping algorithm allows NAPTR records to 380 incrementally specify a complete rule. These incremental rules can 381 be delegated which allows other entities to specify rules so that 382 one entity does not need to understand _all_ rules. 384 The algorithm starts with a string and some known key (domain). 385 NAPTR records for this key are retrieved, those with unknown Flags 386 or inappropriate Services are discarded and the remaining records 387 are sorted by their Order field. Within each value of Order, the 388 records are further sorted by the Preferences field. 390 The records are examined in sorted order until a matching record is 391 found. A record is considered a match iff: 393 o it has a Replacement field value instead of a Regexp field value. 395 o or the Regexp field matches the string held by the client. 397 The first match MUST be the match that is used. Once a match is 398 found, the Services field is examined for whether or not this rule 399 advances toward the desired result. If so, the rule is applied to 400 the target string. If not, the process halts. The domain that 401 results from the regular expression is then used as the domain of 402 the next loop through the NAPTR algorithm. Note that the same target 403 string is used throughout the algorithm. 405 This looping is extremely important since it is the method by which 406 complex rules are broken down into manageable delegated chunks. The 407 flags fields simply determine at which point the looping should stop 408 (or other specialized behavior). 410 Since flags are valid at any level of the algorithm, the 411 degenerative case is to never loop but to look up the NAPTR and then 412 stop. In many specialized cases this is all that is needed. 413 Implementors should be aware that the degenerative case should not 414 become the common case. 416 5. Concerning How NAPTR Uses SRV Records 418 When the SRV record type was originally specified it assumed that 419 the client did not know the specific domain-name before hand. The 420 client would construct a domain-name more in the form of a question 421 than the usual case of knowing ahead of time that the domain-name 422 should exist. I.e., if the client wants to know if there is a TCP 423 based HTTP server running at a particular domain, the client would 424 construct the domain-name _http._tcp.somedomain.com and ask the DNS 425 if that records exists. The underscores are used to avoid collisions 426 with potentially 'real' domain-names. 428 In the case of NAPTR, the actual domain-name is specified by the 429 various fields in the NAPTR record. In this case the client isn't 430 asking a question but is instead attempting to get at information 431 that it has been told exists in an SRV record at that particular 432 domain-name. While this usage of SRV is slightly different than the 433 SRV authors originally intended it does not break any of the 434 assumptions concerning what SRV contains. Also, since the NAPTR 435 explicitly spells out the domain-name for which an SRV exists, that 436 domain-name MUST be used in SRV queries with NO transformations. Any 437 given NAPTR record may result in a domain-name to be used for SRV 438 queries that may or may not contain the SRV standardized underscore 439 characters. NAPTR applications that make use of SRV MUST NOT attempt 440 to understand these domains or use them according to how the SRV 441 specification structures its query domains. 443 6. Application Specifications 445 It should be noted that the NAPTR algorithm is the basic assumption 446 about how NAPTR works. The reasons for the rewrite and the expected 447 output and its use are specified by documents that define what 448 applications the NAPTR record and algorithm are used for. Any 449 document that defines such an application must define the following: 451 o The first known domain-name or how to build it 453 o The valid Services and Protocols 455 o What the expected use is for the output of the last rewrite 457 o The validity and/or behavior of any 'P' flag protocols. 459 o The general semantics surrounding why and how NAPTR and its 460 algorithm are being used. 462 7. Examples 464 NOTE: These are examples only. They are taken from ongoing work and 465 may not represent the end result of that work. They are here for 466 pedagogical reasons only. 468 7.1 Example 1 470 NAPTR was originally specified for use with the a Uniform Resource 471 Name Resolver Discovery System. This example details how a 472 particular URN would use the NAPTR record to find a resolver 473 service. 475 Consider a URN namespace based on MIME Content-Ids. The URN might 476 look like this: 478 (Note that this example is chosen for pedagogical purposes, and does 479 not conform to the CID URL scheme.) 481 The first step in the resolution process is to find out about the 482 CID namespace. The namespace identifier[3], 'cid', is extracted from 483 the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the 484 first 'known' key in the NAPTR algorithm. The NAPTR records for 485 cid.urn.arpa looked up and return a single record: 487 cid.urn.arpa. 488 ;; order pref flags service regexp replacement 489 IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" . 491 There is only one NAPTR response, so ordering the responses is not a 492 problem. The replacement field is empty, so the pattern provided in 493 the regexp field is used . We apply that regexp to the entire URN to 494 see if it matches, which it does. The \2 part of the substitution 495 expression returns the string "gatech.edu". Since the flags field 496 does not contain "s" or "a", the lookup is not terminal and our next 497 probe to DNS is for more NAPTR records where the new domain is 498 'gatech.edu' and the string is the same string as before. 500 Note that the rule does not extract the full domain name from the 501 CID, instead it assumes the CID comes from a host and extracts its 502 domain. While all hosts, such as mordred, could have their very own 503 NAPTR, maintaining those records for all the machines at a site as 504 large as Georgia Tech would be an intolerable burden. Wildcards are 505 not appropriate here since they only return results when there is no 506 exactly matching names already in the system. 508 The record returned from the query on "gatech.edu" might look like: 510 gatech.edu. 511 ;; order pref flags service regexp replacement 512 IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" _z3950._tcp.gatech.edu. 513 IN NAPTR 100 50 "s" "rcds+I2C" "" _rcds._udp.gatech.edu. 514 IN NAPTR 100 50 "s" "http+I2L+I2C+I2R" "" _http._tcp.gatech.edu. 516 Continuing with the example, note that the values of the order and 517 preference fields are equal in all records, so the client is free to 518 pick any record. The flags field tells us that these are the last 519 NAPTR patterns we should see, and after the rewrite (a simple 520 replacement in this case) we should look up SRV records to get 521 information on the hosts that can provide the necessary service. 523 Assuming we prefer the Z39.50 protocol, our lookup might return: 525 ;; Pref Weight Port Target 526 _z3950._tcp.gatech.edu. IN SRV 0 0 1000 z3950.gatech.edu. 527 IN SRV 0 0 1000 z3950.cc.gatech.edu. 528 IN SRV 0 0 1000 z3950.uga.edu. 530 telling us three hosts that could actually do the resolution, and 531 giving us the port we should use to talk to their Z39.50 server. 533 Recall that the regular expression used \2 to extract a domain name 534 from the CID, and \. for matching the literal '.' characters 535 separating the domain name components. Since '\' is the escape 536 character, literal occurances of a backslash must be escaped by 537 another backslash. For the case of the cid.urn.arpa record above, 538 the regular expression entered into the master file should be 539 "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code 540 actually receives the record, the pattern will have been converted 541 to "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i". 543 7.2 Example 2 545 Even if URN systems were in place now, there would still be a 546 tremendous number of URLs. It should be possible to develop a URN 547 resolution system that can also provide location independence for 548 those URLs. This is related to the requirement that URNs be able to 549 grandfather in names from other naming systems, such as ISO Formal 550 Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, 551 etc. 553 The NAPTR RR could also be used for URLs that have already been 554 assigned. Assume we have the URL for a very popular piece of 555 software that the publisher wishes to mirror at multiple sites 556 around the world: 558 Using the rules specified for this application we extract the 559 prefix, "http", and lookup NAPTR records for http.uri.arpa. This 560 might return a record of the form 562 http.uri.arpa. IN NAPTR 563 ;; order pref flags service regexp replacement 564 100 90 "" "" "!http://([^/:]+)!\1!i" . 566 This expression returns everything after the first double slash and 567 before the next slash or colon. (We use the '!' character to delimit 568 the parts of the substitution expression. Otherwise we would have to 569 use backslashes to escape the forward slashes and would have a 570 regexp in the zone file that looked like 571 "/http:\\/\\/([^\\/:]+)/\\1/i".). 573 Applying this pattern to the URL extracts "www.foo.com". Looking up 574 NAPTR records for that might return: 576 www.foo.com. 577 ;; order pref flags service regexp replacement 578 IN NAPTR 100 100 "s" "http+I2R" "" _http._tcp.foo.com. 579 IN NAPTR 100 100 "s" "ftp+I2R" "" _ftp._tcp.foo.com. 581 Looking up SRV records for http.tcp.foo.com would return information 582 on the hosts that foo.com has designated to be its mirror sites. The 583 client can then pick one for the user. 585 7.3 Example 3 587 A non-URI example is the ENUM application which uses a NAPTR record 588 to map an e.164 telephone number to a URI. In order to convert the 589 phone number to a domain name for the first iteration all characters 590 other than digits are removed from the the telephone number, the 591 entire number is inverted, periods are put between each digit and 592 the string ".e164.arpa" is put on the left-hand side. For example, 593 the E.164 phone number "+1-770-555-1212" converted to a domain-name 594 it would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa." 596 For this example telephone number we might get back the following 597 NAPTR records: 599 $ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. 600 IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@tele2.se!" . 601 IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!" . 603 This application uses the same 'u' flag as the URI Resolution 604 application. This flag states that the Rule is terminal and that the 605 output is a URI which contains the information needed to contact 606 that telephone service. ENUM also uses the same format for its 607 Service field except that it defines the 'E2U' service instead of 608 the 'I2*' services that URI resolution uses. The example above 609 states that the available protocols used to access that telephone's 610 service are either the Session Initiation Protocol or SMTP mail. 612 8. DNS Packet Format 614 The packet format for the NAPTR record is: 616 1 1 1 1 1 1 617 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 618 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 619 | ORDER | 620 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 621 | PREFERENCE | 622 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 623 / FLAGS / 624 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 625 / SERVICES / 626 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 627 / REGEXP / 628 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 629 / REPLACEMENT / 630 / / 631 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 633 where: 635 FLAGS A which contains various flags. 637 SERVICES A which contains protocol and service 638 identifiers. 640 REGEXP A which contains a regular expression. 642 REPLACEMENT A which specifies the new value in the 643 case where the regular expression is a simple replacement 644 operation. 646 and as used here are defined in 647 RFC1035[1]. 649 9. Master File Format 651 The master file format follows the standard rules in RFC-1035[1]. 652 Order and preference, being 16-bit unsigned integers, shall be an 653 integer between 0 and 65535. The Flags and Services and Regexp 654 fields are all quoted s. Since the Regexp field 655 can contain numerous backslashes and thus should be treated with 656 care. See Section 10 for how to correctly enter and escape the 657 regular expression. 659 10. Advice for DNS Administrators 661 Beware of regular expressions. Not only are they difficult to get 662 correct on their own, but there is the previously mentioned 663 interaction with DNS. Any backslashes in a regexp must be entered 664 twice in a zone file in order to appear once in a query response. 665 More seriously, the need for double backslashes has probably not 666 been tested by all implementors of DNS servers. 668 The "a" flag allows the next lookup to be for address records (A, 669 AAAA, A6) rather than SRV records. Since there is no place for a 670 port specification in the NAPTR record, when the "A" flag is used 671 the specified protocol must be running on its default port. 673 The URN Syntax draft defines a canonical form for each URN, which 674 requires %encoding characters outside a limited repertoire. The 675 regular expressions MUST be written to operate on that canonical 676 form. Since international character sets will end up with extensive 677 use of %encoded characters, regular expressions operating on them 678 will be essentially impossible to read or write by hand. 680 11. Notes 682 o A client MUST process multiple NAPTR records in the order 683 specified by the "order" field, it MUST NOT simply use the first 684 record that provides a known protocol and service combination. 686 o When multiple RRs have the same "order" and all other criteria 687 being equal, the client should use the value of the preference 688 field to select the next NAPTR to consider. However, because it 689 will often be the case where preferred protocols or services 690 exist, clients may use this additional criteria to sort 691 the records. 693 o If the lookup after a rewrite fails, clients are strongly 694 encouraged to report a failure, rather than backing up to pursue 695 other rewrite paths. 697 o Note that SRV RRs impose additional requirements on clients. 699 12. IANA Considerations 701 The only registration function that impacts the IANA is for the 702 values that are standardized for the Services and Flags fields. To 703 extend the valid values of the Flags field beyond what is specified 704 in this document requires a published specification that is approved 705 by the IESG. 707 The values for the Services field will be determined by the 708 application that makes use of the NAPTR record. Those values must be 709 specified in a published specification and approved by the IESG. 711 13. Security Considerations 713 The interactions with DNSSEC are currently being studied. It is 714 expected that NAPTR records will be signed with SIG records once the 715 DNSSEC work is deployed. 717 The rewrite rules make identifiers from other namespaces subject to 718 the same attacks as normal domain names. Since they have not been 719 easily resolvable before, this may or may not be considered a 720 problem. 722 Regular expressions should be checked for sanity, not blindly passed 723 to something like PERL. 725 This document has discussed a way of locating a service, but has not 726 discussed any detail of how the communication with that service 727 takes place. There are significant security considerations attached 728 to the communication with a service. Those considerations are 729 outside the scope of this document, and must be addressed by the 730 specifications for particular communication protocols. 732 14. Acknowledgments 734 The editors would like to thank Keith Moore for all his 735 consultations during the development of this draft. We would also 736 like to thank Paul Vixie for his assistance in debugging our 737 implementation, and his answers on our questions. Finally, we would 738 like to acknowledge our enormous intellectual debt to the 739 participants in the Knoxville series of meetings, as well as to the 740 participants in the URI and URN working groups. 742 References 744 [1] Mockapetris, P.V., "Domain names - implementation and 745 specification", RFC 1035, STD 13, Nov 1987. 747 [2] Mockapetris, P.V., "Domain names - concepts and facilities", 748 RFC 1034, STD 13, Nov 1987. 750 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 752 [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 753 specifying the location of services (DNS SRV)", RFC 2782, 754 February 2000. 756 [5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 757 RFC 2234, November 1997. 759 [6] Danie1, R., "A Trivial Convention for using HTTP in URN 760 Resolution", RFC 2169, June 1997. 762 [7] Danie1, R. and M. Mealling, "Resolution of Uniform Resource 763 Identifiers using the Domain Name System", RFC 2168, June 1997. 765 [8] IEEE, "IEEE Standard for Information Technology - Portable 766 Operating System Interface (POSIX) - Part 2: Shell and 767 Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993. 769 [9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform 770 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 771 1998. 773 Authors' Addresses 775 Michael Mealling 776 Network Solutions, Inc. 777 505 Huntmar Park Drive 778 Herndon, VA 22070 779 US 781 Phone: +1 770 921 2251 782 EMail: michaelm@netsol.com 783 URI: http://www.netsol.com 784 Ron Daniel 785 DATAFUSION, Inc. 786 139 Townsend Street, Ste. 100 787 San Francisco, CA 94107 788 US 790 Phone: +1 415 222 0100 791 EMail: rdaniel@datafusion.net 792 URI: http://www.datafusion.net 794 Full Copyright Statement 796 Copyright (C) The Internet Society (2000). All Rights Reserved. 798 This document and translations of it may be copied and furnished to 799 others, and derivative works that comment on or otherwise explain it 800 or assist in its implmentation may be prepared, copied, published 801 and distributed, in whole or in part, without restriction of any 802 kind, provided that the above copyright notice and this paragraph 803 are included on all such copies and derivative works. However, this 804 document itself may not be modified in any way, such as by removing 805 the copyright notice or references to the Internet Society or other 806 Internet organizations, except as needed for the purpose of 807 developing Internet standards in which case the procedures for 808 copyrights defined in the Internet Standards process must be 809 followed, or as required to translate it into languages other than 810 English. 812 The limited permissions granted above are perpetual and will not be 813 revoked by the Internet Society or its successors or assigns. 815 This document and the information contained herein is provided on an 816 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 817 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 818 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 819 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 820 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 822 Acknowledgement 824 Funding for the RFC editor function is currently provided by the 825 Internet Society.