Prior to the release of BIND 9.11, Fedora and RHEL carried a downstream patch implementing a feature called 'dyndb' or 'dynamic-db'. For e.g., here's F25's patch:
FreeIPA sets up this feature (I don't know what it's for, or what it does, but I know we use it) when you do a default ipa-server-install deployment.
In BIND 9.11, the feature was merged into upstream, but with significant changes. pspacek says "The API accepted upstream is totally incompatible with the old API we used".
BIND 9.11 has landed in Fedora Rawhide and the downstream patch has been dropped, so Fedora Rawhide is now using "The API accepted upstream" rather than "the old API we used". However, freeipa doesn't appear to have been adapted to this.
Our openQA test that just does a pretty default FreeIPA server deployment (via rolekit) fails:
if you check the logs (which can be downloaded at https://openqa.fedoraproject.org/tests/50976/file/role_deploy_domain_controller-var_log.tar.gz ), this is because (actually this log extract is from a couple of days ago, but it's the same failure):
Dec 07 11:57:26 ipa001.domain.local systemd: Starting Berkeley Internet Name Domain (DNS) with native PKCS#11...
Dec 07 11:57:26 ipa001.domain.local bash: /etc/named.conf:46: unknown option 'dynamic-db'
Dec 07 11:57:26 ipa001.domain.local systemd: named-pkcs11.service: Control process exited, code=exited status=1
As part of the changes to the feature when merged upstream, the config file directive name was changed from 'dynamic-db' to 'dyndb'. Apparently this isn't the only change, though. It sounds like ipa-server-install will need changing to make the named.conf modifications in the new format, and we will also need to migrate existing named.conf to the new format when BIND is upgraded from a < 9.11 build with the Fedora/RHEL downstream patches to >= 9.11 with the upstream implementation...
Proposing as a Fedora 26 Alpha blocker, per criterion "Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried." - https://fedoraproject.org/wiki/Fedora_25_Alpha_Release_Criteria#Role_functional_requirements (I didn't copy the criteria for F26 yet) - this bug makes it impossible to deploy the domain controller role, which is a release-blocking role.
At this point, unless Petr and other DNS maintainers can provide a plan for migrating dyndb backend to the new API, we will have to back out the use of BIND 9.11.
The plugin is ready for quite some time, the missing part is just FreeIPA-generated named.conf.
Let's fix this ASAP.
While attempting to fix new installations of IPA in rawhide, I encountered bug 1404409. It prevents named to start, because it fails to connect to LDAP.
Discussed during the 2017-01-09 blocker review meeting: 
The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:
"Release-blocking roles and the supported role configuration interfaces must meet the core functional Role Definition Requirements to the extent that supported roles can be successfully deployed, started, stopped, brought to a working configuration, and queried" (domain controller is a blocking role)
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.
According to the package changelog, this should be fixed since 4.4.3-5:
* Wed Feb 15 2017 Tomas Krizek <email@example.com> - 4.4.3-5
- Fixes #1403352 - bind-dyndb-ldap: support new named.conf API in BIND 9.11
- Fixes #1412739 - ipa-kdb: support DAL version 6.1
but we've had various other issues since then which prevent verification. Setting to ON_QA; I'm hoping the next compose should have the certmonger and system-python bugs fixed and we can see if this one is fixed.
This does indeed look to be fixed; in recent openQA tests, FreeIPA server deployment finally works again. Client enrolment is failing, so it looks like there's still a blocker bug, but we're at least moving forward...
bind-dyndb-ldap-11.1-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-f6f66523b8
I've submitted a build that has two minor fixes related to this bug. It correctly converts named.conf of existing FreeIPA installations and also bumps the required version of BIND.
bind-dyndb-ldap-11.1-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-f6f66523b8
Then I'll move this to Beta blocker, as upgrades block Beta, not Alpha.
Discussed during the 2017-03-20 blocker review meeting: 
The decision was made to classify this bug as an AcceptedBlocker (Beta) as it violates the following criteria:
"For each one of the release-blocking package sets, it must be possible to successfully complete a direct upgrade from fully updated installations of the last two stable Fedora releases with that..."
bind-dyndb-ldap-11.1-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
So, should upgrades of FreeIPA servers to F26 be working now so far as anyone knows? tkrizek, is anything still outstanding here? I guess I can try and set up a test for it.
FreeIPA upgrade with DNS should work with bind-dyndb-ldap-11.1-2.fc26
When bind-dyndb-ldap is upgraded, it should pull in the new version of bind that has the new API (>9.11.0-6.P2) and transform /etc/named.conf to conform with the new API.
As of now, I'm not aware of any bugs that would be blocking FreeIPA server upgrade.
Stephen, I think you were gonna test an upgrade to F26 from an existing FreeIPA install, right? Did you do that? I forget.
(In reply to Adam Williamson from comment #24)
> Stephen, I think you were gonna test an upgrade to F26 from an existing
> FreeIPA install, right? Did you do that? I forget.
I have not done so and I unfortunately don't see myself having the time in the next week before Beta Freeze.
OK. I'll try and get to doing it myself, then.
So I've been working on getting openQA to test FreeIPA upgrade scenarios, and I *think* I've got it to the point where the test is valid and it's finding problems. I'm not sure yet if the problems are related to this bug; I'll file a new one and leave this open a bit longer while we figure out if they're related.
https://bugzilla.redhat.com/show_bug.cgi?id=1452866 is the new bug, logs are available there.
So ths bug effectively depends on 1452866 now, for the upgrade case; FreeIPA upgrade process currently doesn't work properly at all. I'm gonna drop the blocker metadata from this bug, though, as we decided in review of 1452866 that FreeIPA upgrades in general don't block Beta, so the Alpha/Beta-blocking aspect of this is fixed already. If this turns out to be a problem on upgrade after the general upgrade bug is fixed, we can propose it as a Final blocker.
I'm pretty sure this turned out to be fine in testing.