On Wed, 20 Feb 2013 17:46:51 +0100 Stephane Bortzmeyer <[email protected]> wrote:
> http://www.cloudshield.com/applications/dns-control-traffic-load.asp > > My first reaction was "These solutions are incredibly stupid" and my > second one "But let's check among the experts at the dns-operations ML > before trolling". In addition to what I saw others respond with... It seems to me this is written with very limited experience outside of corporate environments, where the solution there is often to simply block everything not strictly prohibited. Even there, sometimes that is bad advice. To wit, suggestion #1 is to block query types you know you do not have answers for. On the face, this may seem sensible and in some dire, but probably limited scenarios maybe it even helps. To do so typically requires some sort of DPI device in front of the DNS server, a solution often not readily available. This suggestion also hurts a legitimate resolver. A resolver receiving an NXDOMAIN is going to perform much better than one that has to incur the timeout for an unresponsive query. This solution forces all resolvers, who happen to ask for something they can't possibly know doesn't exist until they actually ask, to maintain additional query state. It could be annoying if one DNS operator implemented this suggestion, it would probably be very detrimental and require resolver changes if everyone applied this advice. The second part of suggestion #1, which should probably be a separate suggestion, seems equally naive, short sighted and annoying as the first. Strangely the author refers to 'NXDOMAIN type query', but notwithstanding perhaps some mild confusion in the lead up to the proposed solution, many types are not A or AAAA, so this is of limited value with other query types. The spoofed DDoS attacks, very often the kind we care about, aren't going to get these answers so this won't reduce the attack at all. In fact, it makes the response slightly larger by including an answer section. That doesn't seem very helpful. Further still, legitimate resolvers would likely have cached the NXDOMAIN for at least 5 minutes anyway. In suggestion #2, a clue that this advice is written from a very particular perspective is the notion of a 'DNS server pool'. That sounds like corporate network speak for a handful of DNS servers behind a physical load balancing device. The rate limiting advice is fairly generic, there doesn't seem to be any awareness of RRL or other TCP-based switchover, plus no recognition that many flooding attacks will simply overwhelm available capacity, making rate limiting at the edge of little use. Suggestion #3 is essentially #2 with the added stipulation of monitoring and rate limiting per source prefix. John _______________________________________________ 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
