[nsd-users] Best practices to switch from BIND to NSD

Fri Jun 8 15:06:39 UTC 2012

Hi,

Sorry, I forgot my attachment and to include example of the output:

Example for one domain for the master: 
key:
    name: key_example.com
    algorithm: hmac-md5
    secret: "WG63kDcIXqPg0+5Ec8J7UdE+02E1gv7i2/+D//S9"
zone:
    name: example.com
    zonefile: zones/example.com/example.com
    notify: ip.slave.number.one key_example.com
    notify: ip.slave.number.two key_example.com
    provide-xfr: ip.slave.number.one key_example.com
    provide-xfr: ip.slave.number.two key_example.com
    outgoing-interface: ip.master.server.only
Example for one domain for the slave: 
key:
    name: key_example.com
    algorithm: hmac-md5
    secret: "WG63kDcIXqPg0+5Ec8J7UdE+02E1gv7i2/+D//S9"
zone:
    name: example.com
    zonefile: zones/example.com/example.com
    allow-notify: ip.master.server.only key_example.com
    request-xfr: AXFR ip.master.server.only key_example.com
    outgoing-interface: ip.slave.number.one

Kind regards,

Alexandre Maumené
----------------------------------------------------------
P./ +33.1.49.70.86.12
M./ alexandre at enovance.com
W./ www.enovance.com
S./ enovance-alexandre.maumene
eNovance SAS - 10 rue de la Victoire 75009 Paris - France
----------------------------------------------------------

----- Original Message -----

2012/6/8 Alexandre Maumené < alexandre at enovance.com > 

Hi, 

Thanks for all your quick answers. 

To begin with, I must say that I already had taken all your advices into 
account on BIND, but still, I'd like to give NSD a shot. 

I have several questions about various pieces of advice on this post: 

Is it long to rebuild entirely the database if I got ~17 000 DNS entries? I 
can accept a small downtime but I'll be interest if you have any advices to 
minimize it 

You can launch NSD on other port than BIND, prepare everything and measure how long it takes to start. After all is done simply stop BIND and start NSD on default port. 
I tried stop/start my NSD server with four big (millions of records) and about twenty small zones, it takes about 30 seconds to start. 

I already wrote a small python script to create a file containing a key and a 
zone for a domain. 

Example for one domain for the master: 

Example for one domain for the slave: 

I joined as attachement my Python script, its unittest and a example of a zone 
file definition, please feel free to review it and post your critics. 

I don't see any attachments. 

Since I had to generate these files while I add/remove zones, I'm asking 
myself if a master/slave configuration is really the best option? I mean I can 
also scp to all my NSD servers theses files and databases and not use the 
master/slave mechanism. 

But since I had to re-create these files when I add/remove some zones, I only 
benefit from the master/slave scheme when I update my zones. So I can launch 
the generation on a server and scp them to my others servers. Are there any 
disadvantages? 

Why not rsync? Linux has a bit strange but secure and powerful piece of software called csync2 based on rsync. 
We used to use ssh inside perl scripts to transfer about 100k zones, not a very good idea unless you have very fast disks. 

Trick question: do you have any thoughts about how to integrate (in the 
best way) puppet and NSD? We start to deploy as much as possible using puppet. 
(I'm not personnaly working but some collegues are). 

Kind regards, 

Alexandre Maumené 
---------------------------------------------------------- 
P./ +33.1.49.70.86.12 
M./ alexandre at enovance.com 
W./ www.enovance.com 
S./ enovance-alexandre.maumene 
eNovance SAS - 10 rue de la Victoire 75009 Paris - France 
---------------------------------------------------------- 

----- Original Message ----- 

2012/6/8 Jan-Piet Mens < jpmens.dns at gmail.com > 

> I'm a sys admin and currently working for a french hosting company. We 
> provide DNS services to our customers and at the moment we are using BIND 
> on Debian servers. BIND is a good software but we don't need a recursing 
> DNS for our public DNS, and we needed better security than what BIND provides. 

As you probably know, you can disable recursion in BIND, thus making it 
authoritative only. :) 

I would also recommend disabling additional-from-cache. 

> So I made the suggestion to replace BIND by another DNS software. 
> NSD appears to be the best alternative. 

NSD is indeed an excellent choice. There is one thing you must be aware 
of: you can't add/remove zones to NSD on-the-fly. You have to configure 
them in `nsd.conf' (or an included file) and then rebuild NSD's 
database. If you can live with that, you should be set to go. 

NSD also means no outgoing IXFR's and some additional cron jobs for "nsdc patch". 

May be TS should take a look on Knot DNS and Yadifa to choose the proper server for his tasks? 

> I'm currently writing some scripts to help the migration process, but I'd 
> like to know if something already exists to help me in this task. If not I 
> probably will make my scripts public and post it to this mailing-list. 

I'm not really aware of any scripts... Basically it's a matter of 
listing your zones and creating nsd.conf "zone" stanzas. A bit of 
[ ls | {awk|perl} ] will probably get you going pretty quickly. 

> I also would like to know if you have some best-practices about NSD in 
> general. 

I recommend you look at past postings in the archive of this mailing- 
list. 

Good luck! 

-JP 

PS: And if you do need recursive service somewhere on your network, I 
greatly recommend you look at Unbound, also by NLnet Labs. 

_______________________________________________ 
nsd-users mailing list 
nsd-users at NLnetLabs.nl 
http://open.nlnetlabs.nl/mailman/listinfo/nsd-users 

-- 
AP 

_______________________________________________ 
nsd-users mailing list 
nsd-users at NLnetLabs.nl 
http://open.nlnetlabs.nl/mailman/listinfo/nsd-users 

-- 
AP 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft_python.tar.gz
Type: application/x-compressed-tar
Size: 2156 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20120608/75a4b7cb/attachment.bin>