On 12/16/21 11:10 PM, Alexander Bokovoy wrote:
On to, 16 joulu 2021, Harry G. Coin via FreeIPA-users wrote:
Alexander and others who care about dnssec:
Given the ongoing problems with opendnssec/libp11 and the many freeipa routines and resources dedicated to working around it, has bind9's native dnssec implementation improved to the point we can greatly reduce the freeipa package count by just using bind's dnssec provisions? What's the roadmap on that?
We did a research some time ago and a result was that native DNSSEC implementation in BIND required some tooling that would have been an equivalent of what is being done with SoftHSM/OpenDNSSEC:
The BIND / DNSSec guide is rather naive when it comes to storing private keys: https://bind9.readthedocs.io/en/latest/dnssec-guide.html#key-storage
Quoting the guide: "Ideally, private keys should be stored offline, in secure devices such as a smart card. Operationally, however, this creates certain challenges, since the private key is needed to create RRSIG resource records, and it is a hassle to bring the private key out of storage every time the zone file changes or signatures expire. A common approach to strike the balance between security and practicality is to have two sets of keys (...) For example, a KSK private key stored on a USB flash drive that is kept in a fireproof safe, only brought online once a year to sign a new pair of ZSKs, combined with a ZSK private key stored on the network file system and available for routine use, may be a good balance between operational flexibility and security."
Effectively, this is a repeatance of what OpenDNSSEC provides if you'd look into making HSM-backed keys.
My dnssec database was corrupted by a recent freeipa upgrade that reverted to upstream code I patched locally some time ago. The upstream doesn't really comprehend/value/test multi-concurrent thread machine speed key/context/pin updates as deployed by opendnssec / softhsm2. Even after I fixed the database by rolling keys and identifying corrupt files, etc, etc , the 'new and improved' upstream code corrupted it again within minutes. So I've disabled dnssec entirely as money to fund those minutes has run out.
Probably a good way going forward would be to have an isolated example with OpenDNSSEC/SoftHSMv2 alone that shows this set of problems and work with that to identify the issue. Right now, it seems, there is no a single place with end to end description of the problem.
Thinking about it for a few days, given ICANN's call for full dnssec deployment, and the fact that dns-over-tls only provides improved results between end-user and server (nothing regarding confidence about server data integrity): I think it's fair to ask the freeipa community whether now is the time to re-assess the reasons why, after so many years, freeipa's caution 'dnssec support is experimental' remains (https://www.freeipa.org/page/Howto/DNSSEC).
Alexander correctly suggests that creating an isolated example that highlights an issue be done. Notice that becomes much easier to ask for than produce when the problem is a race condition among threads that manifests itself in a library that's, what, 4 or 5 packages deep from the launching daemons, each package maintained by different groups with different dev priorities abilities regarding multithreading. Remember 'softhsm' is an add-on to a 'smart card' technology most use not at machine speeds but as humans insert and remove physical security devices. And significantly -- almost always just one at a time per host. Multi-processing, multi-threading and re-entrancy (such as during bulk reconsideration of multiple zsk's, ksks and sqlite db contents while other threads are assessing master-slave sync issues) are not top of softhsm/libp11 dev minds and quite understandably. Just a quick look at libp11's eng_back.c will show even a casual reader externally accessible routines could find essential variables in an inconsistent state from a multi-threading perspective ( e.g. ctx->pin ctx->pin_length).
Moreover, since freeipa last reassessed the matter in the big picture, bind's dnssec shortcomings have been improved. From a maintainability perspective, there's obviously something to be said for the same results being delivered by fewer dependencies and fewer points of failure in sub packages. After all, in the present case, to cite just one example, we have freeipa's dnssec routines (call it 'top level') running code quite literally to 'fix' cert/key file permissions so that softhsm, opendnssec, libp11, openssl-pkcs11, and, bind, can interoperate with dyndb-ldap and, last, freeipa. While that's obviously necessary to deliver function, I don't think anybody would call it 'their first design choice'.
I respectfully ask freeipa folks to re-assess whether bind's implementation has improved to the point the, ah, 'unfortunate' documentation Alexander points at might be less important than the tenuous reliability we experience now owing to reliance on so many levels of differently maintained packages.
Whether this particular issues persuades the freeipa community or does not: At least to me, most significantly, it has been many years that freeipa has written 'dnssec is experimental'. After so long, it's fair to ask what is lacking that dnssec can't be considered 'production ready' and take steps to cause that to occur.
Best to all
Harry Coin