OpenDNSSEC is much more dependent on proper timing than plain DNS, mainly because of the regular rollover of keys. Because of this, a lot of care must go into the design of timing, and especially the TTL parts of DNS records.
This is a nasty procedure that must only be performed if private key material of ZSK and/or KSK is (or may have been) compromised. It always leads to temporary unsatisfactory performance, which is why the chances for this are virtually eliminated with our architecture: either the domain drops out of validating resolvers, or it becomes insecure.
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.
In our architecture, we consider three levels of users: End users who understand DNS at a conceptual level Operators who understand DNS at an operational level Security officers who are mindful about the cryptographic intricacies of DNSSEC After initial setup has been done, a security officer only needs to oversee the secure operation of the […]
When you start to support DNSSEC, you are suddenly supposed to manage the keys used to sign the domain. This is a typical task for a security officer. Typical concerns are to conceal the private keys from outside-world prying eyes, and to avoid losing keys as long as the outside world needs them to trust […]
DNS data is spread accross the internet, at different levels of maturity. When activating or de-activating DNSSEC, it is important to ripple the data through the various servers in a known-good order, with known-good time delays built into the process.