[dns-operations] Load balancing DNS queries across many machines
Matthew Dempsky
matthew at dempsky.org
Fri Jul 17 06:13:40 UTC 2009
On Thu, Jul 16, 2009 at 10:32 PM, Michael
Sinatra<michael at rancid.berkeley.edu> wrote:
> That's cool, but it doesn't solve the redundancy/reliability issue.
I think it does, but see below.
> Because
> you asked about how we deal with load-sharing, I assumed you were interested
> in solving that issue.
I'm sorry if I was misleading.
> Even if you have a client address and cookie in the
> packet payload, the packet itself won't be received by the failover
> forwarder if the main forwarder goes down before the backend has answered.
You can have the forwarder use CARP or something for the source IP
address when talking to the backend servers. If the forwarder is
stateless (e.g., by embedding the state in a cookie), then it doesn't
matter what host the response packet is routed to.
However, like you mentioned, the client already has to retry if a DNS
query fails, so it's not a huge deal if a forwarder fails and its
outstanding queries are dropped.
> Therefore, the only advantage of doing that is for query logging.
And client differentiation. E.g., some sites like to vary their
responses based on the client's geographic location.
> I see. So the question was really, has anyone tried any kind of stateful
> load-sharing protocol for DNS beyond anycast or CARP that might have already
> done what you want to do.
Exactly. Another interesting scenario your email reminded me of is
proxying DNS requests from IPv6 clients to IPv4-only DNS servers.
> My personal answer (which I think I explained
> somewhat in my previous message) is "probably not." Because anycast and
> other simple redundancy mechanisms work so well for DNS, there is little
> need to do anything that replicates state, since there is very little state
> to replicate.
Right, that's what I suspected, but thought I'd ask anyway. :)
More information about the dns-operations
mailing list