home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2219 < prev    next >
Text File  |  1997-10-09  |  18KB  |  452 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        M. Hamilton
  8. Request for Comments: 2219                       Loughborough University
  9. BCP: 17                                                        R. Wright
  10. Category: Best Current Practice             Lawrence Berkeley Laboratory
  11.                                                             October 1997
  12.  
  13.  
  14.                 Use of DNS Aliases for Network Services
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet Best Current Practices for the
  19.    Internet Community, and requests discussion and suggestions for
  20.    improvements.  Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    It has become a common practice to use symbolic names (usually
  25.    CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to
  26.    refer to network services such as anonymous FTP [RFC-959] servers,
  27.    Gopher [RFC-1436] servers, and most notably World-Wide Web HTTP
  28.    [RFC-1945] servers.  This is desirable for a number of reasons.  It
  29.    provides a way of moving services from one machine to another
  30.    transparently, and a mechanism by which people or agents may
  31.    programmatically discover that an organization runs, say, a World-
  32.    Wide Web server.
  33.  
  34.    Although this approach has been almost universally adopted, there is
  35.    no standards document or similar specification for these commonly
  36.    used names.  This document seeks to rectify this situation by
  37.    gathering together the extant 'folklore' on naming conventions, and
  38.    proposes a mechanism for accommodating new protocols.
  39.  
  40.    It is important to note that these naming conventions do not provide
  41.    a complete long term solution to the problem of finding a particular
  42.    network service for a site.  There are efforts in other IETF working
  43.    groups to address the long term solution to this problem, such as the
  44.    Server Location Resource Records (DNS SRV) [RFC-2052] work.
  45.  
  46. 1. Rationale
  47.  
  48.    In order to locate the network services offered at a particular
  49.    Internet domain one is faced with the choice of selecting from a
  50.    growing number of centralized databases - typically Web or Usenet
  51.    News "wanderers", or attempting to infer the existence of network
  52.    services from whatever DNS information may be available.  The former
  53.    approach is not practical in some cases, notably when the entity
  54.    seeking service information is a program.
  55.  
  56.  
  57.  
  58. Hamilton & Wright        Best Current Practice                  [Page 1]
  59.  
  60. RFC 2219                      DNS Aliases                   October 1997
  61.  
  62.  
  63.    Perhaps the most visible example of the latter approach at work is in
  64.    the case of World-Wide Web HTTP servers.  It is common practice to
  65.    try prefixing the domain name of an organization with "http://www."
  66.    in order to reach its World-Wide Web site, e.g. taking "hivnet.fr"
  67.    and arriving at "http://www.hivnet.fr."  Some popular World-Wide Web
  68.    browsers have gone so far as to provide automatic support for this
  69.    domain name expansion.
  70.  
  71.    Ideally, the DNS or some complementary directory service would
  72.    provide a means for programs to determine automatically the network
  73.    services which are offered at a particular Internet domain, the
  74.    protocols which are used to deliver them, and other technical
  75.    information.  Unfortunately, although much work has been done to
  76.    develop said directory service technologies and to define new types
  77.    of DNS resource record to provide this type of information, there is
  78.    no widely agreed upon or widely deployed solution to the problem -
  79.    except in a small number of cases.
  80.  
  81.    The first case is where the DNS already provides a lookup capability
  82.    for the type of information being sought after.  For example: Mail
  83.    Exchanger (MX) records specify how mail to a particular domain should
  84.    be routed [RFC-974], the Start of Authority (SOA) records make it
  85.    possible to determine who is responsible for a given domain, and Name
  86.    Server (NS) records indicate which hosts provide DNS name service for
  87.    a given domain.
  88.  
  89.    The second case is where the DNS does not provide an appropriate
  90.    lookup capability, but there is some widely accepted convention for
  91.    finding this information.  Some use has been made of Text (TXT)
  92.    [RFC-1035] records in this scenario, but in the vast majority of
  93.    cases a Canonical Name (CNAME) or Address (A) record pointer is used
  94.    to indicate the host or hosts which provide the service.  This
  95.    document proposes a slight formalization of this well-known alias
  96.    approach.
  97.  
  98.    It should be noted that the DNS provides a Well Known Services (WKS)
  99.    [RFC-1035] lookup capability, which makes it possible to determine
  100.    the network services offered at a given domain name.  In practice
  101.    this is not widely used, perhaps because of the absence of a suitable
  102.    programming interface.  Use of WKS for mail routing was deprecated in
  103.    the Host Requirements specification [RFC-1123] in favour of the MX
  104.    record, and in the long term it is conceivable that SRV records will
  105.    supersede both WKS and MX.
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Hamilton & Wright        Best Current Practice                  [Page 2]
  115.  
  116. RFC 2219                      DNS Aliases                   October 1997
  117.  
  118.  
  119. 2. A generic framework
  120.  
  121.    Our approach to dealing with aliases for protocols is
  122.    straightforward. We define a standard set of DNS aliases for the most
  123.    popular network services that currently exist (see the "Special
  124.    Cases" section below). For protocols that are not explicitly listed
  125.    in this document, the protocol specification must propose a name.
  126.  
  127. 3. Special cases
  128.  
  129.    Special Cases:
  130.         -----------------------------------------------------------
  131.         Alias     Service
  132.         -----------------------------------------------------------
  133.         archie    archie [ARCHIE]
  134.         finger    Finger [RFC-1288]
  135.         ftp       File Transfer Protocol [RFC-959]
  136.         gopher    Internet Gopher Protocol [RFC-1436]
  137.         ldap      Lightweight Directory Access Protocol [RFC-1777]
  138.         mail      SMTP mail [RFC-821]
  139.         news      Usenet News via NNTP [RFC-977]
  140.         ntp       Network Time Protocol [RFC-1305]
  141.         ph        CCSO nameserver [PH]
  142.         pop       Post Office Protocol [RFC-1939]
  143.         rwhois    Referral WHOIS [RFC-1714]
  144.         wais      Wide Area Information Server [RFC-1625]
  145.         whois     NICNAME/WHOIS [RFC-954]
  146.         www       World-Wide Web HTTP [RFC-1945]
  147.         -----------------------------------------------------------
  148.  
  149. 4. (Ab)Use of the DNS as a directory service
  150.  
  151.    The widespread use of these common aliases effectively means that it
  152.    is sometimes possible to "guess" the domain names associated with an
  153.    organization's network services, though this is becoming more
  154.    difficult as the number of organizations registered in the DNS
  155.    increases.
  156.  
  157.    It should be understood by implementors that the existence of a DNS
  158.    entry such as
  159.  
  160.         www.hivnet.fr
  161.  
  162.    does not constitute a registration of a World-Wide Web service.
  163.    There is no requirement that the domain name resolve to an IP address
  164.    or addresses.  There is no requirement that a host be listening for
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Hamilton & Wright        Best Current Practice                  [Page 3]
  171.  
  172. RFC 2219                      DNS Aliases                   October 1997
  173.  
  174.  
  175.    HTTP connections, or if it is, that the HTTP server be running on
  176.    port 80.  Finally, even if all of these things are true, there can be
  177.    no guarantee that the World-Wide Web server will be prepared to honor
  178.    requests from arbitrary clients.
  179.  
  180.    Having said this, the aliases do provide useful "hints" about the
  181.    services offered.  We propose that they be taken in this spirit.
  182.  
  183.    The conventions described in this document are, essentially, only
  184.    useful when the organization's domain name can be determined - e.g.
  185.    from some external database.  A number of groups, including the IETF,
  186.    have been working on ways of finding domain names given a set of
  187.    information such as organization name, location, and business type.
  188.    It is hoped that one or more of these will eventually make it
  189.    possible to augment the basic lookup service which the DNS provides
  190.    with a more generalized search and retrieval capability.
  191.  
  192. 5. DNS server configuration
  193.  
  194.    In the short term, whilst directory service technology and further
  195.    types of DNS resource record are being developed, domain name
  196.    administrators are encouraged to use these common names for the
  197.    network services they run.  They will make it easier for outsiders to
  198.    find information about your organization, and also make it easier for
  199.    you to move services from one machine to another.
  200.  
  201.    There are two conventional approaches to creating these DNS entries.
  202.    One is to add a single CNAME record to your DNS server's
  203.    configuration, e.g.
  204.  
  205.         ph.hivnet.fr. IN CNAME baby.hivnet.fr.
  206.  
  207.    Note that in this scenario no information about ph.hivnet.fr should
  208.    exist in the DNS other than the CNAME record. For example,
  209.    ph.hivnet.fr could not contain a MX record.
  210.  
  211.    An alternative approach would be to create an A record for each of
  212.    the IP addresses associated with ph.hivnet.fr, e.g.
  213.  
  214.         ph.hivnet.fr. IN A 194.167.157.2
  215.  
  216.    It isn't a simple matter of recommending CNAMEs over A records. Each
  217.    site has it's own set of requirements that may make one approach
  218.    better than the other. RFC 1912 [RFC-1912]  discusses some of the
  219.    configuration issues involved in using CNAMEs.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Hamilton & Wright        Best Current Practice                  [Page 4]
  227.  
  228. RFC 2219                      DNS Aliases                   October 1997
  229.  
  230.  
  231.    Recent DNS server implementations provide a "round-robin" feature
  232.    which causes the host's IP addresses to be returned in a different
  233.    order each time the address is looked up.
  234.  
  235.    Network clients are starting to appear which, when they encounter a
  236.    host with multiple addresses, use heuristics to determine the address
  237.    to contact - e.g. picking the one which has the shortest round-trip-
  238.    time.  Thus, if a server is mirrored (replicated) at a number of
  239.    locations, it may be desirable to list the IP addresses of the mirror
  240.    servers as A records of the primary server.  This is only likely to
  241.    be appropriate if the mirror servers are exact copies of the original
  242.    server.
  243.  
  244. 6. Limitations of this approach
  245.  
  246.    Some services require that a client have more information than the
  247.    server's domain name.  For example, an LDAP client needs to know a
  248.    starting search base within the Directory Information Tree in order
  249.    to have a meaningful dialogue with the server.  This document does
  250.    not attempt to address this problem.
  251.  
  252. 7. CCSO service name
  253.  
  254.    There are currently at least three different aliases in common use
  255.    for the CCSO nameserver - e.g. "ph", "cso" and "ns".  It would appear
  256.    to be in everyone's interest to narrow the choice of alias down to a
  257.    single name.  "ns" would seem to be the best choice since it is the
  258.    most commonly used name.  However, "ns" is also being used by DNS to
  259.    point to the DNS server.  In fact, the most prevalent use of "ns" is
  260.    to name DNS servers.  For this reason, we suggest the use of "ph" as
  261.    the best name to use for CCSO nameservers.
  262.  
  263.    Sites with existing CCSO servers using some of these aliases may find
  264.    it desirable to use all three.  This increases the likelihood of the
  265.    service being found.
  266.  
  267.    As noted earlier, implementations should be resilient in the event
  268.    that the name does not point to the expected service.
  269.  
  270. 8. Security Considerations
  271.  
  272.    The DNS is open to many kinds of "spoofing" attacks, and it cannot be
  273.    guaranteed that the result returned by a DNS lookup is indeed the
  274.    genuine information.  Spoofing may take the form of denial of
  275.    service, such as directing of the client to a non-existent address,
  276.    or a passive attack such as an intruder's server which masquerades as
  277.    the legitimate one.
  278.  
  279.  
  280.  
  281.  
  282. Hamilton & Wright        Best Current Practice                  [Page 5]
  283.  
  284. RFC 2219                      DNS Aliases                   October 1997
  285.  
  286.  
  287.    Work is ongoing to remedy this situation insofar as the DNS is
  288.    concerned [RFC-2065].  In the meantime it should be noted that
  289.    stronger authentication mechanisms such as public key cryptography
  290.    with large key sizes are a pre-requisite if the DNS is being used in
  291.    any sensitive situations.  Examples of these would be on-line
  292.    financial transactions, and any situation where privacy is a concern
  293.    - such as the querying of medical records over the network.  Strong
  294.    encryption of the network traffic may also be advisable, to protect
  295.    against TCP connection "hijacking" and packet sniffing.
  296.  
  297. 9. Conclusions
  298.  
  299.    The service names listed in this document provide a sensible set of
  300.    defaults which may be used as an aid in determining the hosts which
  301.    offer particular services for a given domain name.
  302.  
  303.    This document has noted some exceptions which are either inherently
  304.    unsuitable for this treatment, or already have a substantial
  305.    installed base using alternative aliases.
  306.  
  307. 10. Acknowledgements
  308.  
  309.    Thanks to Jeff Allen, Tom Gillman, Renato Iannella, Thomas
  310.    Lenggenhager, Bill Manning, Andy Powell, Sri Sataluri, Patrik
  311.    Faltstrom, Paul Vixie and Greg Woods for their comments on draft
  312.    versions of this document.
  313.  
  314.    This work was supported by UK Electronic Libraries Programme (eLib)
  315.    grant 12/39/01, the European Commission's Telematics for Research
  316.    Programme grant RE 1004, and U. S. Department of Energy Contract
  317.    Number DE-AC03-76SF00098.
  318.  
  319. 11. References
  320.  
  321.    Request For Comments (RFC) documents are available from
  322.    <URL:ftp://ftp.internic.net/rfc> and numerous mirror sites.
  323.  
  324.    [ARCHIE]    A. Emtage, P. Deutsch. "archie - An Electronic
  325.                Directory Service for the Internet", Winter Usenix
  326.                Conference Proceedings 1992.  Pages 93-110.
  327.  
  328.    [PH]        R. Hedberg, S. Dorner, P. Pomes.  "The CCSO
  329.                Nameserver (Ph) Architecture", Work in Progress.
  330.  
  331.    [RFC-768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
  332.                August 1980.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Hamilton & Wright        Best Current Practice                  [Page 6]
  339.  
  340. RFC 2219                      DNS Aliases                   October 1997
  341.  
  342.  
  343.    [RFC-793]   Postel, J., "Transmission Control Protocol", STD 7,
  344.                RFC 793, September 1981.
  345.  
  346.    [RFC-821]   Postel, J., "Simple Mail Transfer Protocol", STD 10,
  347.                RFC 821, August 1982.
  348.  
  349.    [RFC-954]   Harrenstien, K., Stahl, M., and E. Feinler,
  350.                "NICNAME/WHOIS", RFC 954, October 1985.
  351.  
  352.    [RFC-959]   Postel, J., and J.K. Reynolds, "File Transfer
  353.                Protocol", STD 9, RFC 959, October 1985.
  354.  
  355.    [RFC-974]   Partridge, C., "Mail routing and the domain
  356.                System", STD 14, RFC 974,  January 1986.
  357.  
  358.    [RFC-977]   Kantor, B., and P. Lapsley, "Network News Transfer
  359.                Protocol", RFC 977, February 1986.
  360.  
  361.    [RFC-1034]  Mockapetris, P., "Domain names - concepts and
  362.                facilities", STD 13, RFC 1034, November 1987.
  363.  
  364.    [RFC-1035]  Mockapetris, P., "Domain names - implementation
  365.                and specification", STD 13, RFC 1035, November 1987.
  366.  
  367.    [RFC-1123]  Braden, R., "Requirements for Internet hosts -
  368.                application and support", STD 3, RFC 1123, October 1989.
  369.  
  370.    [RFC-1288]  Zimmerman, D., "The Finger User Information
  371.                Protocol", RFC 1288, December 1992.
  372.  
  373.    [RFC-1305]  Mills, D., "Network Time Protocol (Version 3)
  374.                Specification, Implementation", RFC 1305,  March  1992.
  375.  
  376.    [RFC-1436]  Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
  377.                Torrey, D., and B. Albert, "The Internet Gopher Protocol
  378.                (a distributed document search and retrieval protocol)",
  379.                RFC 1436, March 1993.
  380.  
  381.    [RFC-1590]  Postel, J., "Media Type Registration Procedure",
  382.                RFC 1590, March 1994.
  383.  
  384.    [RFC-1625]  St. Pierre, M., Fullton, J., Gamiel, K., Goldman, J.,
  385.                Kahle, B., Kunze, J., Morris, H., and F. Schiettecatte,
  386.                "WAIS over Z39.50-1988", RFC 1625, June 1994.
  387.  
  388.    [RFC-1700]  Reynolds, J.K., and J. Postel,  "ASSIGNED NUMBERS",
  389.                STD 2, RFC 1700, October 1994.
  390.  
  391.  
  392.  
  393.  
  394. Hamilton & Wright        Best Current Practice                  [Page 7]
  395.  
  396. RFC 2219                      DNS Aliases                   October 1997
  397.  
  398.  
  399.    [RFC-1714]  Williamson, S., and M. Kosters, "Referral Whois
  400.                Protocol (RWhois)", RFC 1714, November 1994.
  401.  
  402.    [RFC-1777]  Yeong, W., Howes, T., and S. Kille, "Lightweight
  403.                Directory Access Protocol", RFC 1777, March 1995.
  404.  
  405.    [RFC-1912]  Barr, D., "Common DNS Operational and Configuration
  406.                Errors", RFC 1912, Feburary 1996.
  407.  
  408.    [RFC-1939]  Myers, J., and M. Rose, "Post Office Protocol - Version
  409.                3", STD 53, RFC 1939, May 1996.
  410.  
  411.    [RFC-1945]  Berners-Lee, T., Fielding, R., and H. Nielsen,
  412.                "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May
  413.                1996.
  414.  
  415.    [RFC-2052]  Gulbrandsen, A., and P. Vixie, "A DNS RR for specifying
  416.                the location of services (DNS SRV)", RFC 2052, October
  417.                1996.
  418.  
  419.    [RFC-2065]  Eastlake, D., and C. Kaufman, "Domain Name System
  420.                Security Extensions", RFC 2065, January 1997.
  421.  
  422. 12. Authors' Addresses
  423.  
  424.    Martin Hamilton
  425.    Department of Computer Studies
  426.    Loughborough University of Technology
  427.    Leics. LE11 3TU, UK
  428.  
  429.    EMail: m.t.hamilton@lut.ac.uk
  430.  
  431.  
  432.    Russ Wright
  433.    Information & Computing Sciences Division
  434.    Lawrence Berkeley National Laboratory
  435.    1 Cyclotron Road, Berkeley
  436.    Mail-Stop: 50A-3111
  437.    CA 94720, USA
  438.  
  439.    EMail: wright@lbl.gov
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Hamilton & Wright        Best Current Practice                  [Page 8]
  451.  
  452.