bind-9.2.0: 2 minor query denial logging issues

Ted_Rule at flextech.co.uk Ted_Rule at flextech.co.uk
Sat Mar 23 18:20:57 UTC 2002




I've noticed a couple of minor annoyance in the log stream for bind-9.2.0,
regarding queries which are rejected.

By default, with query logging itself disabled, one may occasionally see
something like this in the logs under the general security category:

Mar 23 17:26:54 miranda named[607]: security: info: client 194.117.157.4#53:
query (cache) denied
Mar 23 17:26:55 miranda named[607]: security: info: client 194.117.157.4#42207:
query (cache) denied
Mar 23 17:36:30 miranda named[607]: security: info: client 194.117.157.4#53:
query (cache) denied
Mar 23 17:36:31 miranda named[607]: security: info: client 194.117.157.4#42632:
query (cache) denied

This happens to be for a non-recursive server, where the acl's are set to deny
anything recursive by default, and to deny any query for a zone not loaded on
the server.

However , if one enables query logging the picture becomes clearer:

Mar 23 17:06:30 miranda named[607]: queries: info: client 194.117.157.4#53:
query: troubleradio.com IN SOA
Mar 23 17:06:30 miranda named[607]: security: info: client 194.117.157.4#53:
query (cache) denied
Mar 23 17:06:31 miranda named[607]: queries: info: client 194.117.157.4#41368:
query: troubleradio.com IN SOA
Mar 23 17:06:31 miranda named[607]: security: info: client 194.117.157.4#41368:
query (cache) denied

i.e. the remote server is querying for a domain not on the box, which I happened
 to
have forgotten to load by mistake.

Oddly enough, the remote server ( the 157.4 address is a bind 8 server ) seems
to be
making queries from both port 53 and a random port ( at least that's what the
number after
the hash in the logs seems to represent  ) - I guess this is the remote
server falling back to tcp on the 2nd attempt, though I must admit this seems
odd to me, given that it should have got a REFUSED status reply on the first
attempt.

The problem of course, is that it's difficult  to deduce the exact configuration
 fault
from the logs without query logging enabled, and one wouldn't want to enable
such verbosity in general.

It seems that the security log could be usefully enhanced to include the
original query,
an indication of the recursive flag on the original query, and the protocol (
udp/tcp )
involved. Likewise, the query logging could be enhanced to include
the recursive flag and protocol.

Additionally, though I admit this is one to argue about till the cows come home,
one might argue that the messages should be logged at
security:warning rather than security:info.




Ted









***************************************************************************************************

This E-mail message, including any attachments, is intended only for the person
or entity to which it is addressed, and may contain confidential information.

If you are not the intended recipient, any review, retransmission, disclosure,
copying, modification or other use of this E-mail message or attachments is
strictly forbidden.

If you have received this E-mail message in error, please contact the author and
delete the message and any attachments from your computer.

You are also advised that the views and opinions expressed in this E-mail
message and any attachments are the author's own, and may not reflect the views
and opinions of FLEXTECH Television Limited.

***************************************************************************************************



More information about the bind-workers mailing list