First time config - room for improvement?

[Kevin Darcy]

Paul Cocker wrote:
> 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
> setting.
>
> 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? 
TSIG is used for authenticating DNS transactions, using it doesn't 
obligate you to participate in the whole DNSSEC framework (e.g. to sign 
your zone), but it does require that you generate a shared key and then 
configure that key into both sides of the transaction (client and 
server). As with all static keys, one should probably re-key 
periodically as well.

- Kevin

> Thanks,
>
> Paul Cocker
>
> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
> Behalf Of Kevin Darcy
> Sent: 28 August 2008 02:42
> To: bind-users at isc.org
> Subject: Re: First time config - room for improvement?
>
> 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
>
>
>
>
>
>
> 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.
>
>
>
>
>