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
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
