[cifs-protocol] dNSProperty parsing of DSPROPERTY_ZONE_NS_SERVERS_DA in particular [120040622000005]
Obaid Farooqi
obaidf at microsoft.com
Mon Apr 6 01:44:52 UTC 2020
Hi Andrew:
Thanks for contacting Microsoft. I have created a case to track this issue. A member of the open specifications team will be in touch soon.
Regards,
Obaid Farooqi
Escalation Engineer | Microsoft
-----Original Message-----
From: Andrew Bartlett <abartlet at samba.org>
Sent: Sunday, April 5, 2020 6:44 PM
To: Interoperability Documentation Help <dochelp at microsoft.com>; cifs-protocol mailing list <cifs-protocol at lists.samba.org>
Subject: [EXTERNAL] dNSProperty parsing of DSPROPERTY_ZONE_NS_SERVERS_DA in particular
G'Day Dochelp,
I'm hoping for a little help with interoperability here. The situation is a Samba AD Domain that has also had a Windows AD DC in it, so some records were not created by Samba, like this records in the DNS partition.
In the
DC=_msdcs.X.Y,CN=MicrosoftDNS,DC=ForestDnsZones,DC=X,DC=Y
record, there is an attribute:
dNSProperty:: AAAAAAAAAAAAAAAAAQAAAJIAAAAAAAAA
000000 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 >................<
000010 92 00 00 00 00 00 00 00 >........<
000018
We, until samba 4.12, would parse this as:
pull returned Success
dnsp_DnsProperty: struct dnsp_DnsProperty
wDataLength : 0x00000000 (0)
namelength : 0x00000000 (0)
flag : 0x00000000 (0)
version : 0x00000001 (1)
id : DSPROPERTY_ZONE_NS_SERVERS_DA (146)
data : union dnsPropertyData(case 0)
name : 0x00000000 (0)
dump OK
However, the wDataLength is 0. There is not anything in [MS-DNSP] 2.3.2.1 dnsProperty to describe any special behaviour for when the id suggests that there is a value, but wDataLength is 0.
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-dnsp%2F445c7843-e4a1-4222-8c0f-630c230a4c80&data=02%7C01%7Cobaidf%40microsoft.com%7C53955661696c49047dc508d7d9bb33c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637217270370382699&sdata=IUnBXWE4A7Ku3aKOxxIt0qNVruGmL2SCrGEirHfaWPg%3D&reserved=0
We now fail to parse it, because we expect an entry with id DSPROPERTY_ZONE_NS_SERVERS_DA to therefore have a valid DNS_ADDR_ARRAY (section 2.2.3.2.3).
As context (mostly for my fellow team members), we changed it in our commit
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.samba.org%2F%3Fp%3Dsamba.git%3Ba%3Dcommit%3Bh%3Dfee5c6a4247aeac71318186bbff7708d25de5912&data=02%7C01%7Cobaidf%40microsoft.com%7C53955661696c49047dc508d7d9bb33c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637217270370382699&sdata=E28dvOwtiXIrLv9cAOAPbA0ZZt8ymFhf41IV2ZKrsfk%3D&reserved=0
because of bug https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.samba.org%2Fshow_bug.cgi%3Fid%3D14206&data=02%7C01%7Cobaidf%40microsoft.com%7C53955661696c49047dc508d7d9bb33c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637217270370382699&sdata=g2eUwHHxb34BENWmCFMiLdooqEwX0fIpJ0sAVfl3AVk%3D&reserved=0
which was due to the artificial environment of the fuzzer.
Can you clarify how this should be interpreted, so we can fix this properly?
Thanks!
Andrew Bartlett
--
Andrew Bartlett https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fsamba.org%2F~abartlet%2F&data=02%7C01%7Cobaidf%40microsoft.com%7C53955661696c49047dc508d7d9bb33c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637217270370382699&sdata=d%2BJQIdjP%2BDn7NuClbayhg6oQn2TexoZCGFTwIEPmu%2BI%3D&reserved=0
Authentication Developer, Samba Team https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsamba.org%2F&data=02%7C01%7Cobaidf%40microsoft.com%7C53955661696c49047dc508d7d9bb33c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637217270370382699&sdata=VeDOBAx8f%2Bhu%2BnsUQonYxFuGSOv3j2CSokR1n9bfnJM%3D&reserved=0
Samba Developer, Catalyst IT
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcatalyst.net.nz%2Fservices%2Fsamba&data=02%7C01%7Cobaidf%40microsoft.com%7C53955661696c49047dc508d7d9bb33c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637217270370392695&sdata=OsigF8WWnJnhoRs4dVO0TuQpe9HucOrvyO4HjhQ73hc%3D&reserved=0
More information about the cifs-protocol
mailing list