NSD and OpenDNSSEC under FreeBSD 10 [Part 1: Layout]

In the following set of articles I’m planning to explain how to run NSD and OpenDNSSEC under FreeBSD 10. Since the setup involves a number of servers and at the end becomes “kind of” complicated I’m going to split it into series of articles, so it should be easier to track the progress.

Before we jump into technical nuances let me try to explain what exactly I’m trying to achieve and why.

Prior to deploying DNSSEC our setup was pretty straight-forward — a pair of authoritative DNS servers: one acting as a master and another one as a slave, with extra slave on the ISP side. Nothing fancy — it just works. With the introduction of DNSSEC a number of questions arose.

The first one is obviously related to the security: authoritative servers are exposed to the Internet. If the server is compromised your DNSSEC keys are gone, so we need to segregate authoritative servers from the signing engine and store keys in some secure media.

The second question is manageability: you will be dealing with regular renewals of ZSK keys and occasional renewals of KSK keys. Multiply this by a number of domains and you quickly realize that you would like to automate it to the maximum possible extent (either by using scripts like zkt or something more intelligent like OpenDNSSEC). And although KSK renewal is still manual ZSK renewal should be fully automated.

The third question is flexibility: you should be able to construct a “tree” of DNS servers in a such way that will allow you to add additional slaves quickly without touching the master node.

So here is the setup that we’ll be working on. I’m sure it’s not fully bullet-proof and there are plenty of things to improve, but it’s a good start.


We’re going to configure four servers: NS-FEED, NS-SIGN, NS-3 and NS-4. ISP’s slave DNS is out of our control and is shown as a reference only, since it’s going to be one of the slaves. The operating system on all four servers is FreeBSD 10.0-STABLE (for those interested: KERNEL, make.conf, src.conf) with IPv6 disabled.

Here are more details about each server:

NS-FEED is our hidden master running NSD. It’s placed in the private LAN and it can only communicate with NS-SIGN, NS-3 and NS-4. This server will hold plain DNS zones. As you can see from the setup there are certain zones that don’t need to be signed — they will be fed directly to NS-3 and NS-4. Those zones that do need to be signed will be fed to NS-SIGN. This is the only server you need to access in order to make zone changes (add/delete/update records). The IP address of NS-FEED is

NS-SIGN is our signing server running OpenDNSSEC. It’s also placed in the private LAN and it can only communicate with NS-FEED, NS-3 and NS-4. The primary role of this server is to get a plain zone from NS-FEED, sign it and transfer it to NS-3 and NS-4. This is the server where the DNSSEC keys are stored in a secure store provided by SoftHSM. All operational tasks, like how and when to (re-)sign zones, using what algorithm and such are handled by OpenDNSSEC. SoftHSM cryptographic store is accessible through a PKCS #11 interface which gives you a possibility to replace it with the “proper” hardware HSM in the future. Keep in mind that from the DNS perspective NS-SIGN is not an authoritative server — although it does zone transfers over AXFR/IXFR and listens on port 53/udp/tcp it doesn’t actually hold any zones so if you try to query it with dig you’ll get no response. The IP address of NS-SIGN is

NS-3 and NS-4 are our publicly visible slaves running NSD. They are located in the DMZ, respond to 53/udp/tcp from the outside and keep plain and signed zones. However, they are not simple slaves (and this is where the fun begins), but also act as masters for other slaves (in our case it’s the ISP DNS). Without this hook, the slave from the ISP won’t be able to fetch zones, so you’ll have to feed it from NS-SIGN which you don’t want to do. IP addresses of NS-3 and NS-4 are and

Finally, ISP SLAVE DNS is the slave located on the ISP side. The IP address is

So, to summarize: there is a hidden master (NS-FEED) holding plain zones and distributing it further, there is a hidden signer (NS-SIGN) getting plain zones from NS-FEED, signing and distributing them to NS-3/NS-4, there are two public slaves (NS-3 and NS-4) acting as slave+master, and there is a slave on the ISP side.

Tomorrow we’ll start with the first task: configuring NS-FEED and NS-3/NS-4 to deal with plain zones.

Tags: , , , , , , ,

Leave a Reply