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
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.
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.
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.
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".
