[155610] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

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



home help back first fref pref prev next nref lref last post