Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1810963 - Support OpenDNSSEC 2.1 in FreeIPA
Summary: Support OpenDNSSEC 2.1 in FreeIPA
Alias: None
Product: Fedora
Classification: Fedora
Component: freeipa
Version: 32
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: IPA Maintainers
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker RejectedFreezeException
Depends On:
TreeView+ depends on / blocked
Reported: 2020-03-06 10:18 UTC by Alexander Bokovoy
Modified: 2020-04-05 00:15 UTC (History)
12 users (show)

Fixed In Version: freeipa-4.8.6-1.fc32
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-04-05 00:15:19 UTC
Type: Bug

Attachments (Terms of Use)

Description Alexander Bokovoy 2020-03-06 10:18:53 UTC
There are more issues with OpenDNSSEC 2.1 upgrade than FreeIPA team anticipated originally. We are working on fixing them ASAP at (upstream ticket 

Meanwhile, this means it is not possible to correctly upgrade Fedora 31 to Fedora 32 if FreeIPA server with DNS support is deployed and DNSSEC signing of the DNS zones is enabled. Additionally, DNSSEC signing support in FreeIPA is currently broken in Fedora 32+.

This bug can be used to track the fixed version of FreeIPA to Fedora 32.

Comment 1 Fedora Blocker Bugs Application 2020-03-06 10:29:21 UTC
Proposed as a Blocker and Freeze Exception for 32-beta by Fedora user abbra using the blocker tracking app because:

 FreeIPA 4.8 in Fedora 32 is not compatible with OpenDNSSEC 2.1 -- we originally anticipated less incompatibilty and went ahead with OpenDNSSEC upgrade in Fedora 32+. The team at FreeIPA upstream works on fixing the remaining issues and hopes to get through them before F32 beta. This is a request to make sure the issue is visible as it would violate Fedora server product release criteria because DNSSEC support is automatically enabled if DNS support is installed and DNS support is part of Fedora server product criteria:

Comment 2 Adam Williamson 2020-03-07 18:32:49 UTC
I'm +1 FE on this, but not clearly +1 blocker on it, because the openQA tests pass. So server deployment and basic client interaction work even if the DNSSEC support is broken. What exactly is the impact of this? If a client specifically does a DNSSEC request it will fail?

Comment 3 Adam Williamson 2020-03-07 18:35:57 UTC
Oh, here's another explanation: opendnssec 2.1 has not made it out of updates-testing for F32, AFAICS. There have been two builds, one is in u-t, the other has no tags. I believe stable is still 1.4.14. If that's the case, there is no reason for an FE or blocker here, but it would be good to ensure we do not push the opendnssec update stable until FreeIPA is ready. I see a FreeIPA build is already in the opendnssec update:

so it seems like this is being taken care of already? If that FreeIPA build is not yet good enough, I'd recommend at least disabling auto-push on the update, and maybe unpushing it.

Comment 4 Alexander Bokovoy 2020-03-09 07:31:22 UTC

that Bodhi update is not complete, it includes only basic parts which aren't fully covering DNSSEC operations.
Problems we found so far and are addressing them in the upstream pull request:

 - database schema change happened in OpenDNSSEC 2.0, FreeIPA code needs changes (done)
 - internal protocol between DNSSEC signer and a daemon which FreeIPA wraps with own code changed in OpenDNSSEC 2.0, FreeIPA code needs update (done)
 - ksm-util utility gone, its replacement got few commands changing its output, FreeIPA code needs update (partially done)
 - DNSSEC default policy for a zone is not loaded when the database is initialized, FreeIPA code needs update (done)
 - removal of DNSSEC details in case DNS zone is removed triggers unhandled response from the new ksm-util replacement utility, FreeIPA code needs changes (not done yet)

We are hoping to complete this work before Wednesday so that we can have update in Fedora before Thursday.

Since is in updates-testing only, the contingency plan would be to unpush it and continue working on the issues until the release. Update to OpenDNSSEC 2.1 is important before we start updating bind9 to the 9.16 release.

Comment 5 Geoffrey Marr 2020-03-09 23:54:25 UTC
Discussed during the 2020-03-09 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker" and a "RejectedFreezeException" was made as this bug is a request to pull a new opendnssec and a FreeIPA build updated to work with it into Beta. This is clearly not release-blocking as it doesn't fix some criteria-breaking bug we have in current Beta packages. We also reject it as for FE status as we think it's not 'baked' enough yet given where we are in the Beta cycle.


Comment 6 Fedora Update System 2020-03-21 22:23:18 UTC
FEDORA-2020-e3a79248dc has been submitted as an update to Fedora 32.

Comment 7 Fedora Update System 2020-03-22 01:41:42 UTC
freeipa-4.8.5-2.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report.
See for
instructions on how to install test updates.
You can provide feedback for this update here:

Comment 8 Fedora Update System 2020-03-27 08:20:01 UTC
FEDORA-2020-e3a79248dc has been submitted as an update to Fedora 32.

Comment 9 Fedora Update System 2020-03-28 14:58:55 UTC
FEDORA-2020-e3a79248dc has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-e3a79248dc`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 10 Fedora Update System 2020-04-05 00:15:19 UTC
FEDORA-2020-e3a79248dc has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.