I’m successfully signing my own domain name with DNSSEC for months. At first I started with manual signing with the Bind tools, then I tried the dnssec-tools software, and finally ended up with OpenDNSSEC; just for playing around for trying different tools. Maybe in a future post I could write a comparison between them.

Thanks to the integration of OpenDNSSEC with any PKCS-11 HSM, I tested with one I already had for digital certificates: an Aladdin USB eToken.

My domain name (vulcano.cl) is served by an external server which I don’t have physical access (impossible to attach an HSM to it) and I don’t manage (no trust to leave the keys in the server). That said, I’m using a local machine (my own laptop, actually) to do the signing, and then transfering automatically the signed zone to the primary dns server every time there’s a resign.

In my current setup I use a Fedora 13 Linux distribution, an Aladdin eToken PRO 64k with the driver 5.00.28 for CentOS 64 bits version, and OpenDNSSEC 1.1.2 compiled from source. I use the HSM only for the KSKs (I’m not sure how many keys it can handle) and I have a SoftHSM repository for the ZSKs. The zone is uploaded to the primary nameserver via ssh using a post-signing script, a script is run after the signing process finishes. My server uses NSD as DNS authoritative server software.

The eToken was pretty straightforward to make it work, once I was able to obtain the right drivers. Aladdin doesn’t have a download page, but you must obtain the drivers with the distributor who sold you the eToken. You should ask them for the last version. As I stated before, the pkiclient-5.00.28-0.x86_64.rpm package worked perfect. It installs a handy graphical application that loads as a task icon in KDE. Every time I plug the eToken I can open the “eToken PKI client” with several options like format, change PIN, rename it, view information, etc. The DNSSEC keys are shown as “Orphaned objects”, maybe because the PKI client waits to see only certificates and not a key by its own.

I have 2 1024 RSA’s KSKs in the eToken using ~24k bytes out of 64k. I haven’t tested it to find out how many keys it can store, but I think that much space it’s used by metadata and the particular eToken’s storage format.

The tests with hsmspeed are given 1.18 sig/s with 1 thread, 1 signatures per thread (RSA 1024 bits).

OpenDNSSEC 1.1.2 doesn’t allow “offline repositories”, meaning that even when my zone didn’t need the KSKs or a resign with them, I have to plug the eToken before the ods-control starts. My KASP parameters are very loose, so I only must take care every one or two days to plug the eToken, start manually the ods-control, and wait to have an updated zone when is needed.

(Special thanks to Sebastian Castro @secastro for his suggestions and corrections to his post)