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:
[email protected];
[email protected]
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
[email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Daigle Standards Track [Page 10]
