Hi, Tridge, I was wondering if you had more context to add to this issue. In [MS-DNSP] at 3.1.4.5 R_DnssrvUpdateRecord (Opnum 4) I am finding product behavior notes (<221>) "<221> Section 3.1.4.5: Windows 2000, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 do not support updates or deletions of the DNS_TYPE_ZERO, DNS_TYPE_LOC, and DNS_TYPE_ALL types.". We will return DNS_ERROR_UNKNOWN_RECORD_TYPE (9704L). From notes I'm reading 9704L should really be interpreted as UNSUPPORTED_RECORD_TYPE.
I'm also looking at Domain Name System (DNS) Parameters (http://www.iana.org/assignments/dns-parameters) that lists type 1 ("A" 1 a host address) through type 49 ("DHCID" 49 DHCID) that corresponds to the table in [MS-DNSP] "2.2.2.1.1 DNS_RECORD_TYPE" DNS_TYPE_A 0x0001 through DNS_TYPE_DHCID 0x0031 with the exception of DNS_TYPE_ZERO 0x0000, which, at http://www.iana.org/assignments/dns-parameters, is noted as "RRTYPE zero is used as a special indicator for the SIG RR [RFC2931], [RFC4034] and in other circumstances and must never be allocated for ordinary use." So, it's not clear to me in what context you are seeing this. From other notes that I am seeing, we might return these records if enumerated, but we wouldn't originate these records nor allow them to be updated or deleted. Do you see these going on-the-wire? Notwithstanding my observations above, I see information in MS-DNSP that re-enforces my earlier research that if this does go on the wire, then it is a time. [MS-DNSP] 2.2.2.2.5 "DNS_RPC_RECORD" Buffer has Value: DNS_TYPE_ZERO 0x0000 with the meaning DNS_RPC_RECORD_TS. 2.2.2.2.4.23 " DNS_RPC_RECORD_TS" specifies "The DNS_RPC_RECORD_TS specifies information for a node that has been tombstoned. EntombedTime (8 bytes): The unsigned integer value for the time-stamp at which this node was tombstoned.", which is a "time stamp: An integer value representing the number of hours that have elapsed since midnight (00:00:00), January 1, 1601 UTC". That does not seem to match the value you supplied as a sample "40 47 30 F4 9F A0 CB 01" by a longshot. However, I also see this note in MS-DNSP's Glossary: "tombstone: An inactive DNS node which is not considered to be part of a DNS zone but has not yet been deleted from the zone database in the directory server. Tombstones may be permanently deleted from the zone once they reach a certain age. Tombstones are not used for DNS zones that are not stored in the directory server. A node is a tombstone if its dnsTombstoned attribute has been set to "TRUE"." I'm hypothesizing that perhaps dnsTombstoned is FALSE in this case and that the space that would contain EntombedTime is garbage in the example you provided. Is this possible? Bryan -----Original Message----- From: Bryan Burgin Sent: Tuesday, December 21, 2010 10:05 PM To: [email protected] Cc: [email protected]; [email protected]; MSSolve Case Email Subject: RE: [REG:110122106325012] [MS-DNSP] Documentation for DNS_TYPE_ZERO (was "strange records in DNS LDAP NCs") Hay, Tridge, I was doing some initial research on this today: dnsRecord: NDR: struct dnsp_DnssrvRpcRecord wDataLength : 0x0008 (8) wType : DNS_TYPE_ZERO (0) dwFlags : 0x00000005 (5) dwSerial : 0x000002b1 (689) dwTtlSeconds : 0x00000000 (0) dwTimeStamp : 0x00000000 (0) dwReserved : 0x00000000 (0) data : union dnsRecordData(case 0) data : DATA_BLOB length=8 [0000] 40 47 30 F4 9F A0 CB 01 @G0..... what are they for? What is in that 8 bytes of data? Can you give me more context of when you're seeing this (On the wire? Elsewhere?). Initially, I share your expectation that wDataLength should be zero. Do you always see eight. My review is very preliminary, but I thought I would share with you what I had. I'm seeing some code that this may be a pointer (( ULONG64 ) record.Data.NOEXIST.pnodeZoneRoot) that wouldn't have any context outside the running process. And, this doesn't look like a pointer (even if you invert bytes within DWORDs or do any of the standard byte transformations from network order). I'm also seeing some other code that suggests that a "tombstone" value might be stored there as the output of RtlGetSystemTime(), but that doesn't match the data sample you supplied. Both of the forgoing possibilities would contain eight bytes, but neither seem to fit (40 47 30 F4 9F A0 CB 01), so the hunt continues. Bryan -----Original Message----- From: Bryan Burgin Sent: Monday, December 20, 2010 5:49 PM To: '[email protected]' Cc: [email protected]; [email protected]; MSSolve Case Email Subject: [REG:110122106325012] strange records in DNS LDAP NCs [dochelp to bcc] Tridge, I created SR 110122106325012 to track this issue. An engineer from the protocols team will contact you soon. Bryan -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, December 20, 2010 5:23 PM To: Interoperability Documentation Help Cc: [email protected]; [email protected] Subject: strange records in DNS LDAP NCs There are a few aspects of the Windows DNS NCs that are puzzling us: 1) we see records like this: dn: DC=..SerialNo-W2K8R2B.v2.tridgell.net,DC=v2.tridgell.net,CN=MicrosoftDNS,DC=DomainDnsZones,DC=v2,DC=tridgell,DC=net dnsRecord: NDR: struct dnsp_DnssrvRpcRecord wDataLength : 0x0008 (8) wType : DNS_TYPE_ZERO (0) dwFlags : 0x00000005 (5) dwSerial : 0x000002b1 (689) dwTtlSeconds : 0x00000000 (0) dwTimeStamp : 0x00000000 (0) dwReserved : 0x00000000 (0) data : union dnsRecordData(case 0) data : DATA_BLOB length=8 [0000] 40 47 30 F4 9F A0 CB 01 @G0..... what are they for? What is in that 8 bytes of data? What is the significance of the "..SerialNo-HOSTNAME" records? The MS-DNSP doc says: DNS_TYPE_ZERO An empty record type (section 3.6 in [RFC1034] and section 3.2.2 in [RFC1035]). 0x0000 which isn't very useful! 2) what is the dwReserved field in all the dnsNode records? The MS-DNSP doc says: dwReserved: This value MUST be set to 0x00000000 when sent by the client and ignored on receipt by the server. but that makes no sense. These are fields that are sent by the LDAP or DRS server in response to queries. The values are far too consistent to be random. Note that we are not asking about the DNS RPC protocol that MS-DNSP concentrates on. In our case Samba is a DC that is replicating the DNS NCs with Microsoft DCs. We need to know how to fill in these fields when we create records that will be replicated to MS DNS servers via DRS. Cheers, Tridge _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
