Network Working Group L. Daigle Internet-Draft A. Newton Expires: August 23, 2002 VeriSign, Inc. February 22, 2002 NAPSTR: A constrained use of NAPTR and SRV RRs for domain-based service location draft-daigle-napstr-00.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 23, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines a use of NAPTR records [3] to provide one more layer of redirection for service lookup than is feasible with SRV records. Some will view this as a dangerous use of DNS. 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. 1. Introduction It is currently becoming popular to stipulate, within new protocols, Daigle & Newton Expires August 23, 2002 [Page 1] Internet-Draft draft-daigle-napstr-00 February 2002 the use of SRV records to locate a particular server within a domain. This enables the use of several servers to support a single application in a domain, but it does not facilitate the redirection from one domain to another that fulfills the service. (E.g., when a small company's SIP services are supported by its ISP's SIP servers). This is discussed more fully in section [3.1]. This document defines a DDDS [4] Application to map service+protocol+domain to specific server addresses using NAPTR 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. Specifically, the use of NAPTR allows multiple levels of redirection before locating the target server machine with an SRV record. However, this use of NAPTR is bound strictly to domain names, and does not make use of the REGEXP field of NAPTR, which makes the resolution process much more predictable (prefetchable, cachable) than with some uses of NAPTR records. As an illustration of this approach, this document also discusses the possibility of using NAPSTR to follow "chains of trust" in DNSSEC to find key servers for individual applications, without having to store the application keys directly in DNS. 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). 2. Basic Proposal The precise details of the specification of this profiled use of NAPTR 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. For the purposes of this proposal, and "application service" is an IANA-registered tag associated with a type of application. For example, instant messaging is a type of application, which is implemented by many different application-layer protocols, and the Daigle & Newton Expires August 23, 2002 [Page 2] Internet-Draft draft-daigle-napstr-00 February 2002 tag "IM" (used as an illustration here) could be registered for it. An "application protocol" is a standard protocol used to implement the application service. Note that such a protocol may be used to implement several different application services. For example, LDAP is a general purpose directory protocol that can be used to implement a so-called whitepages directory of personal information, or to locate network service information ("directory enabled networking"), etc. 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 3.1 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 NAPSTR 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: [Need to do something about application collision -- does this need to be something like "_srvnaptr.thinkingcat.com", changing the First Well Known Rule?] Daigle & Newton Expires August 23, 2002 [Page 3] Internet-Draft draft-daigle-napstr-00 February 2002 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 3.2 Application Key Storage 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 AppKey service has been defined to be a leaf node service holding the keys/certs for the servers operated by (or for) the domain. NAPSTR is used to find the AppKey server that holds the information. thinkingcat.com. ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "AppKey+LDAP" "" ldap.tcp.thinkingcat.com IN NAPTR 100 20 "s" "AppKey+LDAP" "" ldap.tcp.example.com 4. Transiting Trust One issue to be considered in the use of this proposal is the matter of trusting an end server once resolution of the end server's IP address is completed. This can pose a problem when used with the popular model of trusting an end server in use on the Internet today, TLS. Consider the following example of electronic commerce for which a user must make a trust association to an end server. 1. The end-user types into the browser the name of the server, for example "www.thinkingcat.com". 2. The server sends to the client its certificate and certificate chain information. Daigle & Newton Expires August 23, 2002 [Page 4] Internet-Draft draft-daigle-napstr-00 February 2002 3. The client verifies the server's certificate via the certificate chain. 4. The client compares the domain name in the server's certificate to the domain name it was given. 5. The client sends the session key encrypted with the server's public key back to the server. 6. If the server is really the server it claims to be, then it will possess the corresponding private key to use in decrypting the session key. 7. The server and client communicate using encrypted means via the session key. However, the necessity for the client to compare the domain it was given with the domain name found in the certificate (step 4) can be problematic when the name resolution process changes the domain name being sought. This problem can be solved using one of the two methods outlined below. For full transition of trust using TLS, each method requires the use of DNSSEC [1] to insure the SRV and NAPTR records have not been compromised. Neither method requires any change to either the TLS or DNSSEC protocols. 4.1 Using the Translated Name The first method is a simple modification of the client's use of the domain name in comparison with the name present in the certificate. The following is a modification of the process outlined above. 1. The end-user types into the client application the name of the server. For this example, the client application is a PRIM client and the name of the server is "thinkingcat.com". 2. During the name resolution process for the PRIM service of "thinkingcat.com", the NAPTR record will yield the name "prim.tcp.example.com". The client must remember this as the translated name. 3. The server, bigiron.example.com, sends to the client its certificate for "prim.tcp.example.com" and certificate chain information. 4. The client verifies the server's certificate via the certificate chain. 5. The client compares the translated name from the resolution Daigle & Newton Expires August 23, 2002 [Page 5] Internet-Draft draft-daigle-napstr-00 February 2002 process, "prim.tcp.example.com", with the name found in the certificate, "prim.tcp.example.com". 6. The client sends the session key encrypted with the server's public key back to the server. 7. If the server is really one of the servers for "prim.tcp.example.com", then it will possess the corresponding private key to use in decrypting the session key. 8. The server and client communicate using encrypted means via the session key. Note that the translated name is taken from the NAPTR record and not the SRV record. This is done because the use-case is such that the user is interested in the PRIM service for "thinkingcat.com" and not the particular server where it is hosted. 4.2 Trusting the DNS Signer Due to the fact that DNSSEC must already be used to trust this name resolution process, another method is to simply use the certificate chain for the certificate that is present in DNS. The following steps illustrate this process. 1. The end-user types into the PRIM application the name "thinkingcat.com". 2. The final outcome of the name resolution process will yield an A record containing the IP address for "bigiron.example.com". 3. The server sends to the client its certificate. The certificate chain for this certificate leads to the signer for the A record (the certificate is signed using the same private key as the A record). 4. The client verifies the server's certificate using the same public key of the A record for "bigiron.example.com". 5. The client sends the session key encrypted with the server's public key back to the server. 6. If the server is really bigiron.example.com, then it will possess the corresponding private key to use in decrypting the session key. 7. The server and client communicate using encrypted means via the session key. Daigle & Newton Expires August 23, 2002 [Page 6] Internet-Draft draft-daigle-napstr-00 February 2002 5. 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 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 [2] "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. 6. So, why not just NAPTR records? That's a trick question. NAPTR records cannot appear in the wild -- see RFCWWWW. They must be part of a DDDS application. The purpose here is to define a single, common mechanism 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 its 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 unintelligle, noodle-like rule sets that are difficult to test and administer. Daigle & Newton Expires August 23, 2002 [Page 7] Internet-Draft draft-daigle-napstr-00 February 2002 This proposal specifically uses a profile of NAPTR's abilities. Only "replacement" expressions are allowed, not "regular expressions". 7. IANA Considerations ?? Fill out with specifics for registering "application service" tags (and "application protocols", if this is something other than the existing port registry). 8. Security Considerations This is primarily addressed in the "Transiting Trust" section. References [1] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", May 2000. [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard draft-ietf-urn-ddds-toc- 01.txt", January 2002. 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 Daigle & Newton Expires August 23, 2002 [Page 8] Internet-Draft draft-daigle-napstr-00 February 2002 Appendix A. Generic Service Lookup Application of DDDS This section defines the DDDS application, as described in [4]. A.1 Application Unique String The Application Unique String is the name of the domain in 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 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 ([4]): "S" and "A". No other Flags are valid. Both "S" and "A" 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-name for which one or more SRV [2] 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. A.5 Services Parameters Service Parameters for this Application take the form of a string of characters that follow this ABNF ([4]): service-parms = [ [app-service] *("+" app-protocol)] app-service = ALPHA *31ALPHANUM app-protocol = ALPHA *31ALPHANUM ; The app-service and app-protocol fields are limited to 32 ; characters and must start with an alphabetic character. 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. Daigle & Newton Expires August 23, 2002 [Page 9] Internet-Draft draft-daigle-napstr-00 February 2002 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, no regular expressions are allowed. A.7 Valid Databases At present only one DDDS Database is specified for this Application. "Dynamic Delegation Discovery System (DDDS) Part Three: The DNS Database" [4] 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 RFC WWWW for more information on NAPTR records and the Additional Information section of a DNS response packet. Daigle & Newton Expires August 23, 2002 [Page 10] Internet-Draft draft-daigle-napstr-00 February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 23, 2002 [Page 11]