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