NSD for BIND users
------------------
Contents
1.  Zone compiler.
2.  Authoritative only.
3.  Config file format.
4.  Keys not per IP address.
5.  NOTIFY of NS-entries.
6.  Less options.
7.  Master-Slave meshes.
8.  AXFR behaviour.
9.  Ports.
10. nsdc needs no secret to talk to the server.

Please see the README for general information. This document
assumes the reader is familiar with BIND tools and explains
the differences between BIND and NSD.

1. Zone compiler.

In its memory NSD maintains fragments of data that are ready to put 
'on the wire' without a lot of additional work by the server. Those 
fragments of data need to be compiled from the zone file. Therefore 
NSD has a zone compiler that translates the text format zone files
into a binary format database file that the server reads.

2. Authoritative only.

NSD only serves authoritatively. So, NSD does not provide caching, and
does not provide recursion, or resolver functionality. NSD can, in other
words, function as master or slave server.

This also means no root zone '.' type hint is used; leave out the root
zone entirely from your configuration. NSD does not cache the root.
NSD will not provide an upward referral in case an authoritative answer 
cannot be found. Because of this design choice (see Appendix B.1 of the 
REQUIREMENTS file) NSD does not need to maintain knowledge of the 
root-server set and there is no need for a root.hints file.
Also leave out localhost zones from NSD config.

3. Config file format.

The config file for NSD nsd.conf(5) is different from BIND named.conf(5).
See the manual pages for differences in syntax. The zone files with 
resource records have the same format however.

A short configuration file for BIND can look like this:

// Name server configuration named.conf
options {
	directory "/etc/dns";
	pid-file "/etc/dns/pid-file";
	dnssec-enable yes;
	listen-on-v6 { any; };
	recursion no;
};

// logging options for the DNS Server
logging {
	channel mainlog {
		file "/var/log/dns.log" size 10m;
		severity info;
	};
	category default {
		mainlog;
	};
};

// root hints
zone "." IN {
	type hint;
	file "root.servers";
};

zone "localhost" IN {
	type master;
	file "localhost.zone";
	allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
	type master;
	file "localhost.rev";
	allow-update { none; };
};

// authoritative server for example.com
zone "example.com" IN {
	type master;
	file "example.com.signed";
};

The equivalent configuration file for NSD is shown below. Note no
;s at the end of statements. No braces {}, and comment is with #.

# Name server config for NSD, nsd.conf
server:
	zonesdir: "/etc/dns"
	pidfile: "/etc/dns/pid-file"
	# dnssec is automatically enabled in NSD for signed zones.
	# ip6 is also enabled for NSD. (ip4-only: yes to turn off).
	# NSD does not do recursion.
	database: "/etc/dns/nsd.db"
	# logging clause comes here, no size or severity options.
	logfile: "/var/log/dns.log"

# NOTE: no root hints.
#   no localhost, and no 0.0.127.in-addr.arpa zone.

# authoritative server for example.com
zone:
	name: "example.com"
	zonefile: "example.com.signed"

4. Keys not per IP address.

BIND associates TSIG keys with an IP address. When communicating from/to
that address BIND will TSIG sign.  NSD associates TSIG keys with the
acl entries, when performing these functions NSD will sign with TSIG.
It is thus possible to configure NSD to use a different key for
notifications then for zone transfers, and a different key in one
direction from the other.
Additionally, NSD will reply TSIG signed queries with TSIG signed responses.

In BIND you might have a master that uses tsig for zone updates.

// ... rest of named.conf config file

// the TSIG key shared secret with the slave server
key key23.example.com. {
	algorithm hmac-md5;
	secret "6KM6qiKfwfEpamEq72HQdA==";
};

// when BIND communicates with this server, use the key
server 168.192.0.15 {
	keys { key23.example.com.; };
};

zone "example.com" IN {
	type master;
	file "example.com.signed";
	allow-transfer { key key23.example.com.; };
};

For NSD the master configuration would look a little different.

# ... rest of nsd.conf config file.

# The TSIG key shared secret with the slave server
key:
	name: "key23.example.com."
	algorithm: hmac-md5
	secret: "6KM6qiKfwfEpamEq72HQdA=="

# no need to list the server <addr> { keys { keyname; }; }; statement

zone:
	name: "example.com"
	zonefile: "key23.example.com."
	# the allow-tranfer and server statements from BIND rolled into one.
	provide-xfr: 168.192.0.15 key23.example.com.
	#
	# since NSD does not send notifies to the servers listed in the NS rrs,
	# the above server must be explicitly named to get notify messages.
	# see item 5, below. Note, the keyname is repeated here.
	notify: 168.192.0.15 key23.example.com.

5. NOTIFY of NS-entries.

BIND sends notification messages automatically to the servers named
in the SOA and NS entries of a zone. NSD does not. It sends only to
the 'notify:' entries in the config file. If you want NSD to send 
notifications to these servers, include notify: statements in the config
file for them.

6. Less options.

NSD has less options than bind has. It is designed to be small.

Some options that are *not* available in NSD are:
	provide-ixfr
	trusted-keys {}
	controls {}
	logging options
	lwres {}
	rrset-order
	recursion yes;
	cache options
	zone types: hint, forward, stub
	view clauses 
	
7. Master-Slave meshes.

NSD can be configure as both a slave of a (hidden) master and as
a master to further slaves as well.  This way meshes of name servers
can be created, like with BIND.

8. AXFR behaviour.

To do a manual AXFR, nsd-xfer will perform like the BIND tools. But,
the initial query for the SOA is done by TCP, where the BIND tools
use UDP for that SOA query. According to RFC (1034, 1035) specs, both
UDP and TCP for the initial SOA probe are OK.

An AXFR initiated by the built-in transfer process will not start with a
SOA query at all.  The first packet of the AXFR transfer will be used
to determine the SOA version number in that case.  This is a conscious
breach of RFC spec to ease implementation and efficiency.

Note that usually the built-in transfer process will request an IXFR, 
and preceed the IXFR with a UDP IXFR request like the RFC says.

9. Ports.

Nsd can be configured to run on another port than port 53. See the 
'port:' statement in the nsd.conf file.  Access control list elements
can be appended with @port_number to refer to a specific port only,
such as 10.11.12.100@8853. NSD will not set its source port for 
outgoing connections to be equal to the configured port, ephemeral 
ports are used for notify, ixfr and axfr requests to other servers.

10. nsdc needs no secret to talk to the server.

The rndc tool for BIND named needs a secret to communicate securely with
the server. rndc is designed to work on remote machines. The NSD nsdc tool 
does not need that. It works on the local machine, and sends signals 
instead of opening a socket. Since nsdc is on the local machine a secret
is not so opportune.