[ratelimits] Logging category

[Vernon Schryver]

> From: Phil Mayers <p.mayers at imperial.ac.uk>

> But the external process I'm using to "tail" the logs is written in a 
> scripting language, so a sensible optimisation is to reduce the amount 
> of data it has to parse/process. If you're telling me that RRL logging 
> will always go in the "query" category, then I will investigate other 
> alternatives (e.g. stick a "grep -v" in the pipeline).

If the external scripting language cannot ignore irrelevant data
at speed, then for my own systems I'd try `sed`, `grep`, or `awk`
before trying to get BIND modified.


> I've read that; I know what the current behaviour is. I'm wondering if 
> it will always be that way.

"Always" is a long time, but I don't understand why the "rate-limit"
log category does not already fit the need for helping that external
scripting language generate the iptables changes.  What about the
notices about the start of rate limiting actions in the "rate-limit"
category?


I probably don't understand the problem.  The description,

> >                                       amplification attacks 
> > (DNSSEC-enabled site, "ANY" queries to our zone apex, 

> >                "tail" the logs and insert short-lived iptables rules (via 
> > ipset) 

suggests the external script solves any overload problem as it installs
firewall rules.  The DNS requests in a DNS reflection attack often
come from many sources but appear at the DNS server to come from a
single source, the intended target of the attack.  Don't the entries
in the "queries" category disappeaer when the iptable rule is added?


Vernon Schryver    vjs at rhyolite.com