[dns-operations] DDoS botnet behaviour

[Vernon Schryver]

> From: Tony Finch <dot at dotat.at>
> To: Vernon Schryver <vjs at rhyolite.com>
> cc: dns-operations at mail.dns-oarc.net


> At the moment I'm just using BIND's sockaddr_hash routine, adapted to hash
> on the network prefix and to provide two variant hashes. 

I think you would do better by treating the IP address as an integer
(including IPv6) and taking the remainder after division by a suitable
prime number.  I think that would be more certain to be uniformly
distributed over a range consisting of IP addresses.  That's not a
criticism of BIND's hash_calc() et al but a nod to the particular case.

By the way, are you removing the port number from the sockaddr?  Do
you have an optional netmask on IP addresses (both IPv4 and IPv6) to
deal with bad guys that are using DNS reflections to attack networks
instead of individual hosts?

What about the qname and qtype?  Imagine that you are at an ISP
running a customer facint recursive resolver with rate limiting.
Imagine also that I am one of your customers or "own" one of your
customers systems and that I want to attack one of your other
customers by shutting down all DNS service to that that other
customer.  Would your code make my DoS attack if I forged a modest
steam of requests from that other customer?

Another issue is the significant reflection amplification a bad guy
can get with signed NXDOMAIN responses.  I think one should also worry
about un- or minimally amplified reflections using SERVFAIL or FORMERR.


>                                                          It has the nice
> property of being randomised when the server starts.

Why is that a nice property?  It strikes me as either irrelevant or a
defect for this application.  For a hash funtion, one usually needs
"uniform" instead of any of the technical definitions of "random."


> > What is your estimate for the memory required for a simple hash
> > based scheme?
>
> I haven't done the sums yet, sorry.

Please don't be offended, but how can one write any code for use
by others without first estimating CPU, memory, implementation, bug
rates due to learning curves, and so forth of some of the several
ways to solve the problem?  I think one must do at least mental
back-of-the-envelope estimates before firing up vi or emacs for
anything except private, throw-away shell scripts.  How do you know
that the costs of a Bloom filter (starting with the multiple
hash tables) are lower than the costs of other schemes?


> > Do you believe that single set of Bloom filter parameters can serve an
> > interesting class of installations without using more RAM than a classic
> > hash function?  To understate it--I don't.
>
> Of course not :-) But I think it will be possible to set them
> automatically based on overall query rate.

Wouldn't that involve the dreaded dynamic memory allocation?  In which
case, how does using a Bloom filter reduce dynamic memory allocation?

 ....


} From: Tony Finch <dot at dotat.at>

} > My hope and almost ambition for the code I've been working on is
} > find a default set of parameters response rate limiting parameters
} > to reduce the nuisance of open resolvers.
}
} Do you expect the parameters to differ for reflected amplification attacks
} on authoritative servers? (which is the case that I care about.)

I don't know.  I've been told my hope is silly.

} Have you considered minimal truncated replies as an alternative response
} to over-limit clients? The idea being to move legit queries from the
} victims onto TCP.

Yes, please see section 2.2.7 of the document linked as "Technical note
describing the implementation ..." and the words about "slip" linked
as "Draft text ...ARM" from http://www.redbarn.org/dns/ratelimits


Vernon Schryver    vjs at rhyolite.com