diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2915.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2915.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2915.txt b/contrib/bind9/doc/rfc/rfc2915.txt new file mode 100644 index 000000000000..2022ba115724 --- /dev/null +++ b/contrib/bind9/doc/rfc/rfc2915.txt @@ -0,0 +1,1011 @@ + + + + + + +Network Working Group M. Mealling +Request for Comments: 2915 Network Solutions, Inc. +Updates: 2168 R. Daniel +Category: Standards Track DATAFUSION, Inc. + September 2000 + + + The Naming Authority Pointer (NAPTR) DNS Resource Record + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This document describes a Domain Name System (DNS) resource record + which specifies a regular expression based rewrite rule that, when + applied to an existing string, will produce a new domain label or + Uniform Resource Identifier (URI). Depending on the value of the + flags field of the resource record, the resulting domain label or URI + may be used in subsequent queries for the Naming Authority Pointer + (NAPTR) resource records (to delegate the name lookup) or as the + output of the entire process for which this system is used (a + resolution server for URI resolution, a service URI for ENUM style + e.164 number to URI mapping, etc). + + This allows the DNS to be used to lookup services for a wide variety + of resource names (including URIs) which are not in domain name + syntax. Reasons for doing this range from URN Resource Discovery + Systems to moving out-of-date services to new domains. + + This document updates the portions of RFC 2168 specifically dealing + with the definition of the NAPTR records and how other, non-URI + specific applications, might use NAPTR. + + + + + + + + + +Mealling & Daniel Standards Track [Page 1] + +RFC 2915 NAPTR DNS RR September 2000 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Substitution Expression Grammar . . . . . . . . . . . . . . 7 + 4. The Basic NAPTR Algorithm . . . . . . . . . . . . . . . . . 8 + 5. Concerning How NAPTR Uses SRV Records . . . . . . . . . . . 9 + 6. Application Specifications . . . . . . . . . . . . . . . . . 10 + 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. DNS Packet Format . . . . . . . . . . . . . . . . . . . . . 13 + 9. Master File Format . . . . . . . . . . . . . . . . . . . . . 14 + 10. Advice for DNS Administrators . . . . . . . . . . . . . . . 14 + 11. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 + 13. Security Considerations . . . . . . . . . . . . . . . . . . 15 + 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16 + References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 + +1. Introduction + + This RR was originally produced by the URN Working Group [3] as a way + to encode rule-sets in DNS so that the delegated sections of a URI + could be decomposed in such a way that they could be changed and re- + delegated over time. The result was a Resource Record that included + a regular expression that would be used by a client program to + rewrite a string into a domain name. Regular expressions were chosen + for their compactness to expressivity ratio allowing for a great deal + of information to be encoded in a rather small DNS packet. + + The function of rewriting a string according to the rules in a record + has usefulness in several different applications. This document + defines the basic assumptions to which all of those applications must + adhere to. It does not define the reasons the rewrite is used, what + the expected outcomes are, or what they are used for. Those are + specified by applications that define how they use the NAPTR record + and algorithms within their contexts. + + Flags and other fields are also specified in the RR to control the + rewrite procedure in various ways or to provide information on how to + communicate with the host at the domain name that was the result of + the rewrite. + + + + + +Mealling & Daniel Standards Track [Page 2] + +RFC 2915 NAPTR DNS RR September 2000 + + + The final result is a RR that has several fields that interact in a + non-trivial but implementable way. This document specifies those + fields and their values. + + This document does not define applications that utilizes this rewrite + functionality. Instead it specifies just the mechanics of how it is + done. Why its done, what the rules concerning the inputs, and the + types of rules used are reserved for other documents that fully + specify a particular application. This separation is due to several + different applications all wanting to take advantage of the rewrite + rule lookup process. Each one has vastly different reasons for why + and how it uses the service, thus requiring that the definition of + the service be generic. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL + NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" + in this document are to be interpreted as described in RFC 2119. + + All references to Uniform Resource Identifiers in this document + adhere to the 'absoluteURI' production of the "Collected ABNF" + found in RFC 2396 [9]. Specifically, the semantics of URI + References do not apply since the concept of a Base makes no sense + here. + +2. NAPTR RR Format + + The format of the NAPTR RR is given below. The DNS type code [1] for + NAPTR is 35. + + Domain TTL Class Type Order Preference Flags Service Regexp + Replacement + + Domain + The domain name to which this resource record refers. This is the + 'key' for this entry in the rule database. This value will either + be the first well known key (<something>.uri.arpa for example) or + a new key that is the output of a replacement or regexp rewrite. + Beyond this, it has the standard DNS requirements [1]. + + TTL + Standard DNS meaning [1]. + + Class + Standard DNS meaning [1]. + + Type + The Type Code [1] for NAPTR is 35. + + + + +Mealling & Daniel Standards Track [Page 3] + +RFC 2915 NAPTR DNS RR September 2000 + + + Order + A 16-bit unsigned integer specifying the order in which the NAPTR + records MUST be processed to ensure the correct ordering of + rules. Low numbers are processed before high numbers, and once a + NAPTR is found whose rule "matches" the target, the client MUST + NOT consider any NAPTRs with a higher value for order (except as + noted below for the Flags field). + + Preference + A 16-bit unsigned integer that specifies the order in which NAPTR + records with equal "order" values SHOULD be processed, low + numbers being processed before high numbers. This is similar to + the preference field in an MX record, and is used so domain + administrators can direct clients towards more capable hosts or + lighter weight protocols. A client MAY look at records with + higher preference values if it has a good reason to do so such as + not understanding the preferred protocol or service. + + The important difference between Order and Preference is that + once a match is found the client MUST NOT consider records with a + different Order but they MAY process records with the same Order + but different Preferences. I.e., Preference is used to give weight + to rules that are considered the same from an authority + standpoint but not from a simple load balancing standpoint. + + Flags + A <character-string> containing flags to control aspects of the + rewriting and interpretation of the fields in the record. Flags + are single characters from the set [A-Z0-9]. The case of the + alphabetic characters is not significant. + + At this time only four flags, "S", "A", "U", and "P", are + defined. The "S", "A" and "U" flags denote a terminal lookup. + This means that this NAPTR record is the last one and that the + flag determines what the next stage should be. The "S" flag + means that the next lookup should be for SRV records [4]. See + Section 5 for additional information on how NAPTR uses the SRV + record type. "A" means that the next lookup should be for either + an A, AAAA, or A6 record. The "U" flag means that the next step + is not a DNS lookup but that the output of the Regexp field is an + URI that adheres to the 'absoluteURI' production found in the + ABNF of RFC 2396 [9]. Since there may be applications that use + NAPTR to also lookup aspects of URIs, implementors should be + aware that this may cause loop conditions and should act + accordingly. + + + + + + +Mealling & Daniel Standards Track [Page 4] + +RFC 2915 NAPTR DNS RR September 2000 + + + The "P" flag says that the remainder of the application side + algorithm shall be carried out in a Protocol-specific fashion. + The new set of rules is identified by the Protocol specified in + the Services field. The record that contains the 'P' flag is the + last record that is interpreted by the rules specified in this + document. The new rules are dependent on the application for + which they are being used and the protocol specified. For + example, if the application is a URI RDS and the protocol is WIRE + then the new set of rules are governed by the algorithms + surrounding the WIRE HTTP specification and not this document. + + The remaining alphabetic flags are reserved for future versions + of the NAPTR specification. The numeric flags may be used for + local experimentation. The S, A, U and P flags are all mutually + exclusive, and resolution libraries MAY signal an error if more + than one is given. (Experimental code and code for assisting in + the creation of NAPTRs would be more likely to signal such an + error than a client such as a browser). It is anticipated that + multiple flags will be allowed in the future, so implementers + MUST NOT assume that the flags field can only contain 0 or 1 + characters. Finally, if a client encounters a record with an + unknown flag, it MUST ignore it and move to the next record. This + test takes precedence even over the "order" field. Since flags + can control the interpretation placed on fields, a novel flag + might change the interpretation of the regexp and/or replacement + fields such that it is impossible to determine if a record + matched a given target. + + The "S", "A", and "U" flags are called 'terminal' flags since + they halt the looping rewrite algorithm. If those flags are not + present, clients may assume that another NAPTR RR exists at the + domain name produced by the current rewrite rule. Since the "P" + flag specifies a new algorithm, it may or may not be 'terminal'. + Thus, the client cannot assume that another NAPTR exists since + this case is determined elsewhere. + + DNS servers MAY interpret these flags and values and use that + information to include appropriate SRV and A,AAAA, or A6 records + in the additional information portion of the DNS packet. Clients + are encouraged to check for additional information but are not + required to do so. + + Service + Specifies the service(s) available down this rewrite path. It may + also specify the particular protocol that is used to talk with a + service. A protocol MUST be specified if the flags field states + that the NAPTR is terminal. If a protocol is specified, but the + flags field does not state that the NAPTR is terminal, the next + + + +Mealling & Daniel Standards Track [Page 5] + +RFC 2915 NAPTR DNS RR September 2000 + + + lookup MUST be for a NAPTR. The client MAY choose not to perform + the next lookup if the protocol is unknown, but that behavior + MUST NOT be relied upon. + + The service field may take any of the values below (using the + Augmented BNF of RFC 2234 [5]): + + service_field = [ [protocol] *("+" rs)] + protocol = ALPHA *31ALPHANUM + rs = ALPHA *31ALPHANUM + ; The protocol and rs fields are limited to 32 + ; characters and must start with an alphabetic. + + For example, an optional protocol specification followed by 0 or + more resolution services. Each resolution service is indicated by + an initial '+' character. + + Note that the empty string is also a valid service field. This + will typically be seen at the beginning of a series of rules, + when it is impossible to know what services and protocols will be + offered by a particular service. + + The actual format of the service request and response will be + determined by the resolution protocol, and is the subject for + other documents. Protocols need not offer all services. The + labels for service requests shall be formed from the set of + characters [A-Z0-9]. The case of the alphabetic characters is + not significant. + + The list of "valid" protocols for any given NAPTR record is any + protocol that implements some or all of the services defined for + a NAPTR application. Currently, THTTP [6] is the only protocol + that is known to make that claim at the time of publication. Any + other protocol that is to be used must have documentation + specifying: + + * how it implements the services of the application + + * how it is to appear in the NAPTR record (i.e., the string id + of the protocol) + + The list of valid Resolution Services is defined by the documents + that specify individual NAPTR based applications. + + It is worth noting that the interpretation of this field is + subject to being changed by new flags, and that the current + specification is oriented towards telling clients how to talk + with a URN resolver. + + + +Mealling & Daniel Standards Track [Page 6] + +RFC 2915 NAPTR DNS RR September 2000 + + + Regexp + A STRING containing a substitution expression that is applied to + the original string held by the client in order to construct the + next domain name to lookup. The grammar of the substitution + expression is given in the next section. + + The regular expressions MUST NOT be used in a cumulative fashion, + that is, they should only be applied to the original string held + by the client, never to the domain name produced by a previous + NAPTR rewrite. The latter is tempting in some applications but + experience has shown such use to be extremely fault sensitive, + very error prone, and extremely difficult to debug. + + Replacement + The next NAME to query for NAPTR, SRV, or address records + depending on the value of the flags field. This MUST be a fully + qualified domain-name. Unless and until permitted by future + standards action, name compression is not to be used for this + field. + +3. Substitution Expression Grammar + + The content of the regexp field is a substitution expression. True + sed(1) and Perl style substitution expressions are not appropriate + for use in this application for a variety of reasons stemming from + internationalization requirements and backref limitations, therefore + the contents of the regexp field MUST follow the grammar below: + +subst_expr = delim-char ere delim-char repl delim-char *flags +delim-char = "/" / "!" / ... <Any non-digit or non-flag character + other than backslash '\'. All occurances of a delim_char + in a subst_expr must be the same character.> +ere = POSIX Extended Regular Expression +repl = 1 * ( OCTET / backref ) +backref = "\" 1POS_DIGIT +flags = "i" +POS_DIGIT = %x31-39 ; 0 is not an allowed backref + + The definition of a POSIX Extended Regular Expression can be found in + [8], section 2.8.4. + + The result of applying the substitution expression to the original + URI MUST result in either a string that obeys the syntax for DNS + domain-names [1] or a URI [9] if the Flags field contains a 'u'. + Since it is possible for the regexp field to be improperly specified, + such that a non-conforming domain-name can be constructed, client + software SHOULD verify that the result is a legal DNS domain-name + before making queries on it. + + + +Mealling & Daniel Standards Track [Page 7] + +RFC 2915 NAPTR DNS RR September 2000 + + + Backref expressions in the repl portion of the substitution + expression are replaced by the (possibly empty) string of characters + enclosed by '(' and ')' in the ERE portion of the substitution + expression. N is a single digit from 1 through 9, inclusive. It + specifies the N'th backref expression, the one that begins with the + N'th '(' and continues to the matching ')'. For example, the ERE + + (A(B(C)DE)(F)G) + + has backref expressions: + + \1 = ABCDEFG + \2 = BCDE + \3 = C + \4 = F + \5..\9 = error - no matching subexpression + + The "i" flag indicates that the ERE matching SHALL be performed in a + case-insensitive fashion. Furthermore, any backref replacements MAY + be normalized to lower case when the "i" flag is given. + + The first character in the substitution expression shall be used as + the character that delimits the components of the substitution + expression. There must be exactly three non-escaped occurrences of + the delimiter character in a substitution expression. Since escaped + occurrences of the delimiter character will be interpreted as + occurrences of that character, digits MUST NOT be used as delimiters. + Backrefs would be confused with literal digits were this allowed. + Similarly, if flags are specified in the substitution expression, the + delimiter character must not also be a flag character. + +4. The Basic NAPTR Algorithm + + The behavior and meaning of the flags and services assume an + algorithm where the output of one rewrite is a new key that points to + another rule. This looping algorithm allows NAPTR records to + incrementally specify a complete rule. These incremental rules can + be delegated which allows other entities to specify rules so that one + entity does not need to understand _all_ rules. + + The algorithm starts with a string and some known key (domain). + NAPTR records for this key are retrieved, those with unknown Flags or + inappropriate Services are discarded and the remaining records are + sorted by their Order field. Within each value of Order, the records + are further sorted by the Preferences field. + + The records are examined in sorted order until a matching record is + found. A record is considered a match iff: + + + +Mealling & Daniel Standards Track [Page 8] + +RFC 2915 NAPTR DNS RR September 2000 + + + o it has a Replacement field value instead of a Regexp field value. + + o or the Regexp field matches the string held by the client. + + The first match MUST be the match that is used. Once a match is + found, the Services field is examined for whether or not this rule + advances toward the desired result. If so, the rule is applied to + the target string. If not, the process halts. The domain that + results from the regular expression is then used as the domain of the + next loop through the NAPTR algorithm. Note that the same target + string is used throughout the algorithm. + + This looping is extremely important since it is the method by which + complex rules are broken down into manageable delegated chunks. The + flags fields simply determine at which point the looping should stop + (or other specialized behavior). + + Since flags are valid at any level of the algorithm, the degenerative + case is to never loop but to look up the NAPTR and then stop. In + many specialized cases this is all that is needed. Implementors + should be aware that the degenerative case should not become the + common case. + +5. Concerning How NAPTR Uses SRV Records + + When the SRV record type was originally specified it assumed that the + client did not know the specific domain-name before hand. The client + would construct a domain-name more in the form of a question than the + usual case of knowing ahead of time that the domain-name should + exist. I.e., if the client wants to know if there is a TCP based + HTTP server running at a particular domain, the client would + construct the domain-name _http._tcp.somedomain.com and ask the DNS + if that records exists. The underscores are used to avoid collisions + with potentially 'real' domain-names. + + In the case of NAPTR, the actual domain-name is specified by the + various fields in the NAPTR record. In this case the client isn't + asking a question but is instead attempting to get at information + that it has been told exists in an SRV record at that particular + domain-name. While this usage of SRV is slightly different than the + SRV authors originally intended it does not break any of the + assumptions concerning what SRV contains. Also, since the NAPTR + explicitly spells out the domain-name for which an SRV exists, that + domain-name MUST be used in SRV queries with NO transformations. Any + given NAPTR record may result in a domain-name to be used for SRV + queries that may or may not contain the SRV standardized underscore + + + + + +Mealling & Daniel Standards Track [Page 9] + +RFC 2915 NAPTR DNS RR September 2000 + + + characters. NAPTR applications that make use of SRV MUST NOT attempt + to understand these domains or use them according to how the SRV + specification structures its query domains. + +6. Application Specifications + + It should be noted that the NAPTR algorithm is the basic assumption + about how NAPTR works. The reasons for the rewrite and the expected + output and its use are specified by documents that define what + applications the NAPTR record and algorithm are used for. Any + document that defines such an application must define the following: + + o The first known domain-name or how to build it + + o The valid Services and Protocols + + o What the expected use is for the output of the last rewrite + + o The validity and/or behavior of any 'P' flag protocols. + + o The general semantics surrounding why and how NAPTR and its + algorithm are being used. + +7. Examples + + NOTE: These are examples only. They are taken from ongoing work and + may not represent the end result of that work. They are here for + pedagogical reasons only. + +7.1 Example 1 + + NAPTR was originally specified for use with the a Uniform Resource + Name Resolver Discovery System. This example details how a + particular URN would use the NAPTR record to find a resolver service. + + Consider a URN namespace based on MIME Content-Ids. The URN might + look like this: + + urn:cid:39CB83F7.A8450130@fake.gatech.edu + + (Note that this example is chosen for pedagogical purposes, and does + not conform to the CID URL scheme.) + + The first step in the resolution process is to find out about the CID + namespace. The namespace identifier [3], 'cid', is extracted from + the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first + 'known' key in the NAPTR algorithm. The NAPTR records for + cid.urn.arpa looked up and return a single record: + + + +Mealling & Daniel Standards Track [Page 10] + +RFC 2915 NAPTR DNS RR September 2000 + + + cid.urn.arpa. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "" "" "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i" . + + There is only one NAPTR response, so ordering the responses is not a + problem. The replacement field is empty, so the pattern provided in + the regexp field is used. We apply that regexp to the entire URN to + see if it matches, which it does. The \2 part of the substitution + expression returns the string "gatech.edu". Since the flags field + does not contain "s" or "a", the lookup is not terminal and our next + probe to DNS is for more NAPTR records where the new domain is ' + gatech.edu' and the string is the same string as before. + + Note that the rule does not extract the full domain name from the + CID, instead it assumes the CID comes from a host and extracts its + domain. While all hosts, such as mordred, could have their very own + NAPTR, maintaining those records for all the machines at a site as + large as Georgia Tech would be an intolerable burden. Wildcards are + not appropriate here since they only return results when there is no + exactly matching names already in the system. + + The record returned from the query on "gatech.edu" might look like: + +;; order pref flags service regexp replacement + IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" _z3950._tcp.gatech.edu. + IN NAPTR 100 50 "s" "rcds+I2C" "" _rcds._udp.gatech.edu. + IN NAPTR 100 50 "s" "http+I2L+I2C+I2R" "" _http._tcp.gatech.edu. + + Continuing with the example, note that the values of the order and + preference fields are equal in all records, so the client is free to + pick any record. The flags field tells us that these are the last + NAPTR patterns we should see, and after the rewrite (a simple + replacement in this case) we should look up SRV records to get + information on the hosts that can provide the necessary service. + + Assuming we prefer the Z39.50 protocol, our lookup might return: + + ;; Pref Weight Port Target + _z3950._tcp.gatech.edu. IN SRV 0 0 1000 z3950.gatech.edu. + IN SRV 0 0 1000 z3950.cc.gatech.edu. + IN SRV 0 0 1000 z3950.uga.edu. + + telling us three hosts that could actually do the resolution, and + giving us the port we should use to talk to their Z39.50 server. + + Recall that the regular expression used \2 to extract a domain name + from the CID, and \. for matching the literal '.' characters + separating the domain name components. Since '\' is the escape + + + +Mealling & Daniel Standards Track [Page 11] + +RFC 2915 NAPTR DNS RR September 2000 + + + character, literal occurances of a backslash must be escaped by + another backslash. For the case of the cid.urn.arpa record above, + the regular expression entered into the master file should be + "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i". When the client code actually + receives the record, the pattern will have been converted to + "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i". + +7.2 Example 2 + + Even if URN systems were in place now, there would still be a + tremendous number of URLs. It should be possible to develop a URN + resolution system that can also provide location independence for + those URLs. This is related to the requirement that URNs be able to + grandfather in names from other naming systems, such as ISO Formal + Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, + etc. + + The NAPTR RR could also be used for URLs that have already been + assigned. Assume we have the URL for a very popular piece of + software that the publisher wishes to mirror at multiple sites around + the world: + + Using the rules specified for this application we extract the prefix, + "http", and lookup NAPTR records for http.uri.arpa. This might + return a record of the form + + http.uri.arpa. IN NAPTR + ;; order pref flags service regexp replacement + 100 90 "" "" "!http://([^/:]+)!\1!i" . + + This expression returns everything after the first double slash and + before the next slash or colon. (We use the '!' character to delimit + the parts of the substitution expression. Otherwise we would have to + use backslashes to escape the forward slashes and would have a regexp + in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".). + + Applying this pattern to the URL extracts "www.foo.com". Looking up + NAPTR records for that might return: + + www.foo.com. + ;; order pref flags service regexp replacement + IN NAPTR 100 100 "s" "http+I2R" "" _http._tcp.foo.com. + IN NAPTR 100 100 "s" "ftp+I2R" "" _ftp._tcp.foo.com. + + Looking up SRV records for http.tcp.foo.com would return information + on the hosts that foo.com has designated to be its mirror sites. The + client can then pick one for the user. + + + + +Mealling & Daniel Standards Track [Page 12] + +RFC 2915 NAPTR DNS RR September 2000 + + +7.3 Example 3 + + A non-URI example is the ENUM application which uses a NAPTR record + to map an e.164 telephone number to a URI. In order to convert the + phone number to a domain name for the first iteration all characters + other than digits are removed from the the telephone number, the + entire number is inverted, periods are put between each digit and the + string ".e164.arpa" is put on the left-hand side. For example, the + E.164 phone number "+1-770-555-1212" converted to a domain-name it + would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa." + + For this example telephone number we might get back the following + NAPTR records: + +$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. + IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@tele2.se!" . + IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!" . + + This application uses the same 'u' flag as the URI Resolution + application. This flag states that the Rule is terminal and that the + output is a URI which contains the information needed to contact that + telephone service. ENUM also uses the same format for its Service + field except that it defines the 'E2U' service instead of the 'I2*' + services that URI resolution uses. The example above states that the + available protocols used to access that telephone's service are + either the Session Initiation Protocol or SMTP mail. + +8. DNS Packet Format + + The packet format for the NAPTR record is: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ORDER | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | PREFERENCE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / FLAGS / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / SERVICES / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / REGEXP / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / REPLACEMENT / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + + + +Mealling & Daniel Standards Track [Page 13] + +RFC 2915 NAPTR DNS RR September 2000 + + + where: + + FLAGS A <character-string> which contains various flags. + + SERVICES A <character-string> which contains protocol and service + identifiers. + + REGEXP A <character-string> which contains a regular expression. + + REPLACEMENT A <domain-name> which specifies the new value in the + case where the regular expression is a simple replacement + operation. + + <character-string> and <domain-name> as used here are defined in + RFC1035 [1]. + +9. Master File Format + + The master file format follows the standard rules in RFC-1035 [1]. + Order and preference, being 16-bit unsigned integers, shall be an + integer between 0 and 65535. The Flags and Services and Regexp + fields are all quoted <character-string>s. Since the Regexp field + can contain numerous backslashes and thus should be treated with + care. See Section 10 for how to correctly enter and escape the + regular expression. + +10. Advice for DNS Administrators + + Beware of regular expressions. Not only are they difficult to get + correct on their own, but there is the previously mentioned + interaction with DNS. Any backslashes in a regexp must be entered + twice in a zone file in order to appear once in a query response. + More seriously, the need for double backslashes has probably not been + tested by all implementors of DNS servers. + + The "a" flag allows the next lookup to be for address records (A, + AAAA, A6) rather than SRV records. Since there is no place for a + port specification in the NAPTR record, when the "A" flag is used the + specified protocol must be running on its default port. + + The URN Syntax draft defines a canonical form for each URN, which + requires %encoding characters outside a limited repertoire. The + regular expressions MUST be written to operate on that canonical + form. Since international character sets will end up with extensive + use of %encoded characters, regular expressions operating on them + will be essentially impossible to read or write by hand. + + + + + +Mealling & Daniel Standards Track [Page 14] + +RFC 2915 NAPTR DNS RR September 2000 + + +11. Notes + + o A client MUST process multiple NAPTR records in the order + specified by the "order" field, it MUST NOT simply use the first + record that provides a known protocol and service combination. + + o When multiple RRs have the same "order" and all other criteria + being equal, the client should use the value of the preference + field to select the next NAPTR to consider. However, because it + will often be the case where preferred protocols or services + exist, clients may use this additional criteria to sort + the records. + + o If the lookup after a rewrite fails, clients are strongly + encouraged to report a failure, rather than backing up to pursue + other rewrite paths. + + o Note that SRV RRs impose additional requirements on clients. + +12. IANA Considerations + + The only registration function that impacts the IANA is for the + values that are standardized for the Services and Flags fields. To + extend the valid values of the Flags field beyond what is specified + in this document requires a published specification that is approved + by the IESG. + + The values for the Services field will be determined by the + application that makes use of the NAPTR record. Those values must be + specified in a published specification and approved by the IESG. + +13. Security Considerations + + The interactions with DNSSEC are currently being studied. It is + expected that NAPTR records will be signed with SIG records once the + DNSSEC work is deployed. + + The rewrite rules make identifiers from other namespaces subject to + the same attacks as normal domain names. Since they have not been + easily resolvable before, this may or may not be considered a + problem. + + Regular expressions should be checked for sanity, not blindly passed + to something like PERL. + + This document has discussed a way of locating a service, but has not + discussed any detail of how the communication with that service takes + place. There are significant security considerations attached to the + + + +Mealling & Daniel Standards Track [Page 15] + +RFC 2915 NAPTR DNS RR September 2000 + + + communication with a service. Those considerations are outside the + scope of this document, and must be addressed by the specifications + for particular communication protocols. + +14. Acknowledgments + + The editors would like to thank Keith Moore for all his consultations + during the development of this memo. We would also like to thank + Paul Vixie for his assistance in debugging our implementation, and + his answers on our questions. Finally, we would like to acknowledge + our enormous intellectual debt to the participants in the Knoxville + series of meetings, as well as to the participants in the URI and URN + working groups. + +References + + [1] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [3] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", + RFC 2234, November 1997. + + [6] Daniel, R., "A Trivial Convention for using HTTP in URN + Resolution", RFC 2169, June 1997. + + [7] Daniel, R. and M. Mealling, "Resolution of Uniform Resource + Identifiers using the Domain Name System", RFC 2168, June 1997. + + [8] IEEE, "IEEE Standard for Information Technology - Portable + Operating System Interface (POSIX) - Part 2: Shell and Utilities + (Vol. 1)", IEEE Std 1003.2-1992, January 1993. + + [9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, August + 1998. + + + + + + + +Mealling & Daniel Standards Track [Page 16] + +RFC 2915 NAPTR DNS RR September 2000 + + +Authors' Addresses + + Michael Mealling + Network Solutions, Inc. + 505 Huntmar Park Drive + Herndon, VA 22070 + US + + Phone: +1 770 921 2251 + EMail: michaelm@netsol.com + URI: http://www.netsol.com + + + Ron Daniel + DATAFUSION, Inc. + 139 Townsend Street, Ste. 100 + San Francisco, CA 94107 + US + + Phone: +1 415 222 0100 + EMail: rdaniel@datafusion.net + URI: http://www.datafusion.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mealling & Daniel Standards Track [Page 17] + +RFC 2915 NAPTR DNS RR September 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Mealling & Daniel Standards Track [Page 18] + |