Network Working Group L. Daigle Internet-Draft Cisco Systems Expires: December 21, 2006 June 19, 2006 Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS) draft-daigle-unaptr-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The purpose of this memo is to provide a small extension to the "Straightforward NAPTR" (S-NAPTR) Dynamic Delegation Discovery System (DDDS) Application so that URIs can be offered as the target of the DDDS resolution. It is not yet clear (in this -00 draft) whether that is best achievedby extending the S-NAPTR specification, or by providing a new DDDS Application. This version of the draft focuses on describing Daigle Expires December 21, 2006 [Page 1]
Internet-Draft draft-daigle-unaptr-00 June 2006 the extension and pros/cons of either approach. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Straightforward URI-enabled NAPTR (U-NAPTR) Specification . . . 3 2.1. Permitted Flags . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Permitted Regular Expressions . . . . . . . . . . . . . . . 3 3. Sample U-NAPTR DNS records . . . . . . . . . . . . . . . . . . 4 4. Update or Replace S-NAPTR? . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Daigle Expires December 21, 2006 [Page 2]
Internet-Draft draft-daigle-unaptr-00 June 2006 1. Introduction The goal of this document is to provide an extention to the Straightforward NAPTR (S-NAPTR) specification found in [13] to allow URIs as targets. S-NAPTR provides for application service location that does not rely on rigid domain naming conventions. It is deemed "straightforward" in part because it rules out the use of regular expressions in NAPTR records (for the S-NAPTR DDDS Application). However, that also rules out the possibility of providing a URI as the target of DDDS resolution, and a number of applications, specified ([12]) and proposed, find the restriction too limiting, making S-NAPTR a near miss to suit their needs. This memo proposes a modest extension to S-NAPTR, to accommodate the use of URIs as targets, without allowing the full range of possible regular expressions in NAPTR records. The implications of approaching this as an update of S-NAPTR or a new DDDS application altogether are discussed. 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 ([1]). 2. Straightforward URI-enabled NAPTR (U-NAPTR) Specification This document assumes the reader is familiar with the S-NAPTR specification ([13]). The intention of U-NAPTR is to provide everything that S-NAPTR does, except that it allows the use of the "U" flag in the NAPTR record, and a specific form of REGEXP. 2.1. Permitted Flags U-NAPTR permits the same flags as S-NAPTR plus the "U" Flag. For the U-NAPTR DDDS Application, the presence of the "U" Flag in the NAPTR record indicates the REGEXP field must be populated (and, consequently, the REPLACEMENT field is empty). The regular expression in the REGEXP field must be of the limited form described below, and the result of the regular expression evaluation will be a URI that is the result of the DDDS resolution. 2.2. Permitted Regular Expressions U-NAPTR permits regular expressions of a form that does a complete replacement of the matched string with a URI, expressed as a constant string. This is essentially a dodge around the fact that the Daigle Expires December 21, 2006 [Page 3]
Internet-Draft draft-daigle-unaptr-00 June 2006 REPLACEMENT field in NAPTR is required to produce only a fully qualified domain name (and, therefore, cannot be used for a URI). The specific allowed syntax for U-NAPTR regular expressions is: u-naptr-regexp = "!.*!"<URI>"!" <URI> = (as defined in [14] , current URI syntax) With this limited form of regular expression, applications using U-NAPTR need not implement full regular expression parsers. 3. Sample U-NAPTR DNS records In the sample NAPTR RRs for example.com shown below, "WP" is the imagined application service tag for "white pages", and "EM" is the application service tag for an imagined "Extensible Messaging" application service. example.com. ;; order pref flags IN NAPTR 100 10 "" "WP:whois++" ( ; service "" ; regexp bunyip.example.com. ; replacement ) IN NAPTR 100 20 "s" "WP:ldap" ( ; service "" ; regexp _ldap._tcp.myldap.example.com. ; replacement ) IN NAPTR 200 10 "" "EM:protA" ( ; service "!*.!prota://someisp.example.com!" ; regexp "" ; replacement ) IN NAPTR 200 30 "a" "EM:protB" ; service "" ; regexp myprotB.example.com.; replacement ) 4. Update or Replace S-NAPTR? There are 2 obvious ways to implement the functionality described in this memo. The first approach would be to declare U-NAPTR an extension of S-NAPTR, and have this specification formally "update" the S-NAPTR Daigle Expires December 21, 2006 [Page 4]
Internet-Draft draft-daigle-unaptr-00 June 2006 RFC. The implication would be instant access to all S-NAPTR registered Application Services and Application Protocols, and no question of a new IANA registry. However, it goes against the S-NAPTR specification, which specificallly requires the "REGEXP" field of the NAPTR record to be empty. This would not be a change that is backwards compatible with existing S-NAPTR implementations. Alternatively, U-NAPTR could be written as a completely separate DDDS Application, copying text from the S-NAPTR application and adding the 2 U-NAPTR specific bits. This would likely imply the need to create a new set of IANA registries, for U-NAPTR aware Application Services and Application Protocols. This would be an unpleasant amount of overhead, but would be backwards compatible with existing S-NAPTR implementations (because they are completely separate), and would allow application protocol designers to choose whether S-NAPTR or U-NAPTR fit their requirements. Perhaps the best approach is to make U-NAPTR an update of S-NAPTR, updating the IANA registry to include an indication of whether an Application Service expects S-NAPTR or supports U-NAPTR (i.e., is findable with or without "U" flags). And, existing registrations are assumed to be "S-NAPTR" unless otherwise updated. 5. IANA Considerations It's not yet clear whether this memo will incur any IANA actions. 6. Security Considerations U-NAPTR has the same considerations for security as S-NAPTR, and the additional consideration that resolving URIs (from the result of the DDDS resolution) has its own set of security implications, covered in the URI specfication. In essence, using DNSSEC, client software can be confident that the URI obtained using U-NAPTR is indeed the one specified by the administrator of the domain from which it was retrieved; but the validity of the service reached by resolving that URI is a matter of URI resolution security practices. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Daigle Expires December 21, 2006 [Page 5]
Internet-Draft draft-daigle-unaptr-00 June 2006 [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the locatio n of services (DNS SRV)", RFC 2782, February 2000. [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002. [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 7.2. Informative References [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [9] Newton, A. and M. Sanz, "IRIS Domain Registry Schema", draft-ietf-crisp-iris-dreg-06 (work in progress), April 2004. [10] Newton, A. and M. Sanz, "Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", draft-ietf-crisp-iris-beep-04 (work in progress), April 2004. [11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name System", draft-ietf-dnsext-dns-threats-07 (work in progress), April 2004. [12] Malamud, C., "Attaching Meaning to Solicitation Class Keywords", RFC 4095, May 2005. [13] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005. [14] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, Daigle Expires December 21, 2006 [Page 6]
Internet-Draft draft-daigle-unaptr-00 June 2006 January 2005. [15] Arends, R., Larson, M., Austein, R., and D. Massey, "Protocol Modifications for the DNS Security Extensions", draft-ietf-dnsext-dnssec-protocol-06 (work in progress), May 2004. Daigle Expires December 21, 2006 [Page 7]
Internet-Draft draft-daigle-unaptr-00 June 2006 Author's Address Leslie L. Daigle Cisco Systems 13600 Dulles Technology Drive Herndon, VA 20171 US Email: ledaigle@cisco.com; leslie@thinkingcat.com Daigle Expires December 21, 2006 [Page 8]
Internet-Draft draft-daigle-unaptr-00 June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Daigle Expires December 21, 2006 [Page 9]
