[Unbound-users] allowing cache queries but not doing recursion for "foreign" networks

[Paul Wouters]

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
>>> possible.
>
> 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
onto others.

> 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.

Paul