> From: Eric Osterweil <[email protected]> > Fair enough, except I'm pretty sure some of the deployment being > talked about (even in this thread) is at the authority (not the > resolver)...
> > Paul Vixie and I are not advocating DNS rate limiting in firewalls. > > We're talking about rate limiting in the hosts at the ends of the > > intertubes. > > Again, this thread started somewhere else. Clearly, I agree that > people should be able to manage their own user experiences. ;) By definition, all DNS servers and clients run on hosts. When a router or bridge does DNS stuff, it is a host and subject to the Host Requirements RFCs. I and I think some others have been talking about filtering DNS requests and/or responses in the following hosts and/or firewalls close to those aforesaid hosts: - DNS servers, either authority servers or resolvers - putative DNS clients that are targets of DNS reflection DoS attacks. The money-back warranty on the BIND RRL patch only covers its installation on authority DNS servers, although I have received positive reports from resolver operators. The current version includes additional features suggested by operators of combined authorities/resolvers. > 1 - If you uniformly drop 50% of a 100x amplification attack, you > are still reflecting 50x amplification, right? That is wrong for the BIND RRL patch. With default parameters, the BIND RRL drops 50% of responses and substitutes a small TC=1 response for the other 50%. That gives an amplification for the responses it sends of <= 1.0 responses sent and an overall amplification <= 0.5. (It currently forgets about ENDS in the TC=1 responses giving a default amplification of < 0.5. An influential commentator calls that a bug.) > 2 - If you wait for (say) 4 responses, your stub (the client > driving the upstream resolver) has almost certainly timed out, and > the DDoS has succeeded, if I'm not mistaken, right? I think that is mistaken. Consider the implications of the default values of "attempts" and "timeout" keywords in /etc/resolv.conf and of _res.retry and _res.retrans the libc interface to the de facto standard stub. > Then it should be easy enough for someone to explain the above, no? > Having deployed something does not mean that it was effective, and > blocking traffic does not tell me how much legit traffic and how much > attack traffic was blocked. I don't see why this is so hard, I just > want to understand the assertion. Consider where the BIND RRL patch has been installed and then ask yourself why *you* have not noticed any collateral response losses. See https://lists.dns-oarc.net/pipermail/dns-operations/2012-June/008453.html Vernon Schryver [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
