rfc3467.txt

bind 9.3结合mysql数据库

      mechanism is expected to provide this functionality, there are
      three possible models (which might be combined):

      -  supply information about multiple sites (or locations or
         references).  Those sites would, in turn, provide information
         associated with the name and sufficient site-specific
         attributes to permit the application to make a sensible choice
         of destination, or

      -  accept client-site attributes and utilize them in the search
         process, or

      -  return different answers based on the location or identity of
         the requestor.

   While there are some tricks that can provide partial simulations of
   these types of function, DNS responses cannot be reliably conditioned
   in this way.

   These, and similar, issues of performance or content choices can, of
   course, be thought of as not involving the DNS at all.  For example,
   the commonly-cited alternate approach of coupling these issues to
   HTTP content negotiation (cf. [RFC2295]), requires that an HTTP
   connection first be opened to some "common" or "primary" host so that
   preferences can be negotiated and then the client redirected or sent
   alternate data.  At least from the standpoint of improving
   performance by accessing a "closer" location, both initially and
   thereafter, this approach sacrifices the desired result before the
   client initiates any action.  It could even be argued that some of
   the characteristics of common content negotiation approaches are
   workarounds for the non-optimal use of the DNS in web URLs.

   o  Many existing and proposed systems for "finding things on the
      Internet" require a true search capability in which near matches
      can be reported to the user (or to some user agent with an
      appropriate rule-set) and to which queries may be ambiguous or
      fuzzy.  The DNS, by contrast, can accommodate only one set of
      (quite rigid) matching rules.  Proposals to permit different rules
      in different localities (e.g., matching rules that are TLD- or
      zone-specific) help to identify the problem.  But they cannot be
      applied directly to the DNS without either abandoning the desired
      level of flexibility or isolating different parts of the Internet
      from each other (or both).  Fuzzy or ambiguous searches are
      desirable for resolution of names that might have spelling
      variations and for names that can be resolved into different sets
      of glyphs depending on context.  Especially when
      internationalization is considered, variant name problems go
      beyond simple differences in representation of a character or



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


      ordering of a string.  Instead, avoiding user astonishment and
      confusion requires consideration of relationships such as
      languages that can be written with different alphabets, Kanji-
      Hiragana relationships, Simplified and Traditional Chinese, etc.
      See [Seng] for a discussion and suggestions for addressing a
      subset of these issues in the context of characters based on
      Chinese ones.  But that document essentially illustrates the
      difficulty of providing the type of flexible matching that would
      be anticipated by users; instead, it tries to protect against the
      worst types of confusion (and opportunities for fraud).

   o  The historical DNS, and applications that make assumptions about
      how it works, impose significant risk (or forces technical kludges
      and consequent odd restrictions), when one considers adding
      mechanisms for use with various multi-character-set and
      multilingual "internationalization" systems.  See the IAB's
      discussion of some of these issues [RFC2825] for more information.

   o  In order to provide proper functionality to the Internet, the DNS
      must have a single unique root (the IAB provides more discussion
      of this issue [RFC2826]).  There are many desires for local
      treatment of names or character sets that cannot be accommodated
      without either multiple roots (e.g., a separate root for
      multilingual names, proposed at various times by MINC [MINC] and
      others), or mechanisms that would have similar effects in terms of
      Internet fragmentation and isolation.

   o  For some purposes, it is desirable to be able to search not only
      an index entry (labels or fully-qualified names in the DNS case),
      but their values or targets (DNS data).  One might, for example,
      want to locate all of the host (and virtual host) names which
      cause mail to be directed to a given server via MX records.  The
      DNS does not support this capability (see the discussion in
      [IQUERY]) and it can be simulated only by extracting all of the
      relevant records (perhaps by zone transfer if the source permits
      doing so, but that permission is becoming less frequently
      available) and then searching a file built from those records.

   o  Finally, as additional types of personal or identifying
      information are added to the DNS, issues arise with protection of
      that information.  There are increasing calls to make different
      information available based on the credentials and authorization
      of the source of the inquiry.  As with information keyed to site
      locations or proximity (as discussed above), the DNS protocols
      make providing these differentiated services quite difficult if
      not impossible.





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


   In each of these cases, it is, or might be, possible to devise ways
   to trick the DNS system into supporting mechanisms that were not
   designed into it.  Several ingenious solutions have been proposed in
   many of these areas already, and some have been deployed into the
   marketplace with some success.  But the price of each of these
   changes is added complexity and, with it, added risk of unexpected
   and destabilizing problems.

   Several of the above problems are addressed well by a good directory
   system (supported by the LDAP protocol or some protocol more
   precisely suited to these specific applications) or searching
   environment (such as common web search engines) although not by the
   DNS.  Given the difficulty of deploying new applications discussed
   above, an important question is whether the tricks and kludges are
   bad enough, or will become bad enough as usage grows, that new
   solutions are needed and can be deployed.

