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

[Robert Edmonds]

this thread is now completely off-topic for unbound-users; it is more
suited for the dns-operations mailing list.

Greg A. Woods; Planix, Inc. wrote:
> On 15-Feb-2009, at 6:23 PM, 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.
>
> Indeed, but _any_ and _all_ authoritative nameservers are similarly  
> usable as bandwidth amplification engines.

an authoritative nameserver that only returns larger responses for zones
it is authoritative for is not "similarly usable" as an amplifier as an
authoritative nameserver that amplifies all queries.  obviously, the
former requires distributing a lot of data (e.g. what you might find in
a TLD zone) to each abusive host which is to emit spoofed queries, the
latter does not.

> That's the whole point of the text I quoted from the RFC.

you misunderstand the RFC, then.
    
    "DNS authoritative servers that do not provide recursion to clients
    can also be used as amplifiers;"

can != can always

properly configured authoritative servers require much more effort to
take advantage of.

    "however, the amplification potential is greatly reduced when
    authoritative servers are used."

the document speaks in terms of 80:1 amplification ratios, e.g. when
adding EDNS0 and gigantic records to the mix.  the isprime DDoS with its
mere 5:1 ratio was still smashingly successful.

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

no, the former is easier.  attackers are using botnets, not individual
hosts.  the former can be done by distributing a program to each bot;
the latter requires distributing a program and a large data set to each
bot.

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

yes, and?  an attacker with a collection of bots on non-BCP38 networks
has virtually no risk.

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

the IP source address is near the start of the packet, there is no deep
packet inspection involved.  BCP38 must be deployed on routers, not
firewalls; firewalls don't scale.

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

the difference being that an authoritative nameserver that amplifies
only in-zone queries is (far) less bad than an authoritative nameserver
that amplifies indiscriminately.

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

ah, i mean to say, avoid mixing fake DNS data into a cache that can be
queried on a non-RFC 1918 network in this last sentence here.  RFC 1918
networks that are NAT'd will necessarily need to access real DNS data.

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

by no means will "every cache [...] necessarily contain both private and
public records".

-- 
Robert Edmonds
edmonds at debian.org