1NSD for BIND users 2------------------ 3Contents 41. Zone compiler. 52. Authoritative only. 63. Config file format. 74. Keys not per IP address. 85. NOTIFY of NS-entries. 96. Less options. 107. Master-Slave meshes. 118. AXFR behaviour. 129. Ports. 1310. nsd-control setup 14 15Please see the README for general information. This document 16assumes the reader is familiar with BIND tools and explains 17the differences between BIND and NSD. 18 191. Zone compiler. 20 21In its memory NSD maintains fragments of data that are ready to put 22'on the wire' without a lot of additional work by the server. Those 23fragments of data need to be compiled from the zone file. Therefore 24NSD has a zone compiler that translates the text format zone files 25into a binary format database file that the server reads. 26 272. Authoritative only. 28 29NSD only serves authoritatively. So, NSD does not provide caching, and 30does not provide recursion, or resolver functionality. NSD can, in other 31words, function as master or slave server. 32 33This also means no root zone '.' type hint is used; leave out the root 34zone entirely from your configuration. NSD does not cache the root. 35NSD will not provide an upward referral in case an authoritative answer 36cannot be found. Because of this design choice (see Appendix B.1 of the 37REQUIREMENTS file) NSD does not need to maintain knowledge of the 38root-server set and there is no need for a root.hints file. 39Also leave out localhost zones from NSD config. 40 413. Config file format. 42 43The config file for NSD nsd.conf(5) is different from BIND named.conf(5). 44See the manual pages for differences in syntax. The zone files with 45resource records have the same format however. 46 47A short configuration file for BIND can look like this: 48 49// Name server configuration named.conf 50options { 51 directory "/etc/dns"; 52 pid-file "/etc/dns/pid-file"; 53 dnssec-enable yes; 54 listen-on-v6 { any; }; 55 recursion no; 56}; 57 58// logging options for the DNS Server 59logging { 60 channel mainlog { 61 file "/var/log/dns.log" size 10m; 62 severity info; 63 }; 64 category default { 65 mainlog; 66 }; 67}; 68 69// root hints 70zone "." IN { 71 type hint; 72 file "root.servers"; 73}; 74 75zone "localhost" IN { 76 type master; 77 file "localhost.zone"; 78 allow-update { none; }; 79}; 80 81zone "0.0.127.in-addr.arpa" IN { 82 type master; 83 file "localhost.rev"; 84 allow-update { none; }; 85}; 86 87// authoritative server for example.com 88zone "example.com" IN { 89 type master; 90 file "example.com.signed"; 91}; 92 93The equivalent configuration file for NSD is shown below. Note no 94;s at the end of statements. No braces {}, and comment is with #. 95 96# Name server config for NSD, nsd.conf 97server: 98 zonesdir: "/etc/dns" 99 pidfile: "/etc/dns/pid-file" 100 # dnssec is automatically enabled in NSD for signed zones. 101 # ip6 is also enabled for NSD. (ip4-only: yes to turn off). 102 # NSD does not do recursion. 103 database: "/etc/dns/nsd.db" 104 # logging clause comes here, no size or severity options. 105 logfile: "/var/log/dns.log" 106 107# NOTE: no root hints. 108# no localhost, and no 0.0.127.in-addr.arpa zone. 109 110# authoritative server for example.com 111zone: 112 name: "example.com" 113 zonefile: "example.com.signed" 114 1154. Keys not per IP address. 116 117BIND associates TSIG keys with an IP address. When communicating from/to 118that address BIND will TSIG sign. NSD associates TSIG keys with the 119acl entries, when performing these functions NSD will sign with TSIG. 120It is thus possible to configure NSD to use a different key for 121notifications then for zone transfers, and a different key in one 122direction from the other. 123Additionally, NSD will reply TSIG signed queries with TSIG signed responses. 124 125In BIND you might have a master that uses tsig for zone updates. 126 127// ... rest of named.conf config file 128 129// the TSIG key shared secret with the slave server 130key key23.example.com. { 131 algorithm hmac-md5; 132 secret "6KM6qiKfwfEpamEq72HQdA=="; 133}; 134 135// when BIND communicates with this server, use the key 136server 168.192.0.15 { 137 keys { key23.example.com.; }; 138}; 139 140zone "example.com" IN { 141 type master; 142 file "example.com.signed"; 143 allow-transfer { key key23.example.com.; }; 144}; 145 146For NSD the master configuration would look a little different. 147 148# ... rest of nsd.conf config file. 149 150# The TSIG key shared secret with the slave server 151key: 152 name: "key23.example.com." 153 algorithm: hmac-md5 154 secret: "6KM6qiKfwfEpamEq72HQdA==" 155 156# no need to list the server <addr> { keys { keyname; }; }; statement 157 158zone: 159 name: "example.com" 160 zonefile: "key23.example.com." 161 # the allow-transfer and server statements from BIND rolled into one. 162 provide-xfr: 168.192.0.15 key23.example.com. 163 # 164 # since NSD does not send notifies to the servers listed in the NS rrs, 165 # the above server must be explicitly named to get notify messages. 166 # see item 5, below. Note, the keyname is repeated here. 167 notify: 168.192.0.15 key23.example.com. 168 1695. NOTIFY of NS-entries. 170 171BIND sends notification messages automatically to the servers named 172in the SOA and NS entries of a zone. NSD does not. It sends only to 173the 'notify:' entries in the config file. If you want NSD to send 174notifications to these servers, include notify: statements in the config 175file for them. 176 1776. Less options. 178 179NSD has less options than bind has. It is designed to be small. 180 181Some options that are *not* available in NSD are: 182 provide-ixfr 183 trusted-keys {} 184 controls {} 185 logging options 186 lwres {} 187 rrset-order 188 recursion yes; 189 cache options 190 zone types: hint, forward, stub 191 view clauses 192 1937. Master-Slave meshes. 194 195NSD can be configure as both a slave of a (hidden) master and as 196a master to further slaves as well. This way meshes of name servers 197can be created, like with BIND. 198 1998. AXFR behaviour. 200 201To do a manual AXFR, nsd-xfer will perform like the BIND tools. But, 202the initial query for the SOA is done by TCP, where the BIND tools 203use UDP for that SOA query. According to RFC (1034, 1035) specs, both 204UDP and TCP for the initial SOA probe are OK. 205 206An AXFR initiated by the built-in transfer process will not start with a 207SOA query at all. The first packet of the AXFR transfer will be used 208to determine the SOA version number in that case. This is a conscious 209breach of RFC spec to ease implementation and efficiency. 210 211Note that usually the built-in transfer process will request an IXFR, 212and preceed the IXFR with a UDP IXFR request like the RFC says. 213 2149. Ports. 215 216Nsd can be configured to run on another port than port 53. See the 217'port:' statement in the nsd.conf file. Access control list elements 218can be appended with @port_number to refer to a specific port only, 219such as 10.11.12.100@8853. NSD will not set its source port for 220outgoing connections to be equal to the configured port, ephemeral 221ports are used for notify, ixfr and axfr requests to other servers. 222 22310. nsd-control setup 224 225The rndc tool for BIND named needs a secret to communicate securely with 226the server. The NSD tool nsd-control can setup its secrets with the 227nsd-control-setup command. It uses public keys, and SSL connections. 228 229