[cifs-protocol] [REG:110122106325012] [MS-DNSP] Documentation for DNS_TYPE_ZERO (was "strange records in DNS LDAP NCs")

[Bryan Burgin]

Perfect.  I'll make a request to ensure that the document has the correct units of time and close this incident since the format of this field is now known.

As for your comment "I think this DNS tombstoning logic is something else that needs to be added to a new WSPP DNS document, along with all the other DNS server and DNS+ldap behaviour we have been discussing.  There seems to be quite a bit of DNS behaviour in Windows that is not in the DNS RFCs, especially with regard to the mapping between the ldap storage of DNS data and the DNS server implementation.", I'm going to bundle that with the similar comments you made on another thread and address those separately.

Bryan


-----Original Message-----
From: tridge at samba.org [mailto:tridge at samba.org] 
Sent: Tuesday, January 11, 2011 6:00 PM
To: Bryan Burgin
Cc: Andrew Bartlett; 'cifs-protocol at samba.org'; MSSolve Case Email
Subject: RE: [REG:110122106325012] [MS-DNSP] Documentation for DNS_TYPE_ZERO (was "strange records in DNS LDAP NCs")

Hi Bryan,

 > [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 "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".

I think you're on the right track with this being a tombstone record, and the 8 bytes seem to be a 64 bit NTTIME field in little-endian format (a time in 100ns units since 1601).

I tested this by deleting the following site record using the sites and services tool:

dn: DC=_ldap._tcp.RODC-Site._sites.DomainDnsZones,DC=v2.tridgell.net,CN=MicrosoftDNS,DC=DomainDnsZones,DC=v2,DC=tridgell,DC=net
dnsRecord:     NDR: struct dnsp_DnssrvRpcRecord
        wDataLength              : 0x001e (30)
        wType                    : DNS_TYPE_SRV (33)
        version                  : 0x05 (5)
        rank                     : DNS_RANK_ZONE (240)
        flags                    : 0x0000 (0)
        dwSerial                 : 0x00000023 (35)
        dwTtlSeconds             : 0x00000258 (600)
        dwReserved               : 0x00000000 (0)
        dwTimeStamp              : 0x0036c08c (3588236)
        data                     : union dnsRecordData(case 33)
        srv: struct dnsp_srv
            wPriority                : 0x0000 (0)
            wWeight                  : 0x0064 (100)
            wPort                    : 0x0185 (389)
            nameTarget               : w2k8.v2.tridgell.net


and after deleting it, this is what happened to the record:


dn: DC=_ldap._tcp.RODC-Site._sites.DomainDnsZones,DC=v2.tridgell.net,CN=MicrosoftDNS,DC=DomainDnsZones,DC=v2,DC=tridgell,DC=net
dNSTombstoned: TRUE
dnsRecord:     NDR: struct dnsp_DnssrvRpcRecord
        wDataLength              : 0x0008 (8)
        wType                    : DNS_TYPE_TOMBSTONE (0)
        version                  : 0x05 (5)
        rank                     : DNS_RANK_NONE (0)
        flags                    : 0x0000 (0)
        dwSerial                 : 0x0000029d (669)
        dwTtlSeconds             : 0x00000000 (0)
        dwReserved               : 0x00000000 (0)
        dwTimeStamp              : 0x00000000 (0)
        data                     : union dnsRecordData(case 0)
        timestamp                : Wed Jan 12 12:28:15 2011 EST


(I've now changed our display code in ldbsearch to show wType zero as DNS_TYPE_TOMBSTONE, and to display the 8 bytes as a NTTIME called
'timestamp')

 > 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"."

ok, that makes sense

 > 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?

no, dnsTombstoned is TRUE, and the 8 bytes are a NTTIME that the record was deleted.

I think this DNS tombstoning logic is something else that needs to be added to a new WSPP DNS document, along with all the other DNS server and DNS+ldap behaviour we have been discussing.

There seems to be quite a bit of DNS behaviour in Windows that is not in the DNS RFCs, especially with regard to the mapping between the ldap storage of DNS data and the DNS server implementation.

Cheers, Tridge