rfc4367.txt

来自「非常好的dns解析软件」· 文本 代码 · 共 956 行 · 第 1/3 页

6.5.  Human Error

   Of course, human error can be the source of errors in any system, and
   the same is true here.  There are many examples relevant to the
   problem under discussion.

   A client implementation may make the assumption that, just because a
   DNS SRV record exists for a particular protocol in a particular
   domain, indicating that the service is available on some port, that
   the service is, in fact, running there.  This assumption could be
   wrong because the SRV records haven't been updated by the system
   administrators to reflect the services currently running.  As another
   example, a client might assume that a particular domain policy
   applies to all sub-domains.  However, a system administrator might
   have omitted to apply the policy to servers running in one of those
   sub-domains.

7.  Recommendations

   Based on these problems, the clear conclusion is that clients,
   servers, and users should not make assumptions on the nature of the
   service provided to, or by, a domain.  More specifically, however,
   the following can be said:

   Follow the specifications: When specifications define mandatory
      baseline procedures and formats, those should be implemented and
      supported, even if the expectation is that optional procedures
      will most often be used.  For example, if a specification mandates
      a particular baseline authentication technique, but allows others
      to be negotiated and used, implementations need to implement the
      baseline authentication algorithm even if the other ones are used



Rosenberg                    Informational                     [Page 12]

RFC 4367                    Name Assumptions               February 2006


      most of the time.  Put more simply, the behavior of the protocol
      machinery should never change based on the domain name of the
      host.

   Use capability negotiation: Many protocols are engineered with
      capability negotiation mechanisms.  For example, a content
      negotiation framework has been defined for protocols using MIME
      content [13] [14] [15].  SIP allows for clients to negotiate the
      media types used in the multimedia session, as well as protocol
      parameters.  HTTP allows for clients to negotiate the media types
      returned in requests for content.  When such features are
      available in a protocol, client and servers should make use of
      them rather than making assumptions about supported capabilities.
      A corollary is that protocol designers should include such
      mechanisms when evolution is expected in the usage of the
      protocol.

   "Be liberal in what you accept, and conservative in what you send"
      [18]:  This axiom of Internet protocol design is applicable here
      as well.  Implementations should be prepared for the full breadth
      of what a protocol allows another entity to send, rather than be
      limiting in what it is willing to receive.

   To summarize -- there is never a need to make assumptions.  Rather
   than doing so, utilize the specifications and the negotiation
   capabilities they provide, and the overall system will be robust and
   interoperable.

8.  A Note on RFC 2219 and RFC 2782

   Based on the definition of an assumption given here, the behavior
   hinted at by records in the DNS also represents an assumption.  RFC
   2219 [19] defines well-known aliases that can be used to construct
   domain names for reaching various well-known services in a domain.
   This approach was later followed by the definition of a new resource
   record, the SRV record [2], which specifies that a particular service
   is running on a server in a domain.  Although both of these
   mechanisms are useful as a hint that a particular service is running
   in a domain, both of them represent assumptions that may be false.
   However, they differ in the set of reasons why those assumptions
   might be false.

   A client that assumes that "ftp.example.com" is an FTP server may be
   wrong because the presumed naming convention in RFC 2219 was not
   known by, or not followed by, the owner of domain.com.  With RFC
   2782, an SRV record for a particular service would be present only by
   explicit choice of the domain administrator, and thus a client that




Rosenberg                    Informational                     [Page 13]

RFC 4367                    Name Assumptions               February 2006


   assumes that the corresponding host provides this service would be
   wrong only because of human error in configuration.  In this case,
   the assumption is less likely to be wrong, but it certainly can be.

   The only way to determine with certainty that a service is running on
   a host is to initiate a connection to the port for that service, and
   check.  Implementations need to be careful not to codify any
   behaviors that cause failures should the information provided in the
   record actually be false.  This borders on common sense for robust
   implementations, but it is valuable to raise this point explicitly.

9.  Security Considerations

   One of the assumptions that can be made by clients or servers is the
   availability and usage (or lack thereof) of certain security
   protocols and algorithms.  For example, a client accessing a service
   in a particular domain might assume a specific authentication
   algorithm or hash function in the application protocol.  It is
   possible that, over time, weaknesses are found in such a technique,
   requiring usage of a different mechanism.  Similarly, a system might
   start with an insecure mechanism, and then decide later on to use a
   secure one.  In either case, assumptions made on security properties
   can result in interoperability failures, or worse yet, providing
   service in an insecure way, even though the client asked for, and
   thought it would get, secure service.  These kinds of assumptions are
   fundamentally unsound even if the records themselves are secured with
   DNSSEC.

10.  Acknowledgements

   The IAB would like to thank John Klensin, Keith Moore and Peter Koch
   for their comments.

11.  IAB Members

   Internet Architecture Board members at the time of writing of this
   document are:

      Bernard Aboba

      Loa Andersson

      Brian Carpenter

      Leslie Daigle

      Patrik Faltstrom




Rosenberg                    Informational                     [Page 14]

RFC 4367                    Name Assumptions               February 2006


      Bob Hinden

      Kurtis Lindqvist

      David Meyer

      Pekka Nikander

      Eric Rescorla

      Pete Resnick

      Jonathan Rosenberg

12.  Informative References

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

   [2]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
         specifying the location of services (DNS SRV)", RFC 2782,
         February 2000.

   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
         Three: The Domain Name System (DNS) Database", RFC 3403,
         October 2002.

   [4]   Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means
         for Expressing Location Information in the Domain Name System",
         RFC 1876, January 1996.

   [5]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [6]   Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
         Protocol (RTSP)", RFC 2326, April 1998.

   [7]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [8]   Eastlake, D., ".sex Considered Dangerous", RFC 3675,
         February 2004.

   [9]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
         April 2001.




Rosenberg                    Informational                     [Page 15]

RFC 4367                    Name Assumptions               February 2006


   [10]  Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
         Protocol (HTTP) Digest Authentication Using Authentication and
         Key Agreement (AKA)", RFC 3310, September 2002.

   [11]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
         Extensions (MIME) Part One: Format of Internet Message Bodies",
         RFC 2045, November 1996.

   [12]  Internet Architecture Board, "IAB Technical Comment on the
         Unique DNS Root", RFC 2826, May 2000.

   [13]  Klyne, G., "Indicating Media Features for MIME Content",
         RFC 2912, September 2000.

   [14]  Klyne, G., "A Syntax for Describing Media Feature Sets",
         RFC 2533, March 1999.

   [15]  Klyne, G., "Protocol-independent Content Negotiation
         Framework", RFC 2703, September 1999.

   [16]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [17]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
         Responses in Session Initiation Protocol (SIP)", RFC 3262,
         June 2002.

   [18]  Braden, R., "Requirements for Internet Hosts - Communication
         Layers", STD 3, RFC 1122, October 1989.

   [19]  Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
         Services", BCP 17, RFC 2219, October 1997.

   [20]  Faltstrom, P., "Design Choices When Expanding DNS", Work in
         Progress, June 2005.

Author's Address

   Jonathan Rosenberg, Editor
   IAB
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: [phone]
   EMail: [e-mail]
   URI:   http://www.jdrosen.net





Rosenberg                    Informational                     [Page 16]

RFC 4367                    Name Assumptions               February 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Rosenberg                    Informational                     [Page 17]