[dns-operations] CloudShield advices against dDoS

[John Kristoff]

On Wed, 20 Feb 2013 17:46:51 +0100
Stephane Bortzmeyer <bortzmeyer at nic.fr> 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