Oct
15
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.
Oct
10
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.
Aug
09
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.
Aug
06
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 […]
Jul
26
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 […]
Jun
28
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.