New BIND 9 chroot directories

[Charles Swiger]

On Oct 5, 2004, at 1:53 AM, Doug Barton wrote:
> On Mon, 4 Oct 2004, Charles Swiger wrote:
[ ... ]
> Please also keep in mind that I actually USED this configuration in 
> production on hundreds of name servers on a production enterprise 
> network for years with a variety of different kinds of name servers, 
> including authoritative, caching, forwarding, etc.

You bet.  It's worth noting that you've got a config that's heavily 
used in production.  That makes it a good candidate for FreeBSD's 
default values, as well as making you a good candidate to maintain 
named for FreeBSD.

> All that said, the defaults are just the defaults. The thing that 
> people really need to keep in mind is that if you want to change it, 
> you can.

Yes.

>> named_enable="YES"
>> named_flags="-u bind -g bind -c /etc/named.conf"
>>
>> ...in /etc/rc.conf and then do whatever you like under /var/named.
>
> Um, no. First off, the -g option never did what people thought it did, 
> and now does something entirely different in BIND 9.

The options I use now work fine under BIND 8, so it's unfortunate that 
somebody changed the meaning of that option, but the issue is probably 
moot now.

[ FWIW, I thought the -g flag controlled the group of the zone files 
created by a slave xfer, which is probably not significant in terms of 
security.  On the other hand, I always have a group associated with any 
user (that seems BSD convention now), and I don't see any harm in the 
notion. ]

> Also, if your config file is /etc/namedb/named.conf, it's pointless to 
> specify it in named_flags, as that is the compiled in default.

True.  /etc/named.conf is the location mentioned in the O'Reilly DNS & 
BIND books, and is a commonly used default location on other current 
systems today when not running chroot()ed, but I am quite happy to 
leave the layout of the chroot()ed config location of named.conf up to 
your judgement.  :-)

>> I suppose the situation could be improved by having some shell script 
>> which converts pre-chrooted named configs (at least the prior default 
>> config from 4.x) into the new layout, perhaps by creating symlinks 
>> from the current locations into the chroot tree under /var/named.
>
> If anyone wants to come up with something like that, I'm all ears, 
> however my guess is that the variety of input is so varied that such 
> an undertaking would be pointless.

You may be right.  One could turn the set of instructions in the 
20040928 UPDATING entry into a shell script, but it's probably safer to 
perform a manual series in order to note any errors or changes in path 
locations made by per-user customizations anyway.

-- 
-Chuck