invalidate cache on cache-only resolver?

[Frank Cusack]

In message <29904.934225620 at kludge.mpn.cp.philips.com>, 
Jim Reid writes:
> >>>>> "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.

Generating and pushing the configs is no problem.

> 
>     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?

Because I don't WANT them to slave the zones.

> 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 justification is exactly why I want cache invalidations. I want to
keep the recursive servers as stable as possible. The less the config
gets touched, the less chance there will be a problem (let's ignore
possibly unstable patches to BIND as an issue. ;)) And note that the
config does change at least daily (I try very hard to keep it at daily
or longer, but sometimes this doesn't work out. :\).

In either config (cache-only or slave) there is no sysadmin time involved,
configs are all generated automatically, so that's not the issue.

I don't want to do the zone xfers when most of the data isn't even
being queried, and much doesn't get queried between updates.

What's the difference, really, between "invalidating" a zone you are
slave for vs. invalidating a zone you have cached? Killing the cache
for a particular zone is actually quite easy.

> 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?

We have a hierarchy of name servers, ultimately, yes there is a single
point of adminstration. It scales at least to tens of thousands of
zones, I haven't investigated going to hundreds of thousands +.

For sites that master their own zones, we simply slave them to our
central point, and the view from there down is the same. Actually,
the design can support multiple top-level servers/admin-points, but
at the number of zones and number of admin staff currently, it's not
implemented that way. As we get to hundreds of thousands, we may have
to do that. But I digress... As long as the remote site sends us a
NOTIFY, all our servers will update "immediately" since everything is
a slave. With "cache-invalidate", that will still happen when the
recursive servers are cache-only.

We don't currently support Dynamic DNS, so I'm not worried about that,
but for that case we would be at least as up to date as the rest of
the world. The same type of code could also be added for UPDATE as
I want to do for NOTIFY (albeit a little more tricky). If we can
segregate dynamic RRs into their own (sub-)zones, then those zones can
be slaved if the TTL doesn't reflect the dynamic nature of those RRs.

So... I will concede that cache-invalidate has a limited usefulness,
restricted to certain configurations, but within those parameters
it can let you run cache-only instead of slaving lots of zones.
This CAN BE an advantage.

Still disagree?

~f