Is anyone here running FreeIPA on EL8 (a.k.a. RedHat IdM) with DDNS updates enabled from dhcpd, and running that server as their network's recursive resolver? Successfully?
On EL7, this just didn't work for me due to https://bugzilla.redhat.com/show_bug.cgi?id=1409321 and it seems even worse on EL8.
The TL;DR: is that if you have DDNS updates coming named-pkcs11 from ISC dhcpd, many (i.e. recursive resolver) queries to named-pkcs11 will frequently, temporarily and intermittently return SERVFAIL.
If you stop the DDNS updates from ISC DHCP the recursive resolving behaviour of the server stabilizes and it stops returning SERVFAILs.
So, this is just a query to see if anyone is actually running this configuration successfully. If you think you might be successful with this configuration, how many recursive resolvers do you have in your network? If you have more than just the (single) FreeIPA server, it might be that named-pkcs11 on that machine is frequently returning SERVFAIL and that you are just not noticing because your alternate recursive resolvers are masking it.
So if you are running in such a configuration with alternate recursive resolvers, it might be interesting to use tcpdump or some such on your FreeIPA server to see if your named-pkcs11 is indeed returning SERVFAIL for many of your queries.
Cheers, b.
On la, 19 helmi 2022, Brian J. Murrell via FreeIPA-users wrote:
Is anyone here running FreeIPA on EL8 (a.k.a. RedHat IdM) with DDNS updates enabled from dhcpd, and running that server as their network's recursive resolver? Successfully?
On EL7, this just didn't work for me due to https://bugzilla.redhat.com/show_bug.cgi?id=1409321 and it seems even worse on EL8.
The TL;DR: is that if you have DDNS updates coming named-pkcs11 from ISC dhcpd, many (i.e. recursive resolver) queries to named-pkcs11 will frequently, temporarily and intermittently return SERVFAIL.
Can you please provide logs from RHEL 8 deployment that demonstrate this issue, with
sed -i "s/severity info;/severity debug;/" /etc/named/ipa-logging-ext.conf
done before taking logs and restart named.
This would force named to produce debug level logs in /var/named/data/* for a number of logging channels (~dozen or so) and might get a better detail on what happens in the setup you have.
If you have older version (RHEL 7), then you might use a similar configuration file to define your logging channels as in RHEL 8's version of IdM.
If you stop the DDNS updates from ISC DHCP the recursive resolving behaviour of the server stabilizes and it stops returning SERVFAILs.
We are not testing use of ISC DHCP with IdM normally, but for named this should be looking as any regular DDNS client. Depending on how you did set up the access rights for the update, this might influence which paths are in use. I looked at the bug you referenced and you did not mention it was DHCP/DDNS related until this year, nor provided any more details of your configuration. So we probably need to start again with more details.
So, this is just a query to see if anyone is actually running this configuration successfully. If you think you might be successful with this configuration, how many recursive resolvers do you have in your network? If you have more than just the (single) FreeIPA server, it might be that named-pkcs11 on that machine is frequently returning SERVFAIL and that you are just not noticing because your alternate recursive resolvers are masking it.
So if you are running in such a configuration with alternate recursive resolvers, it might be interesting to use tcpdump or some such on your FreeIPA server to see if your named-pkcs11 is indeed returning SERVFAIL for many of your queries.
In most cases where I see SERBFAIL it is related to inability to handle DNSSEC end-to-end through the resolvers for a zone in question. BIND has moved to always enable DNSSEC support and you need to explicitly disable DNSSEC validation if you are in an environment where DNSSEC chain of trust is broken. We've seen that in many places, including some of Fedora OpenQA environments inside Red Hat's datacenter, for example.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Brian J. Murrell