diff options
Diffstat (limited to 'doc/draft/draft-daigle-napstr-04.txt')
| -rw-r--r-- | doc/draft/draft-daigle-napstr-04.txt | 1232 |
1 files changed, 1232 insertions, 0 deletions
diff --git a/doc/draft/draft-daigle-napstr-04.txt b/doc/draft/draft-daigle-napstr-04.txt new file mode 100644 index 0000000..fffa8a5 --- /dev/null +++ b/doc/draft/draft-daigle-napstr-04.txt @@ -0,0 +1,1232 @@ + + +Network Working Group L. Daigle +Internet-Draft A. Newton +Expires: August 15, 2004 VeriSign, Inc. + February 15, 2004 + + + Domain-based Application Service Location Using SRV RRs and the + Dynamic Delegation Discovery Service (DDDS) + draft-daigle-napstr-04.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on August 15, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This memo defines a generalized mechanism for application service + naming that allows service location without relying on rigid domain + naming conventions (so-called name hacks). The proposal defines a + Dynamic Delegation Discovery System (DDDS) Application to map domain + name, application service name, and application protocol to target + server and port, dynamically. + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 1] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . 4 + 2.1 Key Terms . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2 S-NAPTR DDDS Application Usage . . . . . . . . . . . . . . . 5 + 2.2.1 Ordering and Preference . . . . . . . . . . . . . . . . . . 5 + 2.2.2 Matching and non-Matching NAPTR Records . . . . . . . . . . 5 + 2.2.3 Terminal and Non-Terminal NAPTR Records . . . . . . . . . . 5 + 2.2.4 S-NAPTR and Successive Resolution . . . . . . . . . . . . . 6 + 2.2.5 Clients Supporting Multiple Protocols . . . . . . . . . . . 6 + 3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1 Guidelines for Application Protocol Developers . . . . . . . 7 + 3.1.1 Registration of application service and protocol tags . . . 7 + 3.1.2 Definition of conditions for retry/failure . . . . . . . . . 8 + 3.1.3 Server identification and handshake . . . . . . . . . . . . 8 + 3.2 Guidelines for Domain Administrators . . . . . . . . . . . . 8 + 3.3 Guidelines for Client Software Writers . . . . . . . . . . . 9 + 4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.2 Service Discovery within a Domain . . . . . . . . . . . . . 10 + 4.3 Multiple Protocols . . . . . . . . . . . . . . . . . . . . . 10 + 4.4 Remote Hosting . . . . . . . . . . . . . . . . . . . . . . . 11 + 4.5 Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . . . 12 + 4.6 Sample sequence diagram . . . . . . . . . . . . . . . . . . 12 + 5. Motivation and Discussion . . . . . . . . . . . . . . . . . 14 + 5.1 So, why not just SRV records? . . . . . . . . . . . . . . . 15 + 5.2 So, why not just NAPTR records? . . . . . . . . . . . . . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 16 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 + References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 + A. Application Service Location Application of DDDS . . . . . . 18 + A.1 Application Unique String . . . . . . . . . . . . . . . . . 18 + A.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 18 + A.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 18 + A.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + A.5 Service Parameters . . . . . . . . . . . . . . . . . . . . . 19 + A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 19 + A.5.2 Application Protocols . . . . . . . . . . . . . . . . . . . 20 + A.6 Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 20 + A.7 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 20 + B. Pseudo pseudocode for S-NAPTR . . . . . . . . . . . . . . . 20 + B.1 Finding the first (best) target . . . . . . . . . . . . . . 20 + B.2 Finding subsequent targets . . . . . . . . . . . . . . . . . 21 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 23 + + + + +Daigle & Newton Expires August 15, 2004 [Page 2] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +1. Introduction + + This memo defines a generalized mechanism for application service + naming that allows service location without relying on rigid domain + naming conventions (so-called name hacks). The proposal defines a + Dynamic Delegation Discovery System (DDDS -- see [6]) Application to + map domain name, application service name, and application protocol + to target server and port, dynamically. + + As discussed in Section 5, existing approaches to using DNS records + to dynamically determining the current host for a given application + service are limited in terms of the use cases supported. To address + some of the limitations, this document defines a DDDS Application to + map service+protocol+domain to specific server addresses using both + NAPTR [7] and SRV ([5]) DNS resource records. This can be viewed as + a more general version of the use of SRV and/or a very restricted + application of the use of NAPTR resource records. + + 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 RFC2119 ([2]). + +2. Straightforward-NAPTR (S-NAPTR) Specification + + The precise details of the specification of this DDDS application are + given in Appendix A. This section defines the usage of the DDDS + application. + +2.1 Key Terms + + An "application service" is a generic term for some type of + application, indpendent of the protocol that may be used to offer it. + Each application service will be associated with an IANA-registered + tag. For example, instant messaging is a type of application + service, which can be implemented by many different application-layer + protocols, and the tag "IM" (used as an illustration here) could be + registered for it. + + An "application protocol" is used to implement the application + service. These are also associated with IANA-registered tags. In + the case where multiple transports are available for the application, + separate tags should be defined for each transport. + + The intention is that the combination of application service and + protocol tags should be specific enough that finding a known pair + (e.g., "IM:ProtC") is sufficient for a client to identify a server + with which it can communicate. + + + + +Daigle & Newton Expires August 15, 2004 [Page 3] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + Some protocols support multiple application services. For example, + LDAP is an application protocol, and can be found supporting various + services (e.g., "whitepages", "directory enabled networking", etc). + +2.2 S-NAPTR DDDS Application Usage + + As outlined in Appendix A, NAPTR records are used to store + application service+protocol information for a given domain. + Following the DDDS standard, these records are looked up, and the + rewrite rules (contained in the NAPTR records) are used to determine + the successive DNS lookups, until a desirable target is found. + + For the rest of this section, refer to the set of NAPTR resource + records for example.com shown in the figure below. + + example.com. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "" "WP:whois++" "" bunyip.example. + IN NAPTR 100 20 "s" "WP:ldap" "" _ldap._tcp.myldap.example.com. + IN NAPTR 200 10 "" "IM:protA" "" someisp.example. + IN NAPTR 200 30 "a" "IM:protB" "" myprotB.example.com. + + +2.2.1 Ordering and Preference + + A client retrieves all of the NAPTR records associated with the + target domain name (example.com, above). These are to be sorted in + terms of increasing ORDER, and increasing PREF within each ORDER. + +2.2.2 Matching and non-Matching NAPTR Records + + Starting with the first sorted NAPTR record, the client examines the + SERVICE field to find a match. In the case of the S-NAPTR DDDS + application, that means a SERVICE field that includes the tags for + the desired application service and a supported application protocol. + + If more than one NAPTR record matches, they are processed in + increasing sort order. + +2.2.3 Terminal and Non-Terminal NAPTR Records + + A NAPTR record with an empty FLAG field is "non-terminal". That is, + more NAPTR RR lookups are to be performed. Thus, to process a NAPTR + record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is + used as the target of the next DNS lookup -- for NAPTR RRs. + + In S-NAPTR, the only terminal flags are "S" and "A". These are + called "terminal" NAPTR lookups because they denote the end of the + + + +Daigle & Newton Expires August 15, 2004 [Page 4] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + DDDS/NAPTR processing rules. In the case of an "S" flag, the + REPLACEMENT field is used as the target of a DNS query for SRV RRs, + and normal SRV processing is applied. In the case of an "A" flag, an + address record is sought for the REPLACEMENT field target (and the + default protocol port is assumed). + +2.2.4 S-NAPTR and Successive Resolution + + As shown in the example NAPTR RR set above, it is possible to have + multiple possible targets for a single application service+protocol + pair. These are to be pursued in order until a server is + successfully contacted or all possible matching NAPTR records have + been successively pursued to terminal lookups and servers contacted. + That is, a client must backtrack and attempt other resolution paths + in the case of failure. + + "Failure" is declared, and backtracking must be used when + + o the designated remote server (host and port) fail to provide + appropriate security credentials for the *originating* domain + + o connection to the designated remote server otherwise fails -- the + specifics terms of which are defined when an application protocol + is registered + + o the S-NAPTR-designated DNS lookup fails to yield expected results + -- e.g., no A RR for an "A" target, no SRV record for an "S" + target, or no NAPTR record with appropriate application service + and protocol for a NAPTR lookup. Except in the case of the very + first NAPTR lookup, this last is a configuration error: the fact + that example.com has a NAPTR record pointing to "bunyip.example" + for the "WP:Whois++" service and protocol means the administrator + of example.com believes that service exists. If bunyip.example + has no "WP:Whois++" NAPTR record, the application client MUST + backtrack and try the next available "WP:Whois++" option from + example.com. As there is none, the whole resolution fails. + + An application client first queries for the NAPTR RRs for the domain + of a named application service. The application client MUST select + one protocol to choose The PREF field of the NAPTR RRs may be used by + the domain administrator to The first DNS query is for the NAPTR RRs + in the original target domain (example.com, above). + +2.2.5 Clients Supporting Multiple Protocols + + In the case of an application client that supports more than one + protocol for a given application service, it MUST pursue S-NAPTR + resolution completely for one protocol before trying another.j It MAY + + + +Daigle & Newton Expires August 15, 2004 [Page 5] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + choose which protocol to try first based on its own preference, or + from the PREF ranking in the first set of NAPTR records (i.e., those + for the target named domain). However, the chosen protocol MUST be + listed in that first NAPTR RR set. + + That is, what the client MUST NOT do is start looking for one + protocol, observe that a successive NAPTR RR set supports another of + its preferred protocols, and continue the S-NAPTR resolution based on + that protocol. For example, even if someisp.example offers the "IM" + service with protocol "ProtB", there is no reason to believe it does + so on behalf of example.com (since there is no such pointer in + example.com's NAPTR RR set). + +3. Guidelines + +3.1 Guidelines for Application Protocol Developers + + The purpose of S-NAPTR is to provide application standards developers + with a more powerful framework (than SRV RRs alone) for naming + service targets, without requiring each application protocol (or + service) standard to define a separate DDDS application. + + Note that this approach is intended specifically for use when it + makes sense to associate services with particular domain names (e.g., + e-mail addresses, SIP addresses, etc). A non-goal is having all + manner of label mapped into domain names in order to use this. + + Specifically not addressed in this document is how to select the + domain for which the service+protocol is being sought. It is up to + other conventions to define how that might be used (e.g., instant + messaging standards can define what domain to use from IM URIs, how + to step down from foobar.example.com to example.com, and so on, if + that is applicable). + + Although this document proposes a DDDS application that does not use + all the features of NAPTR resource records, it does not mean to imply + that DNS resolvers should fail to implement all aspects of the NAPTR + RR standard. A DDDS application is a client use convention. + + The rest of this section outlines the specific elements that protocol + developers must determine and document in order to make use of S- + NAPTR. + +3.1.1 Registration of application service and protocol tags + + Application protocol developers that wish to make use of S-NAPTR must + make provision to register any relevant application service and + application protocol tags, as described in Section 6. + + + +Daigle & Newton Expires August 15, 2004 [Page 6] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +3.1.2 Definition of conditions for retry/failure + + One other important aspect that must be defined is the expected + behaviour for interacting with the servers that are reached via S- + NAPTR. Specifically, under what circumstances should the client + retry a target that was found via S-NAPTR? What should it consider a + failure that causes it to return to the S-NAPTR process to determine + the next serviceable target (a less preferred target)? + + For example, if the client gets a "connection refused" from a server, + should it retry for some (protocol-dependent) period of time? Or, + should it try the next-preferred target in the S-NAPTR chain of + resolution? Should it only try the next-preferred target if it + receives a protocol-specific permanent error message? + + The most important thing is to select one expected behaviour and + document it as part of the use of S-NAPTR. + + As noted earlier, failure to provide appropriate credentials to + identify the server as being authoritative for the original taret + domain is always considered a failure condition. + +3.1.3 Server identification and handshake + + As noted in Section 7, use of the DNS for server location increases + the importance of using protocol-specific handshakes to determine and + confirm the identity of the server that is eventually reached. + + Therefore, application protocol developers using S-NAPTR should + identify the mechanics of the expected identification handshake when + the client connects to a server found through S-NAPTR. + +3.2 Guidelines for Domain Administrators + + Although S-NAPTR aims to provide a "straightforward" application of + DDDS and use of NAPTR records, it is still possible to create very + complex chains and dependencies with the NAPTR and SRV records. + + Therefore, domain administrators are called upon to use S-NAPTR with + as much restraint as possible, while still achieving their service + design goals. + + The complete set of NAPTR, SRV and A RRs that are "reachable" through + the S-NAPTR process for a particular application service can be + thought of as a "tree". Each NAPTR RR retrieved points to more NAPTR + or SRV records; each SRV record points to several A record lookups. + Even though a particular client can "prune" the tree to use only + those records referring to application protocols supported by the + + + +Daigle & Newton Expires August 15, 2004 [Page 7] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + client, the tree could be quite deep, and retracing the tree to retry + other targets can become expensive if the tree has many branches. + + Therefore, + + o Fewer branches is better: for both NAPTR and SRV records, provide + different targets with varying preferences where appropriate + (e.g., to provide backup services, etc), but don't look for + reasons to provide more. + + o Shallower is better: avoid using NAPTR records to "rename" + services within a zone. Use NAPTR records to identify services + hosted elsewhere (i.e., where you cannot reasonably provide the + SRV records in your own zone). + + +3.3 Guidelines for Client Software Writers + + To properly understand DDDS/NAPTR, an implementor must read [6]. + However, the most important aspect to keep in mind is that, if one + target fails to work for the application, it is expected that the + application will continue through the S-NAPTR tree to try the (less + preferred) alternatives. + +4. Illustrations + +4.1 Use Cases + + The basic intended use cases for which S-NAPTR has been developed + are: + + o Service discovery within a domain. For example, this can be used + to find the "authoritative" server for some type of service within + a domain (see the specific example in Section 4.2). + + o Multiple protocols. This is increasingly common as new + application services are defined. This includes the case of + instant messaging (a service) which can be offered with multiple + protocols (see Section 4.3). + + o Remote hosting. Each of the above use cases applies within the + administration of a single domain. However, one domain operator + may elect to engage another organization to provide an application + service. See Section 4.4 for an example that cannot be served by + SRV records alone. + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 8] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +4.2 Service Discovery within a Domain + + There are occasions when it is useful to be able to determine the + "authoritative" server for a given application service within a + domain. This is "discovery", because there is no a priori knowledge + as to whether or where the service is offered; it is therefore + important to determine the location and characteristics of the + offered service. + + For example, there is growing discussion of having a generic + mechanism for locating the keys or certificates associated with + particular application (servers) operated in (or for) a particular + domain. Here's a hypothetical case for storing application key or + certificate data for a given domain. The premise is that some + credentials registry (CredReg) service has been defined to be a leaf + node service holding the keys/certs for the servers operated by (or + for) the domain. Furthermore, it is assumed that more than one + protocol is available to provide the service for a particular domain. + This DDDS-based approach is used to find the CredReg server that + holds the information. + + Thus, the set of NAPTR records for thinkingcat.example might look + like this: + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "" "CREDREG:ldap:iris-beep" "" theserver.thinkingcat.example. + + Note that another domain, offering the same application service, + might offer it using a different set of application protocols: + + anotherdomain.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "" "CREDREG:iris-lw:iris-beep" "" foo.anotherdomain.example. + + +4.3 Multiple Protocols + + As it stands, there are several different protocols proposed for + offering "instant message" services. Assuming that "IM" was + registered as an application service, this DDDS application could be + used to determine the available services for delivering to a target. + + Two particular features of instant messaging should be noted: + + 1. gatewaying is expected to bridge communications across protocols + + 2. instant messaging servers are likely to be operated out of a + + + +Daigle & Newton Expires August 15, 2004 [Page 9] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + different domain than the instant messaging address, and servers + of different protocols may be offered by independent + organizations + + For example, "thinkingcat.example" may support its own servers for + the "ProtA" instant messaging protocol, but rely on outsourcing from + "example.com" for "ProtC" and "ProtB" servers. + + Using this DDDS-based approach, thinkingcat.example can indicate a + preference ranking for the different types of servers for the instant + messaging service, and yet the out-sourcer can independently rank the + preference and ordering of servers. This independence is not + achievable through the use of SRV records alone. + + Thus, to find the IM services for thinkingcat.example, the NAPTR + records for thinkingcat.example are retrieved: + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. + IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com. + IN NAPTR 100 30 "s" "IM:ProtC" "" _ProtC._tcp.example.com. + + and then the administrators at example.com can manage the preference + rankings of the servers they use to support the ProtB service: + + _ProtB._tcp.example.com. + ;; Pref Weight Port Target + IN SRV 10 0 10001 bigiron.example.com + IN SRV 20 0 10001 backup.im.example.com + IN SRV 30 0 10001 nuclearfallout.australia-isp.example + + +4.4 Remote Hosting + + In the Instant Message hosting example in Section 4.3, the service + owner (thinkingcat.example) had to host pointers to the hosting + service's SRV records in the thinkingcat.example domain. + + A better way to approach this is to have one NAPTR RR in the + thinkingcat.example domain pointing to all the hosted services, and + the hosting domain has NAPTR records for each service to map them to + whatever local hosts it chooses (and may change from time to time). + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 10] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. + IN NAPTR 100 20 "" "IM:ProtB:ProtC" "" thinkingcat.example.com. + + + and then the administrators at example.com can break out the + individual application protocols and manage the preference rankings + of the servers they use to support the ProtB service (as before): + + thinkingcat.example.com. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtC" "" _ProtC._tcp.example.com. + IN NAPTR 100 20 "s" "IM:ProtB" "" _ProtB._tcp.example.com. + + + + _ProtC._tcp.example.com. + ;; Pref Weight Port Target + IN SRV 10 0 10001 bigiron.example.com + IN SRV 20 0 10001 backup.im.example.com + IN SRV 30 0 10001 nuclearfallout.australia-isp.example + + +4.5 Sets of NAPTR RRs + + Note that the above sections assumed that there was one service + available (via S-NAPTR) per domain. Often, that will not be the + case. Assuming thinkingcat.example had the CredReg service set up as + described in Section 4.2 and the instant messaging service set up as + described in Section 4.4, then a client querying for the NAPTR RR set + from thinkingcat.com would get the following answer: + + thinkingcat.example. + ;; order pref flags service regexp replacement + IN NAPTR 100 10 "s" "IM:ProtA" "" _ProtA._tcp.thinkingcat.example. + IN NAPTR 100 20 "" "IM:ProtB:ProtC:" "" thinkingcat.example.com. + IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" "" bouncer.thinkingcat.example. + + Sorting them by increasing "ORDER", the client would look through the + SERVICE strings to determine if there was a NAPTR RR that matched the + application service it was looking for, with an application protocol + it could use. The first (lowest PREF) record that so matched is the + one the client would use to continue. + +4.6 Sample sequence diagram + + Consider the example in Section 4.3. Visually, the sequence of steps + + + +Daigle & Newton Expires August 15, 2004 [Page 11] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + required for the client to reach the final server for a "ProtB" + service for IM for the thinkingcat.example domain is as follows: + + + Client NS for NS for + thinkingcat.example example.com backup.im.example.com + | | | + 1 -------->| | | + 2 <--------| | | + 3 ------------------------------>| | + 4 <------------------------------| | + 5 ------------------------------>| | + 6 <------------------------------| | + 7 ------------------------------>| | + 8 <------------------------------| | + 9 ------------------------------------------------->| + 10 <-------------------------------------------------| + 11 ------------------------------------------------->| + 12 <-------------------------------------------------| + (...) + + + + 1. the name server (NS) for thinkingcat.example is reached with a + request for all NAPTR records + + 2. the server responds with the NAPTR records shown in Section 4.3. + + 3. the second NAPTR record matches the desired criteria; that has an + "s" flag and a replacement fields of "_ProtB._tcp.example.com". + So, the client looks up SRV records for that target, ultimately + making the request of the NS for example.com. + + 4. the response includes the SRV records listed in Section 4.3. + + 5. the client attempts to reach the server with the lowest PREF in + the SRV list -- looking up the A record for the SRV record's + target (bigiron.example.com). + + 6. the example.com NS responds with an error message -- no such + machine! + + 7. the client attempts to reach the second server in the SRV list, + and looks up the A record for backup.im.example.com + + 8. the client gets the A record with the IP address for + backup.im.example.com from example.com's NS. + + + + +Daigle & Newton Expires August 15, 2004 [Page 12] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + 9. the client connects to that IP address, on port 10001 (from the + SRV record), using ProtB over tcp. + + 10. the server responds with an "OK" message. + + 11. the client uses ProtB to challenge that this server has + credentials to operate the service for the original domain + (thinkingcat.example) + + 12. the server responds, and the rest is IM. + + +5. Motivation and Discussion + + Increasingly, application protocol standards are using domain names + to identify server targets, and stipulating that clients should look + up SRV resource records to determine the host and port providing the + server. This enables a distinction between naming an application + service target and actually hosting the server. It also increases + flexibility in hosting the target service: + + o the server may be operated by a completely different organization + without having to list the details of that organization's DNS + setup (SRVs) + + o multiple instances can be set up (e.g., for load balancing or + secondaries) + + o it can be moved from time to time without disrupting clients' + access, etc. + + This is quite useful, but Section 5.1 outlines some of the + limitations inherent in the approach. + + That is, while SRV records can be used to map from a specific service + name and protocol for a specific domain to a specific server, SRV + records are limited to one layer of indirection, and are focused on + server administration rather than on application naming. And, while + the DDDS specification and use of NAPTR allows multiple levels of + redirection before locating the target server machine with an SRV + record, this proposal requires only a subset of NAPTR strictly bound + to domain names, without making use of the REGEXP field of NAPTR. + These restrictions make the client's resolution process much more + predictable and efficient than with some potential uses of NAPTR + records. This is dubbed "S-NAPTR" -- a "S"traightforward use of + NAPTR records. + + + + + +Daigle & Newton Expires August 15, 2004 [Page 13] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +5.1 So, why not just SRV records? + + An expected question at this point is: this is so similar in + structure to SRV records, why are we doing this with DDDS/NAPTR? + + Limitations of SRV include: + + o SRV provides a single layer of indirection -- the outcome of an + SRV lookup is a new domain name for which the A RR is to be found. + + o the purpose of SRV is focused on individual server administration, + not application naming: as stated in [5] "The SRV RR allows + administrators to use several servers for a single domain, to move + services from host to host with little fuss, and to designate some + hosts as primary servers for a service and others as backups." + + o target servers by "service" (e.g., "ldap") and "protocol" (e.g., + "tcp") in a given domain. The definition of these terms implies + specific things (e.g., that protocol should be one of UDP or TCP) + without being precise. Restriction to UDP and TCP is insufficient + for the uses described here. + + The basic answer is that SRV records provide mappings from protocol + names to host and port. The use cases described herein require an + additional layer -- from some service label to servers that may in + fact be hosted within different administrative domains. We could + tweak SRV to say that the next lookup could be something other than + an address record, but that is more complex than is necessary for + most applications of SRV. + +5.2 So, why not just NAPTR records? + + That's a trick question. NAPTR records cannot appear in the wild -- + see [6]. They must be part of a DDDS application. + + The purpose here is to define a single, common mechanism (the DDDS + application) to use NAPTR when all that is desired is simple DNS- + based location of services. This should be easy for applications to + use -- some simple IANA registrations and it's done. + + Also, NAPTR has very powerful tools for expressing "rewrite" rules. + That power (==complexity) makes some protocol designers and service + administrators nervous. The concern is that it can translate into + unintelligible, noodle-like rule sets that are difficult to test and + administer. + + This proposed DDDS application specifically uses a subset of NAPTR's + abilities. Only "replacement" expressions are allowed, not "regular + + + +Daigle & Newton Expires August 15, 2004 [Page 14] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + expressions". + +6. IANA Considerations + + This document calls for 2 IANA registries: one for application + service tags, and one for application protocol tags. + + Application service and protocol tags should be defined in an RFC + (unless the "x-" experimental form is used, in which case they are + unregistered). There are no restrictions placed on the tags other + than that they must conform with the syntax defined below (Appendix + A.5). The IANA registries should list the tags and the RFC that + defines their use. + +7. Security Considerations + + The security of this approach to application service location is only + as good as the security of the DNS servers along the way. If any of + them is compromised, bogus NAPTR and SRV records could be inserted to + redirect clients to unintended destinations. This problem is hardly + unique to S-NAPTR (or NAPTR in general). + + To protect against DNS-vectored attacks, applications should define + some form of end-to-end authentication to ensure that the correct + destination has been reached. Many application protocols such as + HTTPS, BEEP, IMAP, etc... define the necessary handshake mechansims + to accomplish this task. + + The basic mechanism works in the following way: + + 1. During some portion of the protocol handshake, the client sends + to the server the original name of the desired destination (i.e. + no transformations that may have resulted from NAPTR + replacements, SRV targets, or CNAME changes). In certain cases + where the application protocol does not have such a feature but + TLS may be used, it is possible to use the "server_name" TLS + extension. + + 2. The server sends back to the client a credential with the + appropriate name. For X.509 certificates, the name would either + be in the subjectDN or subjectAltName fields. For Kerberos, the + name would be a service principle name. + + 3. Using the matching semantics defined by the application protocol, + the client compares the name in the credential with the name sent + to the server. + + 4. If the names match, there is reasonable assurance that the + + + +Daigle & Newton Expires August 15, 2004 [Page 15] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + correct end point has been reached. + + It is important to note that this document does not define either the + handshake mechanism, the specific credenential naming fields, nor the + name matching semantics. Definitions of S-NAPTR for particular + application protocols MUST define these. + +8. Acknowledgements + + Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd for + discussion and input that has (hopefully!) provoked clarifying + revisions of this document. + +References + + [1] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource + Identifiers (URI): Generic Syntax", RFC 2396, August 1998. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [4] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + + [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + One: The Comprehensive DDDS", RFC 3401, October 2002. + + [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Three: The Domain Name System (DNS) Database", RFC 3403, October + 2002. + + [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part + Four: The Uniform Resource Identifiers (URI)", RFC 3404, October + 2002. + + + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 16] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +Authors' Addresses + + Leslie Daigle + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + EMail: leslie@verisignlabs.com; leslie@thinkingcat.com + + + Andrew Newton + VeriSign, Inc. + 21355 Ridgetop Circle + Dulles, VA 20166 + US + + EMail: anewton@verisignlabs.com + +Appendix A. Application Service Location Application of DDDS + + This section defines the DDDS application, as described in [6]. + +A.1 Application Unique String + + The Application Unique String is domain label for which an + authoritative server for a particular service is sought. + +A.2 First Well Known Rule + + The "First Well Known Rule" is identity -- that is, the output of the + rule is the Application Unique String, the domain label for which the + authoritative server for a particular service is sought. + +A.3 Expected Output + + The expected output of this Application is the information necessary + to connect to authoritative server(s) (host, port, protocol) for an + application service within a given a given domain. + +A.4 Flags + + This DDDS Application uses only 2 of the Flags defined for the + URI/URN Resolution Application ([8]): "S" and "A". No other Flags + are valid. + + Both are for terminal lookups. This means that the Rule is the last + one and that the flag determines what the next stage should be. The + + + +Daigle & Newton Expires August 15, 2004 [Page 17] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + "S" flag means that the output of this Rule is a domain label for + which one or more SRV [5] records exist. "A" means that the output + of the Rule is a domain name and should be used to lookup address + records for that domain. + + Consistent with the DDDS algorithm, if the Flag string is empty the + next lookup is for another NAPTR record (for the replacement target). + +A.5 Service Parameters + + Service Parameters for this Application take the form of a string of + characters that follow this ABNF ([3]): + + service-parms = [ [app-service] *(":" app-protocol)] + app-service = experimental-service / iana-registered-service + app-protocol = experimental-protocol / iana-registered-protocol + experimental-service = "x-" 1*30ALPHANUMSYM + experimental-protocol = "x-" 1*30ALPHANUMSYM + iana-registered-service = ALPHA *31ALPHANUMSYM + iana-registered-protocol = ALPHA *31ALPHANUM + ALPHA = %x41-5A / %x61-7A ; A-Z / a-z + DIGIT = %x30-39 ; 0-9 + SYM = %x2B / %x2D / %x2E ; "+" / "-" / "." + ALPHANUMSYM = ALPHA / DIGIT / SYM + ; The app-service and app-protocol tags are limited to 32 + ; characters and must start with an alphabetic character. + ; The service-parms are considered case-insensitive. + + Thus, the Service Parameters may consist of an empty string, just an + app-service, or an app-service with one or more app-protocol + specifications separated by the ":" symbol. + + Note that this is similar to, but not the same as the syntax used in + the URI DDDS application ([8]). The DDDS DNS database requires each + DDDS application to define the syntax of allowable service strings. + The syntax here is expanded to allow the characters that are valid in + any URI scheme name (see [1]). Since "+" (the separator used in the + RFC3404 service parameter string) is an allowed character for URI + scheme names, ":" is chosen as the separator here. + +A.5.1 Application Services + + The "app-service" must be a registered service [this will be an IANA + registry; this is not the IANA port registry, because we want to + define services for which there is no single protocol, and we don't + want to use up port space for nothing]. + + + + + +Daigle & Newton Expires August 15, 2004 [Page 18] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +A.5.2 Application Protocols + + The protocol identifiers that are valid for the "app-protocol" + production are any standard, registered protocols [IANA registry + again -- is this the list of well known/registered ports?]. + +A.6 Valid Rules + + Only substitution Rules are permitted for this application. That is, + no regular expressions are allowed. + +A.7 Valid Databases + + At present only one DDDS Database is specified for this Application. + [7] specifies a DDDS Database that uses the NAPTR DNS resource record + to contain the rewrite rules. The Keys for this database are encoded + as domain-names. + + The First Well Known Rule produces a domain name, and this is the Key + that is used for the first lookup -- the NAPTR records for that + domain are requested. + + DNS servers MAY interpret Flag values and use that information to + include appropriate NAPTR, SRV or A 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. See + the Additional Information Processing section of [7] for more + information on NAPTR records and the Additional Information section + of a DNS response packet. + +Appendix B. Pseudo pseudocode for S-NAPTR + +B.1 Finding the first (best) target + + Assuming the client supports 1 protocol for a particular application + service, the following pseudocode outlines the expected process to + find the first (best) target for the client, using S-NAPTR. + + + target = [initial domain] + naptr-done = false + + while (not naptr-done) + { + NAPTR-RRset = [DNSlookup of NAPTR RRs for target] + [sort NAPTR-RRset by ORDER, and PREF within each ORDER] + rr-done = false + cur-rr = [first NAPTR RR] + + + +Daigle & Newton Expires August 15, 2004 [Page 19] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + while (not rr-done) + if ([SERVICE field of cur-rr contains desired application + service and application protocol]) + rr-done = true + target= [REPLACEMENT target of NAPTR RR] + else + cur-rr = [next rr in list] + + if (not empty [FLAG in cur-rr]) + naptr-done = true + } + + port = -1 + + if ([FLAG in cur-rr is "S"]) + { + SRV-RRset = [DNSlookup of SRV RRs for target] + [sort SRV-RRset based on PREF] + target = [target of first RR of SRV-RRset] + port = [port in first RR of SRV-RRset] + } + + ; now, whether it was an "S" or an "A" in the NAPTR, we + ; have the target for an A record lookup + + host = [DNSlookup of target] + + return (host, port) + + + +B.2 Finding subsequent targets + + The pseudocode in Appendix B is crafted to find the first, most + preferred, host-port pair for a particular application service an + protocol. If, for any reason, that host-port pair did not work + (connection refused, application-level error), the client is expected + to try the next host-port in the S-NAPTR tree. + + The pseudocode above does not permit retries -- once complete, it + sheds all context of where in the S-NAPTR tree it finished. + Therefore, client software writers could + + o entwine the application-specific protocol with the DNS lookup and + RRset processing described in the pseudocode and continue the S- + NAPTR processing if the application code fails to connect to a + located host-port pair; + + + + +Daigle & Newton Expires August 15, 2004 [Page 20] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + + o use callbacks for the S-NAPTR processing; + + o use an S-NAPTR resolution routine that finds *all* valid servers + for the required application service and protocol from the + originating domain, and provides them in sorted order for the + application to try in order. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 21] + +Internet-Draft draft-daigle-napstr-04 February 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). 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. + + + + + + + + + + + + + + + + + + + +Daigle & Newton Expires August 15, 2004 [Page 22] + |