Re: [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

  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

succeed at this attack

can also be used as amplifiers; however, the amplification potential nobody outside of the networks "trusted" by the caching nameserver can

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

for with REFUSED, it is not an amplification vector.

amplification vector. if it responds to queries it is not authoritative

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

and real DNS data in the same cache.

does not know about your fake DNS data. that way you avoid mixing fake

--
                                        Greg A. Woods; Planix, Inc.
                                        <wo...@planix.ca>

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

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
Unbound-users mailing list
Unbound-users@unbound.net
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users