Hi,
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.
So I made the suggestion to replace BIND by another DNS software.
NSD appears to be the best alternative.
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 also would like to know if you have some best-practices about NSD in
general.
Thanks in advance.
Alexandre Maumené
Hi Alexandre,
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.
So I made the suggestion to replace BIND by another DNS software.
NSD appears to be the best alternative.
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 also would like to know if you have some best-practices about NSD in
general.
In general, NSD works well as a replacement for BIND as an
authoritative-only server. However, it lacks one feature, which may, or
may not be important to you: you cannot add zones to, or remove them
from NSD without a restart. If you want to add a new zone, or remove
one, you have to stop NSD completely, rebuild the zone database, and
then start it again. This will cause downtime. Keep this in mind when
making your switch to NSD.
Regards,
Anand Buddhdev
RIPE NCC
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. 
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.
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.
2012/6/8 Jan-Piet Mens <jpmens.dns@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?
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
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.
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?
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é
2012/6/8 Alexandre Maumené <alexandre@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.
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é
(attachments)
draft_python.tar.gz (2.11 KB)
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,