PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|RFC|rfc0882.txt =

page 3 of 18



      community and is designed to avoid many of the the complicated
      problems found in general purpose database systems.

      The assumptions are:

         The size of the total database will initially be proportional
         to the number of hosts using the system, but will eventually
         grow to be proportional to the number of users on those hosts
         as mailboxes and other information are added to the domain
         system.

         Most of the data in the system will change very slowly (e.g.,
         mailbox bindings, host addresses), but that the system should
         be able to deal with subsets that change more rapidly (on the
         order of minutes).

         The administrative boundaries used to distribute responsibility
         for the database will usually correspond to organizations that
         have one or more hosts.  Each organization that has
         responsibility for a particular set of domains will provide
         redundant name servers, either on the organization's own hosts
         or other hosts that the organization arranges to use.

         Clients of the domain system should be able to identify trusted
         name servers they prefer to use before accepting referrals to
         name servers outside of this "trusted" set.

         Access to information is more critical than instantaneous



 

RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


         updates or guarantees of consistency.  Hence the update process
         allows updates to percolate out though the users of the domain
         system rather than guaranteeing that all copies are
         simultaneously updated.  When updates are unavailable due to
         network or host failure, the usual course is to believe old
         information while continuing efforts to update it.  The general
         model is that copies are distributed with timeouts for
         refreshing.  The distributor sets the timeout value and the
         recipient of the distribution is responsible for performing the
         refresh.  In special situations, very short intervals can be
         specified, or the owner can prohibit copies.

         Some users will wish to access the database via datagrams;
         others will prefer virtual circuits.  The domain system is
         designed so that simple queries and responses can use either
         style, although refreshing operations need the reliability of
         virtual circuits.  The same overall message format is used for
         all communication.  The domain system does not assume any
         special properties of the communications system, and hence
         could be used with any datagram or virtual circuit protocol.

         In any system that has a distributed database, a particular
         name server may be presented with a query that can only be
         answered by some other server.  The two general approaches to
         dealing with this problem are "recursive", in which the first
         server pursues the query for the client at another server, and
         "iterative", in which the server refers the client to another
         server and lets the client pursue the query.  Both approaches
         have advantages and disadvantages, but the iterative approach
         is preferred for the datagram style of access.  The domain
         system requires implementation of the iterative approach, but
         allows the recursive approach as an option.  The optional
         recursive style is discussed in [14], and omitted from further
         discussion in this memo.

      The domain system assumes that all data originates in master files
      scattered through the hosts that use the domain system.  These
      master files are updated by local system administrators.  Master
      files are text files that are read by a local name server, and
      hence become available to users of the domain system.  A standard
      format for these files is given in [14].

      The standard format allows these files to be exchanged between
      hosts (via FTP, mail, or some other mechanism); this facility is
      useful when an organization wants a domain, but doesn't want to
      support a name server.  The organization can maintain the master
      files locally using a text editor, transfer them to a foreign host
      which runs a name server, and then arrange with the system
      administrator of the name server to get the files loaded.



 

RFC 882                                                    November 1983
                                  Domain Names - Concepts and Facilities


      Each host's name servers and resolvers are configured by a local
      system administrator.  For a name server, this configuration data
      includes the identity of local master files and instructions on
      which non-local master files are to be loaded from foreign
      servers.  The name server uses the master files or copies to load
=3=

1|2| < PREV = PAGE 3 = NEXT > |4|5|6|7|8|9|10|11|12.18

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.0112479 wallclock secs ( 0.01 usr + 0.00 sys = 0.01 CPU)