Return two locations or low TTL [was: DNS caches that support partitioning ?]

Mon Aug 20 13:01:15 UTC 2012

On Aug 20, 2012, at 08:25 , Tony Finch <dot at dotat.at> wrote:
> Patrick W. Gilmore <patrick at ianai.net> wrote:
>> On Aug 19, 2012, at 17:37 , Mark Andrews <marka at 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