Paul Wouters wrote:
>From the man page:
yes, the fact that unbound can serve local data does complicate things.
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.
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.
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.
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....
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.
Paul
No, it makes some things a LOT less complicated 
Paul
Paul Wouters 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.
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 attackwrong. 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).
No, that's not what I said. I simply stated my views and I am looking for simple ways that fit into the current scheme so that I can implement my ideas for myself. Nowhere have I ever said that everyone else should be forced to do what I think should be done, and indeed if you look at the concrete suggestions I've made then you'll see that they do not prevent anyone else from continuing to do what they think is right.
I for one am very thankful that it can and does, or else I would most likely be forced to continue to use BIND for many types of common configurations.
In fact in a slightly related issue I wish it would also already either listen to NOTIFY messages for stub zones too so that could automatically flush its own cache of such data, or else never cache responses from stub servers in the first place.
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:
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".