3. Searching, Directories, and the DNS

3.1 Overview

   The constraints of the DNS and the discussion above suggest the
   introduction of an intermediate protocol mechanism, referred to below
   as a "search layer" or "searchable system".  The terms "directory"
   and "directory system" are used interchangeably with "searchable
   system" in this document, although the latter is far more precise.
   Search layer proposals would use a two (or more) stage lookup, not
   unlike several of the proposals for internationalized names in the
   DNS (see section 4), but all operations but the final one would
   involve searching other systems, rather than looking up identifiers
   in the DNS itself.  As explained below, this would permit relaxation
   of several constraints, leading to a more capable and comprehensive
   overall system.

   Ultimately, many of the issues with domain names arise as the result
   of efforts to use the DNS as a directory.  While, at the time this
   document was written, sufficient pressure or demand had not occurred
   to justify a change, it was already quite clear that, as a directory
   system, the DNS is a good deal less than ideal.  This document
   suggests that there actually is a requirement for a directory system,
   and that the right solution to a searchable system requirement is a
   searchable system, not a series of DNS patches, kludges, or
   workarounds.








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


   The following points illustrate particular aspects of this
   conclusion.

   o  A directory system would not require imposition of particular
      length limits on names.

   o  A directory system could permit explicit association of
      attributes, e.g., language and country, with a name, without
      having to utilize trick encodings to incorporate that information
      in DNS labels (or creating artificial hierarchy for doing so).

   o  There is considerable experience (albeit not much of it very
      successful) in doing fuzzy and "sonex" (similar-sounding) matching
      in directory systems.  Moreover, it is plausible to think about
      different matching rules for different areas and sets of names so
      that these can be adapted to local cultural requirements.
      Specifically, it might be possible to have a single form of a name
      in a directory, but to have great flexibility about what queries
      matched that name (and even have different variations in different
      areas).  Of course, the more flexibility that a system provides,
      the greater the possibility of real or imagined trademark
      conflicts.  But the opportunity would exist to design a directory
      structure that dealt with those issues in an intelligent way,
      while DNS constraints almost certainly make a general and
      equitable DNS-only solution impossible.

   o  If a directory system is used to translate to DNS names, and then
      DNS names are looked up in the normal fashion, it may be possible
      to relax several of the constraints that have been traditional
      (and perhaps necessary) with the DNS.  For example, reverse-
      mapping of addresses to directory names may not be a requirement
      even if mapping of addresses to DNS names continues to be, since
      the DNS name(s) would (continue to) uniquely identify the host.

   o  Solutions to multilingual transcription problems that are common
      in "normal life" (e.g., two-sided business cards to be sure that
      recipients trying to contact a person can access romanized
      spellings and numbers if the original language is not
      comprehensible to them) can be easily handled in a directory
      system by inserting both sets of entries.

   o  A directory system could be designed that would return, not a
      single name, but a set of names paired with network-locational
      information or other context-establishing attributes.  This type
      of information might be of considerable use in resolving the
      "nearest (or best) server for a particular named resource"





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


      problems that are a significant concern for organizations hosting
      web and other sites that are accessed from a wide range of
      locations and subnets.

   o  Names bound to countries and languages might help to manage
      trademark realities, while, as discussed in section 1.3 above, use
      of the DNS in trademark-significant contexts tends to require
      worldwide "flattening" of the trademark system.

   Many of these issues are a consequence of another property of the
   DNS:  names must be unique across the Internet.  The need to have a
   system of unique identifiers is fairly obvious (see [RFC2826]).
   However, if that requirement were to be eliminated in a search or
   directory system that was visible to users instead of the DNS, many
   difficult problems -- of both an engineering and a policy nature --
   would be likely to vanish.

3.2 Some Details and Comments

   Almost any internationalization proposal for names that are in, or
   map into, the DNS will require changing DNS resolver API calls
   ("gethostbyname" or equivalent), or adding some pre-resolution
   preparation mechanism, in almost all Internet applications -- whether
   to cause the API to take a different character set (no matter how it
   is then mapped into the bits used in the DNS or another system), to
   accept or return more arguments with qualifying or identifying
   information, or otherwise.  Once applications must be opened to make
   such changes, it is a relatively small matter to switch from calling