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

Fri Oct 1 11:32:31 MDT 2010

[MS-DNSP] was updated.

Section 3.1.6.3 was added

3.1.6.3   dnsRecord in the Directory Server

If the server is directory server integrated, then whenever dnsRecord attribute values (section 2.3.1.2) are written to the directory server by using LDAP, each string MUST be converted from type DNS_RPC_NAME (section 2.2.2.2.1) to type DNS_COUNT_NAME (section 2.2.2.2.3). Similarly, when reading dnsRecords, the DNS server MUST convert each string of type DNS_COUNT_NAME to type DNS_RPC_NAME.

As well as 2.2.2.2.2 DNS_COUNT_NAME, below.

2.2.2.2.1   DNS_RPC_NAME
The DNS_RPC_NAME structure is used to specify an FQDN, a DNS label, or another string in an RPC buffer by the DNS server. See section 3.1.6.3 for the handling of this structure in the directory server.

0

1

2

3

4

5

6

7

8

9

1
0

1

2

3

4

5

6

7

8

9

2
0

1

2

3

4

5

6

7

8

9

3
0

1

cchNameLength

dnsName (variable)

...

cchNameLength (1 byte):  The length, in bytes, of the string stored in the dnsName member. To represent an empty string, cchNameLength MUST be zero and dnsName MUST be empty. The length of this structure will always be 4-byte aligned so there may be 0-3 bytes of padding at the end of the structure. The pad bytes are not included in the cchNameLength count.

dnsName (variable):  A UTF-8 string with length given by cchNameLength. The string MUST NOT be null-terminated. This string can represent a fully qualified domain name or any other string.

2.2.2.2.2   DNS_COUNT_NAME
The DNS_COUNT_NAME structure is used to specify an FQDN in an LDAP message.

0

1

2

3

4

5

6

7

8

9

1
0

1

2

3

4

5

6

7

8

9

2
0

1

2

3

4

5

6

7

8

9

3
0

1

Length

LabelCount

RawName (variable)

...

Length (1 byte):  The length, in bytes, of the string stored in the RawName member, including null termination. To represent an empty string, Length MUST be zero, LabelCount MUST be zero, and RawName MUST be empty.

LabelCount (1 byte):  The count of DNS labels in the RawName member.

RawName (variable):  A string containing an FQDN in which a 1-byte label length count for the subsequent label has been inserted before the first label and in place of each "." delimiter. The string MUST be null-terminated. The maximum length of the string, including the null terminator, is 256 bytes.

These changes will be reflected in a future release of the document.

Bryan

-----Original Message-----
From: Bryan Burgin
Sent: Thursday, September 16, 2010 11:33 AM
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

Hi, Kai,

I worked with the MS-ADTS folks quite a bit and they collaborated with the MS-DNSP devs.  From the MS-ADTS devs:

"Microsoft DNS Server can be configured in Active Directory Integration Mode (see http://technet.microsoft.com/en-us/library/cc772746(WS.10).aspx and http://technet.microsoft.com/en-us/library/cc772774(WS.10).aspx). In this mode, zone data is stored in Active Directory, and the attribute called "dnsRecord" is used to store SOA records. These values are opaque to Active Directory.  After initial investigation, the format of these records appears to differ from a SOA record as described in MS-DNSP."

We will be making an update to MS-DNSP to describe how dnsRecords and "Counted names" appear on-the-wire.

I'll keep you updated and I'll see you next week at SNIA.

Bryan

-----Original Message-----

From: Bryan Burgin

Sent: Wednesday, September 08, 2010 10:39 AM

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

I bundled up all my research (including identifying the source in DNS.EXE that is producing this traffic) and filed an inquiry with the protocol architects.

Bryan

-----Original Message-----

From: Kai Blin [mailto:kai at samba.org]

Sent: Wednesday, September 08, 2010 12:39 AM

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 Tue, 7 Sep 2010 23:26:19 +0000

Bryan Burgin <bburgin at microsoft.com<mailto:bburgin at microsoft.com>> wrote:

Hi Bryan,

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

Ah, I was mostly waiting for the documentation on the LDAP storage format of the DNS data.

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

Ah, great. I'll be at the SNIA conference and then flying over to the Interop Lab as well. I'll be bringing my test environment.

Some thoughts on your previous email:

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

I agree. The SOA record contains two RFC1035 domain-name fields. My request was mainly based on my assumption that the storage of DNS data in LDAP was going to be in the same format as the data sent over the wire in the DNSP protocol. Given that an RFC1035 SOA RDATA record has a different order, the DNSP document looked like a better match.

So basically my question boils down to "Where do I find documentation on how DNS data is stored in LDAP?"

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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20101001/6b1b7d4e/attachment-0001.html>