rfc4367.txt

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

      negotiation capabilities of the underlying protocol.  For example,
      an RTSP client might assume that all audio content delivered to it
      from media.example.cellular uses a low-bandwidth codec.  As
      another example, a mail client might assume that the contents of
      messages it retrieves from a mail server at mail.example.cellular
      are always text, instead of checking the MIME headers [11] in the
      message in order to determine the actual content type.

   Protocol Extensions: A client may attempt an operation on the server
      that requires the server to support an optional protocol
      extension.  However, rather than implementing the necessary
      fallback logic, the client may falsely assume that the extension
      is supported.  As an example, a SIP client that requires reliable
      provisional responses to its request (RFC 3262 [17]) might assume
      that this extension is supported on servers in the domain



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


      sip.example.telecom.  Furthermore, the client would not implement
      the fallback behavior defined in RFC 3262, since it would assume
      that all servers it will communicate with are in this domain and
      that all therefore support this extension.  However, if the
      assumptions prove wrong, the client is unable to make any phone
      calls.

   Languages: A client may support facilities for processing text
      content differently depending on the language of the text.  Rather
      than determining the language from markers in the message from the
      server, the client might assume a language based on the domain
      name.  This assumption can easily be wrong.  For example, a client
      might assume that any text in a web page retrieved from a server
      within the .de country code TLD (ccTLD) is in German, and attempt
      a translation to Finnish.  This would fail dramatically if the
      text was actually in French.  Unfortunately, this client behavior
      is sometimes exhibited because the server has not properly labeled
      the language of the content in the first place, often because the
      server assumed such a labeling was not needed.  This is an example
      of how these false assumptions can create vicious cycles.

4.3.  By the Server

   The server, like the client, is an automaton.  Let us consider one
   servicing a particular domain -- www.company.cellular, for example.
   It might assume that all clients connecting to this domain support
   particular capabilities, rather than using the underlying protocol to
   make this determination.  Some examples include:

   Authentication Algorithm: The server can assume that a client
      supports a particular, optional, authentication technique, and it
      therefore does not support the mandatory one.

   Language: The server can serve content in a particular language,
      based on an assumption that clients accessing the domain speak a
      particular language, or based on an assumption that clients coming
      from a particular IP address speak a certain language.

   Data Formats: The server can assume that the client supports a
      particular set of MIME types and is only capable of sending ones
      within that set.  When it generates content in a protocol
      response, it ignores any content negotiation headers that were
      present in the request.  For example, a web server might ignore
      the Accept HTTP header field and send a specific image format.







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


   Protocol Extensions: The server might assume that the client supports
      a particular optional protocol extension, and so it does not
      support the fallback behavior necessary in the case where the
      client does not.

   Client Characteristics: The server might assume certain things about
      the physical characteristics of its clients, such as memory
      footprint, processing power, screen sizes, screen colors, pointing
      devices, and so on.  Based on these assumptions, it might choose
      specific behaviors when processing a request.  For example, a web
      server might always assume that clients connect through cell
      phones, and therefore return content that lacks images and is
      tuned for such devices.

5.  Consequences of False Assumptions

   There are numerous negative outcomes that can arise from the various
   false assumptions that users, servers, and clients can make.  These
   include:

   Interoperability Failure: In these cases, the client or server
      assumed some kind of protocol operation, and this assumption was
      wrong.  The result is that the two are unable to communicate, and
      the user receives some kind of an error.  This represents a total
      interoperability failure, manifesting itself as a lack of service
      to users of the system.  Unfortunately, this kind of failure
      persists.  Repeated attempts over time by the client to access the
      service will fail.  Only a change in the server or client software
      can fix this problem.

   System Failure: In these cases, the client or server misinterpreted a
      protocol operation, and this misinterpretation was serious enough
      to uncover a bug in the implementation.  The bug causes a system
      crash or some kind of outage, either transient or permanent (until
      user reset).  If this failure occurs in a server, not only will
      the connecting client lose service, but other clients attempting
      to connect will not get service.  As an example, if a web server
      assumes that content passed to it from a client (created, for
      example, by a digital camera) is of a particular content type, and
      it always passes image content to a codec for decompression prior
      to storage, the codec might crash when it unexpectedly receives an
      image compressed in a different format.  Of course, it might crash
      even if the Content-Type was correct, but the compressed bitstream
      was invalid.  False assumptions merely introduce additional
      failure cases.






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


   Poor User Experience: In these cases, the client and server
      communicate, but the user receives a diminished user experience.
      For example, if a client on a PC connects to a web site that
      provides content for mobile devices, the content may be
      underwhelming when viewed on the PC.  Or, a client accessing a
      streaming media service may receive content of very low bitrate,
      even though the client supported better codecs.  Indeed, if a user
      wishes to access content from both a cellular device and a PC
      using a shared address book (that is, an address book shared
      across multiple devices), the user would need two entries in that
      address book, and would need to use the right one from the right
      device.  This is a poor user experience.

   Degraded Security: In these cases, a weaker security mechanism is
      used than the one that ought to have been used.  As an example, a
      server in a domain might assume that it is only contacted by
      clients with a limited set of authentication algorithms, even
      though the clients have been recently upgraded to support a
      stronger set.

