2

We have some BIND DNS servers we are thinking of shutting down. I turned on query logging to see which clients are contacting these servers. The vast majority of entries are from three known culprits. I would like to eliminate these from being logged. Is there any way to do this from within BIND?

I can't find an in-BIND way, so a not-within-BIND method I thought of was making the file in the channel statement be not a file, but a socket. And then have a script reading from this socket and doing the filtering before writing to a file.

    channel queries {
            file "/var/adm/named/querylogsocket" versions 7;
            print-time yes;
            print-category yes;
            print-severity yes;
            severity info;
    };

Is this a viable approach?

John Hascall
  • 287
  • 1
  • 14

1 Answers1

0

There are two approaches: post log filtering and view configuration changes. One is easy, other is hard and error prone.

Neither will be able to reduce your log output.

Post Log Filtering

If you want to continue to let your Bind9 respond to your three big culprits but are only interested in OTHER queries and answers, then none of those Bind9 clauses, statements, and options can help you there.

In all Bind9 versions (and I have a current database of these keywords), there is currently no selective log filtering by address, as it only provides filtering by severity.

Many of Bind9 statements beginning with allow- are directly protocol-impacting (and not what you want for a selective logging output.

The quickest (but not always the best) way, at this point, is to use Unix pipes and filter out the three unwanted IP/hostname addresses.

cd /var/log/named
cat query-errors | \
    grep -v 1.1.1.1 | \
    grep -v 1.1.1.2 | \
    grep -v 1.1.1.3 | \
    <your-log-analysis-program>

Just replace the 1.1.1.x part in the example with your 3 biggest unwanted addresses.

The -v option will filter out your unwanted output such that you’ll only see what you want your log analysis program to see.

View configuration changes

Or you can mess with the named.conf settings and split your current view into two views.

If there is no view statement already in there, this will get a tad bit harder for the non-Bind person to do.

To split a view, edit the named.conf (or one of its include file(s) that contains that desired view clause.

Duplicate that entire view clause (and all its statements within its pair of curly braces.

Rename the newly cloned second view to something else, perhaps just adding a “_original” suffix to the view name.

Go back up to the first view clause (this is important because address matching are done in first-match order.)

Add another statement match-client within that first view clause.

view red {
    match-clients {
        1.1.1.1; 1.1.1.2; 1.1.1.3;
    };
...

Now you have a log file whose lines have different view names and you can easily scan for that view name.

Conclusion

Now I know this is still not addressing the need NOT to log a specific view or set of addresses by Bind9.

John Greene
  • 304
  • 1
  • 12