Bind 9.2.4 and logging

Wed Mar 5 21:38:21 UTC 2008

You can certainly find out what queries were recursive. Just look in  
your query logs for entries ending in "+" (or "+E", "+S", or "+SE").  
For example:

05-Mar-2008 13:05:36.362 queries: info: client 127.0.0.1#61683: query: www.menandmice.com 
  IN A +
05-Mar-2008 13:05:41.642 queries: info: client 127.0.0.1#61688: query: www.menandmice.com 
  IN A -
05-Mar-2008 13:12:46.337 queries: info: client 127.0.0.1#61753: query: www.menandmice.com 
  IN A -S
05-Mar-2008 13:13:35.024 queries: info: client 127.0.0.1#61758: query: www.menandmice.com 
  IN A -SE
05-Mar-2008 13:15:34.256 queries: info: client 127.0.0.1#61764: query: www.menandmice.com 
  IN A +E

The first query was recursive, the second not. This will generally  
tell you what queries are coming from local stub resolvers (recursive,  
+) and from resolving name servers (iterative, -). However, note that  
a name server that forwards a query, rather than conducting its own  
recursion, sends a recursive query.

Also note that it would be exceptionally odd to see a recursive query  
with the S or E flags - this would almost always come from a  
forwarding name server, or from someone playing games or testing.

As to your earlier misunderstanding, the three categories you named  
are described thusly in the ARM:
___

client: Processing of client requests.

resolver: DNS resolution, such as the recursive lookups performed on  
behalf of clients by a caching name server.

queries: Specify where queries should be logged to. At startup,  
specifying the category queries will also enable query logging unless  
querylog option has been specified. The query log entry reports the  
client’s IP address and port number, and the query name, class and  
type. It also reports whether the Recursion Desired ﬂag was set (+ if  
set, - if not set), EDNS was in use (E) or if the query was signed (S).
client 127.0.0.1#62536: query: www.example.com IN AAAA +SE
client ::1#62537: query: www.example.net IN AAAA -SE
___

It is my understanding that log entries of categories "client" and  
"resolver" will only be at debug level. For example, if I set my  
logging severity threshold to debug 5, then send it a query for some  
name it doesn't have in cache, I get dozens of resolver category  
messages at debug 3, plus one or two at debug 1. Category "client"  
contains about 10 messages of level debug 3, plus one of debug 5. Here  
are the client category messages:

05-Mar-2008 13:18:22.519 client: debug 3: client 127.0.0.1#61773: UDP  
request
05-Mar-2008 13:18:22.519 client: debug 5: client 127.0.0.1#61773:  
using view '_default'
05-Mar-2008 13:18:22.520 client: debug 3: client 127.0.0.1#61773: query
05-Mar-2008 13:18:22.520 client: debug 3: client 127.0.0.1#61773:  
replace
05-Mar-2008 13:18:22.520 client: debug 3: client @0x5bf000: create
05-Mar-2008 13:18:22.521 client: debug 3: client @0x5bf000: udprecv
05-Mar-2008 13:18:23.194 client: debug 3: client 127.0.0.1#61773: send
05-Mar-2008 13:18:23.194 client: debug 3: client 127.0.0.1#61773: sendto
05-Mar-2008 13:18:23.194 client: debug 3: client 127.0.0.1#61773:  
senddone
05-Mar-2008 13:18:23.194 client: debug 3: client 127.0.0.1#61773: next
05-Mar-2008 13:18:23.194 client: debug 3: client 127.0.0.1#61773:  
endrequest

As you can see, these are not of much use unless you're debugging  
BIND's behavior.

Chris Buxton
Professional Services
Men & Mice
Address: Noatun 17, IS-105, Reykjavik, Iceland
Phone:   +354 412 1500
Email:   cbuxton at menandmice.com
www.menandmice.com

Men & Mice
We bring control and flexibility to network management

This e-mail and its attachments may contain confidential and  
privileged information only intended for the person or entity to which  
it is addressed. If the reader of this message is not the intended  
recipient, you are hereby notified that any retention, dissemination,  
distribution or copy of this e-mail is strictly prohibited. If you  
have received this e-mail in error, please notify us immediately by  
reply e-mail and immediately delete this message and all its attachment.

On Mar 5, 2008, at 11:22 AM, Henning Markussen wrote:

> So it doesn't look like this is the way ...
> Any other way to find out if it is a recursive request?
>
> - Henning
>
> Jeff Reasoner wrote:
>> I don't know that the other categories are material to what you're
>> trying to achieve. The logs will contain the source IP and query
>> regardless of whether it was for in-zone (authoritative) data or
>> answered out of cache.
>>
>> I did the same thing last summer with 9.4.1-P1 and the following in
>> named.conf:
>>
>>        channel bind-queries {
>>                file "/var/log/queries.log" versions 10 size 6m;
>>                severity info;
>>                };
>>
>> I also did some backend scripting to pull out the unique source IPs  
>> so I
>> knew who I had to contact about changes.
>>
>> On Mon, 2008-03-03 at 22:58 +0100, Henning Markussen wrote:
>>> Hi
>>>
>>> I'm trying to close down some DNS servers that currently are open to
>>> recursive requests.
>>> They are ruining bind 9.2.4
>>>
>>> In this process my plan was to determine what clients are using the
>>> servers as recursive name servers.
>>>
>>> I've found the category resolver, client and queries
>>>
>>> queries logs the queries ok - but nothing gets into the resolver or
>>> client category
>>>
>>> channel queries_log {
>>> file "/var/log/queries.log" versions 5 size 5m;
>>> print-time yes;
>>> severity dynamic;
>>> };
>>>
>>> channel resolver_log {
>>> file "/var/log/resolver.log" versions 5 size 5m;
>>> print-time yes;
>>> severity dynamic;
>>> };
>>>
>>> channel client_log {
>>> file "/var/log/client.log" versions 5 size 5m;
>>> print-time yes;
>>> severity dynamic;
>>> };
>>>
>>> category client { client_log; };
>>> category queries { queries_log; };
>>> category resolver { resolver_log; };
>>>
>>> Is there a category where I can log if a request is to the  
>>> authoritative
>>> or to the recursive, or am I just not using the categories correct?
>>>
>>> Thank you for any input or ideas
>>>
>>> - Henning