Network Working Group L. Daigle Internet-Draft A. Newton Expires: December 5, 2003 VeriSign, Inc. June 6, 2003 Domain-based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS) draft-daigle-napstr-02.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 December 5, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines a Dynamic Delegation Discovery System (DDDS) [5] Application for domain name based discovery of application services. Essentially, this uses DNS NAPTR resource records [6] to provide one more layer of redirection for service lookup than is feasible with SRV ([4]) records. It is proposed because real-life use is demonstrating a need for something slightly more substantial than SRV, and alternatively SRV usage may become twisted out of its intended shape. Daigle & Newton Expires December 5, 2003 [Page 1] Internet-Draft draft-daigle-napstr-02 June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 What this document means for application protocol developers 4 2. Basic Proposal . . . . . . . . . . . . . . . . . . . . . . . 4 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Credentials Registry Network . . . . . . . . . . . . . . . . 5 3.2 Instant Messaging Services . . . . . . . . . . . . . . . . . 6 3.3 Separation of Application Protocol Selection and Hosting . . 7 3.4 Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . . . 7 4. So, why not just SRV records? . . . . . . . . . . . . . . . 8 5. So, why not just NAPTR records? . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 10 A. Application Service Location Application of DDDS . . . . . . 11 A.1 Application Unique String . . . . . . . . . . . . . . . . . 11 A.2 First Well Known Rule . . . . . . . . . . . . . . . . . . . 11 A.3 Expected Output . . . . . . . . . . . . . . . . . . . . . . 11 A.4 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 A.5 Service Parameters . . . . . . . . . . . . . . . . . . . . . 12 A.5.1 Application Services . . . . . . . . . . . . . . . . . . . . 12 A.5.2 Application Protocols . . . . . . . . . . . . . . . . . . . 12 A.6 Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 12 A.7 Valid Databases . . . . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 Daigle & Newton Expires December 5, 2003 [Page 2] Internet-Draft draft-daigle-napstr-02 June 2003 1. Introduction Increasingly, application protocol standards are using domain names to identify server targets, and stipulating that clients should look up SRV ([4]) 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 -- the server may be operated by a completely different organization without having to delegate some portion of the zone, multiple instances can be set up (e.g., for load balancing or secondaries), it can be moved from time to time without disrupting clients' access, etc. This is quite useful, but Section 4 outlines some of the limitations inherent in the approach. To address some of the limitations, this document defines a DDDS [5] Application to map service+protocol+domain to specific server addresses using both NAPTR [6] and SRV 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. 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 (prefetchable, cachable) than with some uses of NAPTR records. This is dubbed "NAPSTR" -- a "S"traightforward use of NAPTR records. For the purposes of this document: o an "application service" is a generic term for some generic type of application, independent of the protocol that may be used to offer it. o an "application protocol" is an IANA-registered tag associated with a protocol (and application tranpsort protocol, if several are available for the application) used to implement one or several services For example, "e-mail" is an application service; "SMTP" is the protocol that is used to implement it. "Instant Messaging" is an application service, for which there are several existing and Daigle & Newton Expires December 5, 2003 [Page 3] Internet-Draft draft-daigle-napstr-02 June 2003 proposed application protocols ("jabber", "simple", etc). "LDAP" is an application protocol which can be used to implement several different application services (e.g., a "whitepages" service, directory enabled networking service, etc). 1.1 What this document means for application protocol developers The purpose of this document 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. 2. Basic Proposal The precise details of the specification of this DDDS application are given in Appendix A. In general, the proposal is to store application service and protocol descriptions in NAPTR records for individual domains. This will enable domain administrators to provide redirection to other domains that provision individual services, with appropriate weightings and preferences. Each "application service" will be associated with an IANA-registered tag. For example, instant messaging is a type of application, which is implemented by many different application-layer protocols, and the tag "IM" (used as an illustration here) could be registered for it. An "application protocol" tag represents a protocol used to implement the application service. In the case where multiple transports are available for the application, separate tags should be defined for each transport. Daigle & Newton Expires December 5, 2003 [Page 4] Internet-Draft draft-daigle-napstr-02 June 2003 The intention is that the combination of application service and protocol tags should be specific enough that finding a known pair (e.g., "IM:simple") is sufficient for a client to identify a server with which it can communicate. 3. Examples Section 3.1 illustrates the use of NAPSTR to express the list of available application protocols to provide a particular service. A chief purpose of NAPSTR is to allow a layer of indirection between service naming and service operation that is not possible with SRV RRs alone. The example in Section 3.2 illustrates this. Section 3.3 revisits the first example to illustrate the power of NAPSTR in separating the choice of available protocols (which the service owner selects) from the choice and preference of running them (which the hosting service establishes). 3.1 Credentials Registry Network 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.com might look like this: thinkingcat.com. ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "CREDREG:ldap:iris-beep" "" credreg.thinkingcat.com. Note that another domain, offering the same application service, might offer it using a different set of application protocols: anotherdomain.com. ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "CREDREG:iris-lw:iris-beep" "" credreg.anotherdomain.com. Daigle & Newton Expires December 5, 2003 [Page 5] Internet-Draft draft-daigle-napstr-02 June 2003 3.2 Instant Messaging Services 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 different domain than the instant messaging address, and servers of different protocols may be offered by independent organizations For example, "thinkingcat.com" may support its own servers for the "apex" instant messaging protocol, but rely on outsourcing from "example.com" for "simple" and "prim" servers. Using this DDDS-based approach, thinkingcat.com 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.com, the NAPTR records for thinkingcat.com are retrieved: thinkingcat.com. ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "IM:apex" "" _apex._tcp.thinkingcat.com. IN NAPTR 100 20 "s" "IM:prim" "" _prim._tcp.example.com. IN NAPTR 100 30 "s" "IM:simple" "" _simple._tcp.example.com. and then the administrators at example.com can manage the preference rankings of the servers they use to support the prim service: _prim._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.example.com.au Daigle & Newton Expires December 5, 2003 [Page 6] Internet-Draft draft-daigle-napstr-02 June 2003 3.3 Separation of Application Protocol Selection and Hosting In the Instant Message hosting example in Section 3.2, the service owner (thinkingcat.com) had to host pointers to the hosting service's SRV records in the thinkingcat.com domain. If the owner domain does not have any preference about which application protocol is used, a better way to approach this is to have one NAPTR RR in the thinkingcat.com 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). thinkingcat.com. ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "IM:apex" "" _apex._tcp.thinkingcat.c om. IN NAPTR 100 20 "" "IM:Prim:Simple" "" 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 prim service (as before): thinkingcat.example.com. ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "IM:simple" "" _simple._tcp.example.c om. IN NAPTR 100 20 "s" "IM:prim" "" _prim._tcp.example.com. _prim._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.example.com.au 3.4 Sets of NAPTR RRs Note that the above sections assumed that there was one service available (via NAPSTR) per domain. Often, that will not be the case. Assuming thinkingcat.com had the CredReg service set up as described in Section 3.1 and the instant messaging service set up as described in Section 3.3, then a client querying for the NAPTR RR set from thinkingcat.com would get the following answer: Daigle & Newton Expires December 5, 2003 [Page 7] Internet-Draft draft-daigle-napstr-02 June 2003 thinkingcat.com. ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "IM:apex" "" _apex._tcp.thinkingcat.c om. IN NAPTR 100 20 "" "IM:Prim:Simple" "" thinkingcat.example.com. IN NAPTR 100 10 "" "CREDREG:ldap:iris-beep" "" credreg.thinkingcat.com. Since they all have the same ORDER value, 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. 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 [4] "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. So, why not just NAPTR records? That's a trick question. NAPTR records cannot appear in the wild -- see [5]. They must be part of a DDDS application. Daigle & Newton Expires December 5, 2003 [Page 8] Internet-Draft draft-daigle-napstr-02 June 2003 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 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 NAPSTR (or NAPTR in general). Applications should use some form of server authentication to ensure that the correct destination has been reached. There is a more general problem that any kind of service redirection or overloading (e.g., apache http servers offering service for multiple domains) increases the likelihood that the primary hostname of the final server will not match the string that the client originally looked up in the DNS. The appropriate action is for the application protocol (transport) to allow the client to challenge the server for the certificate of the domain sought, and use that to establish the authenticity of the server itself. Daigle & Newton Expires December 5, 2003 [Page 9] Internet-Draft draft-daigle-napstr-02 June 2003 8. Acknowledgements Many thanks to Patrik Faltstrom and 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] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. Authors' Addresses Leslie Daigle VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US EMail: leslie@verisignlabs.com; leslie@thinkingcat.com Daigle & Newton Expires December 5, 2003 [Page 10] Internet-Draft draft-daigle-napstr-02 June 2003 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 [5]. 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 3 of the Flags defined for the URI/URN Resolution Application ([7]): "S", "A" and "U". No other Flags are valid. All three 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 "S" flag means that the output of this Rule is a domain label for which one or more SRV [4] 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. "U" means that the output of the Rule is a URI which should be resolved. Consistent with the DDDS algorithm, if the Flag string is empty the next lookup is for another NAPTR record (for the replacement target). Daigle & Newton Expires December 5, 2003 [Page 11] Internet-Draft draft-daigle-napstr-02 June 2003 A.5 Service Parameters Service Parameters for this Application take the form of a string of characters that follow this ABNF ([2]): 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 ([7]). 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]. 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, Daigle & Newton Expires December 5, 2003 [Page 12] Internet-Draft draft-daigle-napstr-02 June 2003 no regular expressions are allowed. A.7 Valid Databases At present only one DDDS Database is specified for this Application. [6] 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 [6] for more information on NAPTR records and the Additional Information section of a DNS response packet. Daigle & Newton Expires December 5, 2003 [Page 13] Internet-Draft draft-daigle-napstr-02 June 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). 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 December 5, 2003 [Page 14]