Request for Comments: 3958 A. Newton
Category: Standards Track VeriSign, Inc.
January 2005
Domain-Based Application Service Location Using SRV RRs 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 Internet Society (2005).
Abstract
This memo defines a generalized mechanism for application service
naming that allows service location without relying on rigid domain
naming conventions (so-called name hacks). The proposal defines a
Dynamic Delegation Discovery System (DDDS) Application to map domain
name, application service name, and application protocol dynamically
to target server and port.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . . 3
2.1. Key Terms. . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. S-NAPTR DDDS Application Usage . . . . . . . . . . . . . 4
2.2.1. Ordering and Preference. . . . . . . . . . . . . 4
2.2.2. Matching and Non-matching NAPTR Records. . . . . 4
2.2.3. Terminal and Non-terminal NAPTR Records. . . . . 5
2.2.4. S-NAPTR and Successive Resolution. . . . . . . . 5
2.2.5. Clients Supporting Multiple Protocols. . . . . . 6
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Guidelines for Application Protocol Developers . . . . . 6
3.1.1. Registration of Application Service and
Protocol Tags. . . . . . . . . . . . . . . . . . 7
3.1.2. Definition of Conditions for Retry/Failure . . . 7
3.1.3. Server Identification and Handshake . . . . . . 8
3.2. Guidelines for Domain Administrators . . . . . . . . . . 8
3.3. Guidelines for Client Software Writers . . . . . . . . . 8
4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Service Discovery within a Domain . . . . . . . . . . . 9
4.3. Multiple Protocols . . . . . . . . . . . . . . . . . . . 10
4.4. Remote Hosting . . . . . . . . . . . . . . . . . . . . . 11
4.5. Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . 12
4.6. Sample Sequence Diagram . . . . . . . . . . . . . . . . 13
5. Motivation and Discussion . . . . . . . . . . . . . . . . . . 14
5.1. So Why Not Just SRV Records? . . . . . . . . . . . . . . 15
5.2. So Why Not Just NAPTR Records? . . . . . . . . . . . . . 15
6. Formal Definition of <Application Service Location>
Application of DDDS . . . . . . . . . . . . . . . . . . . . . 16
6.1. Application-Unique String . . . . . . . . . . . . . . . 16
6.2. First Well-Known Rule . . . . . . . . . . . . . . . . . 16
6.3. Expected Output . . . . . . . . . . . . . . . . . . . . 16
6.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Service Parameters . . . . . . . . . . . . . . . . . . . 17
6.5.1. Application Services . . . . . . . . . . . . . . 17
6.5.2. Application Protocols . . . . . . . . . . . . . 17
6.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Valid Databases . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Application Service Tag IANA Registry . . . . . . . . . 18
7.2. Application Protocol Tag IANA Registry . . . . . . . . . 18
7.3. Registration Process . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A. Pseudo-pseudocode for S-NAPTR. . . . . . . . . . . . . . . 22
A.1. Finding the First (Best) Target. . . . . . . . . . . 22
A.2. Finding Subsequent Targets . . . . . . . . . . . . . 23
B. Availability of Sample Code. . . . . . . . . . . . . . . . 23
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
This memo defines a generalized mechanism for application service
naming that allows service location without relying on rigid domain
naming conventions (so-called name hacks). The proposal defines a
Dynamic Delegation Discovery System (DDDS -- see [4]) Application to
map domain name, application service name, and application protocol
dynamically to target server and port.
As discussed in section 5, existing approaches to using DNS records
for dynamically determining the current host for a given application
service are limited in terms of the use cases supported. To address
some of the limitations, this document defines a DDDS Application to
map service+protocol+domain to specific server addresses by using
both NAPTR [5] and SRV ([3]) 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.
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 BCP 14, RFC 2119 [1].
2. Straightforward-NAPTR (S-NAPTR) Specification
The precise details of the specification of this DDDS application are
given in Section 6. This section defines the usage of the DDDS
application.
2.1. Key Terms
"Application service" is a generic term for some type of application,
independent of the protocol that may be used to offer it. Each
application service will be associated with an IANA-registered tag.
For example, retrieving mail is a type of application service that
can be implemented by different application-layer protocols (e.g.,
POP3, IMAP4). A tag, such as "RetMail", could be registered for it.
(Note that this has not been done, and there are no plans to do so at
the time of this writing.)
An "application protocol" is used to implement the application
service. These are also associated with IANA-registered tags. Using
the mail example above, "POP3" and "IMAP4" could be registered as
application protocol tags. If multiple transports are available for
the application, separate tags should be defined for each transport.
The intention is that the combination of application service and
protocol tags should be specific enough that finding a known pair
(e.g., "RetMail:POP3" would be sufficient for a client to identify a
server with which it can communicate.
Some protocols support multiple application services. For example,
LDAP is an application protocol and can be found supporting various
services (e.g., "whitepages", "directory enabled networking".
2.2. S-NAPTR DDDS Application Usage
As defined in section 6, NAPTR records are used to store application
service+protocol information for a given domain. Following the DDDS
standard, these records are looked up, and the rewrite rules
(contained in the NAPTR records) are used to determine the successive
DNS lookups until a desirable target is found.
For the rest of this section, refer to the set of NAPTR resource
records for example.com, shown in the figure below, where "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. ; replacement
)
IN NAPTR 100 20 "s" "WP:ldap" ( ; service
"" ; regexp
_ldap._tcp.myldap.example.com. ; replacement
)
IN NAPTR 200 10 "" "EM:protA" ( ; service
"" ; regexp
someisp.example. ; replacement
)
IN NAPTR 200 30 "a" "EM:protB" ; service
"" ; regexp
myprotB.example.com.; replacement
)
2.2.1. Ordering and Preference
A client retrieves all the NAPTR records associated with the target
domain name (example.com, above). These are to be sorted in terms of
increasing ORDER and increasing PREF within each ORDER.
2.2.2. Matching and Non-Matching NAPTR Records
Starting with the first sorted NAPTR record, the client examines the
SERVICE field to find a match. In the case of the S-NAPTR DDDS
application, this means a SERVICE field that includes the tags for
the desired application service and a supported application protocol.
If more than one NAPTR record matches, they are processed in
increasing sort order.
2.2.3. Terminal and Non-terminal NAPTR Records
A NAPTR record with an empty FLAG field is "non-terminal" -- that is,
more NAPTR RR lookups are to be performed. Thus, to process a NAPTR
record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is
used as the target of the next DNS lookup -- for NAPTR RRs.
In S-NAPTR, the only terminal flags are "S" and "A". These are
called "terminal" NAPTR lookups because they denote the end of the
DDDS/NAPTR processing rules. In the case of an "S" flag, the
REPLACEMENT field is used as the target of a DNS query for SRV RRs,
and normal SRV processing is applied. In the case of an "A" flag, an
address record is sought for the REPLACEMENT field target (and the
default protocol port is assumed).
2.2.4. S-NAPTR and Successive Resolution
As shown in the example set above, it is possible to have multiple
possible targets for a single application service+protocol pair.
These are to be pursued in order until a server is successfully
contacted or all possible matching NAPTR records have been
successively pursued through terminal lookup and server contact.
That is, a client must backtrack and attempt other resolution paths
in the case of failure.
"Failure" is declared, and backtracking must be used, when
o the designated remote server (host and port) fails to provide
appropriate security credentials for the *originating* domain;
o connection to the designated remote server otherwise fails -- the
specifics terms of which are defined when an application protocol
is registered; or
o the S-NAPTR-designated DNS lookup fails to yield expected results
-- e.g., no A RR for an "A" target, no SRV record for an "S"
target, or no NAPTR record with appropriate application service
and protocol for a NAPTR lookup. Except in the case of the very
first NAPTR lookup, this last is a configuration error: the fact
that example.com has a NAPTR record pointing to "bunyip.example"
for the "WP:Whois++" service and protocol means the administrator
of example.com believes that service exists. If bunyip.example
has no "WP:Whois++" NAPTR record, the application client MUST
backtrack and try the next available "WP:Whois++" option from
example.com. As there is none, the whole resolution fails.
An application client first queries for the NAPTR RRs for the domain
of a named application service. The first DNS query is for the NAPTR
RRs in the original target domain (example.com, above).
2.2.5. Clients Supporting Multiple Protocols
In the case of an application client that supports more than one
protocol for a given application service, it MUST pursue S-NAPTR
resolution completely for one protocol, exploring all potential
terminal lookups in PREF and ORDER ranking, until the application
connects successfully or there are no more possibilities for that
protocol.
That is, the client MUST NOT start looking for one protocol, observe
that a successive NAPTR RR set supports another of its preferred
protocols, and continue the S-NAPTR resolution based on that
protocol. For example, even if someisp.example offers the "EM"
service with protocol "ProtB", there is no reason to believe that it
does so on behalf of example.com (as there is no such pointer in
example.com’s NAPTR RR set).
It MAY choose which protocol to try first based on its own
preference, or on the PREF ranking in the first set of NAPTR records
(i.e., those for the target named domain). However, the chosen
protocol MUST be listed in that first NAPTR RR set.
It MAY choose to run simultaneous DDDS resolutions for more than one
protocol, in which case the requirements above apply for each
protocol independently. That is, do not switch protocols mid-
resolution.
3. Guidelines
3.1. Guidelines for Application Protocol Developers
The purpose of S-NAPTR 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.
This document does not address how to select the domain for which the
service+protocol is being sought. Other conventions will have to
define how this might be used (e.g., new messaging standards can
define what domain to use from their URIs or how to step down from
foobar.example.com to example.com, if applicable).
Although this document proposes a DDDS application that does not use
all the features of NAPTR resource records, it is not intended to
imply that DNS resolvers should fail to implement all aspects of the
NAPTR RR standard. A DDDS application is a client use convention.
The rest of this section outlines the specific elements that protocol
developers must determine and document to make use of S-NAPTR.
3.1.1. Registration of Application Service and Protocol Tags
Application protocol developers who wish to make use of S-NAPTR must
make provisions for registering any relevant application service and
application protocol tags, as described in section 7.
3.1.2. Definition of Conditions for Retry/Failure
One other important aspect that must be defined is the expected
behaviour for interacting with the servers that are reached via S-
NAPTR. Specifically, under what circumstances should the client
retry a target that was found via S-NAPTR? What should it consider a
failure that causes it to return to the S-NAPTR process to determine
the next serviceable target, which by definition will have a lower
preference ranking.
For example, if the client gets a "connection refused" message from a
server, should it retry for some (protocol-dependent) period of time?
Or should it try the next-preferred target in the S-NAPTR chain of
resolution? Should it only try the next-preferred target if it
receives a protocol-specific permanent error message?
The most important thing is to select one expected behaviour and
document it as part of the use of S-NAPTR.
As noted earlier, failure to provide appropriate credentials to
identify the server as being authoritative for the original target
domain is always considered a failure condition.
3.1.3. Server Identification and Handshake
As noted in section 8, use of the DNS for server location increases
the importance of using protocol-specific handshakes to determine and
confirm the identity of the server that is eventually reached.
Therefore, application protocol developers using S-NAPTR should
identify the mechanics of the expected identification handshake when
the client connects to a server found through S-NAPTR.
3.2. Guidelines for Domain Administrators
Although S-NAPTR aims to provide a "straightforward" application of
DDDS and use of NAPTR records, it is still possible to create very
complex chains and dependencies with the NAPTR and SRV records.
Therefore, domain administrators are called upon to use S-NAPTR with
as much restraint as possible while still achieving their service
design goals.
The complete set of NAPTR, SRV, and A RRs "reachable" through the S-
NAPTR process for a particular application service can be thought of
as a "tree". Each NAPTR RR that is retrieved points to more NAPTR or
SRV records; each SRV record points to several A record lookups.
Even though a particular client can "prune" the tree to use only
those records referring to application protocols supported by the
client, the tree could be quite deep, and retracing the tree to retry
other targets can become expensive if the tree has many branches.
Therefore,
o fewer branches is better: For both NAPTR and SRV records, provide
different targets with varying preferences where appropriate
(e.g., to provide backup services) but don’t look for reasons to
provide more; and
o shallower is better: Avoid using NAPTR records to "rename"
services within a zone. Use NAPTR records to identify services
hosted elsewhere (i.e., where you cannot reasonably provide the
SRV records in your own zone).
3.3. Guidelines for Client Software Writers
To understand DDDS/NAPTR properly, an implementor must read [4].
However, the most important aspect to keep in mind is that if the
application cannot successfully connect to one target, the
application will be expected to continue through the S-NAPTR tree to
try the (less preferred) alternatives.
4. Illustrations
4.1. Use Cases
The basic intended use cases for which S-NAPTR has been developed are
as follows
o Service discovery within a domain. For example, this can be used
to find the "authoritative" server for some type of service within
a domain (see the specific example in section 4.2).
o Multiple protocols. This is already common today as new
application services are defined, and is increasingly a problem.
It includes the case of extensible messaging (a hypothetical
service), which can be offered with multiple protocols (see
section 4.3).
o Remote hosting. Each of the above use cases applies within the
administration of a single domain. However, one domain operator
may elect to engage another organization to provide an application
service. See section 4.4 for an example that cannot be served by
SRV records alone.
4.2. Service Discovery within a Domain
There are occasions when it is useful to be able to determine the
"authoritative" server for a given application service within a
domain. This is "discovery", as there is no a priori knowledge as to
whether or where the service is offered; it is therefore important to
determine the location and characteristics of the offered service.
For example, 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. The following is a hypothetical case for storing application
key or certificate data for a given domain: the premise is that a
credentials registry (CredReg) service has been defined as a leaf
node service holding the keys/certs for the servers operated by (or
for) the domain. 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.example might look
like this:
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "" "CREDREG:ldap:iris.beep" ( ; service
"" ; regexp
theserver.thinkingcat.example. ; replacement
Note that the application service might be offered in another domain
using a different set of application protocols:
anotherdomain.example.
;; order pref flags
IN NAPTR 100 10 "" "CREDREG:iris.lwz:iris.beep" ( ; service
"" ; regexp