At some point while running DNSSEC, you will wonder if the base64 blobs in RRSIG and DNSKEY records are actually correct. We specify a few procedures that we follow to have Python calculate signatures if that happens to us. In what follows below, we are assuming that all your RSA public keys are in DNS; […]
How can the Drill utility be used to ensure properly signed zones? When a zone encounters a problem, it is helpful to dig around in DNS, possibly probing the authoritatives directly to bypass validating resolvers. This will yield information, but not actually check signatures. The Drill utility is a replacement of Dig, and can actually […]
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 […]
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.
During the course of the past year Gijs van den Broek has performed research on DNSSEC and UDP fragmentation for his M.Sc. thesis. His work is now finished and the tools he used to perform his research have been made available so others may reproduce his research or extend it. Read more about where to […]
Over the past week we have published a detailed HOWTO on the signer migration process we have gone through last month on our DNSSEC blog. The full process, including a worksheet (also available separately) to help you during the process, is described in the document that you can download by clicking on the image on […]
The purpose of this step is to remove the DNSKEY record for the active ZSK from the source signer from the input zone and to resume automated key management. Once this step has taken place, the migration is complete. The situation at the end of this step is shown in the diagram below: To reach […]
The purpose of this step is to completely switch over to the destination signer. At the end of this step, continuous zone signing has been restarted and will only take place on the destination signer; zone publication will have been resumed and will use the output from the destination signer. The situation at the end […]
The purpose of this step is to switch the DS for the zone to point to the KSK of the destination signer. The situation at the end of this step is shown in the diagram below: To reach this situation, the following sub-steps need to be taken: Contact the parent zone (registry) to submit the […]
The purpose of this step is to create a fully cross-signed zone that includes the key set from the source as well as the destination signer. The situation at the end of this step is shown in the diagram below: To reach this situation, the following sub-steps need to be taken: Edit the output (i.e. […]