Use of DNS Aliases for Network Services
RFC 2219
Document | Type |
RFC - Best Current Practice
(October 1997; No errata)
Also known as BCP 17
|
|
---|---|---|---|
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text pdf html bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2219 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 willShow full document text