[ratelimits] BIND9 DNS rate limit logging
vjs at rhyolite.com
Fri Jul 6 20:43:53 UTC 2012
Many have asked that the BIND9 DNS rate limit logging be less logorrheic.
Most have mentioned the classic syslog "previous msg repeated X times"
I've been looking at that and other ideas to make the logging more useful.
A problem with the syslog idea is that it would not reduce log noise
when there are two or more rate limited streams of responses. Every
log entry would be surrounded by entries for other bulky responses,
and so would not be compressed.
One reason for the current log noise is that when a response is dropped,
there is no sign in the 'queries' category. Normal and many error responses
are logged in the 'queries' category, but not dropped responses, probably
because until now dropping applied mostly duplicate or retransmitted
Another tactic would be:
- all responses dropped or slipped (answered with TC=1) are logged
in the 'queries' category, one log entry per response, at the
- one entry at the INFO level is sent to the 'rate-limit' category
for the first response dropped in a stream of responses.
That should result in
1. the 'queries' category gets the same, often very large number of lines
with or without rate limiting.
2. the 'rate-limit' category gets one log entry per burst of identical
3. a single request/response could result in separate log entries in both
the 'queries' and 'rate-limit' categories.
4. all responses are logged somewhere at least once, but if you don't
watch the 'queries' category, you don't have to see them all.
Would this tactic answer the need for less verbose rate limit logging?
If so, would #2 be improved by generating one log entry per "window"
seconds, so that an attack lasting two days would have 11,520
'rate-limit' log entries instead of only one in the first day's log file?
(As the code is now, there will be 115,200 'rate-limit' category
log entries for 10 attack qps or 1.1M entries for 100 qps)
Vernon Schryver vjs at rhyolite.com
More information about the ratelimits