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