rfc3467.txt

bind 9.3结合mysql数据库

   deeply hierarchical one, and was not.

   Similarly, despite some early speculation about entering people's
   names and email addresses into the DNS directly (e.g., see
   [RFC1034]), electronic mail addresses in the Internet have preserved
   the original, pre-DNS, "user (or mailbox) at location" conceptual
   format rather than a flatter or strictly dot-separated one.
   Location, in that instance, is a reference to a host. The sole
   exception, at least in the "IN" class, has been one field of the SOA
   record.

   Both the DNS architecture itself and the two-level (host name and
   mailbox name) provisions for email and similar functions (e.g., see
   the finger protocol [FINGER]), also anticipated a relatively high
   ratio of users to actual hosts.  Despite the observation in RFC 1034
   that the DNS was expected to grow to be proportional to the number of
   users (section 2.3), it has never been clear that the DNS was
   seriously designed for, or could, scale to the order of magnitude of
   number of users (or, more recently, products or document objects),
   rather than that of physical hosts.

   Just as was the case for the host table before it, the DNS provided
   critical uniqueness for names, and universal accessibility to them,
   as part of overall "single internet" and "end to end" models (cf.



Klensin                      Informational                      [Page 5]

RFC 3467          Role of the Domain Name System (DNS)     February 2003


   [RFC2826]).  However, there are many signs that, as new uses evolved
   and original assumptions were abused (if not violated outright), the
   system was being stretched to, or beyond, its practical limits.

   The original design effort that led to the DNS included examination
   of the directory technologies available at the time.  The design
   group concluded that the DNS design, with its simplifying assumptions
   and restricted capabilities, would be feasible to deploy and make
   adequately robust, which the more comprehensive directory approaches
   were not.  At the same time, some of the participants feared that the
   limitations might cause future problems; this document essentially
   takes the position that they were probably correct.  On the other
   hand, directory technology and implementations have evolved
   significantly in the ensuing years: it may be time to revisit the
   assumptions, either in the context of the two- (or more) level
   mechanism contemplated by the rest of this document or, even more
   radically, as a path toward a DNS replacement.

1.3 The Web and User-visible Domain Names

   From the standpoint of the integrity of the domain name system -- and
   scaling of the Internet, including optimal accessibility to content
   -- the web design decision to use "A record" domain names directly in
   URLs, rather than some system of indirection, has proven to be a
   serious mistake in several respects.  Convenience of typing, and the
   desire to make domain names out of easily-remembered product names,
   has led to a flattening of the DNS, with many people now perceiving
   that second-level names under COM (or in some countries, second- or
   third-level names under the relevant ccTLD) are all that is
   meaningful.  This perception has been reinforced by some domain name
   registrars [REGISTRAR] who have been anxious to "sell" additional
   names.  And, of course, the perception that one needed a second-level
   (or even top-level) domain per product, rather than having names
   associated with a (usually organizational) collection of network
   resources, has led to a rapid acceleration in the number of names
   being registered.  That acceleration has, in turn, clearly benefited
   registrars charging on a per-name basis, "cybersquatters", and others
   in the business of "selling" names, but it has not obviously
   benefited the Internet as a whole.

   This emphasis on second-level domain names has also created a problem
   for the trademark community.  Since the Internet is international,
   and names are being populated in a flat and unqualified space,
   similarly-named entities are in conflict even if there would
   ordinarily be no chance of confusing them in the marketplace.  The
   problem appears to be unsolvable except by a choice between draconian
   measures.  These might include significant changes to the legislation
   and conventions that govern disputes over "names" and "marks".  Or



Klensin                      Informational                      [Page 6]

RFC 3467          Role of the Domain Name System (DNS)     February 2003


   they might result in a situation in which the "rights" to a name are
   typically not settled using the subtle and traditional product (or
   industry) type and geopolitical scope rules of the trademark system.
   Instead they have depended largely on political or economic power,
   e.g., the organization with the greatest resources to invest in
   defending (or attacking) names will ultimately win out.  The latter
   raises not only important issues of equity, but also the risk of
   backlash as the numerous small players are forced to relinquish names
   they find attractive and to adopt less-desirable naming conventions.

   Independent of these sociopolitical problems, content distribution
   issues have made it clear that it should be possible for an
   organization to have copies of data it wishes to make available
   distributed around the network, with a user who asks for the
   information by name getting the topologically-closest copy.  This is
   not possible with simple, as-designed, use of the DNS: DNS names
   identify target resources or, in the case of email "MX" records, a
   preferentially-ordered list of resources "closest" to a target (not
   to the source/user).  Several technologies (and, in some cases,
   corresponding business models) have arisen to work around these
   problems, including intercepting and altering DNS requests so as to
   point to other locations.

   Additional implications are still being discovered and evaluated.

   Approaches that involve interception of DNS queries and rewriting of
   DNS names (or otherwise altering the resolution process based on the
   topological location of the user) seem, however, to risk disrupting
   end-to-end applications in the general case and raise many of the
   issues discussed by the IAB in [IAB-OPES].  These problems occur even
   if the rewriting machinery is accompanied by additional workarounds
   for particular applications.  For example, security associations and
   applications that need to identify "the same host" often run into
   problems if DNS names or other references are changed in the network
   without participation of the applications that are trying to invoke
   the associated services.

