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

Peter Andreev andreev.peter at gmail.com
Fri Jun 8 15:04:39 UTC 2012


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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20120608/339f8040/attachment.htm>


More information about the nsd-users mailing list