6.  Reasons Why the Assumptions Can Be False

   Assumptions made by clients and servers about the operation of
   protocols when contacting a particular domain are brittle, and can be
   wrong for many reasons.  On the server side, many of the assumptions
   are based on the notion that a domain name will only be given to, or
   used by, a restricted set of clients.  If the holder of the domain
   name assumes something about those clients, and can assume that only
   those clients use the domain name, then it can configure or program
   the server to operate specifically for those clients.  Both parts of
   this assumption can be wrong, as discussed in more detail below.

   On the client side, the notion is similar, being based on the
   assumption that a server within a particular domain will provide a
   specific type of service.  Sub-delegation and evolution, both
   discussed below, can make these assumptions wrong.

6.1.  Evolution

   The Internet and the devices that access it are constantly evolving,
   often at a rapid pace.  Unfortunately, there is a tendency to build
   for the here and now, and then worry about the future at a later
   time.  Many of the assumptions above are predicated on
   characteristics of today's clients and servers.  Support for specific
   protocols, authentication techniques, or content are based on today's
   standards and today's devices.  Even though they may, for the most
   part, be true, they won't always be.  An excellent example is mobile
   devices.  A server servicing a domain accessed by mobile devices



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


   might try to make assumptions about the protocols, protocol
   extensions, security mechanisms, screen sizes, or processor power of
   such devices.  However, all of these characteristics can and will
   change over time.

   When they do change, the change is usually evolutionary.  The result
   is that the assumptions remain valid in some cases, but not in
   others.  It is difficult to fix such systems, since it requires the
   server to detect what type of client is connecting, and what its
   capabilities are.  Unless the system is built and deployed with these
   capability negotiation techniques built in to begin with, such
   detection can be extremely difficult.  In fact, fixing it will often
   require the addition of such capability negotiation features that, if
   they had been in place and used to begin with, would have avoided the
   problem altogether.

6.2.  Leakage

   Servers also make assumptions because of the belief that they will
   only be accessed by specific clients, and in particular, those that
   are configured or provisioned to use the domain name.  In essence,
   there is an assumption of community -- that a specific community
   knows and uses the domain name, while others outside of the community
   do not.

   The problem is that this notion of community is a false one.  The
   Internet is global.  The DNS is global.  There is no technical
   barrier that separates those inside of the community from those
   outside.  The ease with which information propagates across the
   Internet makes it extremely likely that such domain names will
   eventually find their way into clients outside of the presumed
   community.  The ubiquitous presence of domain names in various URI
   formats, coupled with the ease of conveyance of URIs, makes such
   leakage merely a matter of time.  Furthermore, since the DNS is
   global, and since it can only have one root [12], it becomes possible
   for clients outside of the community to search and find and use such
   "special" domain names.

   Indeed, this leakage is a strength of the Internet architecture, not
   a weakness.  It enables global access to services from any client
   with a connection to the Internet.  That, in turn, allows for rapid
   growth in the number of customers for any particular service.

6.3.  Sub-Delegation

   Clients and users make assumptions about domains because of the
   notion that there is some kind of centralized control that can
   enforce those assumptions.  However, the DNS is not centralized; it



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


   is distributed.  If a domain doesn't delegate its sub-domains and has
   its records within a single zone, it is possible to maintain a
   centralized policy about operation of its domain.  However, once a
   domain gets sufficiently large that the domain administrators begin
   to delegate sub-domains to other authorities, it becomes increasingly
   difficult to maintain any kind of central control on the nature of
   the service provided in each sub-domain.

   Similarly, the usage of domain names with human semantic connotation
   tends to lead to a registration of multiple domains in which a
   particular service is to run.  As an example, a service provider with
   the name "example" might register and set up its services in
   "example.com", "example.net", and generally example.foo for each foo
   that is a valid TLD.  This, like sub-delegation, results in a growth
   in the number of domains over which it is difficult to maintain
   centralized control.

   Not that it is not possible, since there are many examples of
   successful administration of policies across sub-domains many levels
   deep.  However, it takes an increasing amount of effort to ensure
   this result, as it requires human intervention and the creation of
   process and procedure.  Automated validation of adherence to policies
   is very difficult to do, as there is no way to automatically verify
   many policies that might be put into place.

   A less costly process for providing centralized management of
   policies is to just hope that any centralized policies are being
   followed, and then wait for complaints or perform random audits.
   Those approaches have many problems.

   The invalidation of assumptions due to sub-delegation is discussed in
   further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].

   As a result of the fragility of policy continuity across sub-
   delegations, if a client or user assumes some kind of property
   associated with a TLD (such as ".wifi"), it becomes increasingly more
   likely with the number of sub-domains that this property will not
   exist in a server identified by a particular name.  For example, in
   "store.chain.company.provider.wifi", there may be four levels of
   delegation from ".wifi", making it quite likely that, unless the
   holder of ".wifi" is working diligently, the properties that the
   holder of ".wifi" wishes to enforce are not present.  These
   properties may not be present due to human error or due to a willful
   decision not to adhere to them.







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


6.4.  Mobility

   One of the primary value propositions of a hostname as an identifier
   is its persistence.  A client can change IP addresses, yet still
   retain a persistent identifier used by other hosts to reach it.
   Because their value derives from their persistence, hostnames tend to
   move with a host not just as it changes IP addresses, but as it
   changes access network providers and technologies.  For this reason,
   assumptions made about a host based on the presumed access network
   corresponding to that hostname tend to be wrong over time.  As an
   example, a PC might normally be connected to its broadband provider,
   and through dynamic DNS have a hostname within the domain of that
   provider.  However, one cannot assume that any host within that
   network has access over a broadband link; the user could connect
   their PC over a low-bandwidth wireless access network and still
   retain its domain name.