[cifs-protocol] [REG:110081057234684] Requesting clarification of MS-DNSP data structure DNS_RPC_NAME

Bryan Burgin bburgin at microsoft.com
Tue Sep 7 17:26:19 MDT 2010 

Kai,

I'm touching base to see if you had any feedback from my message last week.

Also, just FYI, I will be at the SNIA conference in two weeks (http://www.snia.org/events/storage-developer2010/) and, since I'm Redmond-based, I'll also be at the Samba Interop Lab the week following.

Bryan

-----Original Message-----
From: Bryan Burgin 
Sent: Thursday, September 02, 2010 4:07 PM
To: 'Kai Blin'
Cc: pfif at tridgell.net; cifs-protocol at samba.org; MSSolve Case Email
Subject: RE: [REG:110081057234684] Requesting clarification of MS-DNSP data structure DNS_RPC_NAME

Quick update.

I reviewed the SOA.BIN record you produced.  I agree that the contents represent SOA information, but it does not appear to be in the format of a MS-DNSP DNS_RPC_RECORD_SOA structure.  The fixed part (SerialNo, Refresh, Retry, Expire and MinimumTtl) line up.  And, Primary Server and Zone Administrator E-mail follow, but not as DNS_RPC_NAMES.  The issue is more than just WORD v DWORD padding.

[MS-DNSP] DNS_RPC_NAMEs are a single byte of length, an array of bytes containing a UTF-8 string followed by 0-3 bytes of padding.

The SOA.BIN you provided is:

    5a000600 05f00000 53000000 00000e10  # 00000000 Z.......S.......
    00000000 00000000 00000052 00000384  # 00000010 ...........R....
    00000258 00015180 00000e10 22050c77  # 00000020 ...X..Q....."..w
    696e326b 3872322d 646e7304 64656d6f  # 00000030 in2k8r2-dns.demo
    04686f6d 65056b62 6c696e03 6f726700  # 00000040 .home.kblin.org.
    20050a68 6f73746d 61737465 72046465  # 00000050  ..hostmaster.de
    6d6f0468 6f6d6505 6b626c69 6e036f72  # 00000060 mo.home.kblin.or
    6700                                 # 00000070 g.

The two strings are:

    ........ ........ ......... 22050c77  # 00000020 ............"..w
    696e326b 3872322d 646e7304 64656d6f  # 00000030 in2k8r2-dns.demo
    04686f6d 65056b62 6c696e03 6f726700  # 00000040 .home.kblin.org.

And 

    20050a68 6f73746d 61737465 72046465  # 00000050  ..hostmaster.de
    6d6f0468 6f6d6505 6b626c69 6e036f72  # 00000060 mo.home.kblin.or
    6700                                 # 00000070 g.

Decoding the last one as an example:

	Length in bytes (excluding this header): 0x20 (32)
	Number of elements: 0x05

	Then, for each element:

		(1)
		Length in bytes: 0x0a
		String: 'hostmaster'

		(2)
		Length in bytes: 0x04
		String: 'demo'

		(3)
		Length in bytes: 0x04
		String: 'home'

		(4)
		Length in bytes: 0x05
		String: 'kblin'

		(5)
		Length in bytes: 0x03
		String: 'org'

	One byte of padding

I'm working out a reference to point you to.

I'm also to produce this traffic using the utility LDP.EXE.  I pass this on to ensure that we're looking at the same record.  After connecting, on the Bind dialog I uncheck "Encrypt traffic after bind".  When doing a search, I select Base DN: "DC=@,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com" and set Attributes="dnsRecord".  I get the attached capture (see frame 238).  See 'Attribute N' I marked below.

Bryan

  Frame: Number = 238, Captured Frame Length = 519, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-4A-E8-55],SourceAddress:[00-15-5D-4A-E8-47]
+ Ipv4: Src = 192.168.0.201, Dest = 192.168.0.5, Next Protocol = TCP, Packet ID = 32704, Total IP Length = 505
+ Tcp: Flags=...AP..., SrcPort=LDAP(389), DstPort=52876, PayloadLen=465, Seq=1653567123 - 1653567588, Ack=673576468, Win=251 (scale factor 0x8) = 64256
  Ldap: Search Result Entry, MessageID: 93, Status: Success
