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