I mentioned back in 2010 that my first impression of OpenDNSSEC wasn’t bad, but I changed my mind when I had to maintain three large installations a few years later and pledged I wouldn’t do so again.

It’s seldom I speak negatively about a particular piece of software; if a program is good I will say so, but otherwise I’ll simply not mention it. I’m making an exception, in spite of OpenDNSSEC having become an NLnet Labs project – the brilliant people who bring us top-notch DNS servers NSD and Unbound.

Note: I originally forgot to mention my notes pertain to a much older, no-longer maintained version of OpenDNSSEC. The software has had significant changes done to it meanwhile, so my complaints may well no longer be valid. Furthermore, I inaccurately stated SoftHSM is an NLnet Labs project: it is an independent project with its own project owners and developers.

Here were four paragraphs detailing the issues we had with the program, but: water under the bridge. I will dwell a bit on the documentation though. OpenDNSSEC’s documentation has gone from one ill-maintained wiki to the next only to meanwhile have even lost all images; I’ve lost the love to report it. For SoftHSM the situation is even worse – what’s termed ‘documentation’ is pretty useless. Just go ahead and compare NSD’s or Unbound’s documentation to that of OpenDNSSEC or SoftHSM. Apropos SoftHSM: during an unrelated experiment about a year ago, I dropped 1,000 keys into a SoftHSM key store which resulted in 655,138 stat(2) system calls when signing a three-record zone; just look at the increasing time required to generate keys. I couldn’t even be bothered to report this as a bug, nor this. I’m sorry.

My time at the company was over and I stopped consulting for them so I wasn’t directly involved, thankfully, but tangentially got to hear about countless OpenDNSSEC enforcer failures, signers which crash, and even one or two unscheduled rollovers occurring on the spur of the moment.

I know there are some people who use OpenDNSSEC for a zone or two, and I know it’s used by some TLDs (who typically have relatively few but large zones), but my experience with the software over the years has been suboptimal, and I have once or twice reccommended against using it.

Roughly two years ago my customer asked me to return as they were having issues with the signing system, but I refused: I wouldn’t touch the existing installation but would gladly return to implement a new system.

“New” was easier said than done because an eventual migration came with one absolute blocking feature: the keys used for DNSSEC KSKs are stored on a slew of Thales/Entrust HSMs and an absolute prerequisite for migration was that KSKs were to be reused and not roll until ordered to.

After a bit of experimentation and different tests with BIND (for which DNSSEC Policy was on the horizon) and Knot-DNS, it turned out the latter had no apparent issues talking PKCS#11 to the installed HSMs, so the future of the project was clear: Knot-DNS would become the signer.

Knot-DNS, like BIND can be a bump-in-the-wire signer, which is how we use it. Knot implements a Key And Signing Policy (KASP) system such as that which was used in OpenDNSSEC, and we were able to configure the new signer according to our requirements, so we were basically good to go.

policy:
  - id: automatic
    keystore: thales
    manual: off
    ksk-shared: off
    algorithm: rsasha256
    ksk-size: 2048
    ksk-lifetime: 360d
    zone-max-ttl: 86400
    dnskey-ttl: 3600
    propagation-delay: 120
    rrsig-lifetime: 30d
    ...

It took a while for the project to actually kick off, enterprise being enterprise, but we’ve meanwhile successfully migrated two of three largish OpenDNSSEC installations to Knot-DNS. (Just in time BTW, because the last OpenDNSSEC installation is logging that keys can no longer be created … I’m crossing my fingers it’ll hold out another fortnight.)

New software means new features (and often also new bugs, but so far so good), and one already now greatly appreciated feature of the new environments is support for Catalog Zones, which Knot also has, and in particular how Knot automates adding member zones to a catalog. BTW, DNS Catalog Zones has just been published as RFC 9432.

Knot’s logs are descriptive and are easy to read (important when I’m trying to find out what the server is doing), and it’s documentation is good. The Knot developers react quickly and helpfully on the mailing list, and are open to new ideas:

• code I contributed to have keymgr produce JSON was merged in short order

• a request for a CKA_LABEL to be added to keys generated via PKCS#11 was implemented in short time

  $ preload -S cklist -n --cka-id=20ecaf71fd4c679166af99c5513721164afa2e3c | grep _LABEL
    CKA_LABEL "j01.example. KSK"
  

And now? I’m satisfied. The new Knot signer is performing well, and the lack of surprises to date is refreshing. It is of course early days, but I’m confident for the future.