Bug 1215735

ipa-replica-prepare adds dns zone of the replica in order to add forward records. 

So if you prepare replica.baz.test but your zone is foo.test then zone baz.test will be added. 

Why(and which) DNS zone should not be present in order to setup replica?

I agree with Aneta that current behavior is confusing, especially when you have multiple replicas scattered around the globe with names beloging to different sub-domains.

Imagine that a company is using IPA for domain example.com.
Replica in Brno is ipa.brno.example.com.
Replica in Boston is ipa.boston.example.com.

There is no reason to assume that domains brno.example.com. or boston.example.com. have to be hosted on the IPA itself.

IMHO the installer should detect if records for replica-to-be-installed are okay and:
a) do nothing if they are,
b) report and error and possibly offer to create a zone if the zones does not exist and IPA is managing DNS.

Currently the installer always creates the zone even if it already is hosted on a different DNS server which is simply wrong and creates hard-to-debug problems.

For reference, this is replica-related part of https://fedorahosted.org/freeipa/ticket/3681

DNS records and zones are added only if option --ip-address is provided.

--ip-address option serves for adding DNS records. Its help says: "add A and PTR records of the future replica. This option can be used multiple times"

--ip-address option is required only if replica's fqdn is not resolvable, installer tells it by error message as follows:
  Add the --ip-address argument to create a DNS entry.
  "Unable to resolve host name, check /etc/hosts or DNS name resolution"
I'm not sure if this error message is confusing.

Therefore if admin provides --ip-address option, the intention is
a) to add the records to IPA's DNS server
b) the admin is confused or he doesn't know what he is doing. In this case we could improve the message or help.

I.e. to avoid adding the zone, admin should not provide --ip-address and fix his DNS setup if the fqdn is not resolvable.

Interesting, I did not know about the --ip-address trick. Anyway, IPA should refuse to create DNS zone which already exists elsewhere to avoid exactly this type of confusion.

It works as designed. But after a conversation with Petr I agree that this behavior might not always be what the admin wants, e.g., when the added zone is already managed by a different DNS server. It may be still valid use case for testing or other environments.

Therefore ipa-replica-prepare should do as written in comment 4 - most importantly report that the required zone is managed by a different server and offer a solution. 

A possibility could be:
- add DNS record if IPA manages the zone and --ip-address option is provided
- add DNS zone only if admin specifies new --create-dns-zone (proposal for new name) option. This option should be regarded as a more specific --force option. Even if this is specified, ipa-replica-prepare should still warn if the added zone is managed by a different server. If zone in IPA already exists, it should fail - to prevent admins from blindly adding this option.
- fail if zone is missing, --create-dns-zone is no specified but --ip-address is.
- fail if zone is managed by a different DNS server and --ip-address option is specified and --create-dns-zone is not.

Upstream ticket:
https://fedorahosted.org/freeipa/ticket/5014

Fixed upstream
master:
https://fedorahosted.org/freeipa/changeset/6a91893ff50fee6d7c71d9bc982d85a3ec8b7583

Verified.

Version ::

ipa-server-4.2.0-9.el7.x86_64

Results ::

[root@master ~]# ipa-replica-prepare -p Secret123 --ip-address=192.168.122.100 replica.domain.dne
DNS zone domain.dne does not exist in IPA managed DNS server. Either create DNS zone or omit --ip-address option.
Cannot add DNS record

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2362.html