Actually there are a few things named will try to write into
/var/named/chroot/var/named (e.g. named.run is written there for tracing
when you turn it on with rndc).

However rather than giving global write to the directory I've found just
giving write permission to the user running named was sufficient - you
might have to touch the file to create an empty one if it weren't there
then set permissions on (again using the named.run example).

-----Original Message-----
From: bind-users-bounce@isc.org [mailto:bind-users-bounce@isc.org] On
Behalf Of Mark Andrews
Sent: Thursday, August 28, 2008 10:06 AM
To: Paul ****er
Cc: bind-users@isc.org
Subject: Re: First time config - room for improvement?


> The chroot setup was created using the bind-chroot package that CentOS
> has... Thank God The default setup there is to make
> $CHROOT/var/named/data writable, but $CHROOT/var/named is only root
> writable, however it strikes me that the config (which is based off

the
> sample as I said) is also setup to assume that $CHROOT/var/named/data

is
> where all the named writable stuff is going. Named is running as

named.
> Since we don't do dynamic updates I can't think of anything named

would
> be writing to $CHROOT/var/named
>
> Thanks for the symbolic link hint, I'll get that setup.
>
> On the named-checkconf I'm kicking myself, I have run this command in
> the past, but I over the past day I've been staring at rndc commands

to
> try and figure out which one I ran to check configs. Well, now I know



Well putting a zone file through named-checkconf will produce
these sorts of errors. You want to use named-checkzone to
check the master file.

e.g.
drugs:9.5.x 00:04 {1429} % named-checkconf junk
junk:1: unknown option '$TTL'
junk:4: unknown option 'serial'
junk:5: unknown option 'refresh'
junk:6: unknown option 'retry'
junk:7: unknown option 'expire'
junk:8: unknown option 'negative'
junk:10: unexpected token near end of file
drugs:9.5.x 00:04 {1430} % named-checkzone example junk
zone example/IN: has no NS records
drugs:9.5.x 00:05 {1431} %

> I ran a check of the zone file and got this:
>
> /var/named/chroot/var/named/domain.co.uk.zone.db:1: unknown option
> '$TTL'
> /var/named/chroot/var/named/domain.co.uk.zone.db:4: unknown option
> 'serial'
> /var/named/chroot/var/named/domain.co.uk.zone.db:5: unknown option
> 'refresh'
> /var/named/chroot/var/named/domain.co.uk.zone.db:6: unknown option
> 'retry'
> /var/named/chroot/var/named/domain.co.uk.zone.db:7: unknown option
> 'expire'
> /var/named/chroot/var/named/domain.co.uk.zone.db:8: unknown option
> 'negative'
> /var/named/chroot/var/named/domain.co.uk.zone.db:41: unexpected token
> near end of file
>
> I get the $TTL warning in the original config under BIND 9.5.0 (as I
> said, a mish-mash of versions), but so far as I know a $TTL ___ is a
> valid opener for a zone record.
>
> The opening reads
>
> $TTL 4d
>
> @ IN SOA hostname.domain.co.uk. address.domain.co.uk. (
> 2008082701 ; serial YYMMDDNN
> 24h ; refresh
> 2h ; retry
> 30d ; expire
> 4d ) ; negative caching ttl
>
> This is a carbon copy of the original record (bar serial number) with
> values taken from RFC 1972or 1932... Or some RFC. Under 9.5.0 these
> lines do not generate warnings.
>
> Likewise the end of the record is (and line 41) is:
>
> ns CNAME hostname
>
> I don't see an issue there either. Is it confused by ending on a CNAME
> not an A record i.e. it expects an IP?
>
> I was not aware it was possible to pull the version information in

other
> ways, interesting. However, as our company is part of a group our

group
> security policies would mean I have to change this setting anyway. Not
> that it means much, because CentOS (or rather, RedHat) is

back-patching
> old versions, the version number often doesn't accurately represent

the
> vulnerability level (see OpenSSL under CentOS 3.9).
>
> Named.root.hints is a tiny config pointing at the
> $CHROOT/var/named/named.root file which contains root hints, while the
> named.rfc1912.zones is, according to the comment in the file "ISC BIND
> named zone configuration for zones recommended by RFC 1912 section 4.1

:
> localhost TLDs and address zones"
>
> I'll have to check on dig, I'm not experienced with the command, bar
> pulling down root hints.
>
> The sample configuration covers SELinux, which is why it is writing
> everything to /data, apparently $CHROOT/var/named is bad,
> $CHROOT/var/named/data is okay.
>
> Named.pid is written under $CHROOT/var/run/named
>
> Since opinion is mixed on whether zone transfers offer any real
> security, but don't appear to be on the fact that DDNS is a pain in

the
> ass, I've chosen just to restrict transfers and leave it at that.
>
> Paul ****er
>
> -----Original Message-----
> From: Bill Larson [mailto:wllarso@swcp.com]
> Sent: 27 August 2008 19:15
> To: Paul ****er
> Subject: Re: First time config - room for improvement?
>
> On Aug 27, 2008, at 10:46 AM, Paul ****er wrote:
>
> > While I have worked with BIND 9.x before, I've never had to set it

