Network Working Group L. Daigle
Internet-Draft A. Newton
Expires: May 5, 2003 VeriSign, Inc.
November 4, 2002
Domain-based Application Service Location Using SRV RRs and the
Dynamic Delegation Discovery Service (DDDS)
draft-daigle-napstr-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo defines a Dynamic Delegation Discovery System (DDDS) [3]
Application for domain name based discovery of application services.
Essentially, this uses DNS NAPTR resource records [4] to provide one
more layer of redirection for service lookup than is feasible with
SRV ([2]) records. It is proposed because real-life use is
demonstrating a need for something slightly more substantial than
SRV, and alternatively SRV usage may become twisted out of its
intended shape.
Daigle & Newton Expires May 5, 2003 [Page 1]
Internet-Draft draft-daigle-napstr-01 November 2002
1. Introduction
Increasingly, application protocol standards are using domain names
to identify server targets, and stipulating that clients should look
up SRV ([2]) 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 -- the server may
be operated by a completely different organization without having to
delegate some portion of the zone, multiple instances can be set up
(e.g., for load balancing or secondaries), it can be moved from time
to time without disrupting clients' access, etc. This is quite
useful, but Section 4 outlines some of the limitations inherent in
the approach.
To address some of the limitations, this document defines a DDDS [3]
Application to map service+protocol+domain to specific server
addresses using both NAPTR [4] and SRV DNS resource records. This
can be viewed as a more general version of the use of SRV and/or a
very restricted application of the use of NAPTR resource records.
That is, while 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. And, while
the DDDS specification and use of NAPTR allows multiple levels of
redirection before locating the target server machine with an SRV
record, 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 (prefetchable, cachable) than with some uses of NAPTR
records.
This form of naming indirection (using just SRV records, or DDDS) has
implications for application protocols attempting to validate
security credentials. This is discussed in Section 6.
For the purposes of this document:
o an "application service" is a generic term for some generic type
of application, independent of the protocol that may be used to
offer it.
o an "application protocol" is a standard protocol used to
implementone or several services
For example, "e-mail" is an application service; "SMTP" is the
protocol that is used to implement it. "Instant Messaging" is an
Daigle & Newton Expires May 5, 2003 [Page 2]
Internet-Draft draft-daigle-napstr-01 November 2002
application service, for which there are several existing and
proposed application protocols ("jabber", "simple", etc). "LDAP" is
an application protocol which can be used to implement several
different application services (e.g., a "whitepages" service,
directory enabled networking service, etc).
1.1 What this document means for application protocol developers
The purpose of this document 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.
Specifically not addressed in this document is how to select the
domain for which the service+protocol is being sought. It is up to
other conventions to define how that might be used (e.g., instant
messaging standards can define what domain to use from IM URIs, how
to step down from foobar.example.com to example.com, and so on, if
that is applicable).
Although this document proposes a DDDS application that does not use
all the features of NAPTR resource records, it does not mean to imply
that DNS resolvers should fail to implement all aspects of the NAPTR
RR standard. A DDDS application is a client use convention.
2. Basic Proposal
The precise details of the specification of this DDDS application are
given in Appendix A. In general, the proposal is to store
application service and protocol descriptions in NAPTR records for
individual domains. This will enable domain administrators to
provide redirection to other domains that provision individual
services, with appropriate weightings and preferences.
Each "application service" will be associated with an IANA-registered
tag. For example, instant messaging is a type of application, which
is implemented by many different application-layer protocols, and the
tag "IM" (used as an illustration here) could be registered for it.
An "application protocol" is a standard protocol used to implement
the application service (as defined... ??).
The intention is that the combination of application service and
Daigle & Newton Expires May 5, 2003 [Page 3]
Internet-Draft draft-daigle-napstr-01 November 2002
protocol tags should be specific enough that finding a known pair
(e.g., "IM+SIMPLE") is sufficient for a client to identify a server
with which it can communicate.
3. Examples
3.1 Instant Messaging Services
As it stands, there are several different protocols proposed for
offering "instant message" services. Assuming that "IM" was
registered as an application service, this DDDS application could be
used to determine the available services for delivering to a target.
Two particular features of instant messaging should be noted:
1. gatewaying is expected to bridge communications across protocols
2. instant messaging servers are likely to be operated out of a
different domain than the instant messaging address, and servers
of different protocols may be offered by independent
organizations
For example, "thinkingcat.com" may support its own servers for the
"apex" instant messaging protocol, but rely on outsourcing from
"example.com" for "simple" and "prim" servers.
Using this DDDS-based approach, thinkingcat.com can indicate a
preference ranking for the different types of servers for the instant
messaging service, and 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 IM services for thinkingcat.com, the NAPTR records
for thinkingcat.com are retrieved:
thinkingcat.com.
;; order pref flags service regexp replacement
IN NAPTR 100 10 "s" "IM+apex" "" _apex._tcp.thinkingcat.com.
IN NAPTR 100 20 "s" "IM+prim" "" _prim._tcp.example.com.
IN NAPTR 100 30 "s" "IM+simple" "" _simple._tcp.example.com.
and then the administrators at example.com can manage the preference
rankings of the servers they use to support the prim service:
Daigle & Newton Expires May 5, 2003 [Page 4]
Internet-Draft draft-daigle-napstr-01 November 2002
_prim._tcp.example.com.
;; Pref Weight Port Target
IN SRV 10 0 10001 bigiron.example.com
IN SRV 20 0 10001 backup.im.example.com
IN SRV 30 0 10001 nuclearfallout.example.com.au
3.2 Application Key Storage
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.
Here's a hypothetical case for storing Application key or certificate
data for a given domain. The premise is that some AppKey service has
been defined to be a leaf node service holding the keys/certs for the
servers operated by (or for) the domain. This DDDS-based approach is
used to find the AppKey server that holds the information.
thinkingcat.com.
;; order pref flags service regexp replacement
IN NAPTR 100 10 "s" "AppKey+LDAP" "" _ldap._tcp.thinkingcat.com
IN NAPTR 100 20 "s" "AppKey+LDAP" "" _ldap._tcp.example.com
4. 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:
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 focused on individual server administration,
not application naming: as stated in [2] "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
Daigle & Newton Expires May 5, 2003 [Page 5]
Internet-Draft draft-daigle-napstr-01 November 2002
additional layer -- from some service label to servers that may in
fact 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 that is more complex than is necessary for
most applications of SRV.
5. So, why not just NAPTR records?
That's a trick question. NAPTR records cannot appear in the wild --
see [3]. 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 -- some simple IANA registrations and it's done.
Also, NAPTR has very powerful tools for expressing "rewrite" rules.
That power (==complexity) makes some protocol designers and service
administrators nervous. The concern is that it can translate into
unintelligle, noodle-like rule sets that are difficult to test and
administer.
This proposed DDDS application specifically uses a subset of NAPTR's
abilities. Only "replacement" expressions are allowed, not "regular
expressions".
6. Transiting Trust
One issue to be considered in the use of SRV records in general, and
this proposal in particular, is the matter of trusting an end server
once resolution of the end server's IP address is completed. This
can pose a problem when used with the popular model of trusting an
end server in use on the Internet today, TLS. Consider the following
example of electronic commerce for which a user must make a trust
association to an end server.
1. The end-user types into the browser the name of the server, for
example "www.thinkingcat.com".
2. The server sends to the client its certificate and certificate
chain information.
3. The client verifies the server's certificate via the certificate
chain.
4. The client compares the domain name in the server's certificate
to the domain name it was given.
Daigle & Newton Expires May 5, 2003 [Page 6]
Internet-Draft draft-daigle-napstr-01 November 2002
5. The client sends the session key encrypted with the server's
public key back to the server.
6. If the server is really the server it claims to be, then it will
possess the corresponding private key to use in decrypting the
session key.
7. The server and client communicate using encrypted means via the
session key.
However, the necessity for the client to compare the domain it was
given with the domain name found in the certificate (step 4) can be
problematic when the name resolution process changes the domain name
being sought. This problem can be solved using one of the two
methods outlined below. For full transition of trust using TLS, each
method requires the use of DNSSEC [1] to insure the SRV and NAPTR
records have not been compromised. Neither method requires any
change to either the TLS or DNSSEC protocols.
6.1 Using the Translated Name
The first method is a simple modification of the client's use of the
domain name in comparison with the name present in the certificate.
The following is a modification of the process outlined above.
1. The end-user types into the client application the name of the
server. For this example, the client application is a PRIM
client and the name of the server is "thinkingcat.com".
2. During the name resolution process for the PRIM service of
"thinkingcat.com", the NAPTR record will yield the name
"_prim._tcp.example.com". The client must remember "example.com"
(i.e., the label without the SRV-style service and protocol
portions) as the translated name.
3. The server, bigiron.example.com, sends to the client its
certificate for "example.com" and certificate chain information.
4. The client verifies the server's certificate via the certificate
chain.
5. The client compares the translated name from the resolution
process, "example.com", with the name found in the certificate,
"example.com".
6. The client sends the session key encrypted with the server's
public key back to the server.
Daigle & Newton Expires May 5, 2003 [Page 7]
Internet-Draft draft-daigle-napstr-01 November 2002
7. If the server is really one of the servers for
"_prim._tcp.example.com", then it will possess the corresponding
private key to use in decrypting the session key.
8. The server and client communicate using encrypted means via the
session key.
Note that the translated name is taken from the NAPTR record and not
the SRV record. This is done because the use-case is such that the
user is interested in the PRIM service for "thinkingcat.com" and not
the particular server where it is hosted.
Note also that this requires that the operator of the service must
have the certificate for the service's domain. This may cause
problems when the final server is operated in a different realm of
administrative control (for example, if it is outsourced to an ISP).
6.2 Trusting the DNS Signer
Due to the fact that DNSSEC must already be used to trust this name
resolution process, another method is to simply use the certificate
chain for the certificate that is present in DNS. The following
steps illustrate this process.
1. The end-user types into the PRIM application the name
"thinkingcat.com".
2. The final outcome of the name resolution process will yield an A
record containing the IP address for "bigiron.example.com".
3. The server sends to the client its certificate. The certificate
chain for this certificate leads to the signer for the A record
(the certificate is signed using the same private key as the A
record).
4. The client verifies the server's certificate using the same
public key of the A record for "bigiron.example.com".
5. The client sends the session key encrypted with the server's
public key back to the server.
6. If the server is really bigiron.example.com, then it will possess
the corresponding private key to use in decrypting the session
key.
7. The server and client communicate using encrypted means via the
session key.
Daigle & Newton Expires May 5, 2003 [Page 8]
Internet-Draft draft-daigle-napstr-01 November 2002
The key premise in this case is that DNSSEC ensures the resolution
yields trustable data in naming the final target server, and
therefore only that server's named certificate must be validated
(against the same chain of trust) in order to trust the server
itself. This approach does not require that the final server have a
certificate for the named service, and it works for NAPTR, NAPTR+SRV,
or just SRV name redirection.
7. IANA Considerations
?? Fill out with specifics for registering "application service" tags
(and "application protocols", if this is something other than the
existing port registry).
8. Security Considerations
This is primarily addressed in the "Transiting Trust" section,Section
6.
9. Acknowledgements
Many thanks to Patrik Faltstrom and Sally Floyd for discussion and
input that has (hopefully!) provoked clarifying revisions of this
document.
References
[1] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehe nsive DDDS", RFC 3401, October 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403, October
2002.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
2002.
Daigle & Newton Expires May 5, 2003 [Page 9]
Internet-Draft draft-daigle-napstr-01 November 2002
Authors' Addresses
Leslie Daigle
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
Andrew Newton
VeriSign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
EMail: anewton@verisignlabs.com
Appendix A. Application Service Location Application of DDDS
This section defines the DDDS application, as described in [3].
A.1 Application Unique String
The Application Unique String is the name of the domain in which an
authoritative server for a particular service is sought.
A.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 for which the
authoritative server for a particular service is sought.
A.3 Expected Output
The expected output of this Application is the information necessary
to connect to authoritative server(s) (host, port, protocol) for an
application service within a given a given domain.
A.4 Flags
This DDDS Application uses only 3 of the Flags defined for the
URI/URN Resolution Application ([5]): "S", "A" and "U". No other
Flags are valid.
All three are for terminal lookups. This means that the Rule is the
last one and that the flag determines what the next stage should be.
Daigle & Newton Expires May 5, 2003 [Page 10]
Internet-Draft draft-daigle-napstr-01 November 2002
The "S" flag means that the output of this Rule is a domain label for
which one or more SRV [2] 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. "U" means that the output of the Rule is a
URI which should be resolved.
A.5 Service Parameters
Service Parameters for this Application take the form of a string of
characters that follow this ABNF ([3]):
service-parms = [ [app-service] *("+" app-protocol)]
app-service = ALPHA *31ALPHANUM
app-protocol = ALPHA *31ALPHANUM
; The app-service and app-protocol fields are limited to 32
; characters and must start with an alphabetic character.
Thus, the Service Parameters may consist of an empty string, just an
app-service, or an app-service with one or more app-protocol
specifications separated by the "+" symbol.
A.5.1 Application Services
The "app-service" must be a registered service [this will be an IANA
registry; this is not the IANA port registry, because we want to
define services for which there is no single protocol, and we don't
want to use up port space for nothing].
A.5.2 Application Protocols
The protocol identifiers that are valid for the "app-protocol"
production are any standard, registered protocols [IANA registry
again -- is this the list of well known/registered ports?].
A.6 Valid Rules
Only substitution Rules are permitted for this application. That is,
no regular expressions are allowed.
A.7 Valid Databases
At present only one DDDS Database is specified for this Application.
[4] specifies a DDDS Database that uses the NAPTR DNS resource record
to 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
that is used for the first lookup -- the NAPTR records for that
Daigle & Newton Expires May 5, 2003 [Page 11]
Internet-Draft draft-daigle-napstr-01 November 2002
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 [4] for more
information on NAPTR records and the Additional Information section
of a DNS response packet.
Daigle & Newton Expires May 5, 2003 [Page 12]
Internet-Draft draft-daigle-napstr-01 November 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Daigle & Newton Expires May 5, 2003 [Page 13]
