Cached Information

David yeodavid at
Thu Dec 2 18:00:37 UTC 2004

We wanted to disallow recursion to address security concerns, but then
realized it would also relieve at least some of the unnecessary work
load on our DNS.

So if I understand you correctly, I can set up one view with recursion
on (for our internal users) which would allow them access to any
cached data, and also set up another view for external users with
recursion turned off which would disallow access to any cached data
since there would be no cached data in this different view that is
acting like a virtual "nameserver" of itself.

Please correct me if I'm totally off base here.

Thanks a lot for your help.

Kevin Darcy <kcd at> wrote in message news:<com4hq$dv$1 at>...
> David wrote:
> >Using views, is there a way to allow access to cached information in
> >one view and disallowing access to the cache in another view?  Can I
> >just set "fetch-glue no" in the disallowed view?
> >
> The cache isn't shared between views anyway; in terms of data storage, 
> each view should be conceptualized as being actually a different 
> nameserver. So, with that conceptualization in place, your question 
> becomes "can I have a nameserver that doesn't allow clients to see the 
> cache?", or, basically "can I have a nameserver that doesn't cache at 
> all?" The simple answer is "no", at least with BIND. What you _can_ do, 
> however, and many people do, is a) limit what gets into the cache in the 
> first place by limiting recursion (e.g. as an exterme case, with no 
> recursion at all, there is nothing in the cache, only authoritative 
> data), and/or b) limit query access by zone (e.g. have a global "deny" 
> which is then selectively overridden). I suppose you could also tune 
> your BIND instance to clean out its cache very aggressively, but that 
> would not be a 100% solution, and whether it is appropriate or not would 
> depend on whether your question was motivated more by security or by 
> performance/capacity concerns.
>                                                          - Kevin

More information about the bind-users mailing list