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 = centers on multiple IPs that can individually fail at any time, 300 = 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 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. -- TTFN, patrick