invalidate cache on cache-only resolver?

[Jim Reid]

>>>>> "Frank" == Frank Cusack <fcusack at iconnet.net> writes:

    Frank> Since we add (and sometimes remove) lots of zones on a
    Frank> daily basis, this means frequent updates to the config on
    Frank> these recursive name servers.

Fine, but what's the problem? Generating new nameserver config files,
distributing them and activating them shouldn't be a Big Deal. If it
is, something needs to be better organised.

    Frank> I want to avoid the config updates and still keep the data
    Frank> as up-to-date as possible. By running a cache-only name
    Frank> server, I can avoid reloads, and avoid frequent zone
    Frank> transfers, and keep the config on those name servers quite
    Frank> stable. But I can't keep the data up-to-the-minute
    Frank> without a way to invalidate parts of the cache.

I must be missing something. If your recursive servers already slave
the valid zones, why do you feel you have to tamper with their cache?
Just give 'em a new named.conf and reload or restart. The old zones go
away and the new ones get added. And since these servers are
authoritative for the new zones, anything they had previously cached
(or slaved for a now dead old zone) goes away. [It works for us.]

    Frank> Note that we have 5 sites now, 7 by the end of the year,
    Frank> and 13 by the end of next year. So this is lots of
    Frank> "recursive name servers" that do lots of zone xfers,
    Frank> really, unnecessarily. Keeping the data up-to-the- minute
    Frank> fresh on these name servers has become an expectation.

I appreciate your concerns - we have the same situation here - but I
just don't see the need to play around with caches. We just made our
resolver servers authoritative for everything on the Intranet and live
with the extra zone transfers and SOA queries. The cost of that extra
traffic is much less than the sysadmin time of maintaining lots of
slightly different named.conf files and figuring out which server(s)
are authoritative for what or trying to nail down cache
intrigues. This is a Big Deal when the things doing DNS lookups are
managing production lines and business-critical tasks like ordering
components or paying wages. :-) Admittedly zones don't get added or
removed all that often here, but even so...

Your strategy might work for a small number of centrally-managed name
servers, but I think it has serious scalability and management
problems. For instance what happens if some site sets up their own
name servers which you can't control? Or how about the W2K fans who
will want to do Dynamic DNS to their local name server(s) to make them
more WINS-like?