[Unbound-users] allowing cache queries but not doing recursion for "foreign" networks
Greg A. Woods; Planix, Inc.
woods at planix.ca
Sun Feb 15 02:49:36 UTC 2009
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.
<woods at planix.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20090214/749baeba/attachment.bin>
More information about the Unbound-users
mailing list