Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1612822

Created attachment 1473574
/var/log/ipaserver-install.log
Description of problem:
Using ipa-server-install in interactive mode the reverse DNS zone is not
created.
It claims to have found a reverse zone, but since the /etc/resolv.conf has been
removed before running ipa-server-install this is not very likely. dig shows
[root@idms00 centos]# dig -x 10.0.10.7
; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> -x 10.0.10.7
;; global options: +cmd
;; connection timed out; no servers could be reached
How reproducible:
Always.
System is CentOS 7.5, freeipa 4.5.4 included.

A comment from BIND maintainer to what we should fix:

RFC 6303 you have mentioned suggests RNAME value to be suggested to value above. However Cloudflare returns also MNAME with such value. I think that is not recommended by any RFC.
I think there is different problem. When private ranges are probed on resolvers with public IPs, I think that should be explicitly requested by configuration. It does not make sense to verify if private range exists in public DNS. Your server should not care what private ranges have authoritative servers on the Internet. These are private ranges and should all be handled locally. If your forwarders are still your local servers, it should be requested explicitly. It should be possible to deny it explicitly at least.
I am afraid I do not know any standard boundary, saying that you are leaving private network. nobody.invalid. could be taken as a hint, but could not be relied on.