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

[Paul Wouters]

On Sun, 15 Feb 2009, Robert Edmonds wrote:

> wrong. if a recursive nameserver is open to cache snooping, it is an
> amplification vector.  if it drops or responds to foreign queries with
> REFUSED, it is not an amplification vector.

I don't see a big difference between a cache reply (1 packet) and a
REFUSED reply (1 packet). The amplification attacks generally work in
having one packet cause a multitude of packets being sent. If you're 
spoofing one packet to get one reply packet, you might as well send
your packet directly to the victim. This situation does not amplify
because you're only getting an already cached answer.

> wrong. if an authoritative nameserver nameserver responds to queries it
> is not authoritative for and responds with a referral, it is an
> amplification vector.

Then all the root nameervers are amplification vectors.

> responding with REFUSED to unsolicited queries is not an amplification
> vector because a REFUSED answer is exactly the same length as the query
> being refused. 


That depends on what you mean with "query being refused". I don't use
the term refuse, but reject or drop, to avoid confusion.


> IMO, unbound should not have convergently evolved towards BIND and its
> separate allow-query-cache and allow-recursion ACLs.  it should have
> dropped all rd==0 queries from the beginning, because an rd==0 query
> indicates a request for authoritative nameservice.

That's in an ideal world. Now add running internal only domains you need
to configure for internal recursors (and vpn users) and LEA overrides,
and blocking/redirecting domains for administrative reasons....

> you can easily achieve this by having one recursive nameserver bound to
> an RFC 1918 address which only serves your RFC 1918 clients and knows
> about your fake DNS data, and another recursive nameserver bound to a
> non-RFC 1918 address which only serves your non-RFC 1918 clients and
> does not know about your fake DNS data.  that way you avoid mixing fake
> and real DNS data in the same cache.

Nope, that breaks a lot of VPN scenarios.

Paul