rfc1794.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   apart, moving that much data that frequently is seen as prohibitive.
   Also; the longer the propagation time between the primary and
   secondary, the larger the window in which circumstances can change -
   thus invalidating the secondary's information.  It is generally
   thought that passing volatile information on to a secondary is fairly
   useless - if secondaries want accurate information, then they should
   calculate it themselves and not obtain it via zone transfers.  This
   avoids the problem with secondaries losing contact with the primaries
   (but access to the targets of the volatile domain are still
   reachable), but the secondary has information that is growing stale.

   What is essentially necessary is a secondary (with no primary) which
   can calculate the necessary ordering of the RR data for itself (which
   also avoids the problem of different versions of domain servers
   predictively ordering RR information in different predictive
   fashions).  For a volatile zone, there is no primary DNS agent, but
   rather a series of autonomous secondary agents.  Each autonomous
   secondary agent is, of course, capable of calculating the ordering or
   content of the volatile RRs itself.








Brisco                                                          [Page 4]

RFC 1794             DNS Support for Load Balancing           April 1995


5. Implementation

   With some help from Masataka Ohta (Tokyo Institute of Technology), I
   implemented modifications to BIND to permit the specification of the
   zone transfer program (zone transfer agent) for particular domains:

           transfer        <domain-name>       <program-name>

   Currently I define a separate subdomain that has a few hosts defined
   in it - all volatile information.  The zone has a refresh rate of
   300, and a minimum TTL of 300 indicated.  The configuration file is
   indicated as "volatile.hosts".  Every 300 seconds a program "doAxfer"
   is run to do the zone transfer.  The program "doAxfer" reads the file
   "volatile.hosts.template" and the file "volatile.hosts.list".  The
   addresses specified in volatile.hosts.list are rotated a random
   number of times, and then substituted (in order) into
   volatile.hosts.template to generate the file volatile.hosts.  The
   program "doAxfer" then exits with a value of 1 - to indicate to the
   nameserver that the zone transfer was successful, and that the file
   should be read in, and the information distributed.  This results in
   a host having multiple addresses, and the addresses are randomized
   every five minutes (300 seconds).

   Two bugs continue to plague us in this endeavor.  BIND currently
   considers any TTL under 300 seconds as "irrational", and substitutes
   in the value of 300 instead.  This greatly hampers the functionality
   of volatile zones.  In the fastest of all cases - a 0 TTL -
   information would be used once, and then thrown away.  Presumably the
   new RR information could be calculated every 5 seconds, and the RRs
   handed out with a TTL of 0.  It must be considered that one
   limitation of the speed of a zone is going to be the ability of a
   machine to calculate new information fast enough.

   The other bug that also effects this is that, as with TTLs, BIND
   considers any zone refresh rate under 15 minutes to be similarly
   irrational.  Obviously zone refresh rates of 15 minutes is
   unacceptable for this sort of applications.

   For a work-around, the current code sets these same hard-coded values
   to 60 seconds.  Sixty seconds is still large enough to avoid any
   residual bugs associated with small timer values, but is also short
   enough to allow fast subzones to be of use.

   This version of BIND is currently in release within Rutgers
   University, operating in both "fast" and normal zones.






Brisco                                                          [Page 5]

RFC 1794             DNS Support for Load Balancing           April 1995


6. Performance

   While the performance of fast zones isn't exactly stellar, it is not
   much more than the normal CPU loads induced by BIND.  Testing was
   performed on a Sun Sparc-2 being used as a normal workstation, but no
   resolvers were using the name server - essentially the nameserver was
   idle.  For a configuration with no fast subzones, BIND accrued 11 CPU
   seconds in 24 hours.  For a configuration with one fast zone, six
   address records, and being refreshed every 300 seconds (5 minutes),
   BIND accrued 1 minute 4 seconds CPU time.  For the same previous
   configuration, but being refreshed every sixty seconds, BIND accrued
   5 minutes and 38 seconds of CPU time.

   As is no great surprise, the CPU load on the serving machine was
   linear to the frequency of the refresh time.  The sixty second
   refresh configuration used approximately five times as much CPU time
   as did the 300 second refresh configuration.  One can easily
   extrapolate that the overall CPU utilization would be linear to the
   number of zones and the frequency of the refresh period.  All of this
   is based on a shell script that always indicated that a zone update
   was necessary, a more intelligent program should realize when the
   reordering of the RRs was unnecessary and avoid such periodic zone
   reloads.

7. Acknowledgments

   Most of the ideas in this document are the results of conversations
   and proposals from many, many people - including, but not limited to,
   Robert Austein, Stuart Vance, Masataka Ohta, Marshall Rose, and the
   members of the IETF DNS Working Group.

8. References

   [1] Mockapetris, P., "Domain Names - Implementation and
       Specification", STD 13, RFC 1035, USC/Information Sciences
       Institute, November 1987.















Brisco                                                          [Page 6]

RFC 1794             DNS Support for Load Balancing           April 1995


9.  Security Considerations

   Security issues are not discussed in this memo.

10. Author's Address

   Thomas P. Brisco
   Associate Director for Network Operations
   Rutgers University
   Computing Services, Telecommunications Division
   Hill Center for the Mathematical Sciences
   Busch Campus
   Piscataway, New Jersey 08855-0879
   USA

   Phone: [phone]
   EMail: [e-mail]


































Brisco                                                          [Page 7]