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