DNS Racing -Multi ISP load balancing with failover using DNS.

[Maren S. Leizaola]

On 5/31/2011 7:39 AM, Mark Andrews wrote:
> It is still a bad idea.  Fixing the clients so they work well with
> multi-homed servers not only works today with mostly IPv4 servers
> but also works well with dual stack server and IPv6 only servers.
>
> You don't have to have artifially low TTLs on the DNS responses.
> You get sub-second failover on new connections.

Easy there fellow.... We run with a 15m TTL and we get no complaints 
from customers. Sure I am sure someone somewhere does get an error but 
they are not enough for people to email us and call us...

Prior to DNS racing we use to get that a lot of calls...... we had to do 
the fail over and balacing by telling them type in
mail2.mailme.hk.com

We do get more traffic on one ISP than the other as it has better 
peering, lower latency pipes, even though the circuit to them is slower 
on our side... Though I can tell when they are having problems as 
traffic volumes move to the other circuit automatically.

> If you really want
> to perform races then connect() races will reflect actual client
> topology not resolver topology.
Yes the flaw has been pointed out, if the DNS resolvers are not on the 
same ISP/AS number the user will not be sent to the optimal path....


>    DNS Race doesn't work in a dual
> stack environment as it is dependent on the record type and transport
> matching.
>
> As for Chrome.  It was a example of a application which does work
> well with multi-homed servers.

Either someone sits down and re-write the archaic code in the resolver 
library client in kernels and builds most of the intelligence in bind OR 
all applications have to be re-written...

Or you can use DNS Racing...... My idea is good as I can do the changes 
on my side.... for the people that are not running duals stacks etc, 
they will expierence the same problems as

I need to polish up on bind and find out about the RR sorting. so that 
CHrome etc works better.

Thank you all for your feed back and criticism....

Maren.

> Mark