[Unbound-users] Effect of val-bogus-ttl

[Florian Weimer]

* W. C. A. Wijngaards:

> Hi Florian,
>
> Could you retry this with current svn trunk of unbound?
> The retry logic in case of dnssec failures should blacklist
> the cached missing-dnskey-response and try to go to the
> network again at step 6.

Oh, sorry, I assumed you had released the trunk as 1.3.4, that's why I
retested that version!  The trunk almost behaves as I would expect.

I know I'm asking the impossible here (protection against spoofing vs
avoiding becoming a DoS amplifier), but would it be possible to make
Unbound somehow back off when it receives a REFUSED response (with the
proper question section)?  I ran basically the same test as before,
this time redirecting DNS traffic to a server which just returned
REFUSED (as a properly configured authoriative name server should when
receiving unexpected requests, IMHO).  Unbound seems to adhere to
val-bogus-ttl as well (which is great!), but sends a few more upstream
queries than for the unsigned answer case.

I understand that there is a very difficult trade-off in the current
protocol framework, and I have no good suggestions here.  Currently,
name servers under in-protocol reflective attacks typically stop
sending REFUSED responses and let resolvers time out instead, in the
hope that the resolvers will run into load issues (because the maximum
number of parallel client transactions is exceeded) and their clients
get eventually cleaned up.  I don't like this, but as I've said, I
haven't got an idea how to deal with this.

Perhaps you can treat a REFUSED response as covering the whole subtree
and all (non-magic) QTYPEs if a secure answer is expected?  But this
opens a trivial way to deny resolution to mis-served signed zones.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99