rfc3467.txt

bind 9.3结合mysql数据库

Network Working Group                                         J. Klensin
Request for Comments: 3467                                 February 2003
Category: Informational


                  Role of the Domain Name System (DNS)

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 (2003).  All Rights Reserved.

Abstract

   This document reviews the original function and purpose of the domain
   name system (DNS).  It contrasts that history with some of the
   purposes for which the DNS has recently been applied and some of the
   newer demands being placed upon it or suggested for it.  A framework
   for an alternative to placing these additional stresses on the DNS is
   then outlined.  This document and that framework are not a proposed
   solution, only a strong suggestion that the time has come to begin
   thinking more broadly about the problems we are encountering and
   possible approaches to solving them.

Table of Contents

   1.  Introduction and History .....................................  2
      1.1 Context for DNS Development ...............................  3
      1.2 Review of the DNS and Its Role as Designed ................  4
      1.3 The Web and User-visible Domain Names .....................  6
      1.4 Internet Applications Protocols and Their Evolution .......  7
   2.  Signs of DNS Overloading .....................................  8
   3.  Searching, Directories, and the DNS .......................... 12
      3.1 Overview  ................................................. 12
      3.2 Some Details and Comments ................................. 14
   4.  Internationalization ......................................... 15
      4.1 ASCII Isn't Just Because of English ....................... 16
      4.2 The "ASCII Encoding" Approaches ........................... 17
      4.3 "Stringprep" and Its Complexities ......................... 17
      4.4 The Unicode Stability Problem ............................. 19
      4.5 Audiences, End Users, and the User Interface Problem ...... 20
      4.6 Business Cards and Other Natural Uses of Natural Languages. 22
      4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22



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


      4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
   5.  Search-based Systems: The Key Controversies .................. 23
   6.  Security Considerations ...................................... 24
   7.  References ................................................... 25
      7.1 Normative References ...................................... 25
      7.2 Explanatory and Informative References .................... 25
   8.  Acknowledgements ............................................. 30
   9.  Author's Address ............................................. 30
   10. Full Copyright Statement ..................................... 31

1. Introduction and History

   The DNS was designed as a replacement for the older "host table"
   system.  Both were intended to provide names for network resources at
   a more abstract level than network (IP) addresses (see, e.g.,
   [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]).  In recent years,
   the DNS has become a database of convenience for the Internet, with
   many proposals to add new features.  Only some of these proposals
   have been successful.  Often the main (or only) motivation for using
   the DNS is because it exists and is widely deployed, not because its
   existing structure, facilities, and content are appropriate for the
   particular application of data involved.  This document reviews the
   history of the DNS, including examination of some of those newer
   applications.  It then argues that the overloading process is often
   inappropriate.  Instead, it suggests that the DNS should be
   supplemented by systems better matched to the intended applications
   and outlines a framework and rationale for one such system.

   Several of the comments that follow are somewhat revisionist.  Good
   design and engineering often requires a level of intuition by the
   designers about things that will be necessary in the future; the
   reasons for some of these design decisions are not made explicit at
   the time because no one is able to articulate them.  The discussion
   below reconstructs some of the decisions about the Internet's primary
   namespace (the "Class=IN" DNS) in the light of subsequent development
   and experience.  In addition, the historical reasons for particular
   decisions about the Internet were often severely underdocumented
   contemporaneously and, not surprisingly, different participants have
   different recollections about what happened and what was considered
   important.  Consequently, the quasi-historical story below is just
   one story.  There may be (indeed, almost certainly are) other stories
   about how the DNS evolved to its present state, but those variants do
   not invalidate the inferences and conclusions.

   This document presumes a general understanding of the terminology of
   RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]).





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


