FW: First time config - room for improvement?

[Paul Cocker]

For the benefit of the list:

-----Original Message-----
From: Bill Larson [mailto:wllarso at swcp.com] 
Sent: 27 August 2008 19:15
To: Paul Cocker
Subject: Re: First time config - room for improvement?

On Aug 27, 2008, at 10:46 AM, Paul Cocker 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),TNT Post North Ltd (05701709) and TNT Post South West Ltd (05983401). Emma's Diary and Lifecycle are trading names for Lifecycle Marketing (Mother and Baby) Ltd (02556692). All companies are registered in England and Wales; registered address: 1 Globeside Business Park, Fieldhouse Lane, Marlow, Buckinghamshire, SL7 1HY.