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: [email protected]; [email protected]; 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:[email protected]] Sent: Friday, August 27, 2010 2:44 PM To: Bryan Burgin Cc: [email protected]; [email protected]; 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 <[email protected]> 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/ _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