1.4 Internet Applications Protocols and Their Evolution

   At the applications level, few of the protocols in active,
   widespread, use on the Internet reflect either contemporary knowledge
   in computer science or human factors or experience accumulated
   through deployment and use.  Instead, protocols tend to be deployed
   at a just-past-prototype level, typically including the types of
   expedient compromises typical with prototypes.  If they prove useful,
   the nature of the network permits very rapid dissemination (i.e.,
   they fill a vacuum, even if a vacuum that no one previously knew
   existed).  But, once the vacuum is filled, the installed base



Klensin                      Informational                      [Page 7]

RFC 3467          Role of the Domain Name System (DNS)     February 2003


   provides its own inertia: unless the design is so seriously faulty as
   to prevent effective use (or there is a widely-perceived sense of
   impending disaster unless the protocol is replaced), future
   developments must maintain backward compatibility and workarounds for
   problematic characteristics rather than benefiting from redesign in
   the light of experience.  Applications that are "almost good enough"
   prevent development and deployment of high-quality replacements.

   The DNS is both an illustration of, and an exception to, parts of
   this pessimistic interpretation. It was a second-generation
   development, with the host table system being seen as at the end of
   its useful life.  There was a serious attempt made to reflect the
   computing state of the art at the time.  However, deployment was much
   slower than expected (and very painful for many sites) and some fixed
   (although relaxed several times) deadlines from a central network
   administration were necessary for deployment to occur at all.
   Replacing it now, in order to add functionality, while it continues
   to perform its core functions at least reasonably well, would
   presumably be extremely difficult.

   There are many, perhaps obvious, examples of this.  Despite many
   known deficiencies and weaknesses of definition, the "finger" and
   "whois" [WHOIS] protocols have not been replaced (despite many
   efforts to update or replace the latter [WHOIS-UPDATE]).  The Telnet
   protocol and its many options drove out the SUPDUP [RFC734] one,
   which was arguably much better designed for a diverse collection of
   network hosts.  A number of efforts to replace the email or file
   transfer protocols with models which their advocates considered much
   better have failed.  And, more recently and below the applications
   level, there is some reason to believe that this resistance to change
   has been one of the factors impeding IPv6 deployment.

2. Signs of DNS Overloading

   Parts of the historical discussion above identify areas in which the
   DNS has become overloaded (semantically if not in the mechanical
   ability to resolve names).  Despite this overloading, it appears that
   DNS performance and reliability are still within an acceptable range:
   there is little evidence of serious performance degradation.  Recent
   proposals and mechanisms to better respond to overloading and scaling
   issues have all focused on patching or working around limitations
   that develop when the DNS is utilized for out-of-design functions,
   rather than on dramatic rethinking of either DNS design or those
   uses.  The number of these issues that have arisen at much the same
   time may argue for just that type of rethinking, and not just for
   adding complexity and attempting to incrementally alter the design
   (see, for example, the discussion of simplicity in section 2 of
   [RFC3439]).



Klensin                      Informational                      [Page 8]

RFC 3467          Role of the Domain Name System (DNS)     February 2003


   For example:

   o  While technical approaches such as larger and higher-powered
      servers and more bandwidth, and legal/political mechanisms such as
      dispute resolution policies, have arguably kept the problems from
      becoming critical, the DNS has not proven adequately responsive to
      business and individual needs to describe or identify things (such
      as product names and names of individuals) other than strict
      network resources.

   o  While stacks have been modified to better handle multiple
      addresses on a physical interface and some protocols have been
      extended to include DNS names for determining context, the DNS
      does not deal especially well with many names associated with a
      given host (e.g., web hosting facilities with multiple domains on
      a server).

   o  Efforts to add names deriving from languages or character sets
      based on other than simple ASCII and English-like names (see
      below), or even to utilize complex company or product names
      without the use of hierarchy, have created apparent requirements
      for names (labels) that are over 63 octets long.  This requirement
      will undoubtedly increase over time; while there are workarounds
      to accommodate longer names, they impose their own restrictions
      and cause their own problems.

   o  Increasing commercialization of the Internet, and visibility of
      domain names that are assumed to match names of companies or
      products, has turned the DNS and DNS names into a trademark
      battleground.  The traditional trademark system in (at least) most
      countries makes careful distinctions about fields of
      applicability.  When the space is flattened, without
      differentiation by either geography or industry sector, not only
      are there likely conflicts between "Joe's Pizza" (of Boston) and
      "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto
      Repair" (of Los Angeles).  All three would like to control
      "Joes.com" (and would prefer, if it were permitted by DNS naming
      rules, to also spell it as "Joe's.com" and have both resolve the
      same way) and may claim trademark rights to do so, even though
      conflict or confusion would not occur with traditional trademark
      principles.

   o  Many organizations wish to have different web sites under the same
      URL and domain name.  Sometimes this is to create local variations
      -- the Widget Company might want to present different material to
      a UK user relative to a US one -- and sometimes it is to provide
      higher performance by supplying information from the server
      topologically closest to the user.  If the name resolution



Klensin                      Informational                      [Page 9]

RFC 3467          Role of the Domain Name System (DNS)     February 2003