Cache not expiring...

[Jim Reid]

>>>>> "Stephen" == Stephen Amadei <amadei at dandy.net> writes:

    >> > While I've never gotten a complaint from my users, I have a
    >> reseller who keeps moving hosts and ips on a separate network
    >> from mine.  Then  since his customers use my dial-up and DNS,
    >> they are not seeing the DNS changes right away.  In fact,
    >> sometimes it takes days... usually until I rehup my named for
    >> a DNS change on my network.  His complain is that  our DNS
    >> returns old cached data for days after other DNS server's
    >> (Uu.net, > Digex, MSN, etc.) serve up the fresh data.
    >> 
    >> It sounds like you are secondarying the zone if HUP fixes
    >> things.  HUPing a nameserver does not clear the cache.  It does
    >> however cause a refresh check to occur.

    Stephen> Oops... Sorry.  Actually a rehup isn't what I meant.  I
    Stephen> need a kill and restart for the cache to clear.  I have
    Stephen> no connection to the zones... I am not primary or
    Stephen> secondary.

In that case the problem is probably not yours. The source of the
trouble is most likely to be the TTL on the names that your server is
looking up. [Too bad you didn't tell us what they were.] If the owner
of the zone(s) containing those names is giving them too long TTLs,
that's their problem, not yours. He or she is telling the world's name
servers to cache details of some resource records for X seconds. And
then after some fraction of X, they change those resource records and
ignore the fact the old names are cached all over the place. This
is not very clever. What's probably happening is that your name
servers are more likely to lookup and therefore cache those names than
the other name servers you quote. So your name servers get lumbered
with those stale cache entries more frequently than anyone else's.

I think you should get this reseller to select more appropriate TTL
values for these constantly changing resource records. It might also
be an idea to find out why they change so frequently. This generally
suggests poor co-odination and organisation, especially if the stuff
that keeps changing are "important" things like web and mail servers.
These shouldn't be moving around much. And when they do, the changes
to the DNS should be planned properly, like dropping the TTL of those
records to say 5-10 minutes well in advance of the change. That way
stale data won't persist in the DNS for long.

    >> But as always this is supposition as you have failed to tell us
    >> the names of the zones and servers involved.

    Stephen> Actually, the guy having problems refuses to tell me what
    Stephen> domains are having problems.  The server serving up stale
    Stephen> cache data is my primary, ns.dandy.net.

    >> > My bind is 8.2.2-P5 and I don't have the option
    >> "cleaning-interval" set in my config.

This has no bearing on how long names are cached. Once a record's TTL
is 0, it is considered to be absent even if it's still present in the
cache. If the name is requested again, the name server has to look it
up again: it doesn't hand out the now stale entry in its cache. The
cleaning interval determines how often the name server does garbage
collection (sort of). At each cleaning-interval, the server goes
through the cache and frees up any memory associated with resource
records that have expired since the last cleaning interval. The
default cleaning-interval of 1 hours is good enough for most name
servers and I think there's no point in you changing it. A different
value won't make any difference to the contents your server's cache.