On Aug 20, 2012, at 08:25 , Tony Finch <d...@dotat.at> wrote: > Patrick W. Gilmore <patr...@ianai.net> wrote: >> On Aug 19, 2012, at 17:37 , Mark Andrews <ma...@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-server-over-tcp
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
