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