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

[Maren S. Leizaola]

Hello,
             I am reading this mailing as a digest so sorry for the late 
replies. Firstly we have been using this method for over 4 years and 
I've yet not had one person tell me that they can connect to our servers 
using POP3, SMPT, IMAP or WEB.

1. Mark, Regarding Chrome, my last big crawl of the internet from Hong 
Kong the average DNS resolution was 450ms average... so 300ms would give 
you what result. Not sure I don't care.  I am talking for IP 
connectivity not some application decigin which RR it shoud use as many 
applications are dumb and you can't ask the remote end to change 
anything.  FYI, I will never use Chrome and nor will many people due to 
privacy issues. It is banned in companies in Asia.

2. Mark there are no modification to any packets at the DNS resolver 
level.... nor sure why there would have be. We have yet not implemented 
DNS SEC so I don't know if this breaks anything. First packet wins....  
both can be signed. Now if you have something set on paranoid mode which 
checks the consistency of the DNS servers it would fail... that is an 
extreme minority and have YET to see a complaint.

Matus, I like your reply. You  are right that the wining IP would be the 
one that is closes to the Resolving server than to the client......  I 
know that not everyone is using a DNS resolver on the same network/AS 
number that they are on.
This could be the biggest flaw. Say you use Google FreeDNS and it will 
give as a reply what ever google can access the fastest. However if you 
are using a DNS resolver within your AS number you will benefit from DNS 
Racing.
Well pointed out. All that this does is breaks the best bath and access 
guarantee that DNS Racing provides.... In reality if you don't implement 
DNS racing you would get the same result.

No it does not rely on BIND RTT feature, we are talking about pure 
latency DNS replies race to the resolver, the one that gets there first 
is the winner.

This is not something that I just dream up yesterday we have been using 
it for years.... without problems....  which is why I feel it is safe to 
document in and recommend it.

Regards,
Maren.




On 3:59 AM, Mark Andrews wrote:
> And if people used happy-eyeballs[1] or similar[2] in the applications
> this would not be needed.  Chrome already does this with their
> latest browser.  It uses a 300ms timer to switch to the next address.
>
> Happy-eyeballs was primarially written to deal with broken 6to4
> links but the techniques are applicable to any multi-homed service
> be it IPv4 only, IPv6 only or a mixture of IPv4 and IPv6.
>
> Mark
>
> [1] http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6-01
> [2] https://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp
>
> In message<4DE2C00B.6090607 at isc.org>, Alan Clegg writes:
>> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>> --===============2705591056810672531==
>> Content-Type: multipart/signed; micalg=pgp-sha1;
>> 	protocol="application/pgp-signature";
>> 	boundary="------------enig46D823F06B8505CC93187062"
>>
>> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
>> --------------enig46D823F06B8505CC93187062
>> Content-Type: text/plain; charset=windows-1252
>> Content-Transfer-Encoding: quoted-printable
>>
>> On 5/29/2011 5:12 PM, Maren S. Leizaola wrote:
>>
>>> IT is a poor man=92s replacement for BGP multihoming and IP anycast.
>>> Hey it is Free and you can implement it using BIND.
>> And you've just broken DNSSEC.
>>
>> AlanC
>>
>>
>> --------------enig46D823F06B8505CC93187062
>> Content-Type: application/pgp-signature; name="signature.asc"
>> Content-Description: OpenPGP digital signature
>> Content-Disposition: attachment; filename="signature.asc"
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.17 (MingW32)
>>
>> iEYEARECAAYFAk3iwA0ACgkQcKpYUrUDCYdMXwCgmIsTehj06i1fsZtJmCaPEHIi
>> JqcAoJPhcXKDf/QgPK06MkkYt2N9gZPB
>> =nLtA
>> -----END PGP SIGNATURE-----
>>
>> --------------enig46D823F06B8505CC93187062--
>>
>> --===============2705591056810672531==
>> Content-Type: text/plain; charset="us-ascii"
>> MIME-Version: 1.0
>> Content-Transfer-Encoding: 7bit
>> Content-Disposition: inline
>>
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>> --===============2705591056810672531==--