Tools no image

Published on March 21st, 2011 | by NJ Ouchn


OpenDNSSEC v1.2.1 released

OpenDNSSEC was created as an open-source turn-key solution for DNSSEC. It secures zone data just before it is published in an authoritative name server.


Many internet protocol hinge on DNS, but the data in DNS caches has become so vulnerable to attack that it cannot be relied upon anymore. The added authenticity in DNSSEC makes sure that such attacks have no effect.

That is, if

  • Zones are verified. Easy-to-deploy software for DNSSEC-aware name resolving (and caching) exists, for example Unbound or properly configured Bind9.
  • Zones are secured. Easy-to-deploy solutions for DNSSEC did not yet exist, at least not in open source. Hence the OpenDNSSEC project.

More on the problems with DNS and about deploying DNSSEC can be found in this white paper.

At present, the relationship between a secure zone and its parent cannot be automatic, in lieu of standards. This means that you will be required to communicate with your parent zone registrar about once a year, with any DNSSEC product.

What does OpenDNSSEC do?

OpenDNSSEC takes in unsigned zones, adds the signatures and other records for DNSSEC and passes it on to the authoritative name servers for that zone.

DNS is complicated, and so is digital signing; their combination in DNSSEC is of course complex as well. The idea of OpenDNSSEC is to handle such difficulties, to relieve the administrator of them after a one-time effort for setting it up.

Architecture overviewArchitecture overview

Key Storage (HSM)

All keys are stored in a Security Module and accessed via PKCS#11, a standard API (software interface) for communicating with devices which hold cryptographic information and perform cryptographic functions. To deploy OpenDNSSEC, an implementation of this API is required, e.g. a software implementation like softHSM or a hardware device like an HSM or a smartcard/token. Whether you should use a “soft” or “hard” implementation (or a combination thereof) depends on your security requirements. Some guidance can be found in the HSM Buyer’s Guide. A list of tested implementations can be found in the list of HSM vendors.


Version 1.2.1 of OpenDNSSEC has now been released.

  • ldns 1.6.9 is required for bugfixes.
  • dnsruby-1.52 required for bugfixes.


  • Auditor: ‘make check’ now works when srcdir != builddir.
  • Auditor: Include the ‘make check’ files in the tarball.
  • Enforcer: Fix the migration script for SQLite.
  • Enforcer: Increase size of keypairs(id) field in MySQL to allow more than 32767 keys; see MIGRATION for details.
  • Enforcer: Minor change to NOT_READY_KEY error message.
  • libhsm: Increase the maximum number of attached HSM:s from 10 to 100.
  • ods-ksmutil: Send trivial MySQL messages to stdout when exporting zonelist etc. Otherwise the resulting XML needs to be edited by hand.
  • ods-control: Fix for Bourne shell.
  • Signer Engine: Prevent race condition when setting up the workers and the command handler.
  • Signer Engine: Check if the signature exists before recycling it.
  • Signer Engine: Quit when there are errors in the configuration.
  • Signer Engine: Enable core dump on failure.
  • Signer Engine: Explicitly close down log msg with null.
  • Signer Engine: Backup state after writing output.
  • Signer Engine: Allow update of serial if internal structure is not initialized.

Tags: ,

About the Author

"Passion is needed for any great work, and for the revolution, passion and audacity are required in big doses"

Back to Top ↑