[arch-general] [arch-dev-public] BIND10? No, thanks.

[Mike Cloaked]

On Sat, Mar 9, 2013 at 9:37 PM, Mike Cloaked <mike.cloaked at gmail.com> wrote:

> having read up a little more about authoritative and caching/recursive
> namerservers - it seems that a good alternative to bind (which I use on all
> my machines especially as a local authoritative DNS server for local
> networking) would be to use nsd as the pure authoritative nameserver in
> combination with unbound as a recursive caching nameserver. Both are
> packages available in arch. Once installed both have systemd service files,
> and it seems that setting them up is not too difficult - and I already had
> ldns installed (presume from the base install) so I guess having those
> three packages running would give a pretty good alternative to
> bind/dnstools though it would be nice to know if anyone is already using
> these and could post on how well they perform?
>
> I have spent some time since I posted about the issue of dns servers to
research a little more on migrating from bind to nsd/unbound as the dns
server/resolver for my own local network.

It is useful to note that the CVE vulnerability records for both nsd and
unbound are very favourable:

http://www.cvedetails.com/product/17420/Nlnetlabs-NSD.html?vendor_id=9613
http://www.cvedetails.com/product/18208/Unbound-Unbound.html?vendor_id=10197

Secondly the process of migration turned out to be fairly straightforward
once several advice pages from the web were looked at and answers to
questions I had about specific points on configuring my own system were
available on the user lists for both packages at:

https://open.nlnetlabs.nl/pipermail/nsd-users/
https://unbound.nlnetlabs.nl/pipermail/unbound-users/

It may be of interest that the approach I took was to set up unbound
initially on a non-critical machine that was not my main server but within
the local network first. Making this a caching/recursive dns server that
forwarded dns requests for the local network to the main LAN dns server
running on another machine was achieved by setting it up to listen on port
53 using advice from the mailing list plus initial tutorial instructions
from:

https://calomel.org/unbound_dns.html

To make the changeover once the configs were ready, the config file was
tested using the unbound-checkconf command, and then was simply a matter of:
systemctl stop named
systemctl start unbound

I made sure that /etc/resolv.conf had the line:
nameserver 127.0.0.1
and then ran tests using the drill command pointing at the internal server
to check forward and reverse lookups.

Once that was done I installed nsd on the main server machine and followed
the tutorial at https://calomel.org/nsd_dns.html plus the mailing list, and
some other google searches with nsd set to listen on a high private port.
Config testing is simple with nsd-checkconf, and then the service can be
started with:

systemctl start nsd

Again testing is simple with commands such as drill @127.0.0.1 -p xxxxx
www.cnn.com for example with xxxxx being the private port on which nsd is
listening.

Once that is tested, and with bind still running at the same time, and
listening on port 53, then unbound can be setup to listen on port 53 but
with a local stub zone for local dns requests pointing to nsd on the
private port to complete the service for both internal and external
addresses.

Once ready to test, and with nsd already running then:
systemctl stop named
systemctl start unbound

will enable dns request tests to be run with commands starting drill @
127.0.0.1 sitename.com

Once the tests are all working then the named service can be disabled and
nsd and unbound enabled so that they will start at boot.

Naturally there are a multitude of different ways to set up dns servers to
suit individual requirements, but I hope that relating my own experience is
useful to others. I now have no bind services running and all the dns
requirements have been running for the past few days with nsd/unbound
without any problems at all.

For anyone planning on migrating from bind to nsd/unbound it is useful to
work on this ahead of the time when bind may no longer be a supported
package in arch - my own experience suggests that nsd/unbound are excellent
alternatives, and indeed more secure than a single server running all dns
services, as separating the authoritative dns server from the
caching/recursive server provides potentially added security.

-- 
mike c