Skip to end of metadata
Go to start of metadata


During the years, we've had discussions about adding support for offline keys to OpenDNSSEC. There are at least two scenarios where you might want to use offline keys and OpenDNSSEC should try to support both. This feature is tracked in issue OPENDNSSEC-251.

Open source code is available at :

Jakob can create example KSR/SKSR files

Output of ksk signing: 

Offline Key Repositories

The keys are stored in an offline HSM connected to the OpenDNSSEC system and can be put online for key management if required. Once online, the enforcer can create the required keys. Some part of OpenDNSSEC also need to prepare some number of future DNSKEY RRset (including signatures) to be used until the HSM is connected the next time.

Distributed Key Management

All key signing keys are managed and stored elsewhere. Public zone signing keys needs to be exported from OpenDNSSEC and the signed keys, together with public KSKs, needs to be imported back.

This setup is very similar to the process set up for the root zone, where Verisign maintain the ZSKs and sends a set of future keys – the Key Signing Request (KSR) – to IANA for signing. Once IANA has signed the keys (four times a year) – producing a Signed Key Response (SKR) – Verisign will import back the signatures and include them in the signed root zone. The KSR/SKR scheme has been in production since 2010 and has been proven to work very well.


Support for offline keys is limited to offline Key Signing Keys (KSK) – offline Zone Signing Keys (ZSK) is out of scope. 

What parts of OpenDNSSEC are affected by offline keys?


The KASP Enforcer needs key repositories to be available for key generation, although one can configure for manual key generate. Once the keys has been generated, the Enforcer actually don't need to access the keys as only key identifiers are communicated to the signer engine as part of the signer configuration. 

The enforcer needs to be aware that another entity manage the KSKs. With distributed key management this also effect timing parameters, as KSK signature lifetimes, TTL etc. is managed by the KSK manager.

Signer Engine

The signer engine expects all key repositories referenced in the signer configuration to be available for signing.

The signer engine needs to allow for already signed RRsets (i.e., a DNSKEY RRset signed with all active offline keys) to be automatically imported into the zone. Functionality is need to determine what pre-signed RRsets (as produced by the KSK manager) to include at what time. Imported DNSKEY RRset may not be altered by the signer engine as the signatures would go bogus if altered. Hence, any conflicting signer configuration (e.g. what keys to publish) must be ignored by the signer engine.


  • No labels


  1. The signer needs a configuration something that tells him where to look for signatures, obviously. Is it signed RRsets stored there or just the RRSIG records?

    1. Yes, the signer needs to automatically include a pre-signed DNSKEY RRset. The imported RRset may not be altered, so any conflicting configuration (e.g., keys published) must be ignored - only additional signatures by online keys are allowed. I've tried to clarify this above.

      1. Thanks, that makes things more clearer. Two questions:

        1. For design considerations: It would thus never be a requirement to have Off-line ZSKs?
        2. What to do if Off-line KSK is configured to be used and such a DNSKEY RRset cannot be found? Options are: fallback to signconf or hard error. Hard error seems appropriate here, as the signer would not know if the signconf is on track with the Off-line KSK.

        Is the observation correct, that if one would use Off-line KSK, it would make the whole KSK part of the KASP insignificant?



  2. Just to note that the enforcer does access keys after generation; for creating DS records and "key list -v"... These actions would need to be aware of the KSK status so that they can fail gracefully.

  3. Sion raised the question of who is responsible for submitting the DS record to the parent