INTERNET-DRAFT Martin Hamilton
draft-ietf-ids-dnsnames-00.txt Loughborough University
Expires in six months Russ Wright
Lawrence Berkeley Laboratory
May 1996
Use of DNS Aliases for Network Services
Filename: draft-ietf-ids-dnsnames-00.txt
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Abstract
It has become a common practice to use symbolic names (usually
CNAMEs) in the Domain Name Service (DNS - [1,2]) to refer to network
services such as anonymous FTP [3] servers, Gopher [4] servers, and
most notably World-Wide Web HTTP [5] servers. This is desirable for
a number of reasons. It provides a way of moving services from one
machine to another transparently, and a mechanism by which people or
agents may programatically discover that an organization runs, say, a
World-Wide Web server.
Although this approach has been almost universally adopted, there is
no standards document or similar specification for these commonly
used names. This document seeks to rectify this situation by
gathering together the extant "folklore" on naming conventions, and
proposes a mechanism for accommodating new protocols. Distribution
of this document is unlimited. Comments should be sent to the IETF
Integrated Directory Services mailing list, ietf-ids@umich.edu, or
[Page 1]
INTERNET-DRAFT May 1996
directly to the authors.
1. Rationale
In order to locate the network services offered at a particular
Internet domain one is faced with the choice of selecting from a
growing number of centralized databases - typically Web or Usenet
News "wanderers", or attempting to infer the existence of network
services from whatever DNS information may be available. The former
approach is not practical in some cases, notably when the entity
seeking service information is a program.
Perhaps the most visible example of the latter approach at work is in
the case of World-Wide Web HTTP servers. It is common practice to
try prefixing the domain name of an organization with "http://www."
in order to reach its World-Wide Web site, e.g. taking "hivnet.fr"
and arriving at "http://www.hivnet.fr." Some popular World-Wide Web
browsers have gone so far as to provide automatic support for this
domain name expansion.
Ideally, the DNS or some complementary directory service would
provide a means for programs to determine automatically the network
services which are offered at a particular Internet domain, the
protocols which are used to deliver them, and other technical
information such as TCP [6] and UDP [7] port numbers.
Unfortunately, although much work has been done on developing "yellow
pages" directory service technologies, and on attempting to define
new types of DNS resource record to provide this type of information,
there is no widely agreed upon or widely deployed solution to the
problem - except in a small number of cases.
The first case is where the DNS already provides a lookup capability
for the type of information being sought after. For example: Mail
Exchanger (MX) records specify how mail to a particular domain should
be routed [8], the Start of Authority (SOA) records make it possible
to determine who is responsible for a given domain, and Name Server
(NS) records indicate which hosts provide DNS name service for a
given domain.
The second case is where the DNS does not provide an appropriate
lookup capability, but there is some widely accepted convention for
finding this information. Some use has been made of Text (TXT)
records in this scenario, but in the vast majority of cases a
Canonical Name (CNAME) or Address (A) record pointer is used to
indicate the host or hosts which provide the service. This document
proposes a slight formalization of this well-known alias approach.
[Page 2]
INTERNET-DRAFT May 1996
It should be noted that the DNS provides a Well Known Services (WKS)
lookup capability, which makes it possible to determine the services
offered by a particular host given its domain name. In practice this
is not widely used, and was deprecated in the Host Requirements
specification [9]. In fact, WKS is really trying to solve a
different problem - advertising the services provided by a particular
machine, rather than which machines provide particular services for a
domain as a whole.
2. A generic framework
One approach to dealing with aliases for new protocols would be to
define a standard set of DNS aliases for the most popular network
services, and an accompanying review procedure for registering new
protocols - such as has been attempted with Internet Media (MIME)
Types [10]. We suggest that in the rapidly changing world of
computer networking this may not be the most appropriate way of
tackling the problem.
The Internet Assigned Numbers Authority (IANA) maintains a registry
of well known port numbers, registered port numbers, protocol and
service names [11]. We propose that this list be used to determine
the a default port number, transport protocol (e.g. TCP or UDP) and
DNS alias for a given application protocol.
e.g.
-----------------------------------------------------------
Name Port Transport Protocol
-----------------------------------------------------------
finger 79 TCP Finger [12]
ftp 21 TCP File Transfer Protocol
gopher 70 TCP Internet Gopher Protocol
ldap 389 TCP/UDP Lightweight Directory Access
Protocol [13]
ntp 123 UDP Network Time Protocol [14]
rwhois 4321 TCP Referral WHOIS [15]
whois 43 TCP NICNAME/WHOIS [16]
-----------------------------------------------------------
If it is not appropriate to use the information registered with IANA
for a particular application protocol, we suggest the protocol
specification should indicate why this is the case - and preferably
propose an alternative mechanism. For example, a Remote Procedure
Call (RPC) based application protocol which does not use a fixed port
number by default might determine which port to use by contacting a
remote RPC portmapper.
[Page 3]
INTERNET-DRAFT May 1996
We suggest that the DNS alias to be used for a service be taken
initially from the IANA lists of well known port numbers (in the
traditionally "restricted" rage 0 to 1023) and registered port
numbers (1024 to 65535), with recourse to the list of protocol and
service names if there is some confusion over the preferred alias.
This might be necessary if, for example, the name associated with the
IANA registered port number for a protocol contains the underscore
character "_", the plus character "+", or the dot character "." -
these are not legal as domain name components.
3. Special cases
In addition to the character set problems outlined above, there are a
small number of special cases which are not currently catered for in
the IANA registry. We propose that IANA maintain a list of these in
addition to the existing assigned numbers information.
Some common examples:
-----------------------------------------------------------
Alias Service
-----------------------------------------------------------
archie archie [17] (alias for "prospero")
cso CCSO nameserver [18] (alias for "csnet-ns")
fsp File Service Protocol [19]
news Usenet News via NNTP [20] (alias for "nntp")
ns DNS servers, and CCSO nameservers (aliases for
"domain" and "csnet-ns")
ph CCSO (alias for "csnet-ns")
wais Wide Area Information Server [21] (alias for
"z39.50")
www World-Wide Web HTTP (alias for "http")
-----------------------------------------------------------
4. (Ab)Use of the DNS as a directory service
The widespread use of these common aliases effectively means that it
is sometimes possible to "guess" the domain names associated with an
organization's network services, though this is becoming more
difficult as the number of organizations registered in the DNS
increases.
It should be understood by implementors that the existence of a DNS
entry such as
www.hivnet.fr
does not constitute a registration of a World-Wide Web service.
[Page 4]
INTERNET-DRAFT May 1996
There is no requirement that the domain name resolve to an IP address
or addresses. There is no requirement that a host be listening for
HTTP connections, or if it is, that the HTTP server be running on
port 80. Finally, even if all of these things are true, there can be
no guarantee that the World-Wide Web server will be prepared to honor
requests from arbitrary clients.
Having said this, the aliases do provide useful "hints" about the
services offered. We propose that they be taken in this spirit.
The conventions described in this document are, essentially, only
useful when the organization's domain name can be determined - e.g.
from some external database. A number of groups, including the IETF,
have been working on ways of finding domain names given a set of
information such as organization name, location, and business type.
It is hoped that one or more of these will eventually make it
possible to augment the basic lookup service which the DNS provides
with a more generalised search and retrieval capability.
5. DNS server configuration
In the short term, whilst directory service technology and further
types of DNS resource record are being developed, domain name
administrators are encouraged to use these common names for the
network services they run. They will make it easier for outsiders to
find information about your organization, and also make it easier for
you to move services from one machine to another.
There are two conventional approaches to creating these DNS entries.
One is to add a single CNAME record to your DNS server's
configuration, e.g.
ph.hivnet.fr. IN CNAME baby.hivnet.fr.
Note that in this scenario no information about ph.hivnet.fr should
exist in the DNS other than the CNAME record. An alternative
approach would be to create an A record for each of the IP addresses
associated with ph.hivnet.fr, e.g.
ph.hivnet.fr. IN A 194.167.157.2
Recent DNS server implementations provide a "round-robin" feature
which causes the host's IP addresses to be returned in a different
order each time the address is looked up.
Network clients are starting to appear which, when they encounter a
host with multiple addresses, use heuristics to determine the address
to contact - e.g. picking the one which has the shortest round-trip-
[Page 5]
INTERNET-DRAFT May 1996
time. Thus, if a server is mirrored (replicated) at a number of
locations, it may be desirable to list the IP addresses of the mirror
servers as A records of the primary server. This is only likely to
be appropriate if the mirror servers are exact copies of the original
server.
6. Limitations of this approach
Some services require that a client have more information than the
server's domain name and (default) port number. For example, an LDAP
client needs to know a starting search base within the Directory
Information Tree in order to have a meaningful dialogue with the
server. This document does not attempt to address this problem.
In some cases, different aliases are in common use for the same
service - e.g. "ph", "cso" and "ns" for the CCSO nameserver. It
might appear to be in everyone's interest to narrow the choice of
alias down to a single name. However, if current practice implies
that a number of aliases are equally valid, it would be advisable to
support them all. This increases the likelihood of the service being
found.
<<contentious>> Given the confusion over the multiple use of the "ns"
alias in particular, we could suggest/mandate that everyone move to a
single name, e.g. the IANA registered "csnet-ns" or one of "cso" and
"ph". Should we be trying to do this ? Discuss! <</contentious>>
Another problem is the use of a single alias to refer to multiple
network services, e.g. "ns" is commonly used to refer to both hosts
which run the CCSO nameserver, and DNS servers themselves. In this
particular case the DNS already provides a lookup capability for
nameservers via the NS record. As noted, implementations should be
resilient in the event that the name does not point to the expected
service.
7. Security considerations
The DNS is open to many kinds of "spoofing" attacks, and it cannot be
guaranteed that the result returned by a DNS lookup is indeed the
genuine information. Spoofing may take the form of denial of
service, such as directing of the client to a non-existent address,
or a passive attack such as an intruder's server which masquerades as
the legitimate one.
Work is ongoing to remedy this situation insofar as the DNS is
concerned [22]. In the meantime it should be noted that stronger
authentication mechanisms such as public key cryptography with large
key sizes are a pre-requisite if the DNS is being used in any
[Page 6]
INTERNET-DRAFT May 1996
sensitive situations. Examples of these would be on-line financial
transactions, and any situation where privacy is a concern - such as
the querying of medical records over the network. Strong encryption
of the network traffic may also be advisable, to protect against TCP
connection "hijacking" and packet sniffing.
8. Conclusions
The service names registered with the IANA provide a sensible set of
defaults which may be used as an aid in determining the hosts which
offer particular services for a given domain name.
This document has noted some exceptions which are either inherently
unsuitable for this treatment, or already have a substantial
installed base using alternative aliases.
9. Acknowledgements
Thanks to Jeff Allen, Tom Gillman, Renato Iannella, Thomas
Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri, and <<your
name here!!>> for their comments on draft versions of this document.
This work was supported by grants from the UK Electronic Libraries
Programme (eLib) and the European Commission's Telematics for
Research Programme.
10. References
Request For Comments (RFC) and Internet Draft documents are available
from <URL:ftp://ftp.internic.net> and numerous mirror sites.
[1] P. V. Mockapetris. "Domain names - concepts and
facilities", RFC 1034. November 1987.
[2] P. V. Mockapetris. "Domain names - implementation
and specification", RFC 1035. November 1987.
[3] J. Postel, J. K. Reynolds. "File Transfer Proto-
col", RFC 959. October 1985.
[4] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson,
D. Torrey & B. Albert. "The Internet Gopher Proto-
col (a distributed document search and retrieval
protocol)", RFC 1436. March 1993.
[Page 7]
INTERNET-DRAFT May 1996
[5] T. Berners-Lee, R. Fielding, H. Nielsen. "Hyper-
text Transfer Protocol -- HTTP/1.0", RFC 1945. May
1996.
[6] J. Postel. "Transmission Control Protocol", RFC
793. September 1981.
[7] J. Postel. "User Datagram Protocol", RFC 768.
August 1980.
[8] C. Partridge. "Mail routing and the domain sys-
tem", RFC 974. January 1986.
[9] R. T. Braden. "Requirements for Internet hosts -
application and support", RFC 1123. October 1989.
[10] J. Postel. "Media Type Registration Procedure",
RFC 1590. March 1994.
[11] J. Reynolds, J. Postel. "ASSIGNED NUMBERS", RFC
1700. October 1994.
[12] D. Zimmerman. "The Finger User Information Proto-
col", RFC 1288. December 1992.
[13] W. Yeong, T. Howes, S. Kille. "Lightweight Direc-
tory Access Protocol", RFC 1777. March 1995.
[14] D. Mills. "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305. March
1992.
[15] S. Williamson & M. Kosters. "Referral Whois Proto-
col (RWhois)", RFC 1714. November 1994.
[16] K. Harrenstien, M. K. Stahl, E.J. Feinler.
"NICNAME/WHOIS", RFC 954. October 1985.
[Page 8]
INTERNET-DRAFT May 1996
[17] A. Emtage, P. Deutsch. "archie - An Electronic
Directory Service for the Internet", Winter Usenix
Conference Proceedings 1992. Pages 93-110.
[18] R. Hedberg, S. Dorner, P. Pomes. "The CCSO
Nameserver (Ph) Architecture", Internet Draft.
February 1996.
[19] FSP software distribution:
<URL:ftp://ftp.germany.eu.net/pub/networking/inet/fsp>
[20] B. Kantor, P. Lapsley. "Network News Transfer Pro-
tocol", RFC 977. February 1986.
[21] M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman,
B. Kahle, J. Kunze, H. Morris & F. Schiettecatte.
"WAIS over Z39.50-1988", RFC 1625. June 1994.
[22] D. E. Eastlake 3rd, C. W. Kaufman. "Domain Name
System Security Extensions", Internet Draft. Janu-
ary 1996.
11. Authors addresses
Martin Hamilton
Department of Computer Studies
Loughborough University of Technology
Leics. LE11 3TU, UK
Email: m.t.hamilton@lut.ac.uk
Russ Wright
Information & Computing Sciences Division
Lawrence Berkeley National Laboratory
1 Cyclotron Road, Berkeley
Mail-Stop: 50B-2258
CA 94720, USA
Email: wright@lbl.gov
[Page 9]
INTERNET-DRAFT May 1996
This Internet Draft expires 29th November, 1996.
[Page 10]
