[ratelimits] RRL patch is too talkative when dropping queries

Bob Harold rharolde at umich.edu
Mon Jun 17 20:51:05 UTC 2013

Does this user realize that the "query-errors" category can be turned off,
and they can use the "rate-limit" category to see what is being
dropped/slipped, usually with far less log lines, just beginning and end
Jun 17 05:49:38 <servername> named[6978]: 17-Jun-2013 05:49:38.397
rate-limit: info: limit referral responses to <IP> for <domainname> IN
Jun 17 05:50:43 <servername> named[6978]: 17-Jun-2013 05:50:43.982
rate-limit: info: stop limiting referral responses to <IP> for <domainname>
IN  (058bfa16)

What would be missing then is the number of packets that were dropped or
slipped, and the exact times of each packet, unless you are logging all
queries and could correlate the logs.
If the "stop limiting" message could include a count of dropped and slipped
packets, that would be great.  Is that feasible?

Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
rharolde at umich.edu
734-647-6524 desk

On Wed, Jun 12, 2013 at 12:57 PM, Vernon Schryver <vjs at rhyolite.com> wrote:

> > From: Phil Mayers <p.mayers at imperial.ac.uk>
> > > There should be no danger of the messages filling a disk if the
> channels
> > > that receive query-errors category messages have limits.  For example:
> >
> > I think the problem here is that they're being sent over syslog, so the
> > bind limits don't apply?
> Yes, the BIND logging file size limits do not affect messages sent to
> syslog.  However, the messages seem to me to have a BIND log file
> format instead of a syslog format.  The timestamp format differs from
> BSD syslog.  There is no hostname, process name, or process ID.
> I just now noticed that the messages are a mixture of "slip" and
> "drop" messages, and so are less similar than I thought.  That
> suggests that the familiar syslog message compression would not
> help if the messages were being sent to syslog.
> I also just now realized that the strings of astrisks (*) are obfuscations
> of IP addresses.  The fact that the "slip" and "drop" messages do not
> alternate suggests the IP addresses differ.  That suggests that the
> DNS reflection attack wa against a network instead of a host, that
> there were multiple concurrent attacks, or that the messages are
> pointing out possible problems that might be addressed by exempting
> some IP addresses from RRL with views or exempt-clients{}.
> Vernon Schryver    vjs at rhyolite.com
> _______________________________________________
> ratelimits mailing list
> ratelimits at lists.redbarn.org
> http://lists.redbarn.org/mailman/listinfo/ratelimits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.redbarn.org/pipermail/ratelimits/attachments/20130617/4f38dd21/attachment.htm>

More information about the ratelimits mailing list