First time config - room for improvement?
Mark Andrews
Mark_Andrews at isc.org
Thu Aug 28 14:05:58 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 :)
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
More information about the bind-users
mailing list