First time config - room for improvement?

[Kevin Darcy]

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. 
Has that version been patched to protect against the Kaminsky attack?

You might want to try a "dig porttest.dns-oarc.net txt" test before you 
put this into production.
> 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; };
>         };
>
> };
>
>   
The match-destinations are superfluous, as is "recursion yes" in the 
recursive view.

Are you planning on actually *using* memstatistics? If not, I'd only 
define it if I intended to use it (i.e. to optimize performance or to 
troubleshoot some sort of memory-usage issue).

You're not logging much of anything by default, but if this is the same 
as what you're currently doing on your legacy installation, then I 
suppose there's no reason to change.

Ditto for the lack of any rndc capability (you have no "controls" 
statement).

Hiding your version doesn't really accomplish much of anything, since 
there are tools (such as fpdns) that can fingerprint your version anyway.

I know it's controversial, but personally I'm of the (apparently 
minority) opinion that restricting transfers of public zones doesn't 
really accomplish much of anything either. (We ran for years with zone 
transfers open, without any problems, until our security department 
decided it was "best practice" to restrict them). In any case, if you 
want proper authentication of zone transfers, you should probably 
generate and use some TSIG keys.

- Kevin