rfc4367.txt

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

Network Working Group                                  J. Rosenberg, Ed.
Request for Comments: 4367                                           IAB
Category: Informational                                    February 2006


          What's in a Name: False Assumptions about DNS Names

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   The Domain Name System (DNS) provides an essential service on the
   Internet, mapping structured names to a variety of data, usually IP
   addresses.  These names appear in email addresses, Uniform Resource
   Identifiers (URIs), and other application-layer identifiers that are
   often rendered to human users.  Because of this, there has been a
   strong demand to acquire names that have significance to people,
   through equivalence to registered trademarks, company names, types of
   services, and so on.  There is a danger in this trend; the humans and
   automata that consume and use such names will associate specific
   semantics with some names and thereby make assumptions about the
   services that are, or should be, provided by the hosts associated
   with the names.  Those assumptions can often be false, resulting in a
   variety of failure conditions.  This document discusses this problem
   in more detail and makes recommendations on how it can be avoided.


















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


Table of Contents

   1. Introduction ....................................................2
   2. Target Audience .................................................4
   3. Modeling Usage of the DNS .......................................4
   4. Possible Assumptions ............................................5
      4.1. By the User ................................................5
      4.2. By the Client ..............................................6
      4.3. By the Server ..............................................7
   5. Consequences of False Assumptions ...............................8
   6. Reasons Why the Assumptions Can Be False ........................9
      6.1. Evolution ..................................................9
      6.2. Leakage ...................................................10
      6.3. Sub-Delegation ............................................10
      6.4. Mobility ..................................................12
      6.5. Human Error ...............................................12
   7. Recommendations ................................................12
   8. A Note on RFC 2219 and RFC 2782 ................................13
   9. Security Considerations ........................................14
   10. Acknowledgements ..............................................14
   11. IAB Members ...................................................14
   12. Informative References ........................................15

1.  Introduction

   The Domain Name System (DNS) [1] provides an essential service on the
   Internet, mapping structured names to a variety of different types of
   data.  Most often it is used to obtain the IP address of a host
   associated with that name [2] [1] [3].  However, it can be used to
   obtain other information, and proposals have been made for nearly
   everything, including geographic information [4].

   Domain names are most often used in identifiers used by application
   protocols.  The most well known include email addresses and URIs,
   such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL
   [6], and SIP URI [7].  These identifiers are ubiquitous, appearing on
   business cards, web pages, street signs, and so on.  Because of this,
   there has been a strong demand to acquire domain names that have
   significance to people through equivalence to registered trademarks,
   company names, types of services, and so on.  Such identifiers serve
   many business purposes, including extension of brand, advertising,
   and so on.

   People often make assumptions about the type of service that is or
   should be provided by a host associated with that name, based on
   their expectations and understanding of what the name implies.  This,
   in turn, triggers attempts by organizations to register domain names
   based on that presumed user expectation.  Examples of this are the



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


   various proposals for a Top-Level Domain (TLD) that could be
   associated with adult content [8], the requests for creation of TLDs
   associated with mobile devices and services, and even phishing
   attacks.

   When these assumptions are codified into the behavior of an
   automaton, such as an application client or server, as a result of
   implementor choice, management directive, or domain owner policy, the
   overall system can fail in various ways.  This document describes a
   number of typical ways in which these assumptions can be codified,
   how they can be wrong, the consequences of those mistakes, and the
   recommended ways in which they can be avoided.

   Section 4 describes some of the possible assumptions that clients,
   servers, and people can make about a domain name.  In this context,
   an "assumption" is defined as any behavior that is expected when
   accessing a service at a domain name, even though the behavior is not
   explicitly codified in protocol specifications.  Frequently, these
   assumptions involve ignoring parts of a specification based on an
   assumption that the client or server is deployed in an environment
   that is more rigid than the specification allows.  Section 5
   overviews some of the consequences of these false assumptions.
   Generally speaking, these consequences can include a variety of
   different interoperability failures, user experience failures, and
   system failures.  Section 6 discusses why these assumptions can be
   false from the very beginning or become false at some point in the
   future.  Most commonly, they become false because the environment
   changes in unexpected ways over time, and what was a valid assumption
   before, no longer is.  Other times, the assumptions prove wrong
   because they were based on the belief that a specific community of
   clients and servers was participating, and an element outside of that
   community began participating.

   Section 7 then provides some recommendations.  These recommendations
   encapsulate some of the engineering mantras that have been at the
   root of Internet protocol design for decades.  These include:

      Follow the specifications.

      Use the capability negotiation techniques provided in the
      protocols.

      Be liberal in what you accept, and conservative in what you send.
      [18]

   Overall, automata should not change their behavior within a protocol
   based on the domain name, or some component of the domain name, of
   the host they are communicating with.



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


