> > One word: qmail. Google "qmail dns any query".
>
> thinking about or acting against ANY is bad infosec economics. any
> investment along those lines is wasted, since ANY is merely the low
> hanging fruit, and an attacker need only switch over to TXT or RRSIG or
> NSEC to get a similar amplification effect from an authoritative name
> server, if ANY were widely nonresponsive.
Agreed. And along the same lines, limiting EDNS responses to 1460 bytes,
as suggested, will block quite a few legitimate replies (not just ANY
replies).
> to that end, vernon schryver and i have been exploring rate limiting in
> BIND 9. there's a patch available, which i've so far offered only to
> anyone whose server is currently getting abused. what i'm worried about
> is that our profile for goodput-vs-badput is wrong headed or too course
> grained. so far so good.
>
> config {
> // ...
> rate-limit {
> responses-per-second 5;
> window 5;
> };
> };
I'm afraid we may need more control. If my clients are generating a DDoS
attack at 20 responses per second, and I limit this to 5 per second -
the C&C can get the same effect by mobilizing four times as many clients
to do the job. On my wishlist, in addition to rate limiting, is also:
- Some way of dynamically blackholing clients, based on one or more of
-- Rate limit exceeded
-- Asking the *same* question (with a large response) repeatedly
-- Asking a *specific* question (e.g. ANY isc.org|ripe.net)
-- Input from an external system, e.g. via rndc
Steinar Haug, Nethelp consulting, sth...@nethelp.no
_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
