Centos – BIND keep crashing – need to investigate

The log entry SOA record not at top of zone (domain.com.domain.com) is a hint that something is amiss; the SOA record at the top of the file is not being considered as the entry for the domain that's supposed to be handled by this zone file.

This could be caused by the $ORIGIN domain.com line mismatching from the zone "domain.com" IN { line in the named.conf file, either due to an actual mismatched or something like a UTF-8 string handling problem.

An easy workaround in this case is to simply remove the $ORIGIN line from the zone file; it will then be automatically built based on the zone definition in named.conf, ensuring that those strings will match.

Does anyone know how to get DNS Query logs, in a rotation of 3 files on a SLES 11 BIND server working? It doesn't seem like it should be anywhere near this much of a hassle.

It shouldn't be a hassle -- the syntax is straightforward and well-exercised (thousands and thousands of nameserver admins have use it.) It's theoretically possible but very unlikely you've found a new bug in it. Let's look at the more likely causes.

It never hurts to check your syntax first.. As explained in the BIND Administrator's Reference Manual (aka "ARM", a copy of the ARM appropriate to your BIND version is included with your BIND source or can be found at ISC's web site) 6.2.10, you should first define a channel, e.g.:

channel example_query_channel { 
   file "bind_query.log" versions 3 size 20m; 
   print-time yes;
   print-category yes;
};

then direct the category you are interested in logging (i.e. "queries") to that channel:

category queries {
   example_query_channel; 
};

You can use the named-checkconf utility that comes with BIND to check the syntax of your config file for errors before you try to restart BIND with it.

If that doesn't work for you, you have a filesystem permission problem of some sort and not a BIND problem specifically; BIND is being prevented somehow from writing to the file you have specified in its appropriate directory. Maybe you are dropping privileges to run as a non-root user and that user doesn't have -x perms to traverse all directories in the path from the filesystem root to the directory you are writing in, or maybe you don't have -w perms to write files in that directory. Or possibly you have another security layer (you mention AppArmor) which is complicating matters further.