[Unbound-users] allowing cache queries but not doing recursion for "foreign" networks
Greg A. Woods; Planix, Inc.
woods at planix.ca
Mon Feb 16 21:33:50 CET 2009
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
>> 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
>> 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
>> 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
> wrong. if an authoritative nameserver nameserver responds to queries
> is not authoritative for and responds with a referral, it is an
> amplification vector. if it responds to queries it is not
> 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
> 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
> 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...
Size: 186 bytes
Desc: This is a digitally signed message part
More information about the Unbound-users