invalidate cache on cache-only resolver?

[Frank Cusack]

In message <29798.934219387 at kludge.mpn.cp.philips.com>, 
Jim Reid writes:
> >>>>> "Frank" == Frank Cusack <fcusack at iconnet.net> writes:
> 
>     Frank> Is it possible to invalidate the cache for a zone on a cache-only
>     Frank> resolver?
> 
> I presume you mean "name server", not "resolver". If so the answer is
> yes: just restart the name server. That invalidates the cache for
> sure. :-)

Yep, I meant name server. :)

> 
>     Frank> On a resolver that is master or slave for a zone, I can run
>     Frank> `ndc reload <zone>'. Anything like this for cache-only?
> 
> See above.
> 
>     Frank> Or, how about letting cache-only servers listen to NOTIFY messages
 and
>     Frank> invalidate their cache based on receiving such a message? Yes, the
re
>     Frank> are security (performance) implications, but something similar to
>     Frank> how NOTIFY works with slaves could happen:
> 
>     Frank> -- master sends NOTIFY to cache-only
>     Frank> -- cache-only sends notify-response to master
>     Frank> -- cache-only requests soa record and checks serial
>     Frank> -- if serial is newer, cache-only invalidates cache for that zone
> 
> And how do you propose to find all the name servers in the world that
> might have cached or slaved old data for your zone(s)?

I don't. I wasn't clear enough, read on.

> This is
> non-trivial. And what if my name server doesn't support your proposed
> mechanism - there are bazillions of legacy name servers out there that
> don't even support NOTIFY (sigh) - or if I don't want Random Users and
> name servers playing with my name server's cache? Think also of the
> fun and games on a name server at a very big ISP that could be getting
> hundreds of your proposed notify-cum-invalidate-my-zone-data messages
> from all over the place every second.
> 
> For a local environment, set up stealth name servers. These slave your
> local zones, but aren't listed in the NS records. You can use the
> also-notify clause in named.conf to see that these servers get NOTIFY
> messages whenever your zones get updated. (=> fast convergence on all
> your servers for the new zone data). This is the best you can do.
> Hoping/wanting the ability to reconfigure someone else's name server
> on the fly is more than a little unrealistic.

Yep, we have that.

Without revealing too much of our infrastructure, :)
all our "recursive name servers", those that are listed in ppl's
/etc/resolv.conf, are slaves for all the zones we manage. This is so that
they are as up-to-date as possible when data in a zone changes. YES, it's
not necessarily the data "the world" sees, due to TTL issues, but I don't
care about that -- LOCALLY, I want the new data as soon as it changes.
Since we add (and sometimes remove) lots of zones on a daily basis, this
means frequent updates to the config on these recursive name servers.

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

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

So, on my authoritative servers, I have a config that includes these
recursive name servers in the also-notify list; and on my recursive
name servers, I have an "allow-cache-invalidate" global option (it has to
be global, otherwise I still have to constantly update the config!)
that takes an address_match_list as an argument. When my recursive
server sees a NOTIFY for a zone in the cache, it checks the source,
and if it comes from an IP in the allow-cache-invalidate list, it
possibly does some other checks and then clears/invalidates that zone.

--> This is very useful in my environment. I am proposing that it might
    be generally useful to many others also.

I already have patched 8.2.1 to do this, except for the ACL part. I 
expect to have that ready today, and submit a patch at the end of the 
week (giving me time to test it a bit, and to do the docos). Oh, I
also need to patch ndc/named to support an "invalidate" command. THAT,
at least, has GOT to be useful, even without the NOTIFY part.

So, where do I submit a patch? I tried subscribing to bind-workers,
and got a "sumitted to the owner" note. I think this patch is at
least worthy enough to be included in the contrib dir. :)

~f