> Patch BIND to include the RRL (Response Rate Limiting) patches > (http://www.redbarn.org/dns/ratelimits), blackhole/ignore those > clients requesting.
The fact that Response Rate Limiting (RRL) does not blackhole/ignore clients is a feature and why it is a better mitigation for DNS Reflection DoS attacks than mechanisms that do blackhole/ignore clients. The apparent DNS clients in DNS reflection attacks is usually not the source of the evil requests, but forged by bad guys trying to attack the nominal clients. Because RRL limits rate of any particular response sent to any particular client address block, the client is generally able to get responses for its legitimate requests and often will not notice the attack. Naively blackholing/ignoring the forged client as with common firewall rules does stop attacks, but lets the bad guy deny name service to the client. Breaking host name resolution has been a part of many security attacks over the years. ... } > I have isc.org attack." isc.org internet *?". It comes from my own clients } > that I have allowed in my ACL. the question is how to stop this attack? } If the queries are really from your clients, find & fix them. They are } probably attacking others in addition to you, so you'd be doing the rest of } the Internet a favor while solving your own problem. Simple request flooding with forged DNS client IP addresses sounds unlikely, because there are many other DoS attacks that are more effective and harder to filter. In other words, the smart money bets on the requests not really coming from the apparent clients, but that they are forged and intended to attack the apparent clients. } If the traffic is spoofed as being from your clients, stop accepting traffic } from elsewhere sourced from your client address space. That is best, if possible and relevant, as with closed recursive resolvers. It is generally irrelevant and impossible for authoritative DNS servers. The RRL patch is intended for authoritative servers, but can be used as better than nothing on recursive resolvers. The best mitigation for open recursive resolvers is to close them except to trusted clients. When that is not possible, RRL can be used at the cost of significantly slowing applications such as browsers and SMTP servers (mail receivers) that make large bursts of identical requests. ... ] Many people will not compromise critical daemons by using third party ] *unofficial* patches. I don't know the status of the CZ-NIC Knot DNS or the NLNetLabs NSD RRL code. Perhaps that either of those is "third party" or "unnofficial," although I have the impression that is at least partly wrong. The BIND RRL patch on http://www.redbarn.org/dns/ratelimits are unofficial, and so it is reasonable to be skeptical and wait for an official release. However, for obvious reasons it is not really accurate to label the BIND RRL patch as "third party." "Pre-pre-release" is a more accurate characterization of the BIND RRL. Please note that users of the FreeBSD bind98 and bind99 ports can get the RRL code without messing with the patch command. See https://www.google.com/search?q=site%3Afreebsd.org+bind+rrl ] iptables does just as good of job. That is widely known to be false in general. In principle one could write iptables rules that do as good a job as RRL. However, the common iptable rules that rate limit incoming requests based entirely on either query types or DNS client IP addresses block ilegitimate queries and so are distinctly inferior to RRL. Vernon Schryver v...@rhyolite.com _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
