[155610] in North American Network Operators' Group
Return two locations or low TTL [was: DNS caches that support
daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Mon Aug 20 06:24:56 2012
From: "Patrick W. Gilmore" <patrick@ianai.net>
In-Reply-To: <20120819213732.6FCD223C36E4@drugs.dv.isc.org>
Date: Mon, 20 Aug 2012 06:24:20 -0400
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
While I hesitate to argue DNS with Mark, I feel this needs a response.
On Aug 19, 2012, at 17:37 , Mark Andrews <marka@isc.org> wrote:
> In message <DDF607B5-415B-41E8-9222-EB549D3DBB0C@semihuman.com>, Chris =
Woodfield writes:
>> What Patrick said. For large sites that offer services in multiple =
data =3D
>> centers on multiple IPs that can individually fail at any time, 300 =3D=
>> seconds is actually a bit on the long end.
> 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. But I do not think returning multiple A records for multiple =
datacenters is as useful as lowering the TTL. Just a few reasons off =
the top of my head:
* How do you guarantee the user goes to the closer location if you =
respond
with multiple addresses? Forcing users to go to farther away =
datacenters
half the time is likely a poor trade-off for the occasional TTL =
problem
when a DC goes down.
* How many applications are even aware multiple addresses were returned?
* How do you guarantee sub-second failover when most apps will wait =
longer=20
than one second to see if an address responds?
Etc.
And that doesn't begin to touch thing such as cache efficiency that =
affect companies like Google, CDNs, etc.
> As for the original problem. LRU replacement will keep "hot" items in
> the cache unless it is seriously undersized.
This was covered well by others.
--=20
TTFN,
patrick