RFC 1794 (rfc1794) - Page 2 of 7
DNS Support for Load Balancing
Alternative Format: Original Text Document
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