Univention Bugzilla – Full Text Bug Listing |
Summary: | DDNS update of Samba/AD doesn't delete dnsRecord from dNSTombstoned Objects | ||
---|---|---|---|
Product: | UCS | Reporter: | Arvid Requate <requate> |
Component: | Samba4 | Assignee: | Lukas Oyen <oyen> |
Status: | CLOSED FIXED | QA Contact: | Arvid Requate <requate> |
Severity: | normal | ||
Priority: | P5 | CC: | gohmann |
Version: | UCS 4.2 | Flags: | oyen:
Patch_Available+
|
Target Milestone: | UCS 4.2-0-errata | ||
Hardware: | Other | ||
OS: | Linux | ||
See Also: |
https://forge.univention.org/bugzilla/show_bug.cgi?id=41867 https://forge.univention.org/bugzilla/show_bug.cgi?id=42324 http://forge.univention.org/bugzilla/show_bug.cgi?id=39806 |
||
What kind of report is it?: | Bug Report | What type of bug is this?: | 5: Major Usability: Impairs usability in key scenarios |
Who will be affected by this bug?: | 2: Will only affect a few installed domains | How will those affected feel about the bug?: | 2: A Pain – users won’t like this once they notice it |
User Pain: | 0.114 | Enterprise Customer affected?: | Yes |
School Customer affected?: | ISV affected?: | ||
Waiting Support: | Flags outvoted (downgraded) after PO Review: | ||
Ticket number: | 2016033021000182 | Bug group (optional): | Troubleshooting |
Max CVSS v3 score: | |||
Attachments: |
refresh_dns_records_for_host
script_and_output 41190-dns-correct-tombstoned-461.patch 41190-dns-correct-tombstoned-461.patch |
*** Bug 40967 has been marked as a duplicate of this bug. *** Created attachment 8828 [details]
script_and_output
I am able to produce the duplicate `dnsRecord` entries in an object, if this
object is `dnsTombstoned=True`. The problem is not limited to MacOS, I am able
to reproduce the duplicate entries with a Windows client or pure `nsupdate`.
To reproduce, create a `host_record` via udm, set it to `dnsTombstoned=True` and
perform modifications per `nsupdate`. This will create duplicate `dnsRecord`
entries. See attached script and output.
The Samba code uses the function `dns_common_replace()` to update objects. This
expects a `DNS_TYPE_TOMBSTONE` marker `dnsRecord` in addition to
`dnsTombstoned=True` (more specifically: `dnsTombstoned=True` is set if a marker
`dnsRecord` exists or existed, otherwise `dnsTombstoned` is not touched). Here
the marker never existed and there is no reason to touch the `dnsTombstoned`
attribute. `dns_common_lookup()` only looks at the `dnsTombstoned` attribute on
the other hand.
[MS-DNSP] specifies, that a `DNS_TYPE_ZERO` record must be created whenever
`dnsTombstoned` is set to TRUE. This `DNS_TYPE_ZERO` translates to
`DNS_TYPE_TOMBSTONE` in Samba. A state where `dnsTombstoned=True`, but no marker
`dnsRecord` exists is therefore invalid.
But: I tried to reproduce the problem with a Windows Server 2012 and Windows8
client. A host record with `dnsRecord` manually set to TRUE, will be
corrected by the server upon modification by the client. A valid object with
`dnsTombstoned=False` and no marker or duplicate `dnsRecord` is restored.
Two questions arise:
1) Is this a bug in Samba and how difficult is the fix?
2) Under what circumstances does the S4Connector produce this invalid state
and how difficult is the fix?
I would answer the first part of 1) with yes and will work on a patch for Samba.
I agree. For the second part there is Bug 39161, at least. Created attachment 8836 [details]
41190-dns-correct-tombstoned-461.patch
The attached patch fixes the issue in `dns_common_replace()` (and wrapping functions) by introducing a new parameter `tombstone`, marking if the object was tombstoned. A modification that revives the object now correctly sets `dnsTombstoned=FALSE`.
With this patches applied, compiled and installed, the previously attached test-script produces the desired output (snippet):
dn: DC=test,DC=loyen.intranet,CN=MicrosoftDNS,DC=DomainDnsZones,DC=loyen,DC=intranet
objectClass: top
objectClass: dnsNode
instanceType: 4
whenCreated: 20170510122133.0Z
uSNCreated: 3817
showInAdvancedViewOnly: TRUE
name: test
objectGUID: 1fba2c33-45d4-4d2c-9df7-a6d05009b79e
objectCategory: CN=Dns-Node,CN=Schema,CN=Configuration,DC=loyen,DC=intranet
dc: test
dnsRecord: NDR: struct dnsp_DnssrvRpcRecord
wDataLength : 0x0004 (4)
wType : DNS_TYPE_A (1)
version : 0x05 (5)
rank : DNS_RANK_ZONE (240)
flags : 0x0000 (0)
dwSerial : 0x0000001d (29)
dwTtlSeconds : 0x00000384 (900)
dwReserved : 0x00000000 (0)
dwTimeStamp : 0x00000000 (0)
data : union dnsRecordData(case 1)
ipv4 : 10.200.46.59
dnsRecord: NDR: struct dnsp_DnssrvRpcRecord
wDataLength : 0x0004 (4)
wType : DNS_TYPE_A (1)
version : 0x05 (5)
rank : DNS_RANK_ZONE (240)
flags : 0x0000 (0)
dwSerial : 0x0000001d (29)
dwTtlSeconds : 0x00000384 (900)
dwReserved : 0x00000000 (0)
dwTimeStamp : 0x0037b09c (3649692)
data : union dnsRecordData(case 1)
ipv4 : 10.200.46.58
dNSTombstoned: FALSE
whenChanged: 20170510122142.0Z
uSNChanged: 3822
distinguishedName: DC=test,DC=loyen.intranet,CN=MicrosoftDNS,DC=DomainDnsZones,DC=loyen,DC=intranet
Created attachment 8845 [details]
41190-dns-correct-tombstoned-461.patch
Updated version of the patch, now tested against (the relevant) Samba-Torture-Tests and `ucs-test-samba4`/`ucs-test-s4connector`.
Ok, it works. I've committed your patch as patches/samba/4.2-0-0-ucs/2:4.6.1-1-errata4.2-0/34_samba_dns_tomstone.quilt and I've built the package with that patch and created an advisory: ucs-4.2-0/doc/errata/staging/samba.yaml If you think that this is everything that should be done, you may just set the bug to resolved, and I'll "continue" with the QA. (In reply to Arvid Requate from comment #6) > Ok, it works. I've committed your patch as > [...] > If you think that this is everything that should be done, you may just set > the bug to resolved, and I'll "continue" with the QA. Thank you! With `patches/samba/4.2-0-0-ucs/2:4.6.1-1-errata4.2-0/34_samba_dns_tomstone.quilt` the commit-messages, which might be useful in the future, are lost. But as long as this Bugzilla is active one should be able to refer to this bug. > With `patches/samba/4.2-0-0-ucs/2:4.6.1-1-errata4.2-0/34_samba_dns_tomstone.quilt` the commit-messages, which might be useful in the future, are lost. AFAICS there have been no commit messages in attachment 8845 [details], otherwise I would have preserved them. <http://errata.software-univention.de/ucs/4.2/42.html> <http://errata.software-univention.de/ucs/4.2/43.html> |
Created attachment 7635 [details] refresh_dns_records_for_host Ticket#: 2016033021000182 shows a case where the DDNS update of Samba/AD doesn't delete dnsRecord from Objects marked as dNSTombstoned: TRUE. In the case of the ticket the customer reported S4-Connector rejects for DNS-Records of MAC clients: ========================================================================= 03.05.2016 13:57:57,58 LDAP (PROCESS): sync to ucs: [ dns] [ modify] relativeDomainName=macbook-teil,zonename=domain.local,cn=dns,dc=domain,dc=local 03.05.2016 13:57:57,682 LDAP (ERROR ): Unknown Exception during sync_to_ucs 03.05.2016 13:57:57,682 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/univention/s4connector/__init__.py", line 1438, in sync_to_ucs result = self.property[property_type].ucs_sync_function(self, property_type, object) File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py", line 1438, in con2ucs ucs_host_record_create(s4connector, object) File "/usr/lib/pymodules/python2.7/univention/s4connector/s4/dns.py", line 876, in ucs_host_record_create newRecord.modify() File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 363, in modify return self._modify(modify_childs,ignore_license=ignore_license) File "/usr/lib/pymodules/python2.7/univention/admin/handlers/__init__.py", line 972, in _modify self.lo.modify(self.dn, ml, ignore_license=ignore_license) File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 423, in modify raise univention.admin.uexceptions.ldapError(_err2str(msg), original_exception=msg) ldapError: Type or value exists: aRecord: value #204 provided more than once ======================================================================== The first impression was, that the MACs didn't take care while updating their DNS-record and would only always add new records. But the initial version attached nsupdate script didn't fix the issue either. The other mysterious point was, that the clients DNS address was not resolvable via DNS lookup! Finally the point seems to be, that the dlz_bind9 module doesn't delete entries from objects marked as "dNSTombstoned: TRUE" -- but it allows to add entries to the object. This results in an unhealthy accumulation of junk values in the Samba/AD dnsRecord attribute. The attached updated version of the refresh_dns_records_for_host script clears the dNSTombstoned attribute before doing the nsupdate cleanup of duplicate dnsRecord values. But we should fix this in the dlz_bind9 module.