BIND9 logging gets too verbose (too chatty) for my taste

Hello!

I've configured logging in my BIND9 server and I have 2 log files:
1) debug.log;
2) query.log.
The second one is Okay. No complaints so far. But the first one is too verbose (too chatty) for me. Like 90% of what it says there I don't even understand. You get like 100's of thousands of text lines within couple of hours only. That's crazy!
Here how it's set:

 channel debug_log {
         file "/var/log/named/debug.log";
        severity debug 3;

Open in new window


If I understand it right, to make it less verbose (chatty), I can try debug 2 or simply debug (which defaults to debug 1). Right?
The next level (less chatty) would be
severity info; 

Open in new window

Right?
David1978Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

JustInCaseCommented:
Debug is mode with most details that you can get, so you should choose some higher severity level than debug.
Acirding to article here are severity levels on BIND9, I guess notice would be OK
Severity 	Description
critical 	only critical errors.
error 	        error and above.
warning 	warning and above.
notice 	        notice and above.
info       	info and above - log starting to get chatty.
debug 	        debug and above. Various debug levels can be defined with 'debug 0' meaning no debugging.
dynamic 	debug and above. Means assume the global debug level defined by either the command line parameter -d or by running rndc trace

Open in new window

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
David1978Author Commented:
Thanks for your reply!

And what about debug 3 vs. just debug (sort of debug 1) ? And why "info" isn't too good?
Or maybe the only way to find out is just to play with it and see...?
0
JustInCaseCommented:
I am from Cisco world, here there is just one severity debug level , but my guess is that different debug number would mean either different type of debug, or more debugging options (types of debug) would be included.
Info severity could be OK, depending on what messages you want to log, but I guess you need to check BIND9 documentation  for more details, or you could play and see what suits your needs.
 :)
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

arnoldCommented:
you can use rndc or issue a a KILL -USR1 and KILL -USR2   <named pid>  To increase/reduce the verbosity level.

What information do you want.  usually, one would set it to warn. you can set it at notice.

The Predrag post of the level means the level you choose will have the logging reflecting its level and above.
0
David1978Author Commented:
Thanks for your replies!

I didn't like debug 2 or debug 1, so I'm trying the info level. Probably, I would have to play after all...
0
David1978Author Commented:
I don't know... After I switched to info, both logs stopped doing anything (they're both empty).

Here's my full logging section:

logging {

channel debug_log {
     file "/var/log/named/debug.log";
    severity info;
    print-category yes;
    print-severity yes;
    print-time yes;
};

channel query_log {
    file "/var/log/named/query.log";
    severity dynamic;
    print-category yes;
    print-severity yes;
    print-time yes;
};

category resolver { debug_log; };
category security { debug_log; }; 
category queries { query_log; };

};

Open in new window

0
David1978Author Commented:
Sorry, had to re-start BIND. Now my second file gets the info (query.log), but debug.log is still empty.
0
David1978Author Commented:
Has switched debug.log to notice, still no difference. query.log is getting the info, but debug.log is still empty. Looks like it needs to be done differently...
0
arnoldCommented:
Your debug.log is applicable to resolver meaning internal non authoritative requests and security which I believe deal with DNS updates.
Query is a general enough to only populate the query_log.

What are you looking to log.

What is your setup?
Do you have a mix of authoritative zones, subordinate name servers, views?
0
David1978Author Commented:
arnold, what I have is one zone file authoritative for one domain (the one that's hosted locally) and local recursion enabled. That's about it.
Frankly, I don't know what I'm looking for. I know when I see it. query.log is fine, actually. It's the debug.log that is problematic. I was thinking (let me know if it's at all possible), to comment out the lines regarding debug.log (until I really need to debug BIND9) in the logging section in this fashion:
logging {

# channel debug_log {
  #   file "/var/log/named/debug.log";
 #   severity debug 3;
  #  print-category yes;
  #  print-severity yes;
    #print-time yes;
#};

channel query_log {
    file "/var/log/named/query.log";
    severity dynamic;
    print-category yes;
    print-severity yes;
    print-time yes;
};

category resolver { debug_log; };
category security { debug_log; }; 
category queries { query_log; };

};

                                          

Open in new window

0
arnoldCommented:
You can using kill -USR1 or -USR2 to PID of named to increase/decrease logging level without the need to restart named.  A similar functionality exists for rndc.

Do your internal systems use this DNS server for recursion?

Your query log has dynamic setting while the others are info.

Try one change at a time. Enable debug on one channel using a security_log, and more what is being reported there. Do the same for resolver and see what is being reported there when you generate queries against it.

This way you can see what is being being reported and at least have a frame of reference.

Try something as
dig @localhost axfr yourdomain.com
Repeat using the LAN ip
dig @lanip axfr yourdomain.com
See if there is an entry in the security channel.
More /etc/resolv.conf for nameserver does your system point to itself (127.0.0.1 or the lanip) or it points to an external/separate nameserver?
0
arnoldCommented:
echo "update add hostname.yourdomain.com. In a 127.0.0.1
" | nsupdate -v

See what happens in the logs.
0
David1978Author Commented:
Thanks for reply!

I don't know what my internal systems use. I've my static public IP as nameserver in resolv.conf
So if I understood you correctly, you want me to try to synchronize both logs (debug and query), ie. so, let's say, I would have one level of severity in BOTH of them, right?
Are you saying that commenting out completely debug log is not a good idea?
0
arnoldCommented:
What I am trying to do is get the information that will be added based on the channel configuration to you. On that basis you can determine whether it is something you want.
Often, the logging is used by ISPs that host many authoritative zone as a way to detect attacks on their systems.
The query channel is used to see whether there is a dos attack coming from the same source. A ddos can not be prevented, but can be identified.

When one runs their own name server as you are, logging need only increase logging to identify a particular issue, I.e. Internal system could not resolve a particular domain/.......
0
David1978Author Commented:
I have in named.conf.local regarding logging is this:

logging {

    channel debug_log {
         file "/var/log/named/debug.log";
        severity notice;
        print-category yes;
        print-severity yes;
        print-time yes;
    };

    channel query_log {
        file "/var/log/named/query.log";
        severity dynamic;
        print-category yes;
        print-severity yes;
        print-time yes;
    };

    category resolver { debug_log; };
    category security { debug_log; }; 
    category queries { query_log; };
   
};

                                

Open in new window


After I turned on my PC, there's something new that was added to debug.log:

02-Nov-2015 19:16:01.684 security: warning: using built-in root key for view _default

And query.log works as usual. Does it mean that both files are getting the info that they should be getting under the conditions set in named.conf.local? Should I just leave it alone for now and IF there're problems with BIND, then I could escalate the severity level to debug 3 for debugging purposes?
0
arnoldCommented:
Yes.
1
David1978Author Commented:
Thanks!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.