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