up
> > from scratch. Due to a server migration I need to setup a new

instance
>
> > of BIND, but would prefer to start afresh due to the old config

being
> > a mish-mash of various BIND versions.
> >
> > Running on CentOS 5.2 I am using BIND 9.3.4 running within a chroot
> > environment. I've confirmed that the service can start so all looks
> > well having used the BIND samples under /usr/share/doc as a starting


> > point, but what I want to check is whether the config can be

improved,
>
> > have I missed any settings necessary to run a secure system
> > (especially important to me), is there anything here which might

bite
> > me in the ass later on, etc.
> >
> > I should note that the role of the BIND service is two-folder, in

one
> > instance it is acting as the authoritative name server for a domain,


> > in the other it is acting as a name cache for localhost.
> >
> > acl slaves
> > {
> > IPAddress;
> > IPAddress2;
> > };
> >
> > options
> > {
> > directory "/var/named"; // the default
> > dump-file "data/cache_dump.db";
> > statistics-file "data/named_stats.txt";
> > memstatistics-file "data/named_mem_stats.txt";
> > version "random text";
> > };
> > logging
> > {
> > channel default_debug {
> > file "data/named.run" versions 5 size 2M;
> > severity dynamic;
> > print-category yes;
> > print-severity yes;
> > print-time yes;
> > };
> > category lame-servers { null; }; };
> >
> > view "localhost_resolver"
> > {
> > match-clients { localhost; };
> > match-destinations { localhost; };
> >
> > recursion yes;
> >
> > include "/etc/named.root.hints";
> > include "/etc/named.rfc1912.zones"; };
> >
> > view "external"
> > {
> > match-clients { any; };
> > match-destinations { any; };
> >
> > recursion no;
> >
> > include "/etc/named.root.hints";
> >
> > zone "domain.co.uk.zone" {
> > type master;
> > file "domain.co.uk.zone.db";
> > allow-transfer { slaves; };
> > };
> >
> > zone "#.#.#.#.in-addr.arpa" {
> > type master;
> > file "domain.co.uk.arpa.db";
> > allow-transfer { slaves; };
> > };
> >
> > };

>
> From your configuration file I can see that you have the following
> directory structure in your chroot environment:
>
> $CHROOT/etc
> $CHROOT/var/named
> $CHROOT/var/named/data
>
> The "/var/named" and "/var/named/data" directories must be writable by
> the user that "named" runs as. All of the other directories must be

at
> least readable by this user.
>
> To insure that you can run "rndc reconfig" or "rnd reload" you will

need
> to have your "named.conf" file located in the $CHROOT/etc directory.

I
> simply make a symbolic link from the normal /etc/ named.conf file to
> this actual file in the chroot directory.
>
> Now, what happens when you run "named-checkconf" against your
> configuration file and "named-checkzone" against all of your zone

files?
> Do you receive any errors or warnings? I suspect not because you say
> that "named" starts up for you, but double check. Errors will stop
> "named" from starting. Warnings will give you messages in your log

file
> that you may want to clean up.
>
> Your configuration is quite simply, which is great. I am strongly of
> the opinion of following the KISS principle. You don't seem to have

any
> unnecessary directives, no "query-source" stuff, etc. You are hiding
> your "version.bind" information, which is reasonable, but be aware

that
> this isn't the only way to determine the version of BIND that you are
> running. Personally, I would get rid of the "match- destination"
> specifications. You don't need them and they make reading/debugging

the
> configuration more difficult.
>
> You have a phrase in your configuration of 'include "/etc/
> named.root.hints"', which makes me wonder what is in this
> "named.root.hints" file. You should have a specification of a "hints"
> zone and the specification of where this file resides. I suspect no
> problems, but double check it. There is a similar phrase for the
> rfc1918 zones. Double check this file too.
>
> I'm not sure of something, so try this out on your server. You have a
> recursive view defined for localhost. I'm not sure if this will get
> information for your two external zones. Just try running a "dig"
> command on your server for some of this external information just to
> make sure that you get it.
>
> I'm not sure about CentOS, but if this is running SE-Linux you have
> issues about what files the "named" can read/write. If so, you will
> need to deal with the filesystem ACLs too.
>
> Where is the "named.pid" file supposed to be written? From your
> configuration it will be in "/var/named". Is this what you want, or
> would you really want it in "/var/named/data" like your other data
> files?
>
> Your configuration doesn't allow DDNS updates. I'm assuming that you
> don't expect this activity otherwise you would have allowed for it.
>
> Bill Larson
>
>
>
>
> TNT Post is the trading name for TNT Post UK Ltd (company number:

04417047),
> TNT Post (Doordrop Media) Ltd (00613278), TNT Post Scotland Ltd

(05695897),TN
> T Post North Ltd (05701709) and TNT Post South West Ltd (05983401).

Emma's Di
> ary and Lifecycle are trading names for Lifecycle Marketing (Mother

and Baby)
> Ltd (02556692). All companies are registered in England and Wales;

registere
> d address: 1 Globeside Business Park, Fieldhouse Lane, Marlow,

Buckinghamshir
> e, SL7 1HY.
>
>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------