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.

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.