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

["Patrick W. Gilmore" <patrick () ianai net>]

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-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