First time config - room for improvement?
Paul Cocker
paul.cocker at tntpost.co.uk
Thu Aug 28 09:03:22 UTC 2008
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 :)
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 Cocker
-----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.
More information about the bind-users
mailing list