home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1794 < prev    next >
Text File  |  1995-04-20  |  15KB  |  396 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          T. Brisco
  8. Request for Comments: 1794                            Rutgers University
  9. Category: Informational                                       April 1995
  10.  
  11.  
  12.                      DNS Support for Load Balancing
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. 1. Introduction
  21.  
  22.    This RFC is meant to first chronicle a foray into the IETF DNS
  23.    Working Group, discuss other possible alternatives to
  24.    provide/simulate load balancing support for DNS, and to provide an
  25.    ultimate, flexible solution for providing DNS support for balancing
  26.    loads of many types.
  27.  
  28. 2. History
  29.  
  30.    The history of this probably dates back well before my own time - so
  31.    undoubtedly some holes are here.  Hopefully they can be filled in by
  32.    other authors.
  33.  
  34.    Initially; "load balancing" was intended to permit the Domain Name
  35.    System (DNS) [1] agents to support the concept of "clusters" (derived
  36.    from the VMS usage) of machines - where all machines were
  37.    functionally similar or the same, and it didn't particularly matter
  38.    which machine was picked - as long as the load of the processing was
  39.    reasonably well distributed across a series of actual different
  40.    hosts.  Around 1986 a number of different schemes started surfacing
  41.    as hacks to the Berkeley Internet Name Domain server (BIND)
  42.    distribution.  Probably the most widely distributed of these were the
  43.    "Shuffle Address" (SA) modifications by Bryan Beecher, or possibly
  44.    Marshall Rose's "Round Robin" code.
  45.  
  46.    The SA records, however, did a round-robin ordering of the Address
  47.    resource records, and didn't do much with regard to the particular
  48.    loads on the target machines.  Matt Madison (of TGV) implemented some
  49.    changes that used VMS facilities to review the system loads, and
  50.    return A RRs in the order of least-loaded to most loaded.
  51.  
  52.    The problem was with SAs was that load was not actually a factor, and
  53.    TGV's relied on VMS specific facilities to order the records.  The SA
  54.    RRs required changes to the DNS specification (in file syntax and in
  55.  
  56.  
  57.  
  58. Brisco                                                          [Page 1]
  59.  
  60. RFC 1794             DNS Support for Load Balancing           April 1995
  61.  
  62.  
  63.    record processing).  These were both viewed as drawbacks and not as
  64.    general solutions.
  65.  
  66.    Most of the Internet waited in anticipation of an IETF approved
  67.    method for simulating "clusters".
  68.  
  69.    Through a few IETF DNS Working Group sessions (Chaired by Rob Austein
  70.    of Epilogue), it was collectively agreed upon that a number of
  71.    criteria must be met:
  72.  
  73.        A) Backwards compatibility with the existing DNS RFC.
  74.  
  75.        B) Information changes frequently.
  76.  
  77.        C) Multiple addresses should be sent out.
  78.  
  79.        D) Must interact with other RRs appropriately.
  80.  
  81.        E) Must be able to represent many types of "loads"
  82.  
  83.        F) Must be fast.
  84.  
  85.    (A) would ensure that the installed base of BIND and other DNS
  86.    implementations would continue to operate and interoperate properly.
  87.  
  88.    (B) would permit very fast update times - to enable modeling of
  89.    real-time data.  Five minutes was thought as a normal interval,
  90.    though changes as fast as every sixty seconds could be imagined.
  91.  
  92.    (C) would cover the possibility of a host's address being advertised
  93.    as optimal, yet the machine crashed during the period within the TTL
  94.    of the RR.  The second-most preferable address would be advertised
  95.    second, the third-most preferable third, and so on.  This would allow
  96.    a reasonable stab at recovery during machine failures.
  97.  
  98.    (D) would ensure correct handling of all ancillary information - such
  99.    as MX, RP, and TXT information, as well as reverse lookup
  100.    information.  It needed to be ensured that such processes as mail
  101.    handling continued to work in an unsurprising and predictable manner.
  102.  
  103.    (E) would ensure the flexibility that everyone wished.  A breadth of
  104.    "loads" were wished to be represented by various members of the DNS
  105.    Working Group.  Some "loads" were fairly eclectic - such as the
  106.    address ordering by the RTT to the host, some were pragmatic - such
  107.    as balancing the CPU load evenly across a series of hosts.  All
  108.    represented valid concerns within their own context, and the idea of
  109.    having separate RR types for each was unthinkable (primarily; it
  110.    would violate goal A).
  111.  
  112.  
  113.  
  114. Brisco                                                          [Page 2]
  115.  
  116. RFC 1794             DNS Support for Load Balancing           April 1995
  117.  
  118.  
  119.    (F) needed to ensure a few things.  Primarily that the time to
  120.    calculate the information to order the addressing information did not
  121.    exceed the TTL of the information distributed - i.e., that elements
  122.    with a TTL of five minutes didn't take six minutes to calculate.
  123.    Similarly; it seems a fairly clear goal in the DNS RFC that clients
  124.    should not be kept waiting - that request processing should continue
  125.    regardless of the state of any other processing occurring.
  126.  
  127. 3. Possible Alternatives
  128.  
  129.    During various discussions with the DNS Working Group and with the
  130.    Load Balancing Committee, it was noted that no existing solution
  131.    dealt with all wishes appropriately.  One of the major successes of
  132.    the DNS is its flexibility - and it was felt that this needed to be
  133.    retained in all aspects.  It was conceived that perhaps not only
  134.    address information would need to be changed rapidly, but other
  135.    records may also need to change rapidly (at least this could not be
  136.    ruled out - who knows what technologies lurk in the future).
  137.  
  138.    Of primary concern to many was the ability to interact with older
  139.    implementations of DNS.  The DNS is implemented widely now, and
  140.    changes to critical portions of the protocol could cause havoc for
  141.    years.  It became rapidly apparent through conversations with Jon
  142.    Postel and Dave Crocker (Area Director) that modifications to the
  143.    protocol would be viewed dimly.
  144.  
  145. 4. A Flexible Model
  146.  
  147.    During many hours of discussions, it arose upon suggestion from Rob
  148.    Austein that the changes could be implemented without changes to the
  149.    protocol; if zone transfer behavior could be subtly changed, then the
  150.    zone transfer process could accommodate the changing of various RR
  151.    information.  What was needed was a smarter program to do the zone
  152.    transfers.  Pursuant to this, changes were made to BIND that would
  153.    permit the specification of the program to do the zone transfers for
  154.    particular zones.
  155.  
  156.    There is no specification that a secondary has to receive updates
  157.    from its primary server in any specific manner - only that it needs
  158.    to check periodically, and obtain new zone copies when changes have
  159.    been made.  Conceivably the zone transfer agent could obtain the
  160.    information from any number of sources (e.g., a load average daemon,
  161.    a round-robin sorter) and present the information back to the
  162.    nameserver for distribution.
  163.  
  164.    A number of questions arose from this concept, and all seem to have
  165.    been dealt with accordingly.  Primarily, the DNS protocol doesn't
  166.    guarantee ordering.  While the DNS protocol doesn't guarantee
  167.  
  168.  
  169.  
  170. Brisco                                                          [Page 3]
  171.  
  172. RFC 1794             DNS Support for Load Balancing           April 1995
  173.  
  174.  
  175.    ordering, it is clear that the ordering is predictive - that
  176.    information read in twice in the same order will be presented twice
  177.    in the same order to clients.  Clients, of course, may reorder this
  178.    information, but that is deemed as a "local issue" as it is
  179.    configurable by the remote systems administrators (e.g., sortlists,
  180.    etc).  The zone transfer agent would have to account for any "mis-
  181.    ordering" that may occur locally, but remote reordering (e.g., client
  182.    side sortlists) of RRs is is impossible to predict.  Since local
  183.    mis-ordering is consistent, the zone transfer agents could easily
  184.    account for this.
  185.  
  186.    Secondarily, but perhaps more subtly, the problem arises that zone
  187.    transfers aren't used by primary nameservers, only by secondary
  188.    nameservers.  To clarify this, the idea of "fast" or "volatile"
  189.    subzones must be dealt with.  In a volatile environment (where
  190.    address or other RR ordering changes rapidly), the refresh rate of a
  191.    zone must be set very low, and the TTL of the RRs handed out must
  192.    similarly be very low.  There is no use in handing out information
  193.    with TTLs of an hour, when the conditions for ordering the RRs
  194.    changes minutely.  There must be a relatively close relationship
  195.    between the refresh rates and TTLs of the information.  Of course,
  196.    with very low refresh rates, zone transfers between the primary and
  197.    secondary would have to occur frequently.  Given that primary and
  198.    secondary nameservers should be topologically and geographically far
  199.    apart, moving that much data that frequently is seen as prohibitive.
  200.    Also; the longer the propagation time between the primary and
  201.    secondary, the larger the window in which circumstances can change -
  202.    thus invalidating the secondary's information.  It is generally
  203.    thought that passing volatile information on to a secondary is fairly
  204.    useless - if secondaries want accurate information, then they should
  205.    calculate it themselves and not obtain it via zone transfers.  This
  206.    avoids the problem with secondaries losing contact with the primaries
  207.    (but access to the targets of the volatile domain are still
  208.    reachable), but the secondary has information that is growing stale.
  209.  
  210.    What is essentially necessary is a secondary (with no primary) which
  211.    can calculate the necessary ordering of the RR data for itself (which
  212.    also avoids the problem of different versions of domain servers
  213.    predictively ordering RR information in different predictive
  214.    fashions).  For a volatile zone, there is no primary DNS agent, but
  215.    rather a series of autonomous secondary agents.  Each autonomous
  216.    secondary agent is, of course, capable of calculating the ordering or
  217.    content of the volatile RRs itself.
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Brisco                                                          [Page 4]
  227.  
  228. RFC 1794             DNS Support for Load Balancing           April 1995
  229.  
  230.  
  231. 5. Implementation
  232.  
  233.    With some help from Masataka Ohta (Tokyo Institute of Technology), I
  234.    implemented modifications to BIND to permit the specification of the
  235.    zone transfer program (zone transfer agent) for particular domains:
  236.  
  237.            transfer        <domain-name>       <program-name>
  238.  
  239.    Currently I define a separate subdomain that has a few hosts defined
  240.    in it - all volatile information.  The zone has a refresh rate of
  241.    300, and a minimum TTL of 300 indicated.  The configuration file is
  242.    indicated as "volatile.hosts".  Every 300 seconds a program "doAxfer"
  243.    is run to do the zone transfer.  The program "doAxfer" reads the file
  244.    "volatile.hosts.template" and the file "volatile.hosts.list".  The
  245.    addresses specified in volatile.hosts.list are rotated a random
  246.    number of times, and then substituted (in order) into
  247.    volatile.hosts.template to generate the file volatile.hosts.  The
  248.    program "doAxfer" then exits with a value of 1 - to indicate to the
  249.    nameserver that the zone transfer was successful, and that the file
  250.    should be read in, and the information distributed.  This results in
  251.    a host having multiple addresses, and the addresses are randomized
  252.    every five minutes (300 seconds).
  253.  
  254.    Two bugs continue to plague us in this endeavor.  BIND currently
  255.    considers any TTL under 300 seconds as "irrational", and substitutes
  256.    in the value of 300 instead.  This greatly hampers the functionality
  257.    of volatile zones.  In the fastest of all cases - a 0 TTL -
  258.    information would be used once, and then thrown away.  Presumably the
  259.    new RR information could be calculated every 5 seconds, and the RRs
  260.    handed out with a TTL of 0.  It must be considered that one
  261.    limitation of the speed of a zone is going to be the ability of a
  262.    machine to calculate new information fast enough.
  263.  
  264.    The other bug that also effects this is that, as with TTLs, BIND
  265.    considers any zone refresh rate under 15 minutes to be similarly
  266.    irrational.  Obviously zone refresh rates of 15 minutes is
  267.    unacceptable for this sort of applications.
  268.  
  269.    For a work-around, the current code sets these same hard-coded values
  270.    to 60 seconds.  Sixty seconds is still large enough to avoid any
  271.    residual bugs associated with small timer values, but is also short
  272.    enough to allow fast subzones to be of use.
  273.  
  274.    This version of BIND is currently in release within Rutgers
  275.    University, operating in both "fast" and normal zones.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Brisco                                                          [Page 5]
  283.  
  284. RFC 1794             DNS Support for Load Balancing           April 1995
  285.  
  286.  
  287. 6. Performance
  288.  
  289.    While the performance of fast zones isn't exactly stellar, it is not
  290.    much more than the normal CPU loads induced by BIND.  Testing was
  291.    performed on a Sun Sparc-2 being used as a normal workstation, but no
  292.    resolvers were using the name server - essentially the nameserver was
  293.    idle.  For a configuration with no fast subzones, BIND accrued 11 CPU
  294.    seconds in 24 hours.  For a configuration with one fast zone, six
  295.    address records, and being refreshed every 300 seconds (5 minutes),
  296.    BIND accrued 1 minute 4 seconds CPU time.  For the same previous
  297.    configuration, but being refreshed every sixty seconds, BIND accrued
  298.    5 minutes and 38 seconds of CPU time.
  299.  
  300.    As is no great surprise, the CPU load on the serving machine was
  301.    linear to the frequency of the refresh time.  The sixty second
  302.    refresh configuration used approximately five times as much CPU time
  303.    as did the 300 second refresh configuration.  One can easily
  304.    extrapolate that the overall CPU utilization would be linear to the
  305.    number of zones and the frequency of the refresh period.  All of this
  306.    is based on a shell script that always indicated that a zone update
  307.    was necessary, a more intelligent program should realize when the
  308.    reordering of the RRs was unnecessary and avoid such periodic zone
  309.    reloads.
  310.  
  311. 7. Acknowledgments
  312.  
  313.    Most of the ideas in this document are the results of conversations
  314.    and proposals from many, many people - including, but not limited to,
  315.    Robert Austein, Stuart Vance, Masataka Ohta, Marshall Rose, and the
  316.    members of the IETF DNS Working Group.
  317.  
  318. 8. References
  319.  
  320.    [1] Mockapetris, P., "Domain Names - Implementation and
  321.        Specification", STD 13, RFC 1035, USC/Information Sciences
  322.        Institute, November 1987.
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Brisco                                                          [Page 6]
  339.  
  340. RFC 1794             DNS Support for Load Balancing           April 1995
  341.  
  342.  
  343. 9.  Security Considerations
  344.  
  345.    Security issues are not discussed in this memo.
  346.  
  347. 10. Author's Address
  348.  
  349.    Thomas P. Brisco
  350.    Associate Director for Network Operations
  351.    Rutgers University
  352.    Computing Services, Telecommunications Division
  353.    Hill Center for the Mathematical Sciences
  354.    Busch Campus
  355.    Piscataway, New Jersey 08855-0879
  356.    USA
  357.  
  358.    Phone: +1-908-445-2351
  359.    EMail: brisco@rutgers.edu
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Brisco                                                          [Page 7]
  395.  
  396.