doc: Add RFC documents

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]
+