summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2219.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2219.txt')
-rw-r--r--doc/rfc/rfc2219.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc2219.txt b/doc/rfc/rfc2219.txt
new file mode 100644
index 0000000..8817819
--- /dev/null
+++ b/doc/rfc/rfc2219.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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
+ supersede both WKS and MX.
+
+
+
+
+
+
+
+
+Hamilton & Wright Best Current Practice [Page 2]
+
+RFC 2219 DNS Aliases October 1997
+
+
+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
+
+ 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]
+ 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
+
+
+
+
+
+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 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 generalized 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.
+ 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. For example,
+ ph.hivnet.fr could not contain a MX 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
+
+ It isn't a simple matter of recommending CNAMEs over A records. Each
+ site has it's own set of requirements that may make one approach
+ better than the other. RFC 1912 [RFC-1912] discusses some of the
+ 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" 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" is
+ 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.
+
+ 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.
+
+
+
+
+Hamilton & Wright Best Current Practice [Page 5]
+
+RFC 2219 DNS Aliases October 1997
+
+
+ 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 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) documents are available from
+ <URL:ftp://ftp.internic.net/rfc> and numerous mirror sites.
+
+ [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", 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 Transfer
+ Protocol", STD 9, RFC 959, October 1985.
+
+ [RFC-974] Partridge, C., "Mail routing and the domain
+ System", STD 14, RFC 974, January 1986.
+
+ [RFC-977] Kantor, B., and P. Lapsley, "Network News Transfer
+ Protocol", RFC 977, February 1986.
+
+ [RFC-1034] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC-1035] Mockapetris, P., "Domain names - implementation
+ 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 Information
+ 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 Protocol
+ (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 Whois
+ Protocol (RWhois)", RFC 1714, November 1994.
+
+ [RFC-1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol", RFC 1777, March 1995.
+
+ [RFC-1912] Barr, D., "Common DNS Operational and Configuration
+ Errors", RFC 1912, Feburary 1996.
+
+ [RFC-1939] Myers, J., and M. Rose, "Post Office Protocol - Version
+ 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, May
+ 1996.
+
+ [RFC-2052] Gulbrandsen, A., and P. Vixie, "A DNS RR for specifying
+ the location of services (DNS SRV)", RFC 2052, October
+ 1996.
+
+ [RFC-2065] Eastlake, D., and C. Kaufman, "Domain Name System
+ Security 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
+
+
+
+
+
+
+
+
+
+
+Hamilton & Wright Best Current Practice [Page 8]
+