GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4848

Network Working Group L. Daigle Request for Comments: 4848 Cisco Systems Category: Standards Track April 2007

      Domain-Based Application Service Location Using URIs and
          the Dynamic Delegation Discovery Service (DDDS)

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The IETF Trust (2007).

Abstract

 The purpose of this document is to define a new, straightforward
 Dynamic Delegation Discovery Service (DDDS) application to allow
 mapping of domain names to URIs for particular application services
 and protocols.  Although defined as a new DDDS application, dubbed
 U-NAPTR, this is effectively an extension of the Straightforward
 NAPTR (S-NAPTR) DDDS Application.

Daigle Standards Track [Page 1] RFC 4848 URI-Enabled NAPTR April 2007

Table of Contents

 1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
 2.  Straightforward URI-Enabled NAPTR (U-NAPTR) . . . . . . . . . . 3
   2.1.  Permitted Flags . . . . . . . . . . . . . . . . . . . . . . 3
   2.2.  Permitted Regular Expressions . . . . . . . . . . . . . . . 4
 3.  Sample U-NAPTR DNS Records  . . . . . . . . . . . . . . . . . . 4
 4.  Formal Definition of U-NAPTR Application of DDDS  . . . . . . . 5
   4.1.  Application Unique String . . . . . . . . . . . . . . . . . 5
   4.2.  First Well Known Rule . . . . . . . . . . . . . . . . . . . 5
   4.3.  Expected Output . . . . . . . . . . . . . . . . . . . . . . 5
   4.4.  Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.5.  Service Parameters  . . . . . . . . . . . . . . . . . . . . 5
     4.5.1.  Application Services  . . . . . . . . . . . . . . . . . 6
     4.5.2.  Application Protocols . . . . . . . . . . . . . . . . . 6
   4.6.  Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.7.  Valid Databases . . . . . . . . . . . . . . . . . . . . . . 7
 5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
 6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
 7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
 8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
   8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
   8.2.  Informative References  . . . . . . . . . . . . . . . . . . 9

Daigle Standards Track [Page 2] RFC 4848 URI-Enabled NAPTR April 2007

1. Introduction

 The purpose of this document is to define a new, straightforward
 Dynamic Delegation Discovery Service (DDDS) [7] application to allow
 mapping of domain names to URIs for particular application services
 and protocols.  This allows the "lookup" of particular services
 available for given domains, for example.
 Although this is defining a new and separate DDDS Application, dubbed
 U-NAPTR, it is built from the same principles as the Straightforward
 NAPTR (S-NAPTR) application, specified in [2].  This specification is
 not an update of S-NAPTR, but the reader is encouraged to review that
 document for extensive coverage of motivation and implementation
 considerations.
 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.  A number of applications, specified (e.g., [9]) and
 proposed, find the restriction too limiting, making S-NAPTR a near
 miss to suit their needs.
 This U-NAPTR is effectively 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.

2. Straightforward URI-Enabled NAPTR (U-NAPTR)

 This document assumes the reader is familiar with the S-NAPTR
 specification [2].  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 ("S", "A", or empty), 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.

Daigle Standards Track [Page 3] RFC 4848 URI-Enabled NAPTR April 2007

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
 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>"!"
 where <URI> is as defined in STD 66 [8], the URI syntax
 specification.
 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   "u"    "EM:protA"        ( ; service
                           "!.*!prota://someisp.example.com!" ; regexp
                           ""                  ; replacement
                                             )
 IN NAPTR 200   30   "a"   "EM:protB"          ; service
                           ""                  ; regexp
                           myprotB.example.com.; replacement
                                             )

Daigle Standards Track [Page 4] RFC 4848 URI-Enabled NAPTR April 2007

4. Formal Definition of U-NAPTR Application of DDDS

 This section formally defines the DDDS Application, as described in
 [7].

4.1. Application Unique String

 The Application Unique String is a fully qualified domain name (FQDN)
 for which an authoritative server for a particular service is sought.

4.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 FQDN for which the
 authoritative server for a particular service is sought.

4.3. Expected Output

 The expected output of this Application is the information necessary
 to connect to authoritative server(s) (host, port, protocol, or URI)
 for an application service within a given domain.

4.4. Flags

 This DDDS Application uses only 3 of the Flags defined for the URI/
 URN Resolution Application [5]: "S", "A", and "U".  No other Flags
 are valid.  If a client obtains a NAPTR RR for a U-NAPTR-using
 application that contains any other flag, that NAPTR RR should be
 ignored and processing continues with the next record (if any).
 These flags 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 FQDN for
 which one or more SRV [3] 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 that should be resolved in order to obtain access to the
 described service.
 Consistent with the DDDS algorithm, if the Flag string is empty the
 next lookup is for another NAPTR record (for the replacement target).

