Hide Forgot
This bug is created as a clone of upstream ticket: https://fedorahosted.org/sssd/ticket/802 Although ipa_dyndns_update is really an awesome feature, it occurred to me that it always unconditionally attempts an update even if the record is already correct. It would be advisable to verify an update is actually needed before performing it, because modification of the DNS tables is not free of cost and should be avoided when not necessary. In the ipa case it increases the amount of ldap data that needs to be replicated around, and may cause slave DNS servers to notice a new serial and perform zone transfers even when not really needed.
please add steps to verify/reproduce this issue. thanks
(In reply to comment #1) > please add steps to verify/reproduce this issue. thanks I should respond because I was the one who actually implemented the feature. With the old packages: Restart sssd, log in as an IPA user to trigger an online action. Even though the IP address of the client didn't change, the logs should indicate that the nsupdate was performed. With the new packages: Restart sssd, log in as an IPA user to trigger an online action. The logs should indicate that the address did not change and hence no update is needed. The message you are looking for is a level-6 DEBUG message that says "No DNS update needed, addresses did not change".
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No documentation needed
Before fix: sssd-1.5.1-66.el6_2.3.x86_64 [domain/lab.eng.pnq.redhat.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = lab.eng.pnq.redhat.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = skyfire.lab.eng.pnq.redhat.com chpass_provider = ipa ipa_server = skyfire.lab.eng.pnq.redhat.com ldap_tls_cacert = /etc/ipa/ca.crt debug_level = 9 ipa_dyndns_update = True [root@skyfire ~]# ssh -l shanks $HOSTNAME shanks.eng.pnq.redhat.com's password: Last login: Mon Apr 9 16:06:51 2012 from skyfire.lab.eng.pnq.redhat.com -sh-4.1$ Relevant sssd domain logs: (Mon Apr 9 16:07:46 2012) [sssd[be[lab.eng.pnq.redhat.com]]] [ipa_dyndns_update_send] (9): Performing update (Mon Apr 9 16:07:46 2012) [sssd[be[lab.eng.pnq.redhat.com]]] [ipa_dyndns_stdin_done] (9): Sending nsupdate data complete (Mon Apr 9 16:07:46 2012) [sssd[be[lab.eng.pnq.redhat.com]]] [ipa_dyndns_child_handler] (1): Dynamic DNS child failed with status [256] (Mon Apr 9 16:07:46 2012) [sssd[be[lab.eng.pnq.redhat.com]]] [ipa_dyndns_gss_tsig_update_done] (9): nsupdate failed, retrying with server name. (Mon Apr 9 16:07:46 2012) [sssd[be[lab.eng.pnq.redhat.com]]] [ipa_dyndns_stdin_done] (9): Sending nsupdate data complete (Mon Apr 9 16:08:01 2012) [sssd[be[lab.eng.pnq.redhat.com]]] [ipa_dyndns_timeout] (1): Timeout reached for dynamic DNS update (Mon Apr 9 16:08:01 2012) [sssd[be[lab.eng.pnq.redhat.com]]] [ipa_dyndns_update_done] (1): Updating DNS entry failed After fix: sssd-1.8.0-20.el6.x86_64 [domain/lab.eng.pnq.redhat.com] debug_level = 6 ipa_dyndns_update = True cache_credentials = True krb5_store_password_if_offline = True ipa_domain = lab.eng.pnq.redhat.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = primenova.lab.eng.pnq.redhat.com chpass_provider = ipa ipa_server = primenova.lab.eng.pnq.redhat.com ldap_tls_cacert = /etc/ipa/ca.crt [root@primenova ~]# ssh -l shanks $HOSTNAME shanks.eng.pnq.redhat.com's password: Last login: Mon Apr 9 07:19:25 2012 from primenova.lab.eng.pnq.redhat.com -sh-4.1$ Relevant sssd domain logs: (Mon Apr 9 07:19:59 2012) [sssd[be[lab.eng.pnq.redhat.com]]] [ipa_dyndns_gss_tsig_update_check] (0x0400): No DNS update needed, addresses did not change (Mon Apr 9 07:19:59 2012) [sssd[be[lab.eng.pnq.redhat.com]]] [ipa_dyndns_update_done] (0x0020): DNS update finished Verified: sssd-1.8.0-20.el6.x86_64
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. http://rhn.redhat.com/errata/RHBA-2012-0747.html