Use of DNS Aliases for Network Services
draft-ietf-ids-dnsnames-02

IDS Working Group Martin Hamilton
INTERNET-DRAFT Loughborough University
 Russ Wright
 Lawrence Berkeley Laboratory
 Feburary 1997
 Use of DNS Aliases for Network Services
 Filename: draft-ietf-ids-dnsnames-02.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).
 Distribution of this document is unlimited. Editorial comments
 should be sent directly to the authors. Technical discussion will
 take place on the IETF Integrated Directory Services mailing list,
 ietf-ids@umich.edu.
 This Internet Draft expires August 1, 1997.
Abstract
 It has become a common practice to use symbolic names (usually
 CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to
 refer to network services such as anonymous FTP [RFC-959] servers,
 Gopher [RFC-1436] servers, and most notably World-Wide Web HTTP
 [RFC-1945] 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.
 [Page 1]
INTERNET-DRAFT Feburary 1997
 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.
 It is important to note that these naming conventions do not provide
 a complete long term solution to the problem of finding a particular
 network service for a site. There are efforts in other IETF working
 groups to address the long term solution to this problem, such as the
 Server Location Resource Records (DNS SRV) [RFC-2052] work.
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.
 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 [RFC-974], 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
 [Page 2]
INTERNET-DRAFT Feburary 1997
 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.
 It should be noted that the DNS provides a Well Known Services (WKS)
 lookup capability, which makes it possible to determine the network
 services offered at a given domain name. In practice this is not
 widely used, perhaps because of the absence of a suitable programming
 interface. Use of WKS for mail routing was deprecated in the Host
 Requirements specification [RFC-1123] in favour of the MX record, and
 in the long term it is conceivable that SRV records will supercede
 both WKS and MX.
2. A generic framework
 Our approach to dealing with aliases for protocols is
 straightforward. We define a standard set of DNS aliases for the most
 popular network services that currently exist (see the "Special
 Cases" section below). For protocols that are not explicitly listed
 in this document, the protocol specification must propose a name.
3. Special cases
 This is a static list of standard aliases and will not be added to in
 the future.
 Special Cases:
 -----------------------------------------------------------
 Alias Service
 -----------------------------------------------------------
 archie archie [ARCHIE]
 finger Finger [RFC-1288]
 ftp File Transfer Protocol [RFC-959]
 gopher Internet Gopher Protocol [RFC-1436]
 ldap Lightweight Directory Access Protocol [RFC-1777]
 mail SMTP mail [RFC-821]
 news Usenet News via NNTP [RFC-977]
 ntp Network Time Protocol [RFC-1305]
 ph CCSO nameserver [PH]
 pop Post Office Protocol [RFC-1939]
 rwhois Referral WHOIS [RFC-1714]
 [Page 3]
INTERNET-DRAFT Feburary 1997
 wais Wide Area Information Server [RFC-1625]
 whois NICNAME/WHOIS [RFC-954]
 www World-Wide Web HTTP [RFC-1945]
 -----------------------------------------------------------
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.
 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.
 [Page 4]
INTERNET-DRAFT Feburary 1997
 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-
 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. 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.
7. CCSO service name
 There are currently at least three different aliases in common use
 for the CCSO nameserver - e.g. "ph", "cso" and "ns". It would appear
 to be in everyone's interest to narrow the choice of alias down to a
 single name. "ns" would seem to be the best choice since it is the
 most commonly used name. However, "ns" is also being used by DNS to
 point to the DNS server. In fact, the most prevalent use of NS to
 name DNS servers. For this reason, we suggest the use of PH as the
 best name to use for CCSO nameservers.
 Sites with existing CCSO servers using some of these aliases may find
 it desirable to use all three. This increases the likelihood of the
 service being found.
 [Page 5]
INTERNET-DRAFT Feburary 1997
 As noted earlier, implementations should be resilient in the event
 that the name does not point to the expected service.
8. 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 [RFC-2065]. 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 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.
9. Conclusions
 The service names listed in this document 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.
10. Acknowledgements
 Thanks to Jeff Allen, Tom Gillman, Renato Iannella, Thomas
 Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri, Patrik
 Faltstrom, Paul Vixie and Greg Woods for their comments on draft
 versions of this document.
 This work was supported by grants from the UK Electronic Libraries
 Programme (eLib) grant 12/39/01, the European Commission's Telematics
 for Research Programme grant RE 1004, and U. S. Department of Energy
 Contract Number DE-AC03-76SF00098.
11. References
 Request For Comments (RFC) and Internet Draft documents are available
 from <URL:ftp://ftp.internic.net> and numerous mirror sites.
 [Page 6]
INTERNET-DRAFT Feburary 1997
 [ARCHIE] A. Emtage, P. Deutsch. "archie - An Electronic
 Directory Service for the Internet", Winter Usenix
 Conference Proceedings 1992. Pages 93-110.
 [PH] R. Hedberg, S. Dorner, P. Pomes. "The CCSO
 Nameserver (Ph) Architecture", Internet Draft.
 February 1996.
 [RFC-768] J. Postel. "User Datagram Protocol", RFC 768.
 August 1980.
 [RFC-793] J. Postel. "Transmission Control Protocol", RFC
 793. September 1981.
 [RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC
 821. August 1982.
 [RFC-954] K. Harrenstien, M. K. Stahl, E.J. Feinler.
 "NICNAME/WHOIS", RFC 954. October 1985.
 [RFC-959] J. Postel, J. K. Reynolds. "File Transfer Proto-
 col", RFC 959. October 1985.
 [RFC-974] C. Partridge. "Mail routing and the domain sys-
 tem", RFC 974. January 1986.
 [RFC-977] B. Kantor, P. Lapsley. "Network News Transfer Pro-
 tocol", RFC 977. February 1986.
 [RFC-1034] P. V. Mockapetris. "Domain names - concepts and
 facilities", RFC 1034. November 1987.
 [RFC-1035] P. V. Mockapetris. "Domain names - implementation
 and specification", RFC 1035. November 1987.
 [RFC-1123] R. T. Braden. "Requirements for Internet hosts -
 application and support", RFC 1123. October 1989.
 [Page 7]
INTERNET-DRAFT Feburary 1997
 [RFC-1288] D. Zimmerman. "The Finger User Information Proto-
 col", RFC 1288. December 1992.
 [RFC-1305] D. Mills. "Network Time Protocol (Version 3)
 Specification, Implementation", RFC 1305. March
 1992.
 [RFC-1436] 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.
 [RFC-1590] J. Postel. "Media Type Registration Procedure",
 RFC 1590. March 1994.
 [RFC-1625] 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.
 [RFC-1700] J. Reynolds, J. Postel. "ASSIGNED NUMBERS", RFC
 1700. October 1994.
 [RFC-1714] S. Williamson & M. Kosters. "Referral Whois Proto-
 col (RWhois)", RFC 1714. November 1994.
 [RFC-1777] W. Yeong, T. Howes, S. Kille. "Lightweight Direc-
 tory Access Protocol", RFC 1777. March 1995.
 [RFC-1939] J. Myers, M. Rose, "Post Office Protocol - Version
 3", RFC 1939, May 1996.
 [RFC-1945] T. Berners-Lee, R. Fielding, H. Nielsen. "Hyper-
 text Transfer Protocol -- HTTP/1.0", RFC 1945. May
 1996.
 [RFC-2052] A. Gulbrandsen, P. Vixie, "A DNS RR for specifying
 the location of services (DNS SRV)", RFC 2052,
 October 1996.
 [Page 8]
INTERNET-DRAFT Feburary 1997
 [RFC-2065] D. Eastlake, C. Kaufman, "Domain Name System Secu-
 rity Extensions", RFC 2065, January 1997.
12. 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: 50A-3111
 CA 94720, USA
 Email: wright@lbl.gov
 This Internet Draft expires August 1, 1997.
 [Page 9]