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

[Greg A. Woods; Planix, Inc.]

On 15-Feb-2009, at 6:23 PM, Robert Edmonds wrote:

> Greg A. Woods; Planix, Inc. wrote:
>> RFC 5358 describes an attack which effectively requires the  
>> nameserver
>> to perform a recursive lookup for the queries that are part of the
>> attack.  To quote the RFC:
>>
>> 	"DNS authoritative servers that do not provide recursion to clients
>>   can also be used as amplifiers; however, the amplification  
>> potential
>>   is greatly reduced when authoritative servers are used."
>>
>> 	"This document's recommendations are
>>   concerned with recursive nameservers only."
>>
>> I.e. if recursion is _not_ performed for any "foreign" queries then
>> nobody outside of the networks "trusted" by the caching nameserver  
>> can
>> succeed at this attack
>
> 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.

Indeed, but _any_ and _all_ authoritative nameservers are similarly  
usable as bandwidth amplification engines.  That's the whole point of  
the text I quoted from the RFC.

The trade-off is that attackers either have to do additional work to  
discover caches they can use for snooping or recursion, OR they must  
discover useful queries that will trigger larger responses from  
authoritative nameservers.  With the current concentration of  
authoritative DNS services to far fewer NS hosts than domains, the  
latter is probably much easier, though I can't claim to have any  
proof.  What is important though is to keep in mind that an attacker  
will also be doing what amounts to a threat/risk analysis for their  
own purposes.  Sending what appear to be legitimate queries to  
legitimate authoritative nameservers will most certainly pose a lower  
risk to the attacker.

What's evident to me is that firewalls really do need to be looking  
deeper into the packets and flows they handle in order to better  
prevent address spoofing from behind their borders, and more people  
really must begin using better anti-spoofing filters.  I.e.  
amplification attacks using DNS are not the fault of the nameservers,  
but rather of the networks hosting the attackers and/or their  
proxies.  Fix the right problem and you solve it once and for all --  
fix the wrong problem and you simply redirect the issue to somewhere  
else.


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

Every authoritative nameserver will respond to some queries with more  
bytes in the answer than were in the query-- that's its whole reason  
for being in the first place.

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


I don't think you understand the operational issues.  The caching  
resolver used by trusted clients which must have access to the private  
RFC 1918 related records will also require access to public DNS  
records and so every cache will necessarily contain both private and  
public records.  At least that's true of most real-life configurations  
(and indeed most I can ever even imagine).

-- 
					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/20090216/5e5aa48d/attachment.bin>