librpc/idl/dnsserver.idl: Ensure DnsProperty id matches what is pulled from the store...

librpc/idl/dnsserver.idl: Ensure DnsProperty id matches what is pulled from the stored buffer

There are two concerns here, assuming the attacker can place arbitary values
in a dnsProperty attribute over LDAP (eg is a DNS administrator).

This comes from the fact that id is used as the switch value at the C layer
but at the NDR layer the wDataLength value is considered first.

One concern is that a pull/push round-trip could include server memory:

 The previous switch_is() behaviour could store the server memory back
 into the attribute.

 However this pattern of pull/push only happens in ndrdump and fuzzing tools, as
 dnsserver_db_do_reset_dword() operates only on the uint32/bitmap union
 arms, and fully initialises those.

The other is that a pull of the attacker-supplied value could
cause the server to expose memory.

 This would be over the network via DNS or the RPC dnsserver protocols.
 However at all times the ndr_pull_struct_blob is passed zeroed memory.

The final concern (which fuzz_ndr_X found) is that in the ndr_size_dnsPropertyData()
the union descriminent is only id.

 This has no impact as only zeroed memory is used so there will be a
 zero value in all scalars, including data->d_ns_servers.AddrArray.

 Therefore the server will not crash processing the attacker-supplied blob

[MS-DNSP] 2.3.2.1 dnsProperty has no mention of this special behaviour.
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dnsp/445c7843-e4a1-4222-8c0f-630c230a4c80

This was known as CVE-2019-14908 before being triaged back to a normal bug.

Found by Douglas Bagnall using Hongfuzz and the new fuzz_ndr_X fuzzer.

BUG: https://bugzilla.samba.org/show_bug.cgi?id=14206
Signed-off-by: Andrew Bartlett <abartlet@samba.org>
Reviewed-by: Gary Lockyer <gary@samba.org>