Monitoring HSM memory usage

Written by Roland van Rijswijk in category: Crypto, Procedures, Resilience, Security, Technical

If, like us, you use an HSM to store your DNSSEC key material you may know that it is important to monitor memory usage in your HSM; with a typical DNSSEC key management scheme you may have as many as 5 keys active per signed domain. This can be a burden on your HSM, especially […]

2 Comments

Reaching out to the parent zone

Written by Rick van Rein in category: Architecture, Procedures, Resilience, Technical

Upload KSK information to the parent zone, following a procedure that is mindful of old results in caches. The code of the engine is included.

1 Comments

MTU woes again…

Written by Roland van Rijswijk in category: Resilience, Technical

We recently experienced some more MTU woes as a result of our main zone being DNSSEC signed that I’d like to share with you in the hope that this can help prevent this problem for others. Last week I got an e-mail from our IT department about mail issues that some of my colleagues were […]

No Comments

Procedure: Replacing a failed HSM

Written by Rick van Rein in category: Procedures, Resilience, Security

This procedure is needed when one (not both) Hardware Security Module (or HSM) has failed. Before doing this, it should be established that there is no repair possible.

No Comments

Procedure: Signer failure

Written by Rick van Rein in category: Procedures, Resilience

If either the master or slave instance of OpenDNSSEC fails, follow the procedures below. It is assumed that an empty instance is available as a cloneable virtual machine.

2 Comments

Procedure: Normal KSK rollover and parent sync

Written by Rick van Rein in category: Procedures, Resilience, Security

Every once in a while, for example once a year, the KSK for each zone needs to be rolled over. This involves communication with the parent zone, making it a little more complicated than internal-only procedures.

No Comments

Master/slave replication with OpenDNSSEC

Written by Rick van Rein in category: Architecture, Resilience

In a previous article we discussed the idea of a high-availability Hardware Security Module (or HSM) service. To make the entire DNSSEC signing service act in high-availability mode there is one more part to replicate, namely the OpenDNSSEC signer machines. These manage the procedures and are aware of the DNS and timing intricacies of DNSSEC. […]

1 Comments

Why .us fails to validate for some (and algorithm rollovers are hard)

Written by Roland van Rijswijk in category: General, Resilience

If you perform DNSSEC validation on your resolver you may have noticed lots of validation failures for the .us top-level domain since yesterday or early today (depending on the content of your cache). You’re probably wondering why this happens and what you can do about. Here’s a short explanation. The maintainers of the .us domain […]

No Comments

Reloading signed zones into BIND

Written by Rick van Rein in category: Procedures, Resilience, Technical, Timing

Our signer publishes signed zones through BIND. We found that updates to BIND can get lost if their succession is too quick; and we solved it.

No Comments

Cryptographic sanity: How many keys?

Written by Rick van Rein in category: Crypto, Resilience, Security

In our architecture, we opt for Hardware Security Modules (or HSMs) as secure key stores. This helps us with high-availability of key material, and thus of our signed domains, but it also poses us with some limitations. An HSM generally has a limited number of keys that it can store. Had we opted for a […]

1 Comments