Note that nsd is not designed to do logging, despite the existence of a logging line in the nsd.conf example file. Attempting to uncomment the logging line will result in being unable to start nsd.

Note that nsd is not designed to do logging, despite the existence of a logging line in the nsd.conf example file. Attempting to uncomment the logging line will result in being unable to start nsd.

−

A sample nsd.conf is given here where the forward and reverse zone files are presumed to be in /etc/nsd3/ and named myhomenet.com.zone and 0.0.10.in-addr.arpa.zone:

+

A sample nsd.conf is given here where the forward and reverse zone files are presumed to be in /etc/nsd3/ and named myhomenet.com.zone and 0.0.10.in-addr.arpa.zone (Note that in nsd version 4 the sample file has new features enabled, but a pre-existing nsd.conf from version 3 should still work, but it is best to merge changes with the new config file:

Revision as of 10:33, 2 November 2013

Contents

Installation

Migration to nsd for bind users

Once the package is installed there are useful migration notes for users who currently run bind as their dns server in the file:

/usr/share/doc/nsd/NSD-FOR-BIND-USERS

Many users will wish to run nsd as their authoritative dns server concurrently with unbound as the validating, recursive, caching dns server on a single machine. It may be useful to refer to the wiki page for unbound at:

Initial Setup

More often than not nsd will be running concurrently with a recursive, caching dns server such as unbound. Usually dns servers will be listening on port 53 but the two services would conflict if they were listening to the same port. Hence if unbound was the main server answering dns queries on port 53 then it is sensible for added security to select a high private port number for nsd to listen on. Also if the only direct access to nsd will be from queries forwarded from unbound, then nsd can be configured to listen only to the localhost machine on the private port chosen, and is not then directly accessible from outside. This gives added security to the authoritative server. In the examples of configuration files here port 53530 is chosen as the listening port number for nsd.

If any firewall running on the machine blocks private port 53530 then this adds to security. The only port that then needs to be open for dns queries coming from external machines (or other machines on the same local network) is port 53.

It is perfectly possible to put the nsd.conf file as well as any zone files into /etc/nsd/ but it is also possible to place the zone files in a separate directory. So for the purpose of this wiki page assume that the zone files are in /etc/nsd3/ and if you have already been running bind previously then copying the zone files that worked with bind into /etc/nsd3/ should work without adjustment. There are sample configuration files in the web page at https://calomel.org/nsd_dns.html but the example here is for a single master zone only.

Note that nsd is not designed to do logging, despite the existence of a logging line in the nsd.conf example file. Attempting to uncomment the logging line will result in being unable to start nsd.

A sample nsd.conf is given here where the forward and reverse zone files are presumed to be in /etc/nsd3/ and named myhomenet.com.zone and 0.0.10.in-addr.arpa.zone (Note that in nsd version 4 the sample file has new features enabled, but a pre-existing nsd.conf from version 3 should still work, but it is best to merge changes with the new config file:

Starting and running nsd

Before starting up nsd you can check the zone files using the nsd-checkconf command with the zone file name as a parameter.

In version 3 in order to build the zone database that makes nsd run exceptionally quickly the database file must be rebuilt each time a zone or config file is changed, and the following command is executed as the nsd user (the daemon runs as nsd and that user must be able to read /var/db/nsd/nsd.db):

nsdc rebuild

However in nsd version 4 nsdc has been removed and a new command nsd-control replaces it. Refer to the doc file at /usr/share/doc/nsd/UPGRADING)

In order to start nsd then type as root:

systemctl start nsd

Once nsd has been tested then make nsd start at boot by typing:

systemctl enable nsd

If you were already running bind listening on port 53 and are moving over to unbound, then it is important to stop bind before starting unbound to avoid conflicts:

systemctl stop named
systemctl start unbound

and to make the correct services start at boot:

systemctl disable named
systemctl enable unbound

Testing nsd

nsd can be run concurrently with bind during the testing phase. You can check forward and reverse local lookups on the port at 53530 using:

Once this is working then if you are running unbound as the caching recursive server then you can switch the unbound config to forward queries from local machines on the same network to query nsd by using the following structure in unbound.conf (and see unbound), where it is assumed that nsd is listening to port 53530:

local-zone: "10.in-addr.arpa." nodefault

stub-zone:
name: "mdylocalnet.com"
stub-addr: 127.0.0.1@53530

stub-zone:
name: "10.in-addr.arpa"
stub-addr: 127.0.0.1@53530

Once the unbound.conf contains the above then restart unbound and check that local queries for the nsd zone entries works. Once it is all tested then you can switch unbound to listen on both 127.0.0.1 as well as on the external interface for the local network by having the lines in unbound.conf including:

interface: 127.0.0.1
interface: 10.0.0.1

where 10.0.0.1 is the ip address of the dns server running both nsd and unbound and providing local dns for other machines on the 10.x.x.x network.

The examples here all assume that only ipv4 is being used. Corresponding configurations for ipv6 should be included where necessary, and further details on the parameters for that can be found in the man files for the two packages as well as examples that can be found with web searches.

WAN facing dns

It is also possible to change the configuration files and interfaces on which the server is listening so that dns queries from machines outside of the local network can access specific machines within the LAN. This is useful for web and mail servers which are accessible from anywhere, and the same techniques can be employed as has been achieved using bind for many years, in combination with appropriate port forwarding in the network firewall machines, to allow incoming requests to access the correct machine.