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

Mon May 30 23:44:47 UTC 2011

Get back to us when you prove that this co-exists with DNSSEC; otherwise 
it's a non-starter. While you're at it, some data proving that this 
actually enhances performance or availability would be nice too.

         - Kevin

On 5/30/2011 3:21 PM, Maren S. Leizaola wrote:
> 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==--
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>