Rick Moen wrote:
The administrative tools and some of the procedures take a little getting used to. I have some notes that I can send if you ever need them.
I'm no bind9 expert, but I didn't find nsd3's workflow substantially different, other than nsd.conf struck me as a good deal more simple, sensible and consistent than did named.conf. FWIW here are the notes I prepared for coworker bind9 refugees: After editing master/com.example.zone, do this:: nsdc rebuild nsdc reload VISUAL=vi etckeeper commit # describe change & give your name Note that nsd MUST BE RUNNING when the rebuild is issued, or it will not DNS NOTIFY the associated slaves. If that happens, the slaves will serve the old zone until they time out and initiate an AXFR/IXFR on their own. For this reason, using "restart nsd3" after a master zonefile update is wrong -- it amounts to nsdc stop+rebuild+start:: restart nsd3 # WRONG! nsdc stop # ALSO WRONG! nsdc rebuild nsdc start Note that "restart nsd3" is this in-house upstart job. In upstart-land, "reload foo" is hard-coded to mean "kill -HUP <foo's PID>" (sigh). I wrote it because, when I first rolled out nsd, it seemed like a "clever" move to replace a 100-line sysvinit script with a four-line upstart one (and gain automatic restart if nsd heisencrashed). start on runlevel [2345] stop on runlevel [!2345] respawn # This DOES NOT WORK because even with -d, nsd will change PID every # time you HUP (nsdc reload) it, and there is no way for upstart to # deal with that. No, expect fork won't work, because that expects # one extra fork -- what happens when you HUP again next week? #pre-start script #install -donsd /var/run/nsd3 #exec nsdc rebuild #end script #exec nsd -d # This is icky, but does work. pre-start script install -donsd /var/run/nsd3 nsdc rebuild exec nsdc start end script post-stop exec nsdc stop PS: I apologize for my part in hijacking/derailing this thread.