Maintained by: NLnet Labs

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

Ondřej Surý
Sun Feb 15 13:18:43 CET 2009


On Sun, Feb 15, 2009 at 3:49 AM, Greg A. Woods; Planix, Inc.
<woods at planix.ca> wrote:
>
> 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.

Use unbound-control dump_cache for debugging.

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

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

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.

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.

Ondrej.
-- 
Ondřej Surý <ondrej at sury.org>