Before we jump into technical details there are a couple of assumptions:

— I assume that HSMs are already configured and partitioned. HSM installation is outside of scope of this guide since it’s a lengthy and pretty time consuming process which has nothing to do with OpenDNSSEC. It also involves a big chunk of work to be done on the access federation field (different teams accessing different partitions with different PEDs or passwords). SafeNet HSM’s documentation is quite solid though, so make sure this part is completed. In our setup, both HSMs run the latest software 6.2.0-15 and there is one partition created on both units called TEST. TEST partition is activated and we’re going to create High Availability group, add both HSMs to the HA group and allow NS-SIGN to access it;

— As you might have noticed, I decided to leave ZSKs to be handled by SoftHSM. One of the things that you’ll have to keep an eye on with network HSMs is the HDD space. The way it works with SafeNet is that you have an appliance with some fixed amount of disk space (let’s say 2MB). Then you create partitions and allocate space out of total amount for each partition (by default it’s equal distribution). So let’s assume we created five partitions 417274 bytes each. Normally, storing a pair of public/private key consumes very little, but with OpenDNSSEC we’re talking about a number of domains each storing a pair of public/private keys for both KSK and ZSK. It’s very important to understand how far you can go, so you’re not surprised after several years when you discover that you run out of space.

Let’s do some basic math: one domain, with both ZSK (1024) and KSK (2048) stored on HSM, will consume 2768 bytes, so with 417274 bytes partition you should be able to handle ~150 domains. However, during ZSK or KSK rollover, another pair will be temporarily created, and although ZSK/KSK rollover shouldn’t happen at the same time and OpenDNSSEC will purge expired keys after the rollover is completed, you’ll have to consider extra 2768 bytes per domain (for a period of time defined in <Purge> stanza in kasp.xml), which leaves you 75 domains. As you can see this isn’t much. That’s why I decided to keep SoftHSM for ZSKs to save some HSM space (which is not cheap to say the least!).

One of the disadvantages of keeping both storage engines is that you’ll have one more dependency to worry about should you consider to upgrade (for example to SoftHSM2), hence the choice is yours. Another option would be to store private keys in HSM and leave public keys aside (<SkipPublicKey/> option under conf.xml), but I’ve read that it’s very much dependent on the HSM provider and could lead to unexpected results. And one more option would be to use <ShareKeys/> under kasp.xml — that way you can share the same key for multiple domains.

NS-FEED needs to be able to send 53/udp to the signer and both slaves (to NOTIFY about zone changes). It has to accept incoming 53/tcp from the signer and both slaves (to allow zone transfers) and also it has to accept 53/udp from the signer (the signer will periodically poll the hidden master for zone changes):

NS-SIGN has to be able to send 53/udp and 53/tcp to the hidden master (to request and perform zone transfer from the hidden master). It has to be able to send 53/udp to both slaves (to notify slaves about zone changes). It has to accept incoming 53/tcp from both slaves (to allow zone transfers) and also it has to accept 53/udp from the hidden master:

NS-3 and NS-4 have to be able to send 53/tcp to the hidden master and the signer (to request zone transfers). They also have to accept incoming 53/udp and 53/tcp from anywhere to serve recursive DNS requests:

This is the second part in the series of articles explaining how to run NSD and OpenDNSSEC under FreeBSD 10.

Today, we’re going to deploy NS-FEED, NS-3 and NS-4 dealing with plain zones only. We’re not going to sign anything yet — we’ll deploy NS-FEED as a hidden master, configure it to feed NS-3 and NS-4 and configure NS-3/NS-4 to be masters for the ISP slave. This is probably the easiest part since configuration of NSD is quite easy.

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 10.9.128.1.

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 10.9.128.2.

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 192.168.128.1 and 192.168.128.2.

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

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.