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

[Robert Edmonds]

Paul Wouters wrote:
> 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.

yes, old smurf attacks etc result in multiple packets being sent, but
the DNS can also be used to increase the amount of bandwidth a DDoS can
wield.

    Recently the hosting company ISPrime became the victim of a
    DNS-based DDoS attack using spoofed source addresses. Some are
    calling it an amplification attack because the query ". IN NS" is
    quite small (47 octets) while an upward referral response is a bit
    larger (256 octets).

    https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful

spoofing a 47 octet packet that sends a 256 octet packet towards your
victim is obviously an amplification.

RFC 5358 also uses the word "amplification" to describe scenarios where
1 query results in 1 response, but the response is larger than the
query.  5358 is primarily concerned with open recursive nameservers but
obviously many of the concerns are similar for openly snoopable
nameservers wrt frequently cached records.  hopefully the population of
closed recursive but openly snoopable nameservers is much smaller than
the population of open recursive nameservers.

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

yes, in a world without universal deployment of BCP38, they are.

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

query being refused := query to which a REFUSED answer is sent.

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

ok, these are all(?) corner cases which involve fragmenting the DNS
namespace?  how many of these cannot be accomplished with dnscache's
'servers' directory?  (leaving alone implementation details like how
many files may comfortably fit in a directory.)

    dnscache reads a list of dotted-decimal root server IP addresses,
    one address per line, from servers/@. It also scans the servers
    directory for server IP addresses for other domains. If there are
    addresses listed in servers/moon.af.mil, for example, then dnscache
    will send queries for anything.moon.af.mil to those addresses, and
    will not cache records for anything.moon.af.mil from outside servers
    such as the root servers.

and how many of your scenarios require cache snooping, not just rd==0
queries?

btw, what is an "LEA override"?  law enforcement agency override?

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

a lot of VPN scenarios are broken, sometimes the VPN vendors cannot even
get the crypto right.

-- 
Robert Edmonds
edmonds at debian.org