What were you trying to do that didn't work?

I've enabled dyndns_update_ptr in IPA domain. However I noticed that reverse is either not updated or only one address is updated, the other is not.

Please provide the package NVR for which bug is seen:

sssd-2.8.2-3.el9_2.alma.x86_64
sssd-ipa-2.8.2-3.el9_2.alma.x86_64

How reproducible:

Always (even by hand, outside sssd, see below).

Steps to reproduce

1.  Enable dyndns_update_ptr in sssd IPA domain and configure whatever is necessary for updates to work (DNS zone, kerberos and so on).
2. Make sure the interface towards IPA server has at least TWO IPv6 addresses, in DIFFERENT zones.
3. Clear the record for the client from DNS.
4. Restart sssd.
5. See the error in /var/log/sssd_<domain>.log about failed DNS update:
   [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [512]
   [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158240]: Dynamic DNS update failed

Expected results

The update is performed.

Actual results

The update failed as shown above.

Additional information

As seen in version information - this was found on AlmaLinux 9.2 but is very easy to reproduce with nsupdate.

The log reveals the following script used with nsupdate:

update delete 204.48.168.192.in-addr.arpa. in PTR 
update add 204.48.168.192.in-addr.arpa. 1200 in PTR vesemir.jot23.net. 
send 
update delete f.2.8.e.1.2.3.6.5.f.e.2.b.c.4.9.0.0.0.3.1.9.9.1.5.0.0.a.6.0.a.2.ip6.arpa. in PTR 
update add f.2.8.e.1.2.3.6.5.f.e.2.b.c.4.9.0.0.0.3.1.9.9.1.5.0.0.a.6.0.a.2.ip6.arpa. 1200 in PTR vesemir.jot23.net. 
update delete c.3.9.1.a.8.e.a.c.c.a.3.1.2.5.8.0.0.0.3.1.a.e.2.f.e.d.f.d.d.d.f.ip6.arpa. in PTR 
update add c.3.9.1.a.8.e.a.c.c.a.3.1.2.5.8.0.0.0.3.1.a.e.2.f.e.d.f.d.d.d.f.ip6.arpa. 1200 in PTR vesemir.jot23.net. 
send

The problem with that is that it packs 4 updates (2 deletes & 2 additions for 2 names) destined for two distinct DNS zones into single update message. My understanding is that this is not supported especially that they can be on distinct nameservers (incidentally they are not).

Splitting the above script between two reverse zones allows update to proceed.

I believe each reverse update should be handled by separate message unless all addresses can be proven to reside in single DNS zone.