Very often problem is that user installs IPA with integrated DNS under domain name which is already managed by another DNS server. This scenario creates split-brain problem and results in various odd problems with DNS resolution.
Server installer should check this condition and throw an error (or warning at least).
example.com
ipa1.example.com
Query NS records for IPA domain (example.com in the example above) and throw an error if any NS records exist and NS records do not point to the IPA server.
E.g. an error should be raised if following DNS record exists: example.com 3600 IN NS ad1.example.com. (because ad1.example.com. != ipa1.example.com.)
example.com 3600 IN NS ad1.example.com.
ad1.example.com.
ipa1.example.com.
The --force switch should allow to continue (for special cases, hidden DNS master?).
--force
As Ana is moving out of the team, I am moving her unresolved tickets to free-to-take pool.
Moving to NEEDS_TRIAGE because this is one of most frequent problems faced by users.
We should add check to ipa-server-install which if domain is detected would produce a WARNING to the interactive wizard + yes/no question. The warning should be also in installation log.
This check is especially important when DNSSEC is in play as it could produce very confusing results otherwise.
I would like to propose this ticket for 'main' 4.2 milestone (i.e. the one with priority higher than 'Backlog').
Replying to [comment:8 pspacek]:
Is this change testable with the upstream tests? What would it take to implement upstream tests this and similar issues?
It is extremely easy if we assume that upstream tests are running in environment connected to the public Internet: We can use constant example.com. as domain name. It is (almost) guaranteed to exist so the check should always fail.
example.com.
In other cases it should be also relatively easy, we just need to find an existing parent domain. E.g. we are testing IPA domain installation on a server with host name my.servers.redhat.com..
my.servers.redhat.com.
Now we can try to naively climb DNS tree up and search for DNS domains:
servers.redhat.com.
redhat.com.
com.
... and use a first domain which exists.
The (original) description for #4706 also suggested that the same check could be available for ipa dnszone-add situations, not just for the initial server installation/configuration.
During processing of remaining tickets in 4.2 Backlog, this ticket was found as suitable to be fixed in the nearest bugfixing branch - which is 4.2.x.
Where we are at it, it should be trivial to test existence of _kerberos._udp, _kerberos, _ldap._tcp and similar domain names under the new IPA domain. That should easily uncover that AD or other IPA already managed that particular domain.
FreeIPA 4.2.1 was released, moving to 4.2.x.
master:
Release note updated to match http://www.freeipa.org/page/Releases/4.3.0#DNS_zone_creation_checks
4.3 was released, open new ticket for possible regressions.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1343142 (Red Hat Enterprise Linux 7)
Metadata Update from @pspacek: - Issue assigned to dkupka - Issue set to the milestone: FreeIPA 4.3
Login to comment on this ticket.