At 14:18 +0000 6/10/12, Paul Vixie wrote:
thinking about or acting against ANY is bad infosec economics.
This I agree with. Here are some of my knee-jerk, anti-filtering thoughts:
1 - DNS providers are paid to answer questions, not drop traffic.
2 - Rate limits that are not managed eventually become the reason why
address blocks are contaminated. Recall the 512 byte limit devices.
3 - Whenever I've considered limiting any pattern I think of a few
other patterns that could be substituted in short order if its an APT.
I agree that rate limiting is an effective short-term, immediate
reaction to events. But once you leave that time horizon they become
liabilities - "permanent fixes to temporary solutions."
Another part of this discussion centered around determining the
source of the offensive traffic. Again, "bad infosec economics"
comes here - while it is interesting to diagnose, rarely does the
search for answers to this question lead to a permanent solution.
We've collectively known about Dan Bernstein's use of t=ANY for a
decade and we know he's reluctant to listen to calls for change nor
make the change. 10+ years. Nothing's changed - except the newest
younger crowd learns about this old tale.
The suggestion to limit EDNS0 to "a smaller size" might be the first
step to decent (but still suboptimal) improvement. Guessing that the
malicious data seeks two things - a large, valid and reputable chunk
of data to throw at a victim and an reputable and capable address
from which to throw it, perhaps at least limiting the data size in a
way that does not cause choking to legitimate uses is a good thing.
I've said in presentations that the same fertile ground that lets DNS
be the beast that it is also enables DDoS (rooted in the nature of
UDP). The fact that we are still talking DDoS prevention many years
after we started is empirical evidence that DDoS is a hard problem to
solve. Rate limiting is one technique, not a cure-all. If it was,
we'd not be talking about it in 2012. So, use it with caution.
PS - One possibility, instead of simply not responding, send back
rcode=REFUSED.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
2012...time to reuse those 1984 calendars!
_______________________________________________
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
