$TTL directive vs. negative cache - 8.2.1

Jim Reid jim at mpn.cp.philips.com
Tue Jun 22 10:19:41 UTC 1999


>>>>> "Auteria" == Auteria Wally Winzer <wally.winzer at ChampUSA.COM> writes:

    Auteria> I administer servers that do adserving for a multitude of
    Auteria> companies all over the US and Canada.  Currently 8.2 is
    Auteria> in production and seems to work fine.  My question is the
    Auteria> following:

    Auteria> The servers get hit with requests virtually every second
    Auteria> or less.  On an average we can get during heavy peaks
    Auteria> over 500 - 1000 hits per second, which is distributed
    Auteria> over 20 servers.  Our image farms will get hit with the
    Auteria> same amount of hits, an additional 10 servers.  Right now
    Auteria> I have both the $TTL and the SOA TTL set for 86400 (both
    Auteria> positive and negative).  In your opinion, what should the
    Auteria> $TTL represent, since we get hit so often?  I feel
    Auteria> leaving the negative cache as is, for it seems to hold
    Auteria> up, but I'm concerned about the overall $TTL.  I was
    Auteria> thinking setting it to 3hr, but that seems to be just a
    Auteria> bit too short.

The time to live values should not be directly influenced by how often
a name is looked up. The questions to ask yourself are
[1] "How long do I want other name servers to cache information about
my web servers?" (Or whatever).
[2] "How long will I tolerate web browsers going to the wrong server
because of stale data in the cache of some name server on the other
side of the world?"

The answers probably depend on the contracts with your customers, how
often you move servers and web pages around, what change windows you
have, etc, etc.

I personally think that the time to live (positive and negative)
values shouldn't be as high as a day because that'll mean it can take up
to 1 day before the rest of the world knows that www.fubar.com has
been moved. Perhaps TTLs around 1-3 hours would be more appropriate?



More information about the bind-users mailing list