Since the release of OpenDNSSEC 2 we’ve made incremental updates leading to the most recent 2.1.4 release. These updates all have been geared towards ironing out issues and contained only minor improvements. The frequency of updates has been modest, mostly because of good news: we have not seen many bugs that need urgent fixing.
Feature-wise we have been holding back on the existing release to let people safely migrate. Our development effort, on the other hand, has shifted focus to the next major release cycle of OpenDNSSEC. The uptake of OpenDNSSEC 2 has, perhaps, not been as fast as we had hoped. The positive news is that all migrations we have received feedback on from users have been performed without any major problems. Understandably, however, operators are conservative — if it works, don’t fix it. We have also held back on declaring 1.4 end of life to allow the community time to give us feedback on their experiences with OpenDNSSEC 2.
What we believe may be needed is to target killer features for next releases so people will really want to upgrade. Our efforts in the past year have thus focused on much-wanted and needed improvements.
Features which will only be introduced in the newest versions are high availability, offline KSK, CDS/CDNSKEY, but firstly dynamic updates. The latter has been one of the most sought-after features to fulfill the business checklist.
Wait, this isn’t about RFC 2136, Dynamic DNS. DDNS would be one of the methods to submit changes to the zone to OpenDNSSEC, but this feature is really about significantly improving the responsiveness of the signer when new zone data is offered. All signing solutions are fundamentally limited in their signing speed by the actual hard- or software that generates signatures. For a sufficiently large zone, if you have enough memory, then you are limited by your HSM or equivalent for the most part.
Although OpenDNSSEC already concurrently signs multiple zones with multiple threads, this parallelism is only targeted towards increasing the speed of the signing process. Responsiveness isn’t part of it. On a higher level, OpenDNSSEC goes through the sequential processes of reading a zone file, then processing changes, proceeding to preparing the zone file passing over the entire NSEC chain. When the zone is subsequently signed, it produces a complete internal state file and a signed zone file separately. This sequential processing is very static, and the current versions of OpenDNSSEC are not capable of processing new input when signing is active, or any other combination of activities.
This is usually acceptable when a zone file is updated with a modest frequency. For instance when updating the zone file about a dozen times a day, the per-cycle fixed overhead is a percentage of the time spent signing or idling. The overhead, however, is fixed, so if the update frequency increases, this becomes an issue that influences performance.
From an operator perspective this mode of operation also has advantages. There are no simultaneous processes, each step can be monitored and the regular intervals make for a suitable setup to automate the DNS pipeline.
When everything is set up, this makes a smooth assembly line, but when preparing or experimenting, a system operator can also be annoyed by this way of working. Starting and stopping the daemon takes quite some time and all manual commands may be delayed when the signer is busy with another process in the pipeline.
What’s Being Coded?
Whereas the enforcer received much attention in the 2.0 release, enabling fast updates almost solely impacts the signer. It shouldn’t come as a surprise that turning a sequential process-oriented signer into a responsive signer does has an impact on the architecture.
The biggest impact is on the most fundamental data structure in OpenDNSSEC: the zone contents itself.
One of the design principles of OpenDNSSEC was to keep the entire zone in memory. Currently we still adhere to this, but when multiple internal processes operate and change the same dataset this will fail. To prevent difficult concurrency problems that already existed to some extent, we opted not to let the internal processes handle concurrency. Without needlessly duplicating zone contents we let each process have their own view on the zone contents, and make transactional changes.
This allows the signer to be responsive to changes and handle input, output and zone signing at the same time. The change in the central zone data structure is really an enabler that allows for the other changes needed:
- OpenDNSSEC no longer keeps state in a large file that is recreated at every cycle, but keeps a journal, which saves a ton of time at every cycle.
- The signed output file no longer needs to be written back to disk before serving.
- OpenDNSSEC can now properly handle IXFRs; not only outbound, but now also inbound. A long history of IXFRs can be kept (which is nice when updating a lot, so zone-serving nameservers need not to operate in lock-step) improving in-memory footprint and functional across restarts.
- More convenient than IXFR for back-end systems is the web-based ReSTful interface which targets changes to delegations most TLDs would need to process. This allows for an easier integration with the registry back-end system, without the need for zone generation.
- Zone contents can be served concurrently while processing changes and the signing process.
- NSEC chain management can now be done on the changed records and their neighbors only, rather than going over all individual records to validate the chain.
- The entire zone is no longer inspected to look for signatures that need re-signing, but instead the signer does bookkeeping.
The signer was really optimized for re-signing where a large portion of the zone would require signing. In such a case, 90% of the time was spent on generating signatures, and here we would induce some overhead. In general, we should see a faster turnaround and we have made changes to make further improvements possible.
To facilitate an easy upgrade path, we’ve enabled the signer to handle the 2.1 state files. Note that this allows both up- and downgrades. Log messages needed to change, so monitoring tools may be affected. Further improvements to the logging infrastructure, and command line interface are taking place, but fundamentally the signer plays its normal role.
And the Plan is…
We recognize that signing is a fundamental process where organizations are careful to make changes. Therefore, a tool such as the signer needs to be tested in the real world. We have already been in contact with interested parties and will release a beta version this summer.
What we really need is feedback from you, our community!
We think we have put together an attractive set of new features that are highly sought-after in our community, and strongly encourage our community to give these a test drive. We are also more than happy to help you in this process, so if you’re up for it, don’t hesitate, give it a try and let us know if you need any assistance!