Cached Information

Kevin Darcy kcd at daimlerchrysler.com
Fri Dec 3 18:28:30 UTC 2004


You got it.

                                        - Kevin

David wrote:

>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 daimlerchrysler.com> wrote in message news:<com4hq$dv$1 at sf1.isc.org>...
>  
>
>>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