Forge Home


10,316 latest version

3.5 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 0.0.2 (latest)
  • 0.0.1
released Mar 7th 2013

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'jhr-nsd3', '0.0.2'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add jhr-nsd3
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install jhr-nsd3 --version 0.0.2

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Tags: debian, dns, hiera, nsd


jhr/nsd3 — version 0.0.2 Mar 7th 2013


A nsd3 management module.


Apache 2.0, which should be in this directory.



Please log tickets and issues on Github

Theory of operation

There's something of a technical ramble here but the somewhat shorter version looks a lot like this:

I'm assuming you have a directory filled with zonefiles with names of the format '' and that it's under git-based version control. If you've not got something like that, you can start now, or spend some time modifying the code outlined in the above weblog post such that it's triggered on a change in a different file.

So. You make a change to a zonefile, push it, and through the repo being on the master nameserver, or via a post-commit hook, the state of the zonefile directory changes on your master. On the next puppet run, the module picks up that change and triggers a zone-reload in NSD.

Adding or removing a zone. Edit the file domain-list in nsd3/files/code and push that change. On the next puppet run, the module picks up that change and triggers a config-file rebuild. If you've added a zone, you did remember to create the appropriate master zonefile, right?

Why does the list of domains have to travel separately? Because there has to be some out-of-band way of signalling secondary nameservers that they should be pulling data for a fresh zone. Or stop pulling data for a now removed zone.

Things you will need to change

  • The names attached to the static parts of the config files in nsd3/files. This should be the hostname(s) of the master (and slave) nameservers. For instance 'arthur-nsd.head' and 'ford-nsd.head'.

  • The list of domains/rDNS in nsd3/files/code/domain-list.

  • The IP addresses of your master and slave nameservers in nsd3/files/master.yaml & slave.yaml (You may not need to care about 'outbound-addr' if your servers only have one NIC. Our kit has multiple NICs and a bureacratic firewall policy, so answers from unexpected addresses = quite bad)

  • The mail addresses in nsd3/files/code/ and