On Tue, Sep 11, 2012 at 9:38 AM, Vernon Schryver <[email protected]> wrote: >> From: Klaus Darilion <[email protected]> > >> On 10.09.2012 19:48, Paul Vixie wrote: >> > please don't do, or promulgate, this. ddos filtering in order to do more >> > good than harm has to be based on the attack's answer, not on its query. > >> > vernon schryver and i explain this in the technical note at >> > <http://www.redbarn.org/dns/ratelimits/>. > > Any firewall rule that doesn't compute DNS responses about as good as a DNS > server is simplisitic.
With the greatest of respect; that thinking is itself simplistic. Where I work we concentrate on writing very good firewalls. Sometimes these rules even have to parse DNS, just as the DNS server must ... which causes duplication of work. We do this for several reasons; An in-the-path firewall actually has access to more data than the DNS server alone does. For example, it can build up a simple profile of expectation values for IP TTLs on a per-source network basis. It can use all IP data for that profile; DNS, HTTP, whatever it's seen. Those expectation values can then be used to detect and reject spoofed packets, in combination with other statistical scores. That's just one simple example - there are many more. The other big reason is pragmatism; unix daemons using recv() are extremely limited in the rate at which they can process packets. far far higher throughput is possible via other techniques that involve handling batches of packets at much smaller timescales. A nice benefit of the approach is that it frees higher-level development teams from having to worry about low-level mitigation, and that the work is re-usable across many products. During real attacks, if a packet makes it to the dns server, the game is already lost. If anyone reading is interested in helping us write and build these kinds of line-rate low-level filters, drop me a line at [email protected] - we're always hiring! > Because each request implies its response, in theory there is no > difference between filtering based on requests or responses. When the primary goal is to mitigate the impact of reflection attacks on their potential targets, it makes some sense to filter responses. That way you can implement a rate-limit that takes bandwidth into account, rather than simply PPS. Definitely agreed about that :) -- Colm _______________________________________________ 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
