On 14-Feb-2009, at 3:59 PM, I 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.

A first step towards what I really would like best I think would be the ability to control whether or not recursion is allowed for queries coming from specified addresses while still allowing answers to be given from the cache. Such answers would have the recursion allowed bit turned off too of course.

That way I could configure my cache servers such that recursion would only be done for my own known networks, and I would still allow any other site to query the cache for debugging purposes.

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.

I.e. anyone can see anything in my cache except my private data, but they 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.

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.

Does this all make sense to anyone? Does anyone else want such functionality too?

--
                                        Greg A. Woods; Planix, Inc.
                                        <[email protected]>

Attachment: PGP.sig
Description: This is a digitally signed message part

_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users

Reply via email to