Stuart Cheshire
Document: draft-cheshire-dnsext-nias-00.txt Apple Computer
Expires 13th January 2002 13th July 2001
Discovering Named Instances of Abstract Services using DNS
<draft-cheshire-dnsext-nias-00.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
Distribution of this memo is unlimited.
Abstract
This document proposes a convention for naming and structuring DNS
resource records that allows clients to discover a list of named
instances of a particular given desired type of service.
1. Acknowledgements
This concepts described in this draft have been explored and
developed with help from Bill Woodcock, Erik Guttman, and others.
Expires 13th January 2002 Cheshire [Page 1]
Internet Draft Named Instances of Abstract Services 13th July 2001
2. Introduction
This is a rough first draft. Its purpose is to describe the proposed
idea well enough for meaningful discussion to take place. As such,
while feedback concerning typographical mistakes and similar minutiae
is always appreciated, the reader is advised that it is probably
unwise to waste a lot of time on such trivia until after we find out
whether this proposal will even live long enough to become a
'draft-01'.
This document proposes a convention for naming and structuring DNS
resource records that allows clients to discover a list of named
instances of a particular given desired type of service.
This document proposes no change to the structure of DNS messages,
and no new operation codes, response codes, resource record types, or
any other new DNS protocol values. This document simply proposes a
convention for how existing resource record types can be named and
structured to facilitate service discovery.
This proposal is entirely compatible with today's existing unicast
DNS server and client software.
This proposal is also compatible with the proposal for Multicast DNS
outlined in "Performing DNS queries via IP Multicast" [mDNS-SC].
3. Design Goals
A good service discovery protocol needs to have three properties:
(i) The ability to query for services of a certain type in a certain
logical domain and receive in response a list of named instances
(network browsing, or "Service Instance Enumeration").
(ii) Given a particular named instance, the ability to efficiently
resolve that instance name to the required information a client needs
to actually use the service, i.e. IP address and port number, at the
very least (Service Name Resolution).
(iii) Instance names should be relatively persistent. If a user
selects their default printer from a list of available choices today,
then tomorrow they should still be able to print on that printer --
even if the IP address and/or port number where the service resides
have changed -- without the user (or their software) having to repeat
the network browsing step a second time.
These goals are discussed in detail below.
In addition, if it is to become successful, a service discovery
protocol should be simple enough to implement that virtually any
device capable of implementing IP should not have any trouble
implementing the service discovery software as well.
Expires 13th January 2002 Cheshire [Page 2]
Internet Draft Named Instances of Abstract Services 13th July 2001
4. Service Instance Enumeration
DNS SRV records [RFC 2782] are useful for locating instances of a
particular type of service when all the instances are effectively
indistinguishable and provide the same service to the client.
For example, SRV records with the (hypothetical) name
"_http._tcp.example.com." would allow a client to discover a list of
all servers implementing the "_http._tcp" service (i.e. Web servers)
for the "example.com." domain. The unstated assumption is that all
these servers offer an identical set of Web pages, and it doesn't
matter to the client which of the servers it uses, as long as it
selects one at random according to the weight and priority rules laid
out in RFC 2782.
Instances of other kinds of service are less easily interchangeable.
If a word processing application were to look up the (hypothetical)
SRV record "_lpr._tcp.example.com." to find the list of printers at
Example Co., then picking one at random and printing on it would
probably not be what the user wanted.
This proposal borrows the logical service naming syntax and semantics
from DNS SRV records, but adds one level of indirection. Instead of
requesting records of type "SRV" with name "_lpr._tcp.example.com.",
the client requests records of type "PTR" (pointer from one name in
the DNS namespace to another). The result of this PTR lookup is a
list of zero or more Service Instance Names of the form:
Service Instance Name = <Instance> . <Service> . <Domain>
The <Instance> portion of the name is a single DNS label, containing
arbitrary UTF-8-encoded text [RFC 2279]. DNS recommends guidelines
for allowable characters for host names [RFC 1034][RFC 1033], but
Service Instance Names are not host names. Service Instance Names are
not intended to ever be typed in by a normal user; the user selects a
Service Instance Name by selecting it from a list of choices
presented on the screen. Note that just because this protocol
supports arbitrary UTF-8-encoded names doesn't mean that any
particular user or administrator setting up a service is obliged to
name that service using any characters outside the standard US-ASCII
range.
The names resulting from the PTR lookup are presented to the user in
a list for the user to select one (or more). Having chosen the
desired named instance, the Service Instance Name may then be
used immediately, or saved away in some persistent user-preference
data structure for future use.
DNS labels are limited to 63 octets in length. UTF-8 encoding can
require up to six octets per 31-bit UCS-4 character, which means that
in the worst case, the <Instance> portion of a name could be limited
Expires 13th January 2002 Cheshire [Page 3]
Internet Draft Named Instances of Abstract Services 13th July 2001
to ten characters. However, the UCS-4 characters with longer UTF-8
encodings tend to be the ones which convey greater meaning. A printer
name consisting of ten ancient Egyptian Hieroglyphs may well be far
more descriptive (to an ancient Egyptian) than a name written in
English consisting of just 63 characters.
I welcome input from the IDN Working Group about whether this method
of encoding international text is the most appropriate for this
particular usage.
There have been proposals to keep the true DNS name of the service
typically terse and cryptic, and to use a TXT records attached to
that DNS name to hold the 'user-friendly' name which is displayed to
the user. The problem with this is that it decouples user perception
from reality. Two different instances of services with different DNS
names could inadvertently have the same TXT record name, which could
be very confusing to users. Maintaining a tight one-to-one mapping
between the true DNS name and the 'user-friendly' name as displayed
on the screen avoids these anomalies.
There have been questions about why services are not named using
Service Instance Names of the form: <Service> . <Instance> . <Domain>
There are three reasons why it is beneficial to name service
instances as:
Service Instance Name = <Instance> . <Service> . <Domain>
The first reason is that, the logical decomposition is that a domain
has various services; a service has various instances of that
service. It does not make sense to say that an instance has various
services. These are not host names. The usage model is not, first,
what's the name of the host, and then second, what services is it
running? The usage model is, first, what's the name of the service,
and then second, what are the names of the specific instances of that
service?
The second reason is that, when a DNS response contains multiple
answers, name compression works more effectively if all the names
contain a common suffix. If all the answers in the packet have the
same <Service> and <Domain>, then each PTR's rdata only has to
give the <Instance> part followed by a two-byte compression pointer.
The third reason is that, this allows subdomains to be delegated
along logical service boundaries. For example, the network
administrator at Example Co. could choose to delegate the
_lpr._tcp.example.com subdomain to a particular machine that has the
responsibility to know about all the printers at Example Co. If the
service name were the least significant component of the Service
Instance Name, then there would be no way to separate the printers
from the file servers.
Expires 13th January 2002 Cheshire [Page 4]
Internet Draft Named Instances of Abstract Services 13th July 2001
5. Service Name Resolution
Given a particular Service Instance Name, when a client needs to
contact that service, it sends a DNS request for the SRV record of
that name.
The result of the DNS request is a SRV record giving the port number
and target host where the service may be found.
In some environments such as Zeroconf, the host providing the named
service may itself not have a well-defined host name. In this case,
the 'target' name in the SRV record may simply repeat the same name
as the SRV record itself, with an address record attached to the same
name giving the appropriate IP address.
In the event that more than one SRV is returned, clients MUST
correctly interpret the priority and weight fields -- i.e. Lower
numbered priority servers should be used in preference to higher
numbered priority servers, and servers with equal priority should be
selected randomly in proportion to their relative weights.
Some services discovered via Service Instance Enumeration may need
more than just an IP address and port number to properly identify the
service. For example, printing via lpr typically specifies a queue
name. A file server may have multiple volumes, each identified by its
own volume name. A Web server typically has multiple pages, each
identified by its own URL. In these cases, the necessary additional
data is stored in a TXT record with the same name as the SRV record.
The specific nature of that additional data, and how it is to be
used, is service-dependent.
6. Selective Queries
This proposal does not attempt to define an arbitrary query language
for service discovery, nor do we believe one is necessary.
However, there are some circumstances where narrowing the list of
results may be useful. A printing client that wishes to discover only
printers that accept Postscript over lpr over TCP should issue a PTR
query for the name "_postscript._lpr._tcp.example.com." Only printers
that support Postscript should register this PTR record pointing to
their name.
Note that the printer's Service Instance Name which this PTR record
points to is unchanged -- it is still something of the form
"ThePrinter._lpr._tcp.example.com." The domain in which printer SRV
records are registered defines the namespace within which printer
names are unique. Additional subtypes (e.g. "_postscript") of the
basic service type (e.g. "_lpr._tcp") serve to narrow the list of
results, not to create more namespace.
Expires 13th January 2002 Cheshire [Page 5]
Internet Draft Named Instances of Abstract Services 13th July 2001
The list of possible subtypes, if any, and the additional data stored
in TXT records, if any, are defined separately for each basic service
type.
7. Populating the DNS with information.
How the SRV and PTR records that describe services and allow them to
be enumerated make their way into the DNS is outside the scope of
this document. However, it can happen easily in any of a number of
ways, for example:
On some networks, the administrator might manually enter the records
into the name server's configuration file.
A network monitoring tool could output a standard zone file to be
read into a conventional DNS server.
Future IP printers could use Dynamic DNS Update [RFC 2136] to
automatically register their SRV and PTR records with the DNS server.
A printer manager device which has knowledge of printers on the
network through some other management protocol could also use Dynamic
DNS Update [RFC 2136].
Alternatively, a printer manager device could implement enough of the
DNS protocol that it is able to answer DNS requests directly, and
Example Co.'s main DNS server could delegate the
_lpr._tcp.example.com subdomain to the printer manager device.
Zeroconf printers on an unconfigured ad-hoc network answer Multicast
DNS requests on their own behalf for appropriate PTR and SRV names
within the "local.arpa." domain [mDNS-SC].
8. Relationship to Multicast DNS
This proposal is not strictly related to Multicast DNS, but the two
are highly complementary, particularly in Zeroconf environments [ZC].
Lookups for PTR records of the form "<Service>.local.arpa." are
defined to use multicast, and return a list of named instances of the
form "<Instance>.<Service>.local.arpa."
In Zeroconf environments where state can be transient and
configuration information like IP addresses can change at any time,
the DNS TTL on SRV and A records should be short, on the order of
seconds. However, the DNS TTL on the PTR records pointing to those
SRV names should be long, on the order of hours or days, so that once
a name has been displayed in some other host's network browser
window, the browsing client doesn't have to keep repeatedly asking
for the PTR record to make sure it hasn't disappeared.
Expires 13th January 2002 Cheshire [Page 6]
Internet Draft Named Instances of Abstract Services 13th July 2001
9. Comparison to Alternative Service Discovery Protocols
At the present time there are many proposed ways to do network
service discovery.
The advantage of using DNS is that it makes use of existing software,
protocols, infrastructure, and expertise. Existing network analyser
tools already know how to decode and display DNS packets for network
debugging.
For ad-hoc networks such as Zeroconf environments, peer-to-peer
multicast protocols are appropriate. It is almost certain that the
Zeroconf host profile [ZCHP] will specify the use of Multicast DNS
for host name resolution in the absence of DNS servers. Given that
Zeroconf hosts will have to implement Multicast DNS anyway, it makes
sense for them to also perform service discovery using that same
Multicast DNS software instead of also having to implement an
entirely different service discovery protocol.
In larger networks, a high volume of enterprise-wide IP multicast
traffic may not be desirable, so any credible service discovery
protocol intended for larger networks has to provide some facility to
aggregate registrations and lookups at a central server (or servers)
instead of working exclusively using multicast. This requires some
service discovery aggregation server software to be written,
debugged, deployed, and maintained. This also requires some service
discovery registration protocol to be implemented and deployed for
clients to register with the central aggregation server. Virtually
every company with an IP network already runs DNS server, and DNS
already has a dynamic registration protocol [RFC 2136]. Given that
virtually every company already has to operate and maintain a DNS
server anyway, it makes sense to take advantage of this instead of
also having to learn, operate and maintain a different service
registration server.
Service discovery needs to be able to provide appropriate security.
DNS already has existing mechanisms for security [RFC 2535].
In summary:
Service discovery requires a central aggregation server.
DNS already has one: It's called a DNS server.
Service discovery requires a service registration protocol.
DNS already has one: It's called DNS Dynamic Update.
Service discovery requires a security model.
DNS already has one: It's called DNSSEC.
Service discovery requires a query protocol
DNS already has one: It's called DNS.
Expires 13th January 2002 Cheshire [Page 7]
Internet Draft Named Instances of Abstract Services 13th July 2001
Service discovery requires a multicast mode for ad-hoc networks.
DNS doesn't have one right now, but it will soon, to meet Zeroconf
requirements.
It makes more sense to use the existing software that every network
needs already, instead of deploying an entire parallel system just
for service discovery.
10. Real Example
The following examples were prepared using standard unmodified
nslookup and standard unmodified BIND running on GNU/Linux.
Note: In real life, this information is obtained using graphical
network browser software, not command-line tools.
10.1 Question: What printers do we have at example.com?
nslookup -q=ptr _lpr._tcp.example.com
_lpr._tcp.example.com name = Sales._lpr._tcp.example.com
_lpr._tcp.example.com name = Marketing._lpr._tcp.example.com
_lpr._tcp.example.com name = Engineering._lpr._tcp.example.com
Answer: We have three, called Sales, Marketing, and Engineering.
10.2 Question: What postscript printers do we have at example.com?
nslookup -q=ptr _postscript._lpr._tcp.example.com
_postscript._lpr._tcp.example.com name = Sales._lpr._tcp.example.com
Answer: Only Sales is a postscript printer.
10.3 Question: How do I print on Sales?
nslookup -q=any Sales._lpr._tcp.example.com
Sales._lpr._tcp.example.com text = "SPQ"
Sales._lpr._tcp.example.com priority = 0, weight = 0, port= 49152
host = bigserver.example.com
bigserver.example.com internet address = 10.1.2.3
Answer: You need to connect to 10.1.2.3, port 49152, queue name "SPQ"
Expires 13th January 2002 Cheshire [Page 8]
Internet Draft Named Instances of Abstract Services 13th July 2001
11. IPv6 Considerations
IPv6 has no significant differences, except that the address of the
SRV record's target host is given by the appropriate IPv6 address
records instead of the IPv4 "A" record.
12. Security Considerations
DNSSEC [RFC 2535] should be used where the authenticity of
information is important.
13. IANA Considerations
The IANA will have to allocate symbolic service/protocol names, much
as they allocate TCP port numbers today. However, the textual nature
of service/protocol names means that there are almost infinitely many
more of them available than the finite set of 65535 possible port
numbers. It may also be appropriate to allow use of temporary
self-assigned service/protocol names, much like the "x-foo/bar"
self-assigned experimental MIME types.
14. Copyright
Copyright (C) The Internet Society 8th March 2000.
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.
Expires 13th January 2002 Cheshire [Page 9]
Internet Draft Named Instances of Abstract Services 13th July 2001
15. References
[mDNS-SC] S. Cheshire, "Performing DNS queries via IP Multicast",
Internet-Draft (work in progress),
draft-cheshire-dnsext-multicastdns-00.txt, July 2001.
[RFC 2136] P. Vixie, et al., "Dynamic Updates in the Domain Name
System (DNS UPDATE)", RFC 2136, April 1997.
[RFC 2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC 2535] D. Eastlake, "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC 2782] A. Gulbrandsen, et al., "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2782, February 2000.
[ZC] M. Hattig, "Zeroconf Requirements", Internet-Draft (work
in progress), draft-ietf-zeroconf-reqts-08.txt, May 2001.
[ZCHP] E. Guttman, "Zeroconf Host Profile", Internet-Draft (work
in progress), draft-ietf-zeroconf-host-prof-00.txt, July
2001.
16. Author's Address
Stuart Cheshire
Apple Computer, Inc.
1 Infinite Loop
Cupertino
California 95014
USA
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Expires 13th January 2002 Cheshire [Page 10]
Stuart Cheshire <cheshire@apple.com>
* Wizard Without Portfolio, Apple Computer
* Chairman, IETF ZEROCONF
* www.stuartcheshire.org