* 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 <[email protected]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
