[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 rfc2219                                              
IDS Working Group                                        Martin Hamilton
INTERNET-DRAFT                                   Loughborough University
                                                             Russ Wright
                                            Lawrence Berkeley Laboratory
                                                             August 1996

                Use of DNS Aliases for Network Services
                Filename: draft-ietf-ids-dnsnames-01.txt

Status of this Memo

      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its
      areas, and its working groups.  Note that other groups may also
      distribute working documents as Internet-Drafts.

      Internet-Drafts are draft documents valid for a maximum of six
      months and may be updated, replaced, or obsoleted by other
      documents at any time.  It is inappropriate to use Internet-
      Drafts as reference material or to cite them other than as ``work
      in progress.''

      To learn the current status of any Internet-Draft, please check
      the ``1id-abstracts.txt'' listing contained in the Internet-
      Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
      Coast), or ftp.isi.edu (US West Coast).

      Distribution of this document is unlimited.  Editorial comments
      should be sent directly to the authors.  Technical discussion will
      take place on the IETF Integrated Directory Services mailing list,

      This Internet Draft expires February 12th, 1997.


   It has become a common practice to use symbolic names (usually
   CNAMEs) in the Domain Name Service (DNS - [1,2]) to refer to network
   services such as anonymous FTP [3] servers, Gopher [4] servers, and
   most notably World-Wide Web HTTP [5] 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 programatically discover that an organization runs, say, a
   World-Wide Web server.

                                                                [Page 1]

INTERNET-DRAFT                                               August 1996

   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) 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.

   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 such as TCP [6] and UDP [7] port numbers.

   Unfortunately, although much work has been done on developing "yellow
   pages" directory service technologies, and on attempting 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 [8], 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

                                                                [Page 2]

INTERNET-DRAFT                                               August 1996

   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)
   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)
   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 [9] in favour of the MX record, and in the
   long term it is conceivable that SRV records will supercede both WKS
   and MX.

2. A generic framework

   One approach to dealing with aliases for new protocols would be to
   define a standard set of DNS aliases for the most popular network
   services, and an accompanying review procedure for registering new
   protocols - such as has been attempted with Internet Media (MIME)
   Types [10].  We suggest that in the rapidly changing world of
   computer networking this may not be the most appropriate way of
   tackling the problem.

   The Internet Assigned Numbers Authority (IANA) maintains a registry
   of well known port numbers, registered port numbers, protocol and
   service names [11].  We propose that this list be used to determine
   the DNS alias for a given application protocol.


        Name      Protocol
        finger    Finger [12]
        ftp       File Transfer Protocol
        gopher    Internet Gopher Protocol
        ldap      Lightweight Directory Access Protocol [13]
        ntp       Network Time Protocol [14]
        rwhois    Referral WHOIS [15]
        whois     NICNAME/WHOIS [16]

                                                                [Page 3]

INTERNET-DRAFT                                               August 1996

   We suggest that the DNS alias to be used for a service be taken
   initially from the IANA lists of well known port numbers (in the
   traditionally "restricted" rage 0 to 1023) and registered port
   numbers (1024 to 65535). In the event that the name in the IANA port
   registry contains the underscore character "_", the plus character
   "+", or the dot character ".", the list of protocol and service names
   should be used since these characters are not legal as domain name

   If it is not appropriate to use the information registered with IANA
   for a particular application protocol, we suggest the protocol
   specification should indicate why this is the case and propose an
   alternative name.

3. Special cases

   In addition to the character set problems outlined above, there are a
   small number of special cases which are not currently catered for in
   the IANA registry.  This is a static list and will not be added to in
   the future.

   Special Cases:

        Alias     Service
        archie    archie [17] (alias for "prospero")
        ph        CCSO nameserver [18] (alias for "csnet-ns")
        fsp       File Service Protocol [19]
        news      Usenet News via NNTP [20] (alias for "nntp")
        ns        DNS servers
        wais      Wide Area Information Server [21]
        www       World-Wide Web HTTP (alias for "http")

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

   It should be understood by implementors that the existence of a DNS
   entry such as


                                                                [Page 4]

