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

tridge at samba.org tridge at samba.org
Tue Jan 11 19:00:08 MST 2011

Hi Bryan,

 > [MS-DNSP] "DNS_RPC_RECORD" Buffer has Value: DNS_TYPE_ZERO 0x0000 with the meaning DNS_RPC_RECORD_TS.
 > "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

 > 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

More information about the cifs-protocol mailing list