[Unbound-users] allowing cache queries but not doing recursion for "foreign" networks
paul at xelerance.com
Sun Feb 15 18:29:32 CET 2009
On Sun, 15 Feb 2009, Ondřej Surý wrote:
>>> I prefer to leave the public data in the cache publicly accessible even
>>> if that also gives the bad guys a bit more of an edge (debugging is still
>>> more important to me). However without per-zone ACLs that won't be
> Use unbound-control dump_cache for debugging.
You can also use an ACL with "allow_snoop"
>> Perhaps the next step would be to never return any records for any domain
>> names containing RFC 1918 data (A RRs or PTR RRs or any other RRs associated
>> with RRs containing A or PTR RRs referring to RFC 1918 data) whenever
>> recursion is not allowed for the query. Some private data might still leak
>> with such a rule, but never enough to give away internal network topology.
>> Alternately maybe all RRs returned in answer to queries sent to private
>> addresses should be flagged to remain private.
> Sorry, but your implication RFC1918 => internal network and it's reverse doesn't
> really work, and should not be hardcoded anywhere.
And there is a mechanism to tune this already too, using "private_domain"
with "private_address" options. No need for hardcoding policy anywhere.
>> I.e. anyone can see anything in my cache except my private data
You want them to not "use" the cache, but allow them to "debug" the cache.
To me, "debug" is a higher priviledge then "using".
>> wouldn't be able to force me to try to load anything into my cache. Only
>> clients sending queries from locally "trusted" networks would get full
>> recursion and caching services.
> As Aaron and Robert said before me, this is really bad idea. Also when your
> cache is open to anyone, anybody could see TTLs of cached records and adjust
> attack window with precision of one second.
>> Personally I also think this should be the only way any DNS cache should
>> work -- i.e. it should be the only mode of operation. Public (DNS) data
>> should remain public no matter where it is stored.
There is no reason for enforcing your policy or ideas in a hardcoded way
> Hope not.
>> Does this all make sense to anyone?
> Sorry, but no.
>> Does anyone else want such functionality too?
> No, and I am strongly against adding this type of functionality anywhere.
I second that. And applaud unbound's team for adding the options that
allows everyone to decide their own policy in a very fine grained matter.
More information about the Unbound-users