INTERNET-DRAFT                                               August 1996

   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
   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 generalised 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.

   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

   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

                                                                [Page 5]

INTERNET-DRAFT                                               August 1996

   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

6. Limitations of this approach

   Some services require that a client have more information than the
   server's domain name and (default) port number.  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 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 "cso" and "ns" should add an
   additional CNAME for "ph", while keeping the old name.  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.

   Work is ongoing to remedy this situation insofar as the DNS is
   concerned [22].  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

                                                                [Page 6]

INTERNET-DRAFT                                               August 1996

   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 registered with the IANA 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 grants from the 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) and Internet Draft documents are available
   from <URL:ftp://ftp.internic.net> and numerous mirror sites.

         [1]         P. V. Mockapetris. "Domain names - concepts and
                     facilities", RFC 1034.  November 1987.

         [2]         P. V. Mockapetris. "Domain names - implementation
                     and specification", RFC 1035.  November 1987.

         [3]         J. Postel, J. K. Reynolds.  "File Transfer Proto-
                     col", RFC 959.  October 1985.

         [4]         F. Anklesaria, M. McCahill, P. Lindner, D. Johnson,
                     D. Torrey & B. Albert.  "The Internet Gopher Proto-
                     col (a distributed document search and retrieval
                     protocol)", RFC 1436.  March 1993.

                                                                [Page 7]

INTERNET-DRAFT                                               August 1996

         [5]         T. Berners-Lee, R. Fielding, H. Nielsen.  "Hyper-
                     text Transfer Protocol -- HTTP/1.0", RFC 1945.  May

         [6]         J. Postel.  "Transmission Control Protocol", RFC
                     793.  September 1981.

         [7]         J. Postel.  "User Datagram Protocol", RFC 768.
                     August 1980.

         [8]         C. Partridge.  "Mail routing and the domain sys-
                     tem", RFC 974.  January 1986.

         [9]         R. T. Braden.  "Requirements for Internet hosts -
                     application and support", RFC 1123. October 1989.

         [10]        J. Postel.  "Media Type Registration Procedure",
                     RFC 1590.  March 1994.

         [11]        J. Reynolds, J. Postel.  "ASSIGNED NUMBERS", RFC
                     1700.  October 1994.

         [12]        D. Zimmerman.  "The Finger User Information Proto-
                     col", RFC 1288. December 1992.

         [13]        W. Yeong, T. Howes, S. Kille.  "Lightweight Direc-
                     tory Access Protocol", RFC 1777.  March 1995.

         [14]        D. Mills.  "Network Time Protocol (Version 3)
                     Specification, Implementation", RFC 1305.  March

         [15]        S. Williamson & M. Kosters.  "Referral Whois Proto-
                     col (RWhois)", RFC 1714.  November 1994.

         [16]        K. Harrenstien, M. K. Stahl, E.J. Feinler.
                     "NICNAME/WHOIS", RFC 954.  October 1985.

                                                                [Page 8]

INTERNET-DRAFT                                               August 1996

         [17]        A. Emtage, P. Deutsch. "archie - An Electronic
                     Directory Service for the Internet", Winter Usenix
                     Conference Proceedings 1992.  Pages 93-110.

         [18]        R. Hedberg, S. Dorner, P. Pomes.  "The CCSO
                     Nameserver (Ph) Architecture", Internet Draft.
                     February 1996.

         [19]        FSP software distribution:

         [20]        B. Kantor, P. Lapsley.  "Network News Transfer Pro-
                     tocol", RFC 977.  February 1986.

         [21]        M. St. Pierre, J. Fullton, K. Gamiel, J. Goldman,
                     B. Kahle, J. Kunze, H. Morris & F. Schiettecatte.
                     "WAIS over Z39.50-1988", RFC 1625.  June 1994.

         [22]        D. E. Eastlake 3rd, C. W. Kaufman.  "Domain Name
                     System Security Extensions", Internet Draft.  Janu-
                     ary 1996.

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: 50B-2258
   CA 94720, USA

   Email: wright@lbl.gov

                                                                [Page 9]

INTERNET-DRAFT                                               August 1996

             This Internet Draft expires February 12th, 1997.

                                                               [Page 10]