[cifs-protocol] [REG:110122152819123] dwFlags in dnsRecord; use of dnsNode.dwReserved field

[Bryan Burgin]

Tridge,

This e-mail is a response to your questions regarding dnsRecord's Flags and dwReserved fields.  I was already following up on a big/little endian issue with TtlSeconds for your team.  In my research of that issue, I observed several issues with [MS-DNSP] 2.3.1.2 dnsRecord, including the questions you just raised.  We are in the process of updating [MS-DNSP] 2.3.1.2 dnsRecord.  With the changes, I believe your issues will be resolved.

The new format will be as follows:

DataLength (2 bytes):  An unsigned binary integer containing the length, in bytes, of the Data field.

Type (2 bytes):  The resource record's type. See DNS_RECORD_TYPE (section 2.2.2.1.1).

Version (1 byte):  The version number associated with the resource record attribute. The value MUST be 0x00000005.

Rank (1 byte):  The least-significant byte of one of the RANK* flag values. See dwFlags (section 2.2.2.2.5).

Flags (2 bytes):  Not used. The value MUST be 0x0000.

Serial (4 bytes):  The serial number of the SOA record of the zone containing this resource record. See DNS_RPC_RECORD_SOA (section 2.2.2.2.4.3).

TtlSeconds (4 bytes):  See dwTtlSeconds (section 2.2.2.2.5). This field uses big-endian byte order.

Reserved (4 bytes): This field is reserved for future use. The value MUST be 0x00000000.

TimeStamp (4 bytes):  See dwTimeStamp (section 2.2.2.2.5).

Data (variable):  The resource record's data. See DNS_RPC_RECORD_DATA (section 2.2.2.2.4).

When using the above as a template, I expect that you will now see dwReserved as zero.  I suspect that what you were seeing as non-NULL dwReserved fields are actually TimeStamp fields.  That was my experience.

Regarding the dwFlags examples you provided:

        dwFlags                  : 0x00000005 (5)
        dwFlags                  : 0x00000805 (2053)
        dwFlags                  : 0x00008005 (32773)
        dwFlags                  : 0x00008205 (33285)
        dwFlags                  : 0x0000f005 (61445)

after byte-flipping and breaking dwFlags into Version (1 byte), Rank (1 byte) and Flags (2 bytes) fields:

        Version:                  : 0x05 (5) in all cases
        Rank:                       : 0x00
                                         : 0x08 RANK_ROOT_HINT
                                         : 0x80 RANK_GLUE
                                         : 0x82 RANK_NS_GLUE
                                         : 0xf0 RANK_ZONE
        Flags:                       : 0x0000 (0) in all cases

I snapped a packet that contains three such records and show them below:

(1) DNS_TYPE_A:

Header: 04 00 01 00 05 F0 00 00 04 00 00 00 00 00 02 58 00 00 00 00 4F CD 36 00
Value: (DNS_TYPE_A) 0A 00 00 01 (10.0.0.1)

(2) DNS_TYPE_NS:

Header: 14 00 02 00 05 F0 00 00 04 00 00 00 00 00 0E 10 00 00 00 00 00 00 00 00
Value:12 03 02 64 63 07 63 6F 6E 74 6F 73 6F 05 6C 6F 63 61 6C 00 ("dc contoso local")

(3) DNS_TYPE_SOA:

Header: 44 00 06 00 05 F0 00 00 04 00 00 00 00 00 0E 10 00 00 00 00 00 00 00 00
Value: 00 00 00 03 00 00 03 84 00 00 02 58 00 01 51 80 00 00 0E 10 12 03 02 64 63 07 63 6F 6E 74 6F 73 6F 05 6C 6F 63 61 6C 00 (proper SOA Record)

Taking the three DNS_RPC_HEADERS (adding "|" breaks between fields):

(1) 04 00 | 01 00 | 05 | F0 | 00 00 | 04 00 00 00 | 00 00 02 58 | 00 00 00 00 | 4F CD 36 00
(2) 14 00 | 02 00 | 05 | F0 | 00 00 | 04 00 00 00 | 00 00 0E 10 | 00 00 00 00 | 00 00 00 00
(3) 44 00 | 06 00 | 05 | F0 | 00 00 | 04 00 00 00 | 00 00 0E 10 | 00 00 00 00 | 00 00 00 00

Bryan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20101221/b80786a8/attachment.html>