One Domain; Multiple IPs.
Brad Knowles
brad.knowles at skynet.be
Thu Jul 19 00:58:52 UTC 2001
At 12:22 AM +0000 7/19/01, Barry Margolin wrote:
> I don't think routing-based techniques are appropriate for TCP-based
> services, or anything that requires that an address correspond to the same
> physical server over a long period of time.
I'm willing to concede this point. Please see my other message.
> I suppose if the DNS-based mechanism weren't available, something like HTTP
> redirects could be used.
Use TCP triangulation. Have the SYN packet come into a
particular device, have that device make a decision as to where to
cause that connection to be set up, then it generates an outgoing SYN
packet to that back-end machine, which then proceeds to finish
setting up the TCP connection with the client that generated the
original SYN.
> I agree with your general sentiment. It's best not to use a screwdriver
> as a hammer, but if all you have is a screwdriver, you make do.
Thing is, I think that there are other tools out there that are
available, and which make better hammers.
> Furthermore, most of your complaints about devices like Distributed
> Director don't seem to be related to the way they give out different
> answers to a query, but are about the fact that they aren't a complete
> implementation of DNS.
Indeed, that is part of my complaint.
> Just because a particular DNS appliance is
> half-assed should not be an indictment of the general principle.
True enough, but another part of my complaint is the fact that
they are used to abuse and mis-use the DNS as a mechanism to solve
problems that are best solved with other techniques.
> The web
> hosting company that GTE acquired a few years ago at the same time as they
> acquired BBN (which, coincidentally, was named Genuity, the name we adopted
> when GTE spun us off last year) had a load balancing system based on a
> patched version of BIND, so it did all the normal DNS stuff normally.
> Would you have as much of a complaint about this type of solution?
I would still have some reservations, as the load-balancing
decision is made too early in the process. Moreover, that also
requires importing too much information into the nameserver (such as
routing topology) so that it can attempt to make more intelligent
decisions.
That load-balancing/distribution decision should not be made when
the recursive/caching nameserver on the remote end asks a question
regarding the IP address for a particular "machine". Instead, that
decision should be pushed off until such time as the client(s)
actually go to make the connection to the "machine" in question.
Moreover, that load-balancing/distribution decision should make
as much use as possible of network topology information, but within
the network layer itself, and at the time of the setup of the
connection.
> Admittedly, a problem with this type of solution is keeping the patched
> version in sync with the changes being made in the on-going BIND
> development.
If that code were integrated into the public version of BIND, and
were therefore hopefully reasonably well-tested at a variety of
sites, that would at least eliminate my concerns over the quality of
the code that is performing the service(s), and the degree to which
it had been tested.
I would still have a lot of other issues, however.
--
Brad Knowles, <brad.knowles at skynet.be>
/* efdtt.c Author: Charles M. Hannum <root at ihack.net> */
/* Represented as 1045 digit prime number by Phil Carmody */
/* Prime as DNS cname chain by Roy Arends and Walter Belgers */
/* */
/* Usage is: cat title-key scrambled.vob | efdtt >clear.vob */
/* where title-key = "153 2 8 105 225" or other similar 5-byte key */
dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'
More information about the bind-users
mailing list