Bug 1612822
| Summary: | ipa-server-install does not create reverse DNS zone | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | hdunkel | ||||||||||
| Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> | ||||||||||
| Status: | CLOSED DEFERRED | QA Contact: | ipa-qe <ipa-qe> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | low | ||||||||||||
| Version: | 8.0 | CC: | abiagion, abokovoy, hdunkel, ipa-maint, jcholast, jhrozek, pasik, pcech, pemensik, pvoborni, rcritten, ssorce, tscherf | ||||||||||
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2021-01-06 11:07:52 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 1473575 [details]
ipa-server-install screen output
Hi, sorry if I'm wrong, but you meant it claims to have found a reverse zone or DNS forwarders? If '/etc/resolv.conf' doesn't exist the nameserver used is '127.0.0.1'. See the attached log file. It says : 2018-08-03T08:50:55Z INFO Checking DNS domain 10.0.10.in-addr.arpa., please wait ... 2018-08-03T08:51:25Z INFO Reverse zone 10.0.10.in-addr.arpa. for IP address 10.0.10.7 already exists : I did not define 10.0.10.in-addr.arpa, 0.10.in-addr.arpa or 10.in-addr.arpa anywhere. /etc/resolv.conf doesn't exist. I have no idea where ipa-server-install found the reverse zone. Does dig 10.0.10.in-addr.arpa. show anything? This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'. Reporter is running IPA version '4.5.4-10.el7.centos.3'. I wasn't able to reproduce this, using Fedora release 29 (Rawhide): $ rpm -qa | grep ipa-server freeipa-server-dns-4.7.0-1.fc29.noarch freeipa-server-common-4.7.0-1.fc29.noarch freeipa-server-4.7.0-1.fc29.x86_64 When I delete '/etc/resolv.conf' installation falls back to '127.0.0.1' as nameserver (as expected). My installation output says: ``` Checking DNS domain rawhide.local., please wait ... DNS check for domain rawhide.local. failed: The DNS operation timed out after 30.00157141685486 seconds. Do you want to configure DNS forwarders? [yes]: Following DNS servers are configured in /etc/resolv.conf: 127.0.0.1 Do you want to configure these servers as DNS forwarders? [yes]: All DNS servers from /etc/resolv.conf were added. You can enter additional addresses now: Enter an IP address for a DNS forwarder, or press Enter to skip: Checking DNS forwarders, please wait ... DNS server 127.0.0.1: query '. SOA': The DNS operation timed out after 10.001685619354248 seconds DNS server 127.0.0.1: query '. SOA': The DNS operation timed out after 10.001685619354248 seconds The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information ``` While reporter`s installation output says: ``` Following DNS servers are configured in /etc/resolv.conf: 10.0.10.3, 10.0.10.2 ``` Sorry, apparently the screen output doesn't match the ipaserver-install.log. I tried ipa-server-install several times with and without setting /etc/resolv.conf. My bad. ipaserver-install.log shows in line 152: 2018-08-03T08:50:55Z INFO Checking DNS domain 10.0.10.in-addr.arpa., please wait ... 2018-08-03T08:51:25Z INFO Reverse zone 10.0.10.in-addr.arpa. for IP address 10.0.10.7 already exists In line 39935 it says there is no resolv.conf 2018-08-03T09:02:38Z DEBUG duration: 0 seconds 2018-08-03T09:02:38Z DEBUG [11/11]: changing resolv.conf to point to ourselves 2018-08-03T09:02:38Z DEBUG Backing up system configuration file '/etc/resolv.conf' 2018-08-03T09:02:38Z DEBUG -> Not backing up - '/etc/resolv.conf' doesn't exist 2018-08-03T09:02:38Z DEBUG duration: 0 seconds 2018-08-03T09:02:38Z DEBUG Done configuring DNS (named). 2018-08-03T09:02:38Z DEBUG Starting external process 2018-08-03T09:02:38Z DEBUG args=/bin/systemctl restart httpd.service 2018-08-03T09:02:41Z DEBUG Process finished, return code=0 2018-08-03T09:02:41Z DEBUG stdout= 2018-08-03T09:02:41Z DEBUG stderr= 2018-08-03T09:02:41Z DEBUG Starting external process 2018-08-03T09:02:41Z DEBUG args=/bin/systemctl is-active httpd.service 2018-08-03T09:02:41Z DEBUG Process finished, return code=0 2018-08-03T09:02:41Z DEBUG stdout=active Both /etc/nsswitch.conf and /etc/nsswitch.conf.ipabkp contain [root@idms01 log]# cat /etc/nsswitch.conf.ipabkp | grep hosts #hosts: db files nisplus nis dns hosts: files dns myhostname /etc/hosts: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.0.10.7 idms01.ioap.eu idms01 10.0.10.8 idms02.ioap.eu idms02 Created attachment 1477088 [details]
new ipaserver-install.log
Created attachment 1477089 [details]
new screen output
Attached you can find screen output and ipaserver-install.log of another session, ran on another host. Here is the requested output of dig: [root@sample centos]# dig 10.0.10.in-addr.arpa. ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> 10.0.10.in-addr.arpa. ;; global options: +cmd ;; connection timed out; no servers could be reached [root@sample centos]# dig @1.1.1.1 10.0.10.in-addr.arpa. ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> @1.1.1.1 10.0.10.in-addr.arpa. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23286 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1452 ;; QUESTION SECTION: ;10.0.10.in-addr.arpa. IN A ;; AUTHORITY SECTION: 10.0.10.in-addr.arpa. 10800 IN SOA nobody.invalid. nobody.invalid. 1 3600 1200 604800 10800 ;; ADDITIONAL SECTION: explanation.invalid. 10800 IN TXT "Blocking is mandated by standards, see references on https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml" ;; Query time: 5 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Mon Aug 20 07:47:20 UTC 2018 ;; MSG SIZE rcvd: 272 In this particular case what happens is IPA does a lookup of the reverse zone. If no zone is found then it is allowed to be used. In this case a value is returned which says "don't use me" but because it returns a value, even though that value is "don't use me", it is considered as "zone already exists". Now this doesn't match with the dig in the original report which had no response to the request. Petr, do you believe that a valid DNS client should handle SOA entries like the one above (nobody.invalid.)? Cloudflare and OpenDNS are responding that way, Google doesn't. Also, is RFC6303 [1] supporting this scenario? Or is any other RFC relevant here? 1 - https://tools.ietf.org/html/rfc6303 (In reply to Rob Crittenden from comment #11) > In this particular case what happens is IPA does a lookup of the reverse > zone. If no zone is found then it is allowed to be used. In this case a > value is returned which says "don't use me" but because it returns a value, > even though that value is "don't use me", it is considered as "zone already > exists". Understood. Wouldn't it be nice if I could override this decision manually, either on the ipa-server-install command line, or in a confirmation dialog? There already is a workaround: add the reverse post-install. If there is some standard around the response then we could handle that automatically. Still waiting on input from DNS experts. Armando, 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. Upstream ticket: https://pagure.io/freeipa/issue/7692 This BZ has been evaluated multiple times over the last several years and we assessed that it is a valuable request to keep in the backlog and address it at some point in future. Time showed that we did not have such capacity, nor have it now nor will have in the foreseeable future. In such a situation keeping it in the backlog is misleading and setting the wrong expectation that we will be able to address it. Unfortunately we will not. To reflect this we are closing this BZ. If you disagree with the decision please reopen or open a new support case and create a new BZ. However this does not guarantee that the request will not be closed during the triage as we are currently applying much more rigor to what we actually can accomplish in the foreseeable future. Contributions and collaboration in the upstream community and CentOS Stream is always welcome! Thank you for understanding Red Hat Enterprise Linux Identity Management Team |
Created attachment 1473574 [details] /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.