+ LDAPSASLBuffer: BufferLength: 461, AuthMechanism: GSS-SPNEGO
- LDAPMessage: Search Result Entry, MessageID: 93
  + ParserHeader: 
  + MessageID: 93
  + OperationHeader: Search Result Entry, 4(0x4)
  - SearchResultEntry: DC=@,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com
   + ObjectName: DC=@,DC=contoso.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com
   - Attributes: 1 Partial Attributes
    + SequenceHeader: 
    - PartialAttribute: dnsRecord=(  )(  )( N )(  )(  )(  )
     + PartialAttributeHeader: 0x1
     + Type: dnsRecord
     + AttributeValuesHeader: 
     + Attribute: 
     + Attribute: 
     + Attribute: N <---- I believe this dnsRecord contains the SOA record you are referencing
     + Attribute: 
     + Attribute: 
     + Attribute: 
+ LDAPMessage: search Result Done, MessageID: 93
	
 SOA: 
 
04 66 4E 00 06 00 05 F0 00 00 69 00 00 00 00 00 0E 10 00 00 00 00 00 00 00 00 00 00 00 68 00 00 03 84 00 00 02 58 00 01 51 80 00 00 0E 10 12 03 04 64 63 30 31 07 63 6F 6E 74 6F 73 6F 03 63 6F 6D 00 24 05 0A 68 6F 73 74 6D 61 73 74 65 72 07 63 6F 6E 74 6F 73 6F 03 63 6F 6D 07 63 6F 6E 74 6F 73 6F 03 63 6F 6D 00 

.fN....ð..i..................h...„...X..Q€.......dc01.contoso.com.$..hostmaster.contoso.com.contoso.com.


-----Original Message-----
From: Kai Blin [mailto:kai at samba.org] 
Sent: Friday, August 27, 2010 2:44 PM
To: Bryan Burgin
Cc: pfif at tridgell.net; cifs-protocol at samba.org; MSSolve Case Email
Subject: Re: [REG:110081057234684] Requesting clarification of MS-DNSP data structure DNS_RPC_NAME

On Thu, 26 Aug 2010 23:29:30 +0000
Bryan Burgin <bburgin at microsoft.com> wrote:

Hi Bryan,

> When I look at components that handle DNSP packets, I see asserts in the checked builds that verify that DNS_RPC_NAME structures are DWORD aligned, so I'm inclined to believe that the documentation is correct.  However, I have been trying to verify this myself.  I used DNSMGR.DLL (the Admin snap-in via Start->Administrative Tools->DNS "DNS Manager") and captured MS-DNSP traffic.
> 
> However, that doesn't match your repro scenario at all.
> 
> You cited "MS-DNSP describes a DNS_RPC_NAME data structure in section 2.2.2.2.1.  [...]  Quering a Win2k8R2 server for DNS records via LDAP, it looks like the DNS_RPC_NAME structure is 2-byte-aligned [...]"  When I do LDAP queries (via LDAPDE or "Active Directory Users and Computers"), I'm not seeing any MS_DNSP traffic.
> 
> So, can you help me repro the alignment issue you're seeing re MS-DNSP DNS_RPC_NAME 2.2.2.2.1 (with an emphasis on DNS_RPC_RECORD_SRV records).  Or, is this issue involving something other than MS-DNSP?

I'm not producing MS-DNSP traffic. I'm trying to decode the LDAP datastructures related to the DNS service. These seem to be encoded following the MS-DNSP document, so I used that for my implementation.

I see I made a typo in my last email, I'm seeing the parse error on the SOA record, not the SRV record. The attached record blob was extracted from a win2k8r2 server, and the second DNS_RPC_NAME only decodes correctly if I make sure the first DNS_RPC_NAME is 2-byte-aligned.

I've also attached an LDIF file, on record 7, the 6th DNS_RECORD is the record in question.

All in all my question is more about the LDAP storage of MS-DNSP-related data, rather than the protocol itself. If there's a better description of the DNS data stored in LDAP than MS-DNSP, what document would that be?

Cheers,
Kai

--
Kai Blin
Worldforge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/

More information about the cifs-protocol mailing list