rfc2219.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


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: [e-mail]


   Russ Wright
   Information & Computing Sciences Division
   Lawrence Berkeley National Laboratory
   1 Cyclotron Road, Berkeley
   Mail-Stop: 50A-3111
   CA 94720, USA

   EMail: [e-mail]










Hamilton & Wright        Best Current Practice                  [Page 8]