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. nsd-control setup 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 { keys { keyname; }; }; statement zone: name: "example.com" zonefile: "key23.example.com." # the allow-transfer 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. nsd-control setup The rndc tool for BIND named needs a secret to communicate securely with the server. The NSD tool nsd-control can setup its secrets with the nsd-control-setup command. It uses public keys, and SSL connections.