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.
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
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.
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.
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
)
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.
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
)
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!
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.