2.  Target Audience

   This document has several audiences.  Firstly, it is aimed at
   implementors who ultimately develop the software that make the false
   assumptions that are the subject of this document.  The
   recommendations described here are meant to reinforce the engineering
   guidelines that are often understood by implementors, but frequently
   forgotten as deadlines near and pressures mount.

   The document is also aimed at technology managers, who often develop
   the requirements that lead to these false assumptions.  For them,
   this document serves as a vehicle for emphasizing the importance of
   not taking shortcuts in the scope of applicability of a project.

   Finally, this document is aimed at domain name policy makers and
   administrators.  For them, it points out the perils in establishing
   domain policies that get codified into the operation of applications
   running within that domain.

3.  Modeling Usage of the DNS


                       +--------+
                       |        |
                       |        |
                       |  DNS   |
                       |Service |
                       |        |
                       +--------+
                         ^   |
                         |   |
                         |   |
                         |   |
          /--\           |   |
         |    |          |   V
         |    |        +--------+                     +--------+
          \--/         |        |                     |        |
            |          |        |                     |        |
         ---+---       | Client |-------------------->| Server |
            |          |        |                     |        |
            |          |        |                     |        |
           /\          +--------+                     +--------+
          /  \
         /    \

         User
                                 Figure 1




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


   Figure 1 shows a simple conceptual model of how the DNS is used by
   applications.  A user of the application obtains an identifier for
   particular content or service it wishes to obtain.  This identifier
   is often a URL or URI that contains a domain name.  The user enters
   this identifier into its client application (for example, by typing
   in the URL in a web browser window).  The client is the automaton (a
   software and/or hardware system) that contacts a server for that
   application in order to provide service to the user.  To do that, it
   contacts a DNS server to resolve the domain name in the identifier to
   an IP address.  It then contacts the server at that IP address.  This
   simple model applies to application protocols such as HTTP [5], SIP
   [7], RTSP [6], and SMTP [9].

   >From this model, it is clear that three entities in the system can
   potentially make false assumptions about the service provided by the
   server.  The human user may form expectations relating to the content
   of the service based on a parsing of the host name from which the
   content originated.  The server might assume that the client
   connecting to it supports protocols that it does not, can process
   content that it cannot, or has capabilities that it does not.
   Similarly, the client might assume that the server supports
   protocols, content, or capabilities that it does not.  Furthermore,
   applications can potentially contain a multiplicity of humans,
   clients, and servers, all of which can independently make these false
   assumptions.

4.  Possible Assumptions

   For each of the three elements, there are many types of false
   assumptions that can be made.

4.1.  By the User

   The set of possible assumptions here is nearly boundless.  Users
   might assume that an HTTP URL that looks like a company name maps to
   a server run by that company.  They might assume that an email from a
   email address in the .gov TLD is actually from a government employee.
   They might assume that the content obtained from a web server within
   a TLD labeled as containing adult materials (for example, .sex)
   actually contains adult content [8].  These assumptions are
   unavoidable, may all be false, and are not the focus of this
   document.









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


4.2.  By the Client

   Even though the client is an automaton, it can make some of the same
   assumptions that a human user might make.  For example, many clients
   assume that any host with a hostname that begins with "www" is a web
   server, even though this assumption may be false.

   In addition, the client concerns itself with the protocols needed to
   communicate with the server.  As a result, it might make assumptions
   about the operation of the protocols for communicating with the
   server.  These assumptions manifest themselves in an implementation
   when a standardized protocol negotiation technique defined by the
   protocol is ignored, and instead, some kind of rule is coded into the
   software that comes to its own conclusion about what the negotiation
   would have determined.  The result is often a loss of
   interoperability, degradation in reliability, and worsening of user
   experience.

   Authentication Algorithm: Though a protocol might support a
      multiplicity of authentication techniques, a client might assume
      that a server always supports one that is only optional according
      to the protocol.  For example, a SIP client contacting a SIP
      server in a domain that is apparently used to identify mobile
      devices (for example, www.example.cellular) might assume that the
      server supports the optional Authentication and Key Agreement
      (AKA) digest technique [10], just because of the domain name that
      was used to access the server.  As another example, a web client
      might assume that a server with the name https.example.com
      supports HTTP over Transport Layer Security (TLS) [16].

   Data Formats: Though a protocol might allow a multiplicity of data
      formats to be sent from the server to the client, the client might
      assume a specific one, rather than using the content labeling and