invalidate cache on cache-only resolver?

Frank Cusack fcusack at iconnet.net
Thu Aug 12 02:24:04 UTC 1999


In message <758.934280523 at kludge.mpn.cp.philips.com>, 
Jim Reid writes:
> >>>>> "Frank" == Frank Cusack <fcusack at iconnet.net> writes:
> 
>     Frank> Your justification is exactly why I want cache invalidations.
>     Frank> I want to keep the recursive servers as stable as possible.
>     Frank> The less the config gets touched, the less chance there will
>     Frank> be a problem (let's ignore possibly unstable patches to BIND
>     Frank> as an issue. ;)) And note that the config does change at least
>     Frank> daily (I try very hard to keep it at daily
>     Frank> or longer, but sometimes this doesn't work out. :\).
> 
> Personal opinion: the more you play with name server's caches, the
> higher the chances of screwing up. And what about the servers that
> forward queries to the servers where you're tampering with their
> caches? Aside from the scaling, security and administrative problems,
> you'll be opening a Pandora's box. Next thing, you could be wanting to

I don't agree about the "don't add code, it might screw things up".
The data structures are well laid out and easy to understand (it only
took an hour or so to figure the code out AND write the patch, and
yes, it is thorough).

Scaling: no more difficult than "stealth" slaves.
Admin:   no more difficult than any other config issues.

Security: ouch. That is why I've decided not to actually implement it,
(ie, deploy it; I've already "implemented" it). Without tsig's or IPSec,
it's quite difficult to assure that a NOTIFY into the cache is legit
so an attacker can have lots of fun.

> add or remove individual RRs. And then you might end up using this
> patch-the-cache-on-the-fly mechanism instead of making "real" changes
> via Dynamic DNS or updating zone files.

ooohhh, cool, version 2! :)

> 
>     Frank> What's the difference, really, between "invalidating" a zone
>     Frank> you are slave for vs. invalidating a zone you have cached?
> 
> Authoritative answers.

Yes, that's one of the parameters I allude to (quoted below).

>     Frank> So... I will concede that cache-invalidate has a limited
>     Frank> usefulness, restricted to certain configurations, but within
>     Frank> those parameters it can let you run cache-only instead of
>     Frank> slaving lots of zones. This CAN BE an advantage.
> 
>     Frank> Still disagree?
> 
> Yes. We'll have to agree to differ. You say you already auto-generate
> and distribute named.conf files. So you already have a way of updating
> the caches simply by adding and removing zone statements. That IMHO is
> a lot less work and a lot less dangerous than munging name server
> caches on the fly. And all that's just to save a few zone transfers?

It wasn't just to save zone xfers, there are probs with named.conf
generation scripts that I don't want to fix. :)

Anyway, you've beat me into submission.

~f





More information about the bind-users mailing list