First time config - room for improvement?
Paul Cocker
paul.cocker at tntpost.co.uk
Fri Aug 29 07:53:08 UTC 2008
My humiliation is complete, many thanks :D
Paul Cocker
-----Original Message-----
From: Mark_Andrews at isc.org [mailto:Mark_Andrews at isc.org]
Sent: 28 August 2008 15:06
To: Paul Cocker
Cc: bind-users at 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 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),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 at isc.org
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