3. Guidelines
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.
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.
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).
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.
