Hello,
is it possible to use some trick to configure Unbound to refuse ANY queries?
It would be helpful for (intentionally) open recursors before
https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any is implemented.
Thank you for your time.
Hello,
is it possible to use some trick to configure Unbound to refuse ANY queries?
It would be helpful for (intentionally) open recursors before
https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any is implemented.
Thank you for your time.
Hi Petr,
Unbound already implements that draft. Method 4.1, select one (actually
a couple) RRsets. It picks them from cache if they are available there
(eg. A record or SOA record) and if no records are in cache, it'll make
a query.
There may be tricks with local-zones or local-data or python scripting
or views.
Best regards, Wouter
Hi Petr,
Unbound already implements that draft. Method 4.1, select one (actually
a couple) RRsets. It picks them from cache if they are available there
(eg. A record or SOA record) and if no records are in cache, it'll make
a query.
Oh, nice! Is it released already?
I'm not able to find string "refuse-any" either in
http://unbound.nlnetlabs.nl/svn/trunk/doc/Changelog
or in SVN log.
Curious question: How are these RRsets selected?
For example domain cpsc.gov. which is often used for attacks using our
resolver can produce rather large answers for QTYPE, so returning more
than one QTYPE might not cut the size down as we would wish.
Petr Špaček @ CZ.NIC
Hi Petr,
It is enabled by default, and implemented in Unbound 1.5.4. These are
the changelog entries from the download page:
Unbound 1.5.6
- ANY responses include DNAME records if present, as per Evan Hunt's
remark in dnsop.
Unbound 1.5.4 (9 july 2015)
- Synthesize ANY responses from cache. Does not search exhaustively, but
MX,A,AAAA,SOA,NS also CNAME.
Best regards, Wouter
W.C.A. Wijngaards via Unbound-users:
It is enabled by default, and implemented in Unbound 1.5.4. These are
the changelog entries from the download page:
found: ~unbound-source/service/cache/dns.c, search for 'Fill TYPE_ANY response'
As Petr mentioned, the responses aren't necessary really 'small'
Any chance, someone implement "4.2. Synthesised HINFO RRset"
and let the operator choose 4.1 or 4.2?
Andreas
BTW it is possible to play nasty tricks and reply with an 'actual' ANY:
local-zone: "example.com." typetransparent
local-data: "example.com. TYPE255 \# 1 00"
I hope such answer will break the botnet we are fighting against!
Have a nice weekend.
HINFO synthesis is only suitable for master servers that dynamically sign
answers.
Tony.
good point!
but 4.4 suggest also truncation and force tcp, right?
could a server send an answer without (or as less as possible data) and set the TC bit?
Andreas
Hi,
it is rather off-topic but it could help you: we use dnsdist DNS balancer to
fight with various types of attacks including excessive amount of ANY queries.
You can set up a rule counting queries per IP within a certain amount of time
and react then. We have Unbound backends. 50kqps is a piece of cake.
BR
Aleš
That is not off topic at all. You could use python plugins to facilitate this. The Unbound python plugin documentation/examples page has a blcklist DNS example. It could be modified to trigger blacklist entries on query metrics. You can blacklist requesters through Unbound access control settings. You can blacklist domain responses by creating empty static domains. It seems you can mix the two with the new “views” feature.
but 4.4 suggest also truncation and force tcp, right?
No, it just says implementations can return a full ANY response over TCP
if they want - it doesn't say anything about truncation.
could a server send an answer without (or as less as possible data) and
set the TC bit?
That would be a bad idea. The point of this draft is to make abusive ANY
queries go away with the smallest response possible, so you don't want to
encourage traffic to move to heavyweight TCP.
There are reflection attacks that abuse recursive servers - sometimes many
recursive servers symultaneously. These recursive servers will then
bombard the authoritative servers for the name that is being abused in the
attack. In this situation, if the authoritative server returns a truncated
response, it will have many recursive servers hammering on TCP instead of
UDP, which can easily lead to overload.
If the authoritative server just returns a small subset response, the
abused recursive servers will happily populate their cache with the small
response and they won't hammer the authoritative servers, and the
attackers will not get the amplification factor that they were expecting.
Tony.