Red Hat Bugzilla – Bug 1043826
Sssd dyndns update fails for addresses from different networks
Last modified: 2015-10-02 15:44:14 EDT
Description of problem: Sssd dyndns update of reverse zones fails when "dyndns_iface" points to an interface with addresses from different networks. This is because nsupdate refuses to update two diffferent (reverse) zones in one update. Version-Release number of selected component (if applicable): sssd-common-1.11.2-10.el7.x86_64 sssd-proxy-1.11.2-10.el7.x86_64 sssd-common-pac-1.11.2-10.el7.x86_64 sssd-client-1.11.2-10.el7.x86_64 sssd-krb5-common-1.11.2-10.el7.x86_64 sssd-ldap-1.11.2-10.el7.x86_64 sssd-ad-1.11.2-10.el7.x86_64 sssd-ipa-1.11.2-10.el7.x86_64 python-sssdconfig-1.11.2-10.el7.noarch libsss_idmap-1.11.2-10.el7.x86_64 sssd-krb5-1.11.2-10.el7.x86_64 sssd-1.11.2-10.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Set up dynamic DNS update with sssd, specifying a dummy interface with "dyndns_iface". 2. Add two addresses from different networks to the dummy interface. 3. Restart sssd to induce dynamic DNS update. Actual results: A/AAAA records are present in forward zone. PTR records are NOT present in reverse zones. Expected results: A/AAAA records are present in forward zone. PTR records are present in reverse zones. Additional info: The 0xFFF0 debug level domain log shows the following: ---:<--- (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [nsupdate_msg_create_common] (0x0200): Creating update message for realm [EXAMPLE.COM]. (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [be_nsupdate_create_ptr_msg] (0x0400): -- Begin nsupdate message -- realm EXAMPLE.COM update add 1.0.2.0.0.0.0.c.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 3600 in PTR refresh.dyndns.example.com. update add 1.2.0.192.in-addr.arpa. 3600 in PTR refresh.dyndns.example.com. send (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [be_nsupdate_create_ptr_msg] (0x0400): -- End nsupdate message -- (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [30088] (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [child_handler_setup] (0x2000): Signal handler set up for pid [30088] (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [be_nsupdate_args] (0x0200): nsupdate auth type: GSS-TSIG (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [child_sig_handler] (0x1000): Waiting for child [30088]. (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [child_sig_handler] (0x0020): child [30088] failed with status [2]. (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [512] (Mon Dec 16 20:51:26 2013) [sssd[be[example.com]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed --->:--- The same update retried manually produces error message from nsupdate: "update failed: NOTZONE". NOTE: The following input to nsupdate WORKS: ---:<--- realm EXAMPLE.COM update add 1.0.2.0.0.0.0.c.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 3600 in PTR refresh.dyndns.example.com. send update add 1.2.0.192.in-addr.arpa. 3600 in PTR refresh.dyndns.example.com. send --->:--- Note the "send" command after each "update".
Upstream ticket: https://fedorahosted.org/sssd/ticket/2179
As discussed on IRC with Nikolai, this bug doesn't seem critical for 7.0
Created attachment 850049 [details] 0001-dyndns-Update-PTR-records-separately.patch The attached trivial patch seems to fix the problem. Tested on RHEL7. Please consider including in RHEL7.0.
Created attachment 850120 [details] 0001-dyndns-Update-PTR-records-separately.patch Removed extra "send" from generated nsupdate input.
The patch looks good to me, would you mind sending it to the devel list?
Sure, done.
Fixed upstream: master: 56feae39a4d3c356c13d6826f34f83e0471f6e07
Verified the patch in sssd-client-1.12.2-47.el7.x86_64, added two IPs to the dummy interface and both records were added to the forward and reverse zones.
Logs... (Thu Jan 29 18:26:44 2015) [sssd[be[example.local]]] [nsupdate_msg_create_common] (0x0200): Creating update message for realm [EXAMPLE.LOCAL]. (Thu Jan 29 18:26:44 2015) [sssd[be[example.local]]] [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- realm EXAMPLE.LOCAL update delete test.dyndns.example.local. in A send update delete test.dyndns.example.local. in AAAA send update add test.dyndns.example.local. 3600 in AAAA ::ffff:192.0.2.1 update add test.dyndns.example.local. 3600 in A 192.0.2.1 send (Thu Jan 29 18:26:44 2015) [sssd[be[example.local]]] [be_nsupdate_create_fwd_msg] (0x0400): -- End nsupdate message -- (Thu Jan 29 18:26:44 2015) [sssd[be[example.local]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [20079] (Thu Jan 29 18:26:44 2015) [sssd[be[example.local]]] [child_handler_setup] (0x2000): Signal handler set up for pid [20079] (Thu Jan 29 18:26:44 2015) [sssd[be[example.local]]] [write_pipe_handler] (0x0400): All data has been sent! (Thu Jan 29 18:26:44 2015) [sssd[be[example.local]]] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete (Thu Jan 29 18:26:44 2015) [sssd[be[example.local]]] [be_nsupdate_args] (0x0200): nsupdate auth type: GSS-TSIG (Thu Jan 29 18:26:44 2015) [sssd[be[example.local]]] [ad_online_cb] (0x0400): The AD provider is online (Thu Jan 29 18:26:45 2015) [sssd[be[example.local]]] [child_sig_handler] (0x1000): Waiting for child [20079]. (Thu Jan 29 18:26:45 2015) [sssd[be[example.local]]] [child_sig_handler] (0x0100): child [20079] finished successfully. (Thu Jan 29 18:26:45 2015) [sssd[be[example.local]]] [be_nsupdate_done] (0x0200): nsupdate child status: 0 (Thu Jan 29 18:26:45 2015) [sssd[be[example.local]]] [nsupdate_msg_create_common] (0x0200): Creating update message for realm [EXAMPLE.LOCAL]. (Thu Jan 29 18:26:45 2015) [sssd[be[example.local]]] [be_nsupdate_create_ptr_msg] (0x0400): -- Begin nsupdate message -- realm EXAMPLE.LOCAL update add 1.0.2.0.0.0.0.c.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 3600 in PTR test.dyndns.example.local. send update add 1.2.0.192.in-addr.arpa. 3600 in PTR test.dyndns.example.local. send (Thu Jan 29 18:26:45 2015) [sssd[be[example.local]]] [be_nsupdate_create_ptr_msg] (0x0400): -- End nsupdate message --
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. https://rhn.redhat.com/errata/RHBA-2015-0441.html