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

Fri Jun 8 17:07:30 UTC 2012

Hello community,

To minimize downtime to 0 you can configure one NSD, or BIND server for 
that matter,
as a stealth/hidden name server. You configure all the public facing 
name servers as
slaves for the hidden one. If you have a lot of zones before starting 
the slave you can
copy the zone files, rebuild the database and start NSD. I didn't tried 
this but I don't see
why it wouldn't work.

As for best practices I suggest you read the NLnet Labs publication 
called DNS Threat
Analysis [1]. The publications presents an hierarchical attack tree to 
map DNS security
threats.

Another useful resource is the RFC 2870 - Root Name Server Operational 
Requirements [2].
I can tell that you don't run a Root Server but it sure can help taking 
the right decisions for
you particular case.

[1] - http://www.nlnetlabs.nl/downloads/publications/se-consult.pdf
[2] - http://www.icann.org/en/groups/rssac/rfc2870-01jun00-en.txt

Cheers and Goodwill,
|e

On 6/8/12 6:04 PM, Peter Andreev wrote:
>
>
> 2012/6/8 Alexandre Maumené <alexandre at enovance.com 
> <mailto: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 <mailto:alexandre at enovance.com>
>     W./ www.enovance.com <http://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
>     <mailto: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
>
>
> _______________________________________________
> nsd-users mailing list
> nsd-users at NLnetLabs.nl
> http://open.nlnetlabs.nl/mailman/listinfo/nsd-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20120608/8b574f9d/attachment.htm>