Learn more about these different git repos.
Other Git URLs
During an investigation of DDNS registration failures we found that SSSD includes a 'send' command in between each record modification and does not batch DDNS update requests. This is problematic in complex AD environments because those requests may not be processed by the same server. By suppressing the 'send' commands SSSD gives to nsupdate we can force the entire delete/add request into a single packet which is always processed by a single server. Packet captures from Windows devices show that their delete and update requests are always sent within a single packet. If these requests are sent as separate sessions/packets as with SSSD then we may see a situation where an upstream service successfully processes the delete but drops the add request resulting in no resolvable record.
The gist is that nsupdate should receive this from SSSD when updating A/AAAA records:
update delete A ... update delete AAAA ... update add ... send
Instead of:
update delete A ... send update delete AAAA ... send update add ... send
Similar changes would be needed for PTRs as well.
Thanks!
This started as a private e-mail thread between the reporter and some current or previous SSSD developers. Since the little archeology exercise I did is not anything private, let me also paste it here.
We used to issue a single transaction (so, a single send) until commit a741d0c.
Its commit message says: ''' Separate transaction for A and AAAA addresses updates are important because server might block updates for one of these families and thus the update even for the non-blocked address family would unnecessarily fail. '''
But I also don't like the additional churn this would take. We offer the possibility to restrict the address family, so if you find out that DNS updates are failing because the DNS server doesn't allow updating either of the address families, you can configure that out.
Alternatively, we could use the per-family grouping as a fallback.
Embarrassingly enough it was me who reviewed a741d0c but I'm afraid I don't remember anything about that change in behaviour anymore. FWIW, the commit also links to a ticket which is referenced by https://docs.pagure.org/SSSD.sssd/design_pages/ddns_messages_update.html but I don't really see any explanation about this change either.
There was a valid reason we did the split-transaction, actually. In AD environments, when updating one address family is not permitted, the whole update would fail.
So I would prefer to make this configurable, so that if you need to do the update in a single transaction, you could select so in the config file.
And/or, if the DNS resolution is restricted to ipv4_only or ipv6_only, then we should only update that address family. I think we might already do that, but I'm not totally sure.
Metadata Update from @jhrozek: - Issue set to the milestone: SSSD 2.1
Metadata Update from @thalman: - Issue assigned to thalman
@chrismaz, the behaviour has changed already in upstream and rhel7. Now there are 2 transactions for forward zone - one for IPv4, one for IPv6:
update delete A ... update add ... send update delete AAAA ... update add ... send
We are about to implement new option for sssd.conf to make this one single transaction (something like dns_update_style=(single|per_family)) .
I also checked the source code and PTR records are still send on by one. I want to change it to have the same behaviour as with forward zone - i. e. 1 transaction per protocol family or single transaction if set so in sssd.conf.
Does this proposal solve your problem?
Indeed it would, thanks!
Metadata Update from @jhrozek: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/4823
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.