RFC 2219 (rfc2219) - Page 1 of 8


Use of DNS Aliases for Network Services



Alternative Format: Original Text Document



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