permissions on /etc/namedb

[Ian Smith]

On Mon, 4 Aug 2008, Doug Barton wrote:
 > Adrian Penisoara wrote:
 > > On Mon, Aug 4, 2008 at 12:57 PM, Ian Smith <smithi at nimnet.asn.au 
 > > <mailto:smithi at nimnet.asn.au>> wrote:
 > >     With the notable exception of making standard functions rndc trace and
 > >     querylog work, writing to the default file named.run, which named wants
 > >     to write in 'the working directory'.  You'll have seen my solution to
 > >     that, touching named.run in case it doesn't exist then chown'ing it to
 > >     bind:wheel in /etc/rc.d/named, which I don't think endangers security.
 > 
 > I think that is a reasonable solution for your situation, although I 
 > don't think it's appropriate to enable that by default. The default 
 > configuration is supposed to be a simple local resolver setup. Users 
 > who need more advanced features should be reading the docs.

Over and over :)  I've *almost* got my head around the logging section,
after initially resisting the idea of using rndc trace being 'advanced'. 

 > >     I've not been able to find another solution, and there's no equivalent
 > >     of dump-file and statistics-file for the trace/querylog file (that I
 > 
 > Query logging has its own log category, so you would do something like 
 > this:
 > 
 > logging {
 > 	channel queries_log {
 > 		file "/var/log/queries.log";
 > 		severity debug; print-time yes;
 > 	};
 > 	category queries        { queries_log; };
 > };
 > 
 > The problem is that if you put that in your named.conf file it will 
 > log all queries when you start named. If there is interest I can add 
 > that to the default named.conf and add a knob to rc.conf to turn query 
 > logging on and off by default, but I'm hesitant to add that much 

Even with option 'querylog no' in .conf?  Anyhow, manageable with rndc.

 > complexity to something that is supposed to be simple but is already 
 > too complex. OTOH, one could argue that even for a local resolver 
 > there would be a non-trivial number of users who would want to enable 
 > logging of queries ...

I was starting to wonder if I was the only one who ever used it, though
only wanting it on when and as required.  Same with debug logging; I'm
finding it really handy just now, checking a new setup for a handful of
auth zones, but wouldn't usually want to know except during 'issues'.

 > As for the equivalent functionality for the debug aspect of named.run, 
 > you're right, there is no equivalent. (FYI, the fact that queries are 
 > recorded in named.run when you bump the debug level is a side effect 
 > of the fact that queries are logged to the resolver category at debug 
 > level 1.) The problem is that the default_debug channel has a special 
 > property (only receives input when debug level is > 0) that cannot be 
 > reproduced with configuration options, and you cannot redefine the 
 > default logging channels. (but see below)

Funny thing is, you can redefine these, modulo the exception below,
despite what the ARM says.

Late last night, before reading this from you this morning, I'd found
 http://www.cymru.com/Documents/secure-bind-template.html
showing redefining the default_syslog channel, amidst a useful example
of using channels and categories - where I find the ARM a wee bit terse
- so I thought, why not try:

logging {
        channel default_debug {
                file "/var/log/named.run";
                severity dynamic;
                print-time yes;
                print-category yes;     // education ..
                print-severity yes;     // ditto
        };
        category default { default_syslog; default_debug; };
};

which works fine - except as you say, it logs, tolerably minimally, even
when notrace / debug level is 0.  And using that I'm starting to figure
out which debug messages come from which categories at what levels, so
it's very useful at the moment, though obviously a gross workaround ..