1.1  Context for DNS Development

   During the entire post-startup-period life of the ARPANET and nearly
   the first decade or so of operation of the Internet, the list of host
   names and their mapping to and from addresses was maintained in a
   frequently-updated "host table" [RFC625], [RFC811], [RFC952].  The
   names themselves were restricted to a subset of ASCII [ASCII] chosen
   to avoid ambiguities in printed form, to permit interoperation with
   systems using other character codings (notably EBCDIC), and to avoid
   the "national use" code positions of ISO 646 [IS646].  These
   restrictions later became collectively known as the "LDH" rules for
   "letter-digit-hyphen", the permitted characters.  The table was just
   a list with a common format that was eventually agreed upon; sites
   were expected to frequently obtain copies of, and install, new
   versions.  The host tables themselves were introduced to:

   o  Eliminate the requirement for people to remember host numbers
      (addresses).  Despite apparent experience to the contrary in the
      conventional telephone system, numeric numbering systems,
      including the numeric host number strategy, did not (and do not)
      work well for more than a (large) handful of hosts.

   o  Provide stability when addresses changed.  Since addresses -- to
      some degree in the ARPANET and more importantly in the
      contemporary Internet -- are a function of network topology and
      routing, they often had to be changed when connectivity or
      topology changed.  The names could be kept stable even as
      addresses changed.

   o  Provide the capability to have multiple addresses associated with
      a given host to reflect different types of connectivity and
      topology.  Use of names, rather than explicit addresses, avoided
      the requirement that would otherwise exist for users and other
      hosts to track these multiple host numbers and addresses and the
      topological considerations for selecting one over others.

   After several years of using the host table approach, the community
   concluded that model did not scale adequately and that it would not
   adequately support new service variations.  A number of discussions
   and meetings were held which drew several ideas and incomplete
   proposals together.  The DNS was the result of that effort.  It
   continued to evolve during the design and initial implementation
   period, with a number of documents recording the changes (see
   [RFC819], [RFC830], and [RFC1034]).







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


   The goals for the DNS included:

   o  Preservation of the capabilities of the host table arrangements
      (especially unique, unambiguous, host names),

   o  Provision for addition of additional services (e.g., the special
      record types for electronic mail routing which quickly followed
      introduction of the DNS), and

   o  Creation of a robust, hierarchical, distributed, name lookup
      system to accomplish the other goals.

   The DNS design also permitted distribution of name administration,
   rather than requiring that each host be entered into a single,
   central, table by a central administration.

1.2 Review of the DNS and Its Role as Designed

   The DNS was designed to identify network resources.  Although there
   was speculation about including, e.g., personal names and email
   addresses, it was not designed primarily to identify people, brands,
   etc.  At the same time, the system was designed with the flexibility
   to accommodate new data types and structures, both through the
   addition of new record types to the initial "INternet" class, and,
   potentially, through the introduction of new classes.  Since the
   appropriate identifiers and content of those future extensions could
   not be anticipated, the design provided that these fields could
   contain any (binary) information, not just the restricted text forms
   of the host table.

   However, the DNS, as it is actually used, is intimately tied to the
   applications and application protocols that utilize it, often at a
   fairly low level.

   In particular, despite the ability of the protocols and data
   structures themselves to accommodate any binary representation, DNS
   names as used were historically not even unrestricted ASCII, but a
   very restricted subset of it, a subset that derives from the original
   host table naming rules.  Selection of that subset was driven in part
   by human factors considerations, including a desire to eliminate
   possible ambiguities in an international context.  Hence character
   codes that had international variations in interpretation were
   excluded, the underscore character and case distinctions were
   eliminated as being confusing (in the underscore's case, with the
   hyphen character) when written or read by people, and so on.  These
   considerations appear to be very similar to those that resulted in
   similarly restricted character sets being used as protocol elements
   in many ITU and ISO protocols (cf. [X29]).



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


   Another assumption was that there would be a high ratio of physical
   hosts to second level domains and, more generally, that the system
   would be deeply hierarchical, with most systems (and names) at the
   third level or below and a very large percentage of the total names
   representing physical hosts.  There are domains that follow this
   model: many university and corporate domains use fairly deep
   hierarchies, as do a few country-oriented top level domains
   ("ccTLDs").  Historically, the "US." domain has been an excellent
   example of the deeply hierarchical approach.  However, by 1998,
   comparison of several efforts to survey the DNS showed a count of SOA
   records that approached (and may have passed) the number of distinct
   hosts.  Looked at differently, we appear to be moving toward a
   situation in which the number of delegated domains on the Internet is
   approaching or exceeding the number of hosts, or at least the number
   of hosts able to provide services to others on the network.  This
   presumably results from synonyms or aliases that map a great many
   names onto a smaller number of hosts.  While experience up to this
   time has shown that the DNS is robust enough -- given contemporary
   machines as servers and current bandwidth norms -- to be able to
   continue to operate reasonably well when those historical assumptions
   are not met (e.g., with a flat, structure under ".COM" containing
   well over ten million delegated subdomains [COMSIZE]), it is still
   useful to remember that the system could have been designed to work
   optimally with a flat structure (and very large zones) rather than a