As per Relevance of the word practice, we have this rfc below:
Network Working Group M.
Request for Comments: 2219 Loughborough
BCP: 17 R.
Category: Best Current Practice Lawrence Berkeley
October 1997
Use of DNS Aliases for Network
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
It has become a common practice to use symbolic names (
CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035])
refer to network services such as anonymous FTP [RFC-959] servers
Gopher [RFC-1436] servers, and most notably World-Wide Web
[RFC-1945] servers. This is desirable for a number of reasons.
provides a way of moving services from one machine to
transparently, and a mechanism by which people or agents
programmatically discover that an organization runs, say, a World
Wide Web server
Although this approach has been almost universally adopted, there
no standards document or similar specification for these
used names. This document seeks to rectify this situation
gathering together the extant 'folklore' on naming conventions,
proposes a mechanism for accommodating new protocols
It is important to note that these naming conventions do not
a complete long term solution to the problem of finding a
network service for a site. There are efforts in other IETF
groups to address the long term solution to this problem, such as
Server Location Resource Records (DNS SRV) [RFC-2052] work
1.
In order to locate the network services offered at a
Internet domain one is faced with the choice of selecting from
growing number of centralized databases - typically Web or
News "wanderers", or attempting to infer the existence of
services from whatever DNS information may be available. The
approach is not practical in some cases, notably when the
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
the case of World-Wide Web HTTP servers. It is common practice
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
browsers have gone so far as to provide automatic support for
domain name expansion
Ideally, the DNS or some complementary directory service
provide a means for programs to determine automatically the
services which are offered at a particular Internet domain,
protocols which are used to deliver them, and other
information. Unfortunately, although much work has been done
develop said directory service technologies and to define new
of DNS resource record to provide this type of information, there
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
for the type of information being sought after. For example:
Exchanger (MX) records specify how mail to a particular domain
be routed [RFC-974], the Start of Authority (SOA) records make
possible to determine who is responsible for a given domain, and
Server (NS) records indicate which hosts provide DNS name service
a given domain
The second case is where the DNS does not provide an
lookup capability, but there is some widely accepted convention
finding this information. Some use has been made of Text (TXT
[RFC-1035] records in this scenario, but in the vast majority
cases a Canonical Name (CNAME) or Address (A) record pointer is
to indicate the host or hosts which provide the service.
document proposes a slight formalization of this well-known
approach
It should be noted that the DNS provides a Well Known Services (WKS
[RFC-1035] lookup capability, which makes it possible to
the network services offered at a given domain name. In
this is not widely used, perhaps because of the absence of a
programming interface. Use of WKS for mail routing was deprecated
the Host Requirements specification [RFC-1123] in favour of the
record, and in the long term it is conceivable that SRV records
supersede both WKS and MX
Hamilton & Wright Best Current Practice [Page 2]
RFC 2219 DNS Aliases October 1997
2. A generic
Our approach to dealing with aliases for protocols
straightforward. We define a standard set of DNS aliases for the
popular network services that currently exist (see the "
Cases" section below). For protocols that are not explicitly
in this document, the protocol specification must propose a name
3. Special
Special Cases
-----------------------------------------------------------
Alias
-----------------------------------------------------------
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]
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
The widespread use of these common aliases effectively means that
is sometimes possible to "guess" the domain names associated with
organization's network services, though this is becoming
difficult as the number of organizations registered in the
increases
It should be understood by implementors that the existence of a
entry such
www.hivnet.
does not constitute a registration of a World-Wide Web service
There is no requirement that the domain name resolve to an IP
or addresses. There is no requirement that a host be listening
Hamilton & Wright Best Current Practice [Page 3]
RFC 2219 DNS Aliases October 1997
HTTP connections, or if it is, that the HTTP server be running
port 80. Finally, even if all of these things are true, there can
no guarantee that the World-Wide Web server will be prepared to
requests from arbitrary clients
Having said this, the aliases do provide useful "hints" about
services offered. We propose that they be taken in this spirit
The conventions described in this document are, essentially,
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
information such as organization name, location, and business type
It is hoped that one or more of these will eventually make
possible to augment the basic lookup service which the DNS
with a more generalized search and retrieval capability
5. DNS server
In the short term, whilst directory service technology and
types of DNS resource record are being developed, domain
administrators are encouraged to use these common names for
network services they run. They will make it easier for outsiders
find information about your organization, and also make it easier
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'
configuration, e.g
ph.hivnet.fr. IN CNAME baby.hivnet.fr
Note that in this scenario no information about ph.hivnet.fr
exist in the DNS other than the CNAME record. For example
ph.hivnet.fr could not contain a MX record
An alternative approach would be to create an A record for each
the IP addresses associated with ph.hivnet.fr, e.g
ph.hivnet.fr. IN A 194.167.157.2
It isn't a simple matter of recommending CNAMEs over A records.
site has it's own set of requirements that may make one
better than the other. RFC 1912 [RFC-1912] discusses some of
configuration issues involved in using CNAMEs
Hamilton & Wright Best Current Practice [Page 4]
RFC 2219 DNS Aliases October 1997
Recent DNS server implementations provide a "round-robin"
which causes the host's IP addresses to be returned in a
order each time the address is looked up
Network clients are starting to appear which, when they encounter
host with multiple addresses, use heuristics to determine the
to contact - e.g. picking the one which has the shortest round-trip
time. Thus, if a server is mirrored (replicated) at a number
locations, it may be desirable to list the IP addresses of the
servers as A records of the primary server. This is only likely
be appropriate if the mirror servers are exact copies of the
server
6. Limitations of this
Some services require that a client have more information than
server's domain name. For example, an LDAP client needs to know
starting search base within the Directory Information Tree in
to have a meaningful dialogue with the server. This document
not attempt to address this problem
7. CCSO service
There are currently at least three different aliases in common
for the CCSO nameserver - e.g. "ph", "cso" and "ns". It would
to be in everyone's interest to narrow the choice of alias down to
single name. "ns" would seem to be the best choice since it is
most commonly used name. However, "ns" is also being used by DNS
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"
the best name to use for CCSO nameservers
Sites with existing CCSO servers using some of these aliases may
it desirable to use all three. This increases the likelihood of
service being found
As noted earlier, implementations should be resilient in the
that the name does not point to the expected service
8. Security
The DNS is open to many kinds of "spoofing" attacks, and it cannot
guaranteed that the result returned by a DNS lookup is indeed
genuine information. Spoofing may take the form of denial
service, such as directing of the client to a non-existent address
or a passive attack such as an intruder's server which masquerades
the legitimate one
Hamilton & Wright Best Current Practice [Page 5]
RFC 2219 DNS Aliases October 1997
Work is ongoing to remedy this situation insofar as the DNS
concerned [RFC-2065]. In the meantime it should be noted
stronger authentication mechanisms such as public key
with large key sizes are a pre-requisite if the DNS is being used
any sensitive situations. Examples of these would be on-
financial transactions, and any situation where privacy is a
- such as the querying of medical records over the network.
encryption of the network traffic may also be advisable, to
against TCP connection "hijacking" and packet sniffing
9.
The service names listed in this document provide a sensible set
defaults which may be used as an aid in determining the hosts
offer particular services for a given domain name
This document has noted some exceptions which are either
unsuitable for this treatment, or already have a
installed base using alternative aliases
10.
Thanks to Jeff Allen, Tom Gillman, Renato Iannella,
Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri,
Faltstrom, Paul Vixie and Greg Woods for their comments on
versions of this document
This work was supported by UK Electronic Libraries Programme (eLib
grant 12/39/01, the European Commission's Telematics for
Programme grant RE 1004, and U. S. Department of Energy
Number DE-AC03-76SF00098.
11.
Request For Comments (RFC) documents are available
internic.net/rfc> and numerous mirror sites
[ARCHIE] A. Emtage, P. Deutsch. "archie - An
Directory Service for the Internet", Winter
Conference Proceedings 1992. Pages 93-110.
[PH] R. Hedberg, S. Dorner, P. Pomes. "The
Nameserver (Ph) Architecture", Work in Progress
[RFC-768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
Hamilton & Wright Best Current Practice [Page 6]
RFC 2219 DNS Aliases October 1997
[RFC-793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[RFC-954] Harrenstien, K., Stahl, M., and E. Feinler
"NICNAME/WHOIS", RFC 954, October 1985.
[RFC-959] Postel, J., and J.K. Reynolds, "File
Protocol", STD 9, RFC 959, October 1985.
[RFC-974] Partridge, C., "Mail routing and the
System", STD 14, RFC 974, January 1986.
[RFC-977] Kantor, B., and P. Lapsley, "Network News
Protocol", RFC 977, February 1986.
[RFC-1034] Mockapetris, P., "Domain names - concepts
facilities", STD 13, RFC 1034, November 1987.
[RFC-1035] Mockapetris, P., "Domain names -
and specification", STD 13, RFC 1035, November 1987.
[RFC-1123] Braden, R., "Requirements for Internet hosts -
application and support", STD 3, RFC 1123, October 1989.
[RFC-1288] Zimmerman, D., "The Finger User
Protocol", RFC 1288, December 1992.
[RFC-1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC-1436] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., and B. Albert, "The Internet Gopher
(a distributed document search and retrieval protocol)",
RFC 1436, March 1993.
[RFC-1590] Postel, J., "Media Type Registration Procedure",
RFC 1590, March 1994.
[RFC-1625] St. Pierre, M., Fullton, J., Gamiel, K., Goldman, J.,
Kahle, B., Kunze, J., Morris, H., and F. Schiettecatte
"WAIS over Z39.50-1988", RFC 1625, June 1994.
[RFC-1700] Reynolds, J.K., and J. Postel, "ASSIGNED NUMBERS",
STD 2, RFC 1700, October 1994.
Hamilton & Wright Best Current Practice [Page 7]
RFC 2219 DNS Aliases October 1997
[RFC-1714] Williamson, S., and M. Kosters, "Referral
Protocol (RWhois)", RFC 1714, November 1994.
[RFC-1777] Yeong, W., Howes, T., and S. Kille, "
Directory Access Protocol", RFC 1777, March 1995.
[RFC-1912] Barr, D., "Common DNS Operational and
Errors", RFC 1912, Feburary 1996.
[RFC-1939] Myers, J., and M. Rose, "Post Office Protocol -
3", STD 53, RFC 1939, May 1996.
[RFC-1945] Berners-Lee, T., Fielding, R., and H. Nielsen
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
1996.
[RFC-2052] Gulbrandsen, A., and P. Vixie, "A DNS RR for
the location of services (DNS SRV)", RFC 2052,
1996.
[RFC-2065] Eastlake, D., and C. Kaufman, "Domain Name
Security Extensions", RFC 2065, January 1997.
12. Authors'
Martin
Department of Computer
Loughborough University of
Leics. LE11 3TU,
EMail: m.t.hamilton@lut.ac.
Russ
Information & Computing Sciences
Lawrence Berkeley National
1 Cyclotron Road,
Mail-Stop: 50A-3111
CA 94720,
EMail: wright@lbl.
Hamilton & Wright Best Current Practice [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
