RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1043826 - Sssd dyndns update fails for addresses from different networks
Summary: Sssd dyndns update fails for addresses from different networks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-17 09:59 UTC by Nikolai Kondrashov
Modified: 2020-05-02 17:34 UTC (History)
7 users (show)

Fixed In Version: sssd-1.12.0-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-05 10:27:27 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
0001-dyndns-Update-PTR-records-separately.patch (1.90 KB, patch)
2014-01-14 16:51 UTC, Nikolai Kondrashov 		no flags Details | Diff
0001-dyndns-Update-PTR-records-separately.patch (2.11 KB, patch)
2014-01-14 18:55 UTC, Nikolai Kondrashov 		no flags Details | Diff
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 3221 0 None closed Sssd dyndns update fails for addresses from different networks 2020-11-03 21:32:28 UTC
Red Hat Product Errata RHBA-2015:0441 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2015-03-05 15:05:27 UTC

Description Nikolai Kondrashov 2013-12-17 09:59:43 UTC 
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".
Comment 2 Jakub Hrozek 2013-12-17 11:16:18 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2179
Comment 3 Jakub Hrozek 2013-12-17 11:20:33 UTC 
As discussed on IRC with Nikolai, this bug doesn't seem critical for 7.0
Comment 4 Nikolai Kondrashov 2014-01-14 16:51:00 UTC 
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.
Comment 5 Nikolai Kondrashov 2014-01-14 18:55:58 UTC 
Created attachment 850120 [details]
0001-dyndns-Update-PTR-records-separately.patch

Removed extra "send" from generated nsupdate input.
Comment 6 Jakub Hrozek 2014-01-15 09:44:42 UTC 
The patch looks good to me, would you mind sending it to the devel list?
Comment 7 Nikolai Kondrashov 2014-01-15 10:33:37 UTC 
Sure, done.
Comment 8 Jakub Hrozek 2014-01-31 23:08:45 UTC 
Fixed upstream:
    master: 56feae39a4d3c356c13d6826f34f83e0471f6e07
Comment 11 Dan Lavu 2015-01-29 23:44:10 UTC 
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.
Comment 12 Dan Lavu 2015-01-29 23:49:46 UTC 
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 --
Comment 14 errata-xmlrpc 2015-03-05 10:27:27 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.