I am having an issue when adding an IdM/IPA server as follows:
Lookup failed: Preferred host gdo.isscloud.io does not provide DNS. Reverse DNS resolution of address 168.119.19.53 (ns1.isscloud.io) failed. Clients may not function properly. Please check your DNS setup. (Note that this check queries IPA DNS directly and ignores /etc/hosts.)
Adding IdM/IPA Server / perform dns query to IdM/IPA Servers with dig
Locally on the target IDM Master:
[root@ns1 ~]# dig -x 168.119.19.53 ; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> -x 168.119.19.53 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1445 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 5f96e43642875d751280a28861f94e251a2b8c9c5b5bba4f (good) ;; QUESTION SECTION: ;53.19.119.168.in-addr.arpa. IN PTR ;; ANSWER SECTION: 53.19.119.168.in-addr.arpa. 77650 IN PTR ns1.isscloud.io. ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Feb 01 15:13:41 WET 2022 ;; MSG SIZE rcvd: 112
But if I do it remotely I get a refused error:
% dig @ns1.isscloud.io -x 168.119.19.53 ; <<>> DiG 9.10.6 <<>> @ns1.isscloud.io -x 168.119.19.53 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 10255 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;53.19.119.168.in-addr.arpa. IN PTR ;; Query time: 57 msec
Now, we have another IdM/IPA server (which doesn't have a public IP nor is accessible from the internet, but is still accessible from inside our network. If I do exactly the same query to this other server, it responds correctly:
[rmendes@admin ~]$ dig @10.49.13.10 -x 168.119.19.53 ; <<>> DiG 9.11.26-RedHat-9.11.26-6.el8 <<>> @10.49.13.10 -x 168.119.19.53 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36373 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 2019507e1367aa94645a92bc61f94ba6b525b406e6c20f82 (good) ;; QUESTION SECTION: ;53.19.119.168.in-addr.arpa. IN PTR ;; ANSWER SECTION: 53.19.119.168.in-addr.arpa. 78289 IN PTR ns1.isscloud.io. ;; Query time: 0 msec ;; SERVER: 10.49.13.10#53(10.49.13.10) ;; WHEN: Tue Feb 01 15:03:02 WET 2022 ;; MSG SIZE rcvd: 112
All the servers appear to be correctly synced.
We expected that the IdM/IPA Server to correctly return the PTR record (not a local record)
$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server
[root@idm ~]# rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server package freeipa-server is not installed package freeipa-client is not installed ipa-server-4.9.6-10.module+el8.5.0+13587+92118e57.x86_64 ipa-client-4.9.6-10.module+el8.5.0+13587+92118e57.x86_64 389-ds-base-1.4.3.23-12.module+el8.5.0+13329+4096c77a.x86_64 pki-ca-10.11.2-2.module+el8.5.0+12735+8eb38ccc.noarch krb5-server-1.18.2-14.el8.x86_64
[root@ns1 ~]# rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base pki-ca krb5-server package freeipa-server is not installed package freeipa-client is not installed ipa-server-4.9.6-10.module+el8.5.0+13587+92118e57.x86_64 ipa-client-4.9.6-10.module+el8.5.0+13587+92118e57.x86_64 389-ds-base-1.4.3.23-12.module+el8.5.0+13329+4096c77a.x86_64 pki-ca-10.11.2-2.module+el8.5.0+12735+8eb38ccc.noarch krb5-server-1.18.2-14.el8.x86_64
journalctl -xefu named-pkcs11 returns no feedback regarding the queries. I've reviewed the configuration of the servers, global forwarders and all the relevant options we could think of, and it's consistent across servers. Thank you.
journalctl -xefu named-pkcs11
Thank you.
Please use freeipa-users@ mailing list for issues like this. FreeIPA upstream tracker is not for resolving configuration issues, it is for tracking development work.
If you have RHEL subscription (judging by RHEL 8.5 bits), you can open a customer case with Red Hat support organization instead.
Metadata Update from @abbra: - Issue close_status updated to: invalid - Issue status updated to: Closed (was: Open)
I'm sorry but if the configuration is consistent across servers and there is a differentiated behaviour between one and another, what exactly - and without any further information - allows to classify as "configuration issues" instead of any sort of bug?
Please use the mailing list and provide bind logs. There are query logs that can help to see what bind thinks. There is no additional code in IPA itself.
@abbra again I appreciate your feedback. In the meanwhile in conversation in the RHEL channel I was thrown in the direction of the underlying cause here.
So what happened was the query that was being successfully returned was being performed on a machine sitting on the same subnet as the IdM/IPA server replying. All connections performed from an outside IP bounce back.
The solution is as mentioned here: https://access.redhat.com/solutions/5753431
I will just leave the link in case anyone experiences a similar issue. Sorry for taking your time.
Great to hear it helped. I was going to see if this was the cause by looking at the query logs. This was a change in bind since 9.10, I think.
Login to comment on this ticket.