[maybe this is an SSSD bug and should be filed elsewhere. If so, I apologize for filing that in the wrong place.]
I've a subdomain (say, pc.int.company.com) that's delegated to the IPA servers. Workstations have their hostnames set to this domain, but are still configured to resolve against int.company.com and use our main DNSs. When I set dyndns_update=true, it seems like workstations are trying to update against our main DNSs, despite that they're returning authoritative data that pc.int. is delegated elsewhere.
I assume this type of configuration should still work correctly, if SSSD was to follow the delegation and update the right servers?
To illustrate, this is how my network is set up now:
The PCs seem to perform the initial DNS update (when they are set up) just fine, but fail subsequent DNS updates, because they're trying to update the wrong servers (10.65.4.[23]) all the time pc.int. domain is delegated correctly on 10.65.4.[23], the name resolution is working okay.
Additional information:
Please create new bugs in the default NEEDS_TRIAGE milestone only to keep it in developer focus.
Make description more readable.
ygorshkov, please add details like FreeIPA domain name, SSSD logs and preferably also tcpdump with recording of wrong DNS update. Maybe it is a SSSD issue, maybe not.
tcpdump
I'm looking into src/providers/ipa/ipa_dyndns.c, we should investigate if ipa_dyndns_update_send() can generate wrong zone and server parameters. Real values would help to judge if the core behaves correctly in your case.
src/providers/ipa/ipa_dyndns.c
ipa_dyndns_update_send()
zone
server
Jakub Hrozen confirmed that is it likely a SSSD bug so I have opened https://fedorahosted.org/sssd/ticket/2540 . Please continue with discussion there.
Metadata Update from @ygorshkov: - Issue assigned to someone - Issue set to the milestone: 0.0 NEEDS_TRIAGE
Login to comment on this ticket.