Randy Bush <randy(_at_)psg(_dot_)com> writes:
a constructive answer to the question would be to direct them to the
dnsop wg. or, if this specific case, since it seems product-specific,
the bind-users mailing list.
Except that lbnamed, if they're talking about the Stanford version, has
nothing to do with BIND.
The lbnamed code isn't exactly pretty, but yeah, we've been using it with
a good deal of success for some years now. Roland's original code had the
problem that it relied on chained CNAMEs with 0 TTLs, which runs into a
bug in recent versions of BIND, so we've started to switch towards just
providing an A record instead.
Other sites tend to use hardware solutions to solve the same problem
(generally boxes that relay incoming traffic to one of a number of hidden
back-end servers), but DNS is a nice, light-weight solution to the same
problem that's essentially free to deploy and a great deal more flexible.
lbnamed uses a daemon on each client machine that returns a "load" used by
the daemon to figure out what machines to hand out, and that concept can
be used and abused to play all sorts of very flexible tricks from round
robin to load balancing via a huge variety of criteria to simple hot spare
configurations with a form of automatic fallover (including being able to
switch from one to the other with a minimum amount of fuss and without
having to even touch the lbnamed server).
One can think of lbnamed as a solution on the cheap for a variety of
problems that can be solved other ways, but usually at more expense and
complexity than our applications required.
--
Russ Allbery (rra(_at_)stanford(_dot_)edu)
<http://www.eyrie.org/~eagle/>