DNSSEC is complex, and it is difficult to deploy. As Paul Vixie (of DNS fame) writes:

DNSSEC is the worst design-by-committee effort I’ve ever seen, both in terms of how late it is, how fuzzy the goals have been, how often the goals have changed, and how complicated and heavy it is now that it is trying to be all- things-to-all- people.

DNSSEC ensures the integrity of the DNS data with asymmetric public key encryption. It is not intended to keep DNS data confidential (which would be quite stupid, as nobody would be able to connect to your services), nor does it improve the availability of your DNS data. (It might even degrade it.) If a caching name server receives an answer from an authoritative server and DNSSEC validates the answer successfully, then you know that:

  • The reply came from an authoritative source.
  • The reply has not been altered between the authoritative name server and your caching name server.
  • If the authoritative name server says that a host does not exist (NXDOMAIN), you can believe it.

DNSSEC ensures the integrity of the data only between name servers that implement DNSSEC, but not beyond: it is not end-to-end; it will typically not secure DNS traffic all the way to your workstation. DNSSEC protects clients from forged DNS data by adding additional information to DNS replies. The information allows clients to check that the response is authentic and complete.

To achieve this, DNSSEC uses public/private keys to sign zone data, and it adds the signatures and other DNSSEC information to the zone file, in the form of several additional DNS resource records. The process for signing a zone manually (i.e. with BIND’s tools) is rather convoluted, and I won’t go into that here. What I will recommend however, is that you read through some of the presentations and articles and/or read Chapter 22 of my book Alternative DNS Servers, where I discuss this in quite some detail, with lots of diagrams to help you along. (Sample diagram.)

What makes DNSSEC complex is the management of private and public keys you need for signing zones. This complexity grows when you want to use different keys for signing different zones (highly recommended!) and when keys start expiring and you have to roll them over.

Enter OpenDNSSEC. OpenDNSSEC is an Open Source software which is able to handle the complete management of keys for signing zones including their roll over. Think of OpenDNSSEC as a “man-in-the-middle” between a hidden primary DNS server which contains one or more unsigned zones you want signed, and an external BIND or NSD server which then serves the zones signed by OpenDNSSEC. OpenDNSSEC takes an unsigned zone either via AXFR zone transfer (IXFR is currently not supported, but it is on their TODO list) or from zone files, adds the required signatures to the resource record sets (RRSets), and passes the signed zone (via files) on to the authoritative DNS server(s) that will serve the signed zones. All keys for zone signing are stored in a PKCS#11 HSM (Hardware Security Module). Fortunately for those of us who don’t (yet) own an HSM, the OpenDNSSEC project provides a software implementation (based on an Sqlite3 store) called SoftHSM. The installation of OpenDNSSEC is rather straight forward, although there are a large number of dependencies to be fulfilled. (Most of that is rather easy to set up, though.) Installation and configuration are well enough documented, as is the format of the XML configuration files. If you don’t have an HSM, start off by installing and configuring SoftHSM before starting OpenDNSSEC proper. The important bit here, is to initialize your HSM store with a

softhsm --init-token --slot 0 --label "OpenDNSSEC"

adapting the label on the slot to whatever you specify in OpenDNSSEC’s conf.xml.

<Repository name="softHSM">

If you already have DNSSEC keys (for BIND or NSD) you’d like to import, you can do so as well with the SoftHSM utilities; the manual describes how to do that. After that, I recommend you go back to the Using OpenDNSSEC document to launch the system with an initial zone loaded from a file, until you get the hang of how it all works. I also found a diagram of the architecture useful. If you are more of an audio-visual person and prefer to watch a few hours of talks, there is a series of OpenDNSSEC training videos you may enjoy. OpenDNSSEC works well. The only thing I haven’t been able to get working yet is the signing of zones retrieved via AXFR; the zone is read and stored, but the signer refuses to kick off. Zones read from the file system work fine. Update: they work fine if you don’t, as I did, have old useless crud (A6 RR) in the masters you’re testing with. Sigh. If you have a requirement for serving DNSSEC zones, I very much recommend you have more than just a glance at OpenDNSSEC.


DNS, dnsbook, and dnssec :: 14 Sep 2010 :: e-mail