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