Adrian Penisoara wrote:

 > > Quoting from a default distributed /etc/namedb/named.conf:
 > > 
 > > options {
 > >         // Relative to the chroot directory, if any
 > >         directory       "/etc/namedb";
 > >         pid-file        "/var/run/named/pid";
 > >         dump-file       "/var/dump/named_dump.db";
 > >         statistics-file "/var/stats/named.stats";
 > > 
 > >  You have to take into account that "directory" is used for any 
 > > non-absolute pathname specified in named.conf, including the "file" 
 > > clauses for master/slave zones. If you were to change it now then you 
 > > would break a lot of setups.
 > 
 > Agreed.
 > 
 > >   I believe that the "working directory" and "root config directory" 
 > > concepts should have been dissociated.
 > 
 > Also agreed. :)  I plan to send some feature requests to the 
 > bind-users list based on the discussions in this thread. If you're 
 > interested in this topic I'd suggest that you follow the discussion on 
 > that list.

Wish I had the time, maybe next month.  If there were a 'logdirectory'
option, defaulting to 'directory' as now, that would solve this whole
POLA issue for stragglers from bind 4 and others expecting debug and
query logging to work as per rndc(8) in an out-of-the-box setup. 

 > I have an (unreviewed) patch to add a debug-only option at 
 > http://dougbarton.us/bind-debug-only-channel.diff if anyone wants to 
 > experiment with this. Using that patch I was able to do this:
 > 
 > logging {
 >          channel our_debug {
 >                  file "/var/log/named.run";
 >                  severity dynamic;
 >                  print-time yes;
 >                  debug-only yes;
 >          };
 >          category default { default_syslog; our_debug; };
 >          category unmatched { null; };
 > };
 > 
 > Which duplicates the default logging configuration except that you can 
 > now specify the location for the named.run file (or give it another 
 > file name, etc.).

So debug-only would give the same functionality as that default_debug
special property (log if trace > 0) to other channels as desired, right?

 > >  Another idea would be to add a final "options { directory 
 > > "/var/run/named"; }; " statement at the end of the file -- from the BIND 
 > > sources it appears that there is a callback function which may pickup 
 > > this final statement in order to make it the current working directory 
 > > for the named process.
 > 
 > The problem is that when you do a reconfig or a reload named won't be 
 > able to see its configuration file.
 > 
 > >  Oh, and in the idea that we should keep the default configuration as 
 > > simple as possible for the average user and for whatever scenario, here 
 > > is my proposal:
 > > 
 > >         dump-file       "/var/run/named/named_dump.db";
 > >         statistics-file "/var/run/named/named.stats";
 > 
 > This idea is not without merit, but I actually have them separated for 
 > a reason. The reason is sort of an "intermediate" level thing, but if 
 > you want to dump the db or the stats more than once and keep more than 
 > one version around it's more convenient to do this in a separate 
 > directory. Also the assumption is that /var/run is supposed to be 
 > cleaned out at each boot, and I wouldn't want to lose those files.

Well I'm comfortable with the directory setup as is, only excepting the
desire expressed here for somewhere standard as supplied that bind can
write its other log files to.  So far I only know about named.run and
named.recursing (which I also tried, because it was there :) 

 > >   I'm not sure what happens when the user toggles tracing / query 
 > > logging (with rndc) -- where would these files go by default ?

Currently, named tries to open named.run in its 'working directory', ie
directory "[/var/named]/etc/namedb" by default, owned by root.  Try
'rndc trace' and tail /var/log/messages and you may see "isc_log_open
'named.run' failed: permission denied" ono, at bind 9.3.4-P1 anyway.

 > That depends on how you have syslog configured. If you have no other 
 > logging configured and you do 'rndc querylog' to toggle it on it will 
 > go to syslog with daemon.info. Unfortunately, FreeBSD's default 
 > configuration doesn't log that by default. One could argue that it 
 > should, but I really don't want to open that can of worms. If you want 
 > to give that a try you could change *.notice in syslog.conf for the 
 > /var/log/messages file to *.info, then /etc/rc.d/syslogd restart. (Or 
 > uncomment the all.log option, etc.)

Scary :)

Thanks for the detailed explanations, Doug.  Much appreciated.

cheers, Ian

PS sorry about your direct mail bouncing off our ancient mailserver's
antispam (mis)config.  To be retired any day now, but fixed anyway.