Re: DNS Racing -Multi ISP load balancing with failover using DNS.
On 31/05/11 09:28, Matus UHLAR - fantomas wrote: This problem could be avoided by providing the same data, but differently sorted, correct? On 31.05.11 12:27, Phil Mayers wrote: Not really. Client side sorting may take place (e.g. to comply with RFC 3484 policies in calls to getaddrinfo) and destroy any server-side sorting. On 01/06/11 08:11, Matus UHLAR - fantomas wrote: by this problem I mean the DNSSEC. Providing all the data just differently sorted would cause them to be DNSSEC compliant, wouldn't it? On 01.06.11 10:55, Phil Mayers wrote: Yes, but the client would then re-sort the data, so it wouldn't achieve the original purpose. Sorting the data server side gives you essentially no control over which record the client will pick if they are calling getaddrinfo, as is likely. Aha, I've got it. However data sorting at client's side should not affect much clients, only where - the client has sorting set up - the sorting client prefers one of IP's used in RRset. We have set that up to prefer IPs from our network over foreign. As Mark has already pointed out, the approach is not intrinsically DNSSEC-hostile. It's perfectly legitimate to serve different data with different, valid, signatures. This is what happens with signature regen and key rollover. In this case, it would just be a permanent case of rollover - one KSK, one ZSK per dns server and different copies of the zone. With sorting, they need only one copy of each zone. I withhold judgement on whether it's a good approach in general. I suspect it's just GSLB-lite personally. Correct -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 42.7 percent of all statistics are made up on the spot. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
On 31/05/11 09:28, Matus UHLAR - fantomas wrote: This problem could be avoided by providing the same data, but differently sorted, correct? On 31.05.11 12:27, Phil Mayers wrote: Not really. Client side sorting may take place (e.g. to comply with RFC 3484 policies in calls to getaddrinfo) and destroy any server-side sorting. by this problem I mean the DNSSEC. Providing all the data just differently sorted would cause them to be DNSSEC compliant, wouldn't it? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows 2000: 640 MB ought to be enough for anybody ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
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
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
On 01/06/11 08:11, Matus UHLAR - fantomas wrote: On 31/05/11 09:28, Matus UHLAR - fantomas wrote: This problem could be avoided by providing the same data, but differently sorted, correct? On 31.05.11 12:27, Phil Mayers wrote: Not really. Client side sorting may take place (e.g. to comply with RFC 3484 policies in calls to getaddrinfo) and destroy any server-side sorting. by this problem I mean the DNSSEC. Providing all the data just differently sorted would cause them to be DNSSEC compliant, wouldn't it? Yes, but the client would then re-sort the data, so it wouldn't achieve the original purpose. Sorting the data server side gives you essentially no control over which record the client will pick if they are calling getaddrinfo, as is likely. As Mark has already pointed out, the approach is not intrinsically DNSSEC-hostile. It's perfectly legitimate to serve different data with different, valid, signatures. This is what happens with signature regen and key rollover. In this case, it would just be a permanent case of rollover - one KSK, one ZSK per dns server and different copies of the zone. I withhold judgement on whether it's a good approach in general. I suspect it's just GSLB-lite personally. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
In message 4de43e3e.2040...@chrysler.com, Kevin Darcy writes: Normally I'd defer to your vastly greater knowledge and experience in DNSSEC, but here in the U.S. we have a saying I'm from Missouri, which is a roundabout way of expressing show me (Show Me being the unofficial slogan of the state of Missouri). Maybe it *should* work, but when it comes to nifty technical hacks, until co-existence is actually demonstrated, I still think there might be a gotcha somewhere... On 31.05.11 11:33, Mark Andrews wrote: This happens all the time whenever a signed zone content changes. You have different servers returning different answers for the same query all of which can be validated as secure. DNSSEC requires that the data and signature pass through the system as a atomic unit. DNSSEC aware servers and resolvers keep this data together. If you don't things break. DNS Race just keeps the answers permanently out of sync instead of the temporary condition that happens with normal updates. This problem could be avoided by providing the same data, but differently sorted, correct? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. (R)etry, (A)bort, (C)ancer ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
On 31/05/11 09:28, Matus UHLAR - fantomas wrote: This problem could be avoided by providing the same data, but differently sorted, correct? Not really. Client side sorting may take place (e.g. to comply with RFC 3484 policies in calls to getaddrinfo) and destroy any server-side sorting. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
On 30.05.11 05:12, Maren S. Leizaola wrote: DNS-Racing is a method of load balancing access to servers which are multi homed and provides lowest latency access to users and network resilience to ISP/routing failure. like, RRset sorting? **What does it do?* It permits a server which is connected to two ISPs to use the optimal ISP when transferring data to a user regardless of TCP/UDP protocol. When a user does a DNS look up it will select the IP address of the server to which is closest. If one of the two ISPs is down or there is a routing problem the user will only be offered the IP address of the server it has access to. It also means that traffic will have the lowest latency. DNS Racing can be done with 2 or more providers and permits to scale network bandwidth horizontally by adding more providers. In theory up to 14 different ISPs/IPs could be used to do the delivery. IT is a poor man’s replacement for BGP multihoming and IP anycast. For those that want a full explanation and an implementation guide. http://blog.hk.com/index.php?/archives/84-DNS-Racing.-Multi-ISP-load-balancing-with-failover-using-DNS..html Hey it is Free and you can implement it using BIND. So, any server will return the IP that is closer to the _server_, not to the _client_. It relies on BIND RTT-measring feature that has undergone some changes in the past and ocasionally tries the far (topologically) server to see if it's still far, in which case the client will get the worse result... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Re: DNS Racing -Multi ISP load balancing with failover using DNS.
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 message4de2c00b.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
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
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. If you really want to perform races then connect() races will reflect actual client topology not resolver topology. 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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
In message 4de42bef.3050...@chrysler.com, Kevin Darcy writes: 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. On further examination it will work w/ DNSSEC. As for availability it will decrease it as there is no way the client can do the failover for itself as it no longer has the necessary data. As for performance, your milage may vary, as they say in car commercials. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
Normally I'd defer to your vastly greater knowledge and experience in DNSSEC, but here in the U.S. we have a saying I'm from Missouri, which is a roundabout way of expressing show me (Show Me being the unofficial slogan of the state of Missouri). Maybe it *should* work, but when it comes to nifty technical hacks, until co-existence is actually demonstrated, I still think there might be a gotcha somewhere... - Kevin P.S. Don't even get me started on car commercials. I've seen a few that never even made it to the public eye :-) On 5/30/2011 8:18 PM, Mark Andrews wrote: In message4de42bef.3050...@chrysler.com, Kevin Darcy writes: 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. On further examination it will work w/ DNSSEC. As for availability it will decrease it as there is no way the client can do the failover for itself as it no longer has the necessary data. As for performance, your milage may vary, as they say in car commercials. Mark ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
In message 4de43e3e.2040...@chrysler.com, Kevin Darcy writes: Normally I'd defer to your vastly greater knowledge and experience in DNSSEC, but here in the U.S. we have a saying I'm from Missouri, which is a roundabout way of expressing show me (Show Me being the unofficial slogan of the state of Missouri). Maybe it *should* work, but when it comes to nifty technical hacks, until co-existence is actually demonstrated, I still think there might be a gotcha somewhere... This happens all the time whenever a signed zone content changes. You have different servers returning different answers for the same query all of which can be validated as secure. DNSSEC requires that the data and signature pass through the system as a atomic unit. DNSSEC aware servers and resolvers keep this data together. If you don't things break. DNS Race just keeps the answers permanently out of sync instead of the temporary condition that happens with normal updates. Mark - Kevin P.S. Don't even get me started on car commercials. I've seen a few that never even made it to the public eye :-) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
On 5/29/2011 5:12 PM, Maren S. Leizaola wrote: IT is a poor man’s 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 signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
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==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
Warren Kumari -- Please excuse typing, etc -- This was sent from a device with a tiny keyboard. On May 29, 2011, at 5:52 PM, Alan Clegg acl...@isc.org wrote: On 5/29/2011 5:12 PM, Maren S. Leizaola wrote: IT is a poor man’s replacement for BGP multihoming and IP anycast. Hey it is Free and you can implement it using BIND. And you've just broken DNSSEC. Um, how? Surely you can just sign the responses, same as any others? Maybe I'm missing something obvious, but this just looks like normal DNS LB... W AlanC ___ 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
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
In message 2c591af8-860d-45a5-9f3a-3603f3733...@kumari.net, Warren Kumari writes: Um, how? Surely you can just sign the responses, same as any others? Maybe I'm missing something obvious, but this just looks like normal DNS LB... W It depends on who is doing the modification. From the description it looks like this would be being done in the recursive nameserver as it has view into site reachability which won't work with DNSSEC. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Racing -Multi ISP load balancing with failover using DNS.
Warren Kumari -- Please excuse typing, etc -- This was sent from a device with a tiny keyboard. On May 29, 2011, at 9:32 PM, Mark Andrews ma...@isc.org wrote: In message 2c591af8-860d-45a5-9f3a-3603f3733...@kumari.net, Warren Kumari writes: Um, how? Surely you can just sign the responses, same as any others? Maybe I'm missing something obvious, but this just looks like normal DNS LB... W It depends on who is doing the modification. From the description it looks like this would be being done in the recursive nameserver as it has view into site reachability which won't work with DNSSEC. Oh, well, yeah, there you go then... Thanks, W Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
