Use of DNS Aliases for Network Services
RFC 2219

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                        M. Hamilton
Request for Comments: 2219                       Loughborough University
BCP: 17                                                        R. Wright
Category: Best Current Practice             Lawrence Berkeley Laboratory
                                                            October 1997

                Use of DNS Aliases for Network Services

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

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

   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.

Hamilton & Wright        Best Current Practice                  [Page 1]
RFC 2219                      DNS Aliases                   October 1997

   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 to
   develop said directory service technologies and 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
   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)
   [RFC-1035] 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)
   [RFC-1035] 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