Yes, it's patched, though only as far as P1 I believe.

I assume from your comments that recursive yes is the default for this

I haven't used memstatistics before, so I planned to run with it and
then gauge its usefulness and make changes from there.

On the rndc front I am not familiar with the options in named.conf for
it, I guess I will need to look them up.

The version is hidden due to security requirements of the group my
company belongs to. However, I wasn't aware tools existed that could
still mark you. Handy, thanks.

TSIG keys, those are used for DDNSEC, yes? As the zones being
transferred are public I'm not overly worried, I'm restricting transfers
because it's easy to do and I know how off the top of my head. Whether I
would secure it further depends on how easy that is (the sample config
has an example for internal zones I recall) and whether our secondary
name servers (hosted by our ISP) would agree to this.


Paul ****er

-----Original Message-----
From: [] On
Behalf Of Kevin Darcy
Sent: 28 August 2008 02:42
Subject: Re: First time config - room for improvement?

Paul ****er 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 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/" 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 "" {
> type master;
> file "";
> allow-transfer { slaves; };
> };
> zone "" {
> type master;
> file "";
> 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"

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

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

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.