RFC 1794 (rfc1794) - Page 2 of 7

DNS Support for Load Balancing

RFC 1794             DNS Support for Load Balancing           April 1995


   record processing).  These were both viewed as drawbacks and not as
   general solutions.

   Most of the Internet waited in anticipation of an IETF approved
   method for simulating "clusters".

   Through a few IETF DNS Working Group sessions (Chaired by Rob Austein
   of Epilogue), it was collectively agreed upon that a number of
   criteria must be met:

       A) Backwards compatibility with the existing DNS RFC.

       B) Information changes frequently.

       C) Multiple addresses should be sent out.

       D) Must interact with other RRs appropriately.

       E) Must be able to represent many types of "loads"

       F) Must be fast.

   (A) would ensure that the installed base of BIND and other DNS
   implementations would continue to operate and interoperate properly.

   (B) would permit very fast update times - to enable modeling of
   real-time data.  Five minutes was thought as a normal interval,
   though changes as fast as every sixty seconds could be imagined.

   (C) would cover the possibility of a host's address being advertised
   as optimal, yet the machine crashed during the period within the TTL
   of the RR.  The second-most preferable address would be advertised
   second, the third-most preferable third, and so on.  This would allow
   a reasonable stab at recovery during machine failures.

   (D) would ensure correct handling of all ancillary information - such
   as MX, RP, and TXT information, as well as reverse lookup
   information.  It needed to be ensured that such processes as mail
   handling continued to work in an unsurprising and predictable manner.

   (E) would ensure the flexibility that everyone wished.  A breadth of
   "loads" were wished to be represented by various members of the DNS
   Working Group.  Some "loads" were fairly eclectic - such as the
   address ordering by the RTT to the host, some were pragmatic - such
   as balancing the CPU load evenly across a series of hosts.  All
   represented valid concerns within their own context, and the idea of
   having separate RR types for each was unthinkable (primarily; it
   would violate goal A).



Brisco