On Aug 20, 2012, at 08:25 , Tony Finch <dot@dotat.at> wrote:
Patrick W. Gilmore <patrick@ianai.net> wrote:
On Aug 19, 2012, at 17:37 , Mark Andrews <marka@isc.org> wrote:
Which is why the DNS supports multiple address records. Clients don't have to wait a minutes to fallover to a second address. One doesn't have to point all the addresses returned to the closest data center. One can get sub-second fail over in clients as HE code shows.
I'm afraid I am not familiar with "HE code", so perhaps I am being silly here.
Mark is referring to "happy eyeballs": http://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-ser...
Oh. Yep, I was being silly, thinking only of v4. (I'm sleep deprived of late - yes, more than usual.) Unfortunately, whether we like it or not, 99+% of traffic on the 'Net is still v4, as were the examples given. Even with HE, though, there is no (not yet a?) way in DNS to signal "use this A record first, then that one if the first doesn't work / is slow / whatever". Any chance of getting MX-style weights for A records? :) Even then, it would not solve the original problem of low TTLs. Just as a simple example, when traffic ramps quickly, a provider may want to move some users off a node to balance traffic. With a long TTL, that's not really possible baring really bad hacks like DoS'ing some users to hope they use the next A record, which would lead to massive complaints. We could go on, but hopefully the point is clear that low TTLs are useful in many instances despite the ability to return multiple A records. -- TTFN, patrick