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