Difference between revisions of "Nsd"

From ArchWiki
Jump to: navigation, search
(Starting and running nsd: Change to nsd user instead of root)
(Testing nsd: new section)
 
(15 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
[[Category:Domain Name System]]
 
[[Category:Domain Name System]]
Nsd is an authoritative DNS resolver.
+
[https://www.nlnetlabs.nl/projects/nsd/ NSD] is "an authoritative only, high performance, simple and open source name server."
  
 
==Installation==
 
==Installation==
  
Install {{Pkg|nsd}}:
+
[[Install]] the {{Pkg|nsd}} package.
pacman -S nsd
+
  
 
==Migration to nsd for bind users==
 
==Migration to nsd for bind users==
Line 13: Line 12:
 
  /usr/share/doc/nsd/NSD-FOR-BIND-USERS
 
  /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:
+
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]].
  
[[unbound]]
+
==Initial setup==
  
==Initial Setup==
+
Most likely you will run nsd with a DNS caching servers such as [[Unbound]]. So, to avoid void conflicts, this configuration use port 53530 for nsd, since port 53 is used by the DNS caching server. nsd will listen for requests on ''localhost''. Additionally, the only firewall 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.
  
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.
+
When installed, a commented sample configuration file is placed at {{ic|/etc/nsd/nsd.conf.sample}}. Below is a minimal working example:
  
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.
+
{{hc|/etc/nsd/nsd.conf|
 
+
server:
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.
+
    server-count: 1
 
+
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:
+
 
+
## NSD authoritative only DNS
+
## nsd.conf .:. https://calomel.org
+
## Primary or "Master" NSD server
+
#
+
# The directives "notify" and "provide-xfr" are only needed if you are also going to setup
+
# a secondary NSD server. Uncomment out these lines to use them.
+
server:
+
  # uncomment to specify specific interfaces to bind (default all).
+
 
     ip-address: 127.0.0.1
 
     ip-address: 127.0.0.1
  # port to answer queries on. default is 53.
 
#    port: 53
 
 
     port: 53530
 
     port: 53530
  # Number of NSD servers to fork.
+
     do-ip4: yes
     server-count: 1
+
  # listen only on IPv4 connections
+
    ip4-only: yes
+
  # don't answer VERSION.BIND and VERSION.SERVER CHAOS class queries
+
 
     hide-version: yes
 
     hide-version: yes
  # identify the server (CH TXT ID.SERVER entry).
 
 
     identity: "Home network authoritative DNS"
 
     identity: "Home network authoritative DNS"
  # The directory for zonefile: files.
+
     zonesdir: "//etc/nsd3"
     zonesdir: "/etc/nsd3"
+
key:
key:
+
    name: "''keyname''"
  name: "sec_key"
+
    algorithm: hmac-md5
  algorithm: hmac-md5
+
    secret: "''secretkey''"
  secret: "6KM6qiKfwfEpamEq72HQdA=="
+
zone:
zone:
+
     name: "''example.com''"
     name: myhomenet.com
+
     zonefile: "''example.com.zone''"
     zonefile: myhomenet.com.zone
+
}}
  # notify: 10.0.0.222@53 sec_key
+
 
  # provide-xfr: 10.0.0.222 sec_key
+
See [https://calomel.org/nsd_dns.html] for more examples.
zone:
+
    name: 0.0.10.in-addr.arpa
+
    zonefile: 0.0.10.in-addr.arpa.zone
+
  # notify: 10.0.0.222@53 sec_key
+
  # provide-xfr: 10.0.0.222 sec_key
+
# Logging
+
#logfile: "/etc/nsd/nsd.log"
+
# Do not uncomment these lines as logging in nsd is not currently implemented
+
#
+
## NSD authoritative only DNS
+
## nsd.conf .:. https://calomel.org
+
## Primary or "Master" NSD server
+
  
 
==Starting and running nsd==
 
==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.
+
Before starting up nsd you can check the zone files using the ''nsd-checkconf'' command with the zone file name as a parameter.
  
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 {{ic|/var/db/nsd/nsd.db}}):
+
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:
  
  nsdc rebuild
+
  # nsd-control reload
  
In order to start nsd then type as root:
+
In order to start nsd, [[start/enable]] the {{ic|nsd.service}} systemd service.
 
+
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==
 
==Testing nsd==
Line 107: Line 59:
 
where w.x.y.z is a local address within the LAN.
 
where w.x.y.z is a local address within the LAN.
  
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:
+
== Configuring unbound ==
  
local-zone: "10.in-addr.arpa." nodefault
+
Once this is working then if you are running [[unbound]] as the caching recursive server then you can switch the unbound configuration 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:
  
  stub-zone:
+
  local-zone: "''example.com''" nodefault
        name: "mdylocalnet.com"
+
        stub-addr: 127.0.0.1@53530
+
  
 
  stub-zone:
 
  stub-zone:
         name: "10.in-addr.arpa"
+
         name: "''example.com''"
 
         stub-addr: 127.0.0.1@53530
 
         stub-addr: 127.0.0.1@53530
  

Latest revision as of 17:26, 16 April 2016

NSD is "an authoritative only, high performance, simple and open source name server."

Installation

Install the nsd package.

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.

Initial setup

Most likely you will run nsd with a DNS caching servers such as Unbound. So, to avoid void conflicts, this configuration use port 53530 for nsd, since port 53 is used by the DNS caching server. nsd will listen for requests on localhost. Additionally, the only firewall 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.

When installed, a commented sample configuration file is placed at /etc/nsd/nsd.conf.sample. Below is a minimal working example:

/etc/nsd/nsd.conf
server:
    server-count: 1
    ip-address: 127.0.0.1
    port: 53530
    do-ip4: yes
    hide-version: yes
    identity: "Home network authoritative DNS"
    zonesdir: "//etc/nsd3"
key:
    name: "keyname"
    algorithm: hmac-md5
    secret: "secretkey"
zone:
    name: "example.com"
    zonefile: "example.com.zone"

See [1] for more examples.

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 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:

# nsd-control reload

In order to start nsd, start/enable the nsd.service systemd service.

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:

drill @127.0.0.1 -p 53530 mylocalmachine1.myhomenet.com
drill @127.0.0.1 -p 53530 -x w.x.y.z

where w.x.y.z is a local address within the LAN.

Configuring unbound

Once this is working then if you are running unbound as the caching recursive server then you can switch the unbound configuration 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: "example.com" nodefault
stub-zone:
       name: "example.com"
       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.