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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
