rfc3958
Network Working Group L. Daigle
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
Daigle & Newton Standards Track [Page 1]
RFC 3958 DDDS January 2005
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.
Daigle & Newton Standards Track [Page 2]
RFC 3958 DDDS January 2005
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".
Daigle & Newton Standards Track [Page 3]
RFC 3958 DDDS January 2005
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.
Daigle & Newton Standards Track [Page 4]
RFC 3958 DDDS January 2005
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.
Daigle & Newton Standards Track [Page 5]
RFC 3958 DDDS January 2005
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.
Daigle & Newton Standards Track [Page 6]
RFC 3958 DDDS January 2005
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.
Daigle & Newton Standards Track [Page 7]
RFC 3958 DDDS January 2005
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.
Daigle & Newton Standards Track [Page 8]
RFC 3958 DDDS January 2005
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.
Daigle & Newton Standards Track [Page 9]
RFC 3958 DDDS January 2005
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
foo.anotherdomain.example. ; replacement
)
4.3. Multiple Protocols
Extensible messaging, a hypothetical application service, will be
used for illustrative purposes. (For an example of a real
application service with multiple protocols, see [9] and [10]).
Assuming that "EM" was registered as an application service, this
DDDS application could be used to determine the available services
for delivery to a target.
Two particular features of this hypothetical extensible messaging
should be noted:
1. Gatewaying is expected to bridge communications across protocols.
2. Extensible messaging servers are likely to be operated out of a
different domain than that of the extensible messaging address,
and servers of different protocols may be offered by independent
organizations.
For example, "thinkingcat.example" may support its own servers for
the "ProtA" extensible messaging protocol but rely on outsourcing
from "example.com" for "ProtC" and "ProtB" servers.
Using this DDDS-based approach, thinkingcat.example can indicate a
preference ranking for the different types of servers for the
extensible messaging service, 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.
Daigle & Newton Standards Track [Page 10]
RFC 3958 DDDS January 2005
Thus, to find the EM services for thinkingcat.example, the NAPTR
records for thinkingcat.example are retrieved:
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "s" "EM:ProtB" ( ; service
"" ; regexp
_ProtB._tcp.example.com. ; replacement
)
IN NAPTR 100 30 "s" "EM:ProtC" ( ; service
"" ; regexp
_ProtC._tcp.example.com. ; replacement
)
Then the administrators at example.com can manage the preference
rankings of the servers they use to support the ProtB service:
_ProtB._tcp.example.com.
;; Pref Weight Port Target
IN SRV 10 0 10001 bigiron.example.com.
IN SRV 20 0 10001 backup.em.example.com.
IN SRV 30 0 10001 nuclearfallout.australia-isp.example.
4.4. Remote Hosting
In the Instant Message hosting example in Section 4.3, the service
owner (thinkingcat.example) had to host pointers to the hosting
service's SRV records in the thinkingcat.example domain.
A better approach is to have one NAPTR RR in the thinkingcat.example
domain point to all the hosted services. The hosting domain has
NAPTR records for each service to map them to whatever local hosts it
chooses (this may change from time to time).
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service
"" ; regexp
thinkingcat.example.com. ; replacement
)
Daigle & Newton Standards Track [Page 11]
RFC 3958 DDDS January 2005
Then the administrators at example.com can break out the individual
application protocols and manage the preference rankings of the
servers they use to support the ProtB service (as before):
thinkingcat.example.com.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtC" ( ; service
"" ; regexp
_ProtC._tcp.example.com. ; replacement
)
IN NAPTR 100 20 "s" "EM:ProtB" ( ; service
"" ; regexp
_ProtB._tcp.example.com. ; replacement
)
_ProtC._tcp.example.com.
;; Pref Weight Port Target
IN SRV 10 0 10001 bigiron.example.com.
IN SRV 20 0 10001 backup.em.example.com.
IN SRV 30 0 10001 nuclearfallout.australia-isp.example.
4.5. Sets of NAPTR RRs
Note that the above sections assume that there was one service
available (via S-NAPTR) per domain. Often, this will not be the
case. Assuming that thinkingcat.example had the CredReg service set
up as described in Section 4.2 and had the extensible messaging
service set up as described in Section 4.4, then a client querying
for the NAPTR RR set from thinkingcat.com would get the following
answer:
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service
"" ; regexp
thinkingcat.example.com. ; replacement
)
IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" ( ; service
"" ; regexp
bouncer.thinkingcat.example. ; replacement
)
Daigle & Newton Standards Track [Page 12]
RFC 3958 DDDS January 2005
Sorting them by increasing "ORDER", the client would look through the
SERVICE strings to determine whether there was a NAPTR RR that
matched the application service it was looking for, with an
application protocol it could use. The client would use the first
(lowest PREF) record that matched to continue.
4.6. Sample sequence diagram
Consider the example in section 4.3. Visually, the sequence of steps
required for the client to reach the final server for a "ProtB"
service for EM for the thinkingcat.example domain is as follows:
Client NS for NS for
thinkingcat.example example.com backup.em.example.com
| | |
1 -------->| | |
2 <--------| | |
3 ------------------------------>| |
4 <------------------------------| |
5 ------------------------------>| |
6 <------------------------------| |
7 ------------------------------>| |
8 <------------------------------| |
9 ------------------------------------------------->|
10 <-------------------------------------------------|
11 ------------------------------------------------->|
12 <-------------------------------------------------|
(...)
1. The name server (NS) for thinkingcat.example is reached with a
request for all NAPTR records.
2. The server responds with the NAPTR records shown in section 4.3.
3. The second NAPTR record matches the desired criteria; it has an
"s" flag and a replacement fields of "_ProtB._tcp.example.com".
So the client looks up SRV records for that target, ultimately
making the request of the NS for example.com.
4. The response includes the SRV records listed in Section 4.3.
5. The client attempts to reach the server with the lowest PREF in
the SRV list -- looking up the A record for the SRV record's
target (bigiron.example.com).
6. The example.com NS responds with an error message -- no such
machine!
Daigle & Newton Standards Track [Page 13]
RFC 3958 DDDS January 2005
7. The client attempts to reach the second server in the SRV list
and looks up the A record for backup.em.example.com.
8. The client gets the A record with the IP address for
backup.em.example.com from example.com's NS.
9. The client connects to that IP address, on port 10001 (from the
SRV record), by using ProtB over tcp.
10. The server responds with an "OK" message.
11. The client uses ProtB to challenge that this server has
credentials to operate the service for the original domain
(thinkingcat.example)
12. The server responds, and the rest is EM.
5. Motivation and Discussion
Increasingly, application protocol standards use domain names to
identify server targets and stipulate that clients should look up SRV
resource records to determine the host and port providing the server.
This enables a distinction between naming an application service
target and actually hosting the server. It also increases
flexibility in hosting the target service, as follows:
o The server may be operated by a completely different organization
without having to list the details of that organization's DNS
setup (SRVs).
o Multiple instances can be set up (e.g., for load balancing or
secondaries).
o It can be moved from time to time without disrupting clients'
access, etc.
This approach is quite useful, but section 5.1 outlines some of its
inherent limitations.
That is, although SRV records can be used to map from a specific
service name and protocol for a specific domain to a specific server,
SRV records are limited to one layer of indirection and are focused
on server administration rather than on application naming.
Furthermore, although the DDDS specification and use of NAPTR allows
multiple levels of redirection before the target server machine with
an SRV record is located, this proposal requires only a subset of
NAPTR strictly bound to domain names, without making use of the
REGEXP field of NAPTR. These restrictions make the client's
Daigle & Newton Standards Track [Page 14]
RFC 3958 DDDS January 2005
resolution process much more predictable and efficient than it would
be with some potential uses of NAPTR records. This is dubbed "S-
NAPTR" -- a "S"traightforward use of NAPTR records.
5.1. 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 DDDS/NAPTR?
Limitations of SRV include the following:
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 to address individual server administration
issues, not to provide application naming: As stated in [3], "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 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 this is more complex than is necessary for most
applications of SRV.
5.2. So Why Not Just NAPTR Records?
This is a trick question. NAPTR records cannot appear in the wild;
see [4]. They must be part of a DDDS application.
The purpose here is to define a single, common mechanism (the DDDS
application) to use NAPTR when all that is desired is simple DNS-
based location of services. This should be easy for applications to
use -- a few simple IANA registrations, and it's done.
Daigle & Newton Standards Track [Page 15]
RFC 3958 DDDS January 2005
Also, NAPTR has very powerful tools for expressing "rewrite" rules.
This power (==complexity) makes some protocol designers and service
administrators nervous. The concern is that these rewrites can
translate into unintelligible, noodle-like rule sets that are
difficult to test and administer.
The proposed DDDS application specifically uses a subset of NAPTR's
abilities. Only "replacement" expressions are allowed, not "regular
expressions".
6. Formal Definition of <Application Service Location> Application of
DDDS
This section formally defines the DDDS application, as described in
[4].
6.1. Application-Unique String
The Application Unique String is domain label for which an
authoritative server for a particular service is sought.
6.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 label for which the
authoritative server for a particular service is sought.
6.3. Expected Output
The expected output of this Application is the information necessary
for a client to connect to authoritative server(s) (host, port,
protocol) for a particular application service within a given domain.
6.4. Flags
This DDDS Application uses only 2 of the Flags defined for the URI/
URN Resolution Application ([6]): "S" and "A". No other Flags are
valid.
Both 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 label 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.
Consistent with the DDDS algorithm, if the Flag string is empty the
next lookup is for another NAPTR record (for the replacement target).
Daigle & Newton Standards Track [Page 16]
RFC 3958 DDDS January 2005
6.5. Service Parameters
Service Parameters for this Application take the form of a string of
characters that follow this ABNF ([2]):
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 *31ALPHANUM
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, 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 ([6]). 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]). As "+" (the separator used in the
RFC3404 service parameter string) is an allowed character for URI
scheme names, ":" is chosen as the separator here.
6.5.1. Application Services
The "app-service" must be an IANA-registered service; see Section 7
for instructions on registering new application service tags.
6.5.2. Application Protocols
The protocol identifiers valid for the "app-protocol" production are
standard, registered protocols; see section 7 for instructions on
registering new application protocol tags.
6.6. Valid Rules
Only substitution Rules are permitted for this application. That is,
no regular expressions are allowed.
Daigle & Newton Standards Track [Page 17]
RFC 3958 DDDS January 2005
6.7. Valid Databases
At present only one DDDS Database is specified for this Application.
[5] specifies that a DDDS Database using the NAPTR DNS resource
record 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
used for the first look up. 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 [5] for more
information on NAPTR records and the Additional Information section
of a DNS response packet.
7. IANA Considerations
This document calls for two IANA registries: one for application
service tags, and one for application protocol tags.
7.1. Application Service Tag IANA Registry
IANA has established and will maintain a registry for S-NAPTR
Application Service Tags, listing at least the following information
for each such tag:
o Application Service Tag: A string conforming with the IANA-
registered-service defined in section 6.5.
o Defining publication: The RFC used to define the Application
Service Tag, as defined in the registration process, below.
An initial Application Service Tag registration is contained in [9].
7.2. Application Protocol Tag IANA Registry
IANA has established and will maintain a registry for S-NAPTR
Application Protocol Tags, listing at least the following information
for each such tag:
o Application Protocol Tag: A string conforming with the iana-
registered-protocol defined in section 6.5.
Daigle & Newton Standards Track [Page 18]
RFC 3958 DDDS January 2005
o Defining publication: The RFC used to define the Application
Protocol Tag, as defined in the registration process, below.
An initial Application Protocol Tag registration is defined in [10].
7.3. Registration Process
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. Implementors use them at their own
risk.
All other application service and protocol tags are registered based
on the "specification required" option defined in [7], with the
further stipulation that the "specification" is an RFC (of any
category).
No further restrictions are placed on the tags except that they must
conform with the syntax defined below (Section 6.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,
o security considerations (see section 8 of this document for
further discussion of the types of considerations that are
applicable), and
o any relevant related publications.
8. Security Considerations
The security of this approach to application service location is only
as good as the security of the DNS queries along the way. If any of
them is compromised, bogus NAPTR and SRV records could be inserted to
redirect clients to unintended destinations. This problem is hardly
unique to S-NAPTR (or NAPTR in general). A full discussion of the
security threats pertaining to DNS can be found in [11].
To protect against DNS-vectored attacks, secured DNS (DNSSEC) [12]
can be used to ensure the validity of the DNS records received.
Daigle & Newton Standards Track [Page 19]
RFC 3958 DDDS January 2005
Whether or not DNSSEC is used, applications should define some form
of end-to-end authentication to ensure that the correct destination
has been reached. Many application protocols such as HTTPS, BEEP,
and IMAP define the necessary handshake mechanisms to accomplish this
task. Newly defined application protocols should take this into
consideration and incorporate appropriate mechanisms.
The basic mechanism works as follows:
1. During some portion of the protocol handshake, the client sends to
the server the original name of the desired destination (i.e., no
transformations that may have resulted from NAPTR replacements,
SRV targets, or CNAME changes). In certain cases where the
application protocol does not have such a feature but TLS may be
used, it is possible to use the "server_name" TLS extension.
2. The server sends back to the client a credential with the
appropriate name. For X.509 certificates, the name would be in
either the subjectDN or the subjectAltName field. For Kerberos,
the name would be a service principle name.
3. Using the matching semantics defined by the application protocol,
the client compares the name in the credential with the name sent
to the server.
4. If the names match and the credentials have integrity, there is
reasonable assurance that the correct end point has been reached.
5. The client and server establish an integrity-protected channel.
Note that this document does not define either the handshake
mechanism, the specific credential naming fields, nor the name-
matching semantics. Definitions of S-NAPTR for particular
application protocols MUST define these.
9. Acknowledgements
Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd, and Ted
Hardie for discussion and input that have (hopefully!) provoked
clarifying revisions to this document.
Daigle & Newton Standards Track [Page 20]
RFC 3958 DDDS January 2005
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D., Ed. 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 location 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.
10.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: A Domain Registry (dreg) Type
for the Internet Registry Information Service (IRIS)", RFC 3982,
January 2005.
[10] Newton, A. and M. Sanz, "Using the Internet Registry Information
Service (IRIS) over the Blocks Extensible Exchange Protocol
(BEEP)", RFC 3983, January 2005.
[11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
System", Work in Progress, April 2004.
[12] Arends, R., Larson, M., Austein, R., and D. Massey, "Protocol
Modifications for the DNS Security Extensions", Work in
Progress, May 2004.
Daigle & Newton Standards Track [Page 21]
RFC 3958 DDDS January 2005
Appendix A. Pseudo-Pseudocode for S-NAPTR
A.1. Finding the First (Best) Target
Assuming the client supports 1 protocol for a particular application
service, the following pseudocode outlines the expected process to
find the first (best) target for the client, using S-NAPTR.
target = [initial domain]
naptr-done = false
while (not naptr-done)
{
NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
[sort NAPTR-RRset by ORDER, and PREF within each ORDER]
rr-done = false
cur-rr = [first NAPTR RR]
while (not rr-done)
if ([SERVICE field of cur-rr contains desired application
service and application protocol])
rr-done = true
target= [REPLACEMENT target of NAPTR RR]
else
cur-rr = [next rr in list]
if (not empty [FLAG in cur-rr])
naptr-done = true
}
port = -1
if ([FLAG in cur-rr is "S"])
{
SRV-RRset = [DNSlookup of SRV RRs for target]
[sort SRV-RRset based on PREF]
target = [target of first RR of SRV-RRset]
port = [port in first RR of SRV-RRset]
}
; now, whether it was an "S" or an "A" in the NAPTR, we
; have the target for an A record lookup
Daigle & Newton Standards Track [Page 22]
RFC 3958 DDDS January 2005
host = [DNSlookup of target]
return (host, port)
A.2. Finding Subsequent Targets
The pseudocode in Appendix A is crafted to find the first, most
preferred host-port pair for a particular application service and
protocol. If, for any reason, that host-port pair did not work
(connection refused, application-level error), the client is expected
to try the next host-port in the S-NAPTR tree.
The pseudocode above does not permit retries -- once complete, it
sheds all context of where in the S-NAPTR tree it finished.
Therefore, client software writers could
o entwine the application-specific protocol with the DNS lookup and
RRset processing described in the pseudocode and continue the S-
NAPTR processing if the application code fails to connect to a
located host-port pair;
o use callbacks for the S-NAPTR processing; or
o use an S-NAPTR resolution routine that finds *all* valid servers
for the required application service and protocol from the
originating domain and that provides them in a sorted order for
the application to try.
Appendix B. Availability of Sample Code
Sample Python code for S-NAPTR resolution is available from
http://www.verisignlabs.com/pysnaptr-0.1.tgz
Daigle & Newton Standards Track [Page 23]
RFC 3958 DDDS January 2005
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 Standards Track [Page 24]
RFC 3958 DDDS January 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 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 IETF's procedures with respect to rights in IETF 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 & Newton Standards Track [Page 25]
ERRATA