4.5. Service Parameters

 Service Parameters for this Application take the form of a string of
 characters that follow this ABNF [1]:

Daigle Standards Track [Page 5] RFC 4848 URI-Enabled NAPTR April 2007

    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 *31ALPHANUMSYM
    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 [5].  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 [8]).  Since "+" (the separator used in the
 RFC3404 service parameter string) is an allowed character for URI
 scheme names, ":" is chosen as the separator here.

4.5.1. Application Services

 The "app-service" must be an IANA-registered service; see Section 5
 for instructions on registering new application service tags.

4.5.2. Application Protocols

 The protocol identifiers that are valid for the "app-protocol"
 production are standard, registered protocols; see Section 5 for
 instructions on registering new application protocol tags.

4.6. Valid Rules

 Permitted rules are substitution rules and regular expressions of the
 following syntax (i.e., a regular expression to replace the domain
 name with a URI):
         u-naptr-regexp = "!.*!"<URI>"!"
 where <URI> is as defined in STD 66 [8], the URI syntax
 specification.

Daigle Standards Track [Page 6] RFC 4848 URI-Enabled NAPTR April 2007

4.7. Valid Databases

 At present, only one DDDS Database is specified for this Application.
 [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 [4] for more
 information on NAPTR records and the Additional Information section
 of a DNS response packet.

5. IANA Considerations

 This document does not itself place any requirements on IANA, but
 provides the basis upon which U-NAPTR-using services can make use of
 the existing IANA registries for application service tags and
 application protocol tags (defined in RFC 3958 [2]).
 As is the case for S-NAPTR, all application service and protocol tags
 that start with "x-" are considered experimental, and no provision is
 made to prevent duplicate use of the same string.  Use them at your
 own risk.
 All other application service and protocol tags are registered based
 on the "specification required" option defined in [6], with the
 further stipulation that the "specification" is an RFC (of any
 category).
 There are no further restrictions placed on the tags other than that
 they must conform with the syntax defined above (Section 4.5).
 The defining RFC must clearly identify and describe, for each tag
 being registered:
 o  Application protocol or service tag
 o  Intended usage
 o  Interoperability considerations

Daigle Standards Track [Page 7] RFC 4848 URI-Enabled NAPTR April 2007

 o  Security considerations (see Section 6 of this document for
    further discussion of the types of considerations that are
    applicable)
 o  Any relevant related publications
 The defining RFC may also include further application-specific
 restrictions, such as limitations on the types of URIs that may be
 returned for the application service.

6. Security Considerations

 U-NAPTR has the same considerations for security as S-NAPTR; see
 Section 8 of [2].  U-NAPTR has the additional consideration that
 resolving URIs (from the result of the DDDS resolution) has its own
 set of security implications, covered in the URI specification (in
 particular, Section 7 of [8]).  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. Acknowledgements

 Thanks to Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes,
 Dan Romascanu, Suresh Krishnan, and Lars Eggert for reviewing earlier
 versions and catching errors!

8. References

8.1. Normative References

 [1]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
      Specifications: ABNF", RFC 4234, October 2005.
 [2]  Daigle, L. and A. Newton, "Domain-Based Application Service
      Location Using SRV RRs and the Dynamic Delegation Discovery
      Service (DDDS)", RFC 3958, January 2005.
 [3]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
      specifying the location of services (DNS SRV)", RFC 2782,
      February 2000.
 [4]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
      Three: The Domain Name System (DNS) Database", RFC 3403,
      October 2002.

Daigle Standards Track [Page 8] RFC 4848 URI-Enabled NAPTR April 2007

 [5]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
      Four: The Uniform Resource Identifiers (URI)", RFC 3404,
      October 2002.
 [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

8.2. Informative References

 [7]  Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
      One: The Comprehensive DDDS", RFC 3401, October 2002.
 [8]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
      Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66,
      January 2005.
 [9]  Malamud, C., "Attaching Meaning to Solicitation Class Keywords",
      RFC 4095, May 2005.

Author's Address

 Leslie L. Daigle
 Cisco Systems
 13615 Dulles Technology Drive
 Herndon, VA  20171
 US
 EMail: ledaigle@cisco.com; leslie@thinkingcat.com

Daigle Standards Track [Page 9] RFC 4848 URI-Enabled NAPTR April 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 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.
 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, THE IETF TRUST 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.

Intellectual Property

 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Daigle Standards Track [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4848.txt · Last modified: 2007/05/01 01:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki