From owner-freebsd-current@FreeBSD.ORG Tue Oct 5 05:53:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7EE6216A4CE for ; Tue, 5 Oct 2004 05:53:51 +0000 (GMT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6817F43D2D for ; Tue, 5 Oct 2004 05:53:51 +0000 (GMT) (envelope-from DougB@freebsd.org) Received: from lap (c-24-130-110-32.we.client2.attbi.com[24.130.110.32]) by comcast.net (rwcrmhc12) with SMTP id <2004100505535001400rfbive>; Tue, 5 Oct 2004 05:53:50 +0000 Date: Mon, 4 Oct 2004 22:53:50 -0700 (PDT) From: Doug Barton To: Charles Swiger In-Reply-To: <2EC1F982-1680-11D9-B1D0-003065A20588@mac.com> Message-ID: <20041004223818.I85445@ync.qbhto.arg> References: <200410041734.53316.freebsd@redesjm.local> <20041004181933.H96420@bo.vpnaa.bet> <2EC1F982-1680-11D9-B1D0-003065A20588@mac.com> Organization: http://www.FreeBSD.org/ X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Makoto Matsushita cc: freebsd-current@freebsd.org Subject: Re: New BIND 9 chroot directories X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2004 05:53:51 -0000 On Mon, 4 Oct 2004, Charles Swiger wrote: > On Oct 4, 2004, at 10:48 PM, Makoto Matsushita wrote: >> [ ...hier compliance... ] Yes, the named configuration file (I >> believe it is considered generally as important), master zone files >> (also important, at least for me), are located under "/var." >> >> So here's my question to all "running named with chroot sandobx" >> users: are you ok with such important file is under /var? As a whole, var is no more volatile than any other directory, although bits of it (like /var/run) are recreated at each boot. That said, your point about hier is well taken, and because most name servers will write out some files (even if it's just logs) then it was necessary to at least put the directories where files will be written on /var. Configurations that split volatile and non-volatile bits into seperate directories are possible, but IMO they are needlessly complicated. Also, different environments have different needs. In some environments master files are just as volatile as slaved files, so they need to be on /var too. 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. 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. > 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. 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. > Some people want all of the zone files in one place, others want to use s/ > and /m (or slave/ and master/). Zone file naming conventions also vary: some > append .rev and .db to zone files, some use just the former and not the > latter; etc. > > So long as the options support reasonable flexibility and do not break > backwards compatibility too much, any reasonable default is OK, and Doug as > maintainer is making a reasonable attempt to improve the security of a daemon > that many FreeBSD systems use. Yay! Thanks. > 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. Doug -- This .signature sanitized for your protection