[cifs-protocol] [EXTERNAL] Re: dNSProperty parsing of DSPROPERTY_ZONE_NS_SERVERS_DA in particular [120040622000005]

[Obaid Farooqi]

Hi Andrew:
We are almost there.
The research is just waiting some official confirmation but code browsing suggest that we do not perform any validation when data is written to AD. But at the time when DNS reads it, it will reject such kind of records. 

I'll update you if there is a change in this. 

Regards,
Obaid Farooqi
Escalatiion Engineer | Microsoft

-----Original Message-----
From: Andrew Bartlett <abartlet at samba.org> 
Sent: Wednesday, April 22, 2020 4:59 PM
To: Obaid Farooqi <obaidf at microsoft.com>; cifs-protocol mailing list <cifs-protocol at lists.samba.org>
Cc: support <support at mail.support.microsoft.com>
Subject: [EXTERNAL] Re: [cifs-protocol] dNSProperty parsing of DSPROPERTY_ZONE_NS_SERVERS_DA in particular [120040622000005]

G'Day Obiad,

Any news on this one?

Thanks,

Andrew Bartlett

On Mon, 2020-04-06 at 01:44 +0000, Obaid Farooqi via cifs-protocol
wrote:
> 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%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=YUcS83iOfEhA%2BdDtvh4udt%2FHSS9HHnE1aCdP6yN85cM%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%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=E1zkAtFDG9ONCp8CIKUzNjiZ%2FXVXTfB%2B37v1UyOR9Bs%3D&reserved=0
> because of bug
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugz
> illa.samba.org%2Fshow_bug.cgi%3Fid%3D14206&data=02%7C01%7Cobaidf%4
> 0microsoft.com%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141af91
> ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=3hTeDUXXBaCPKEA0
> aefJ%2Bswd4XDRvrvgflV3iKEM5%2F4%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%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=AzUdz%2FQOb4tLOUebkVKXL3eJ%2BsyJOAEbti%2Fav%2Fehk7A%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%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=KdvIxvqdb86QnnGnQuVSnFSl2stf1OwMsoC9PALuxmg%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%7C314454599b904edc858d08d7e7086cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637231895691697152&sdata=yyRKLHbzoGejyC0C1ZLBjLFYdgf0G9XQkK6NglXXuzs%3D&reserved=0