Univention Bugzilla – Bug 57174
S4-Connector doesn't remove dnsTombstoned: TRUE when updating DNS records from UCS to Samba/AD
Last modified: 2024-04-08 08:36:48 CEST
In Ticket #2024031321000118 a customer reported that the DNS name of some Windows clients could not be resolved. We checked and found records marked "dnsTombstoned: TRUE": univention-s4search --cross-ncs --show-binary dnsTombstoned=TRUE whenChanged On the school server we checked the timestamps: * 20220826094029.0Z (about 3) * 20230224125024.0Z (1) * 20240315084754.0Z (1) The last one looked "normal" in the sense, that it had === dn: DC=foo,DC=some-zone.org,CN=MicrosoftDNS,DC=DomainDnsZones,DC=some-zone,DC=org objectClass: dnsNode dc: foo whenCreated: 20220916100939.0Z whenChanged: 20240315084754.0Z dnsRecord: NDR: struct dnsp_DnssrvRpcRecord wDataLength : 0x0008 (8) wType : DNS_TYPE_TOMBSTONE (0) version : 0x05 (5) rank : DNS_RANK_NONE (0) flags : 0x0000 (0) dwSerial : 0x0000a2fc (41724) dwTtlSeconds : 0x00000000 (0) dwReserved : 0x00000000 (0) dwTimeStamp : 0x00000000 (0) data : union dnsRecordData(case 0) EntombedTime : Fri Mar 15 09:47:54 2024 CET dNSTombstoned: TRUE === and we found a corresponding call in syslog, showing that the windows client removed it's IP-address via dyndns. So far so ok. Since it's a UCS@school server the S4-Connector is configured with connector/s4/mapping/dns/syncmode: write If, in this situation somebody calls /usr/share/univention-s4-connector/resync_object_from_ucs.py on the corresponding relativeDomainName record in OpenLDAP, then the S4-Connector adds two dnsRecord attributes (the system had two IPs in OpenLDAP) with DNS_TYPE_A and removes the dnsRecord with DNS_TYPE_TOMBSTONE but it leaves the dNSTombstoned attribute set to TRUE. This in turn upsets the DNS scavenger code of Samba/AD, which runs daily as part of the KCC process and removes all records with "dnsTombstoned: TRUE" that are older than two weeks ("EntombedTime" in the dnsRecord > 14 * 24 hours): https://gitlab.com/samba-team/samba/-/blob/master/source4/dsdb/kcc/scavenge_dns_records.c?ref_type=heads#L400 This leads to error messages like these in log.samba: === [2024/03/17 01:10:01.611061, 0, pid=2973] ../../source4/dsdb/kcc/scavenge_dns_records.c:474(dns_delete_tombstones) dns_delete_tombstones: The tombstoned dns node DC=foo,DC=some-zone.org,CN=MicrosoftDNS,DC=DomainDnsZones,DC=some-zone,DC=org has 2 dns records, expected one. === We should adjust the S4-Connector to remove dnsTombstoned when modifying records and adding IPs. Don't know if there is good documentation around this * https://lists.samba.org/archive/cifs-protocol/2011-January/001773.html * https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/4a9a3ba3-10eb-430e-b157-1fed0aaf85a5#Appendix_A_109
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/8903e50a-9183-4a7d-9640-53f6f5a91481 says > DsTombstoneInterval: The age at which tombstone objects in the directory service will be deleted. The value SHOULD be limited to the range from 0x0003F480 (3 days) to 0x0049D400 (8 weeks), inclusive, but it MAY be any value. The default value SHOULD be 0x00127500 (14 days), and the value of zero SHOULD be treated as a flag value for the default, but it MAY be allowed and treated literally. Every day at 2:00 AM local time the DNS server MUST conduct a search of all zones stored in the directory server for nodes which have the dnsTombstoned attribute set to TRUE and an EntombedTime (section 2.2.2.2.4.23) value greater than DsTombstoneInterval seconds in the past. Any such nodes MUST be permanently deleted from the directory server <127> In Samba that's controlled by the undocumented global paramter "dnsserver:dns_tombstone_interval" with default 24 * 14 (hours). And > A node is a tombstone if its dnsTombstoned attribute has been set to "TRUE". Apparently the S4-Connector automagically removes the dnsRecord with DNS_TYPE_TOMBSTONE, simply because it replaces the multivalue attribute without caring too much about the previous values in Samba/AD.