Windows主机DNS查询_ldap._tcp.domaincontroller，这是正常的？

为了让我的头更容易，下面是我用在我的例子中的东西：

deecee =我的域控制器
dctoo =另一个域控制器
internal.foo.bar =我的Windows域的完整DNSDomainName。
foo =我的Windows域的短（netbios）名称。
oursite =我们域中唯一的网站

我们将所有的日志logging打开为MS DNS服务器，并看到大量的NXDOMAIN这种forms的请求： _ldap._tcp.deecee.internal.foo.bar. 请注意，我不是在讨论_ldap._tcp.internal.foo.bar. 那些工作正常。这是来自日志的错误条目：

 2/19/2015 8:07:06 AM 0960 PACKET 0000000002F885B0 UDP Snd 10.0.0.87 5052 RQ [8385 A DR NXDOMAIN] SRV (5)_ldap(4)_tcp(6)deecee(8)internal(3)foo(3)bar(0) UDP response info at 0000000002F885B0 Socket = 332 Remote addr 10.0.0.87, port 54309 Time Query=178201, Queued=0, Expire=0 Buf length = 0x0fa0 (4000) Msg length = 0x006d (109) Message: XID 0x5052 Flags 0x8583 QR 1 (RESPONSE) OPCODE 0 (QUERY) AA 1 TC 0 RD 1 RA 1 Z 0 CD 0 AD 0 RCODE 3 (NXDOMAIN) QCOUNT 1 ACOUNT 0 NSCOUNT 1 ARCOUNT 0 QUESTION SECTION: Offset = 0x000c, RR count = 0 Name "(5)_ldap(4)_tcp(6)deecee(8)internal(3)foo(3)bar(0)" QTYPE SRV (33) QCLASS 1 ANSWER SECTION: empty AUTHORITY SECTION: Offset = 0x0030, RR count = 0 Name "(8)internal(3)foo(3)bar(0)" TYPE SOA (6) CLASS 1 TTL 3600 DLEN 38 DATA PrimaryServer: (6)deecee[C030](8)internal(3)foo(3)bar(0) Administrator: (5)admin[C030](8)internal(3)foo(3)bar(0) SerialNo = 247565 Refresh = 900 Retry = 600 Expire = 86400 MinimumTTL = 3600 ADDITIONAL SECTION: empty

请注意，客户_ldap._tcp.deecee.internal.foo.bar.在请求_ldap._tcp.deecee.internal.foo.bar. 根据微软的文档，正确的请求应该是_ldap._tcp.internal.foo.bar.

请求来自我们所有的ADjoin机器。它们包括Windows 7，Server 2008，2008 R2，2012和2012 R2。

我们的DNS服务器确实具有相应的_ldap._tcp.internal.foo.bar SRV条目，并且它们可以正确parsing。所以这不是问题。

一位同事向微软公司开了一个案子，几天后科技终于宣称这是正常的。我不买。为什么在任何文档中都没有提到这种行为？

那么，有没有其他人看到这种行为？查看_ldap._tcp.deecee.internal.foo.bar SRVlogging的客户？如果是这样，他们是否获得NXDOMAIN结果？

任何想法如何解决这一问题？

提前致谢。

更新A – 还有更多

在我的网域中，我以最常见的顺序看到这些无效查询：

 _ldap._tcp.oursite._sites.deecee.internal.foo.bar _ldap._tcp.deecee.internal.foo.bar _ldap._tcp.oursite._sites.dctoo.internal.foo.bar _ldap._tcp.dctoo.internal.foo.bar _ldap._tcp.deecee <- only from our sharepoint hosts _ldap._tcp.oursite._sites.decee _ldap._tcp.oursite._sites.dctoo _ldap._tcp.dctoo <- only from our sharepoint hosts

更新B – 在sharepoint中有一些东西

我打开了一个受影响的机器上的netlogondebugging，发现一些有趣的东西。首先，我相信这是一个成功的查询被发送：

 02/26 22:31:00 [MISC] [6824] DsGetDcName function called: client PID=1884, Dom:FOO Acct:(null) Flags: DS NETBIOS RET_NETBIOS 02/26 22:31:00 [MISC] [6824] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c07ffff1 02/26 22:31:00 [MISC] [6824] NetpDcGetName: internal.foo.bar. using cached information ( NlDcCacheEntry = 0x0000007051E732F0 ) 02/26 22:31:00 [MISC] [6824] DsGetDcName: results as follows: DCName:\\DEECEE DCAddress:\\10.1.1.80 DCAddrType:0x1 DomainName:FOO DnsForestName:internal.hlc.com Flags:0x800031fc DcSiteName:oursite ClientSiteName:oursite 02/26 22:31:00 [MISC] [6824] DsGetDcName function returns 0 (client PID=1884): Dom:FOO Acct:(null) Flags: DS NETBIOS RET_NETBIOS

这是一个不成功的查询被发送的样子：

 02/27 09:13:01 [MISC] [308] DsGetDcName function called: client PID=1884, Dom:DEECEE Acct:(null) Flags: WRITABLE LDAPONLY RET_DNS 02/27 09:13:01 [MISC] [308] DsIGetDcName: DNS suffix search list allowed but single label DNS disallowed for name DEECEE 02/27 09:13:01 [MISC] [308] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c07ffff1 02/27 09:13:01 [CRITICAL] [308] NetpDcGetNameIp: DEECEE: No data returned from DnsQuery. 02/27 09:13:01 [MISC] [308] NetpDcGetName: NetpDcGetNameIp for DEECEE returned 1355 02/27 09:13:01 [MAILSLOT] [308] Sent 'Sam Logon' message to DEECEE[1C] on all transports. 02/27 09:13:03 [CRITICAL] [308] NetpDcGetNameNetbios: DEECEE: Cannot NlBrowserSendDatagram. (ALT) 53 02/27 09:13:03 [MISC] [308] NetpDcGetName: NetpDcGetNameNetbios for DEECEE returned 1355 02/27 09:13:03 [CRITICAL] [308] NetpDcGetName: DEECEE: IP and Netbios are both done. 02/27 09:13:03 [MISC] [308] DsGetDcName function returns 1355 (client PID=1884): Dom:DEECEE Acct:(null) Flags: WRITABLE LDAPONLY RET_DNS

如果我的理解是正确的（请纠正我，如果不正确），第一行表明PID 1884过程是要求netlogonlogin名为“DEECEE”的域。它字面上认为域名是DEECEE。当然，以前的片断（和其他片断）表明，这个过程，pid = 1884，正在寻找请求，其中一些是合法的，有些则不合法。

检查该机器上的进程列表告诉我这是一个w3wp进程。所以我find了应用程序池：

 C:\Windows\System32\inetsrv>appcmd list wps WP "1856" (applicationPool:SharePoint - 80) WP "6540" (applicationPool:SharePoint Central Administration v4) WP "1884" (applicationPool:272b926088ea454c8a4b4caa8526d3bb) WP "8468" (applicationPool:6997d03e3ea94018841409e8b821d8da) WP "6696" (applicationPool:SecurityTokenServiceApplicationPool)

然后我检查了哪个应用程序在该池中运行：

 PS C:\Users\administrator.HLC> Get-SPServiceApplication | foreach { if($_.ApplicationPool.Id -eq "272b9260-88ea-454c-8a4b-4caa8526d3bb") { $_ } } DisplayName TypeName Id ----------- -------- -- PerformancePoint ... PerformancePoint ... 8681c71c-81b9-41e5-ac19-58d0ccf11227 Managed Metadata ... Managed Metadata ... ef99af38-a3f8-4864-8c88-9ee421f3dfa0 App Management Se... App Management Se... 183ca7a4-825a-4807-91fc-4fe1c9fe93e0 Excel Services Excel Services Ap... 46557c93-3d60-47f0-99ab-45cc32258137 Subscription Sett... Microsoft SharePo... 9fd75bbe-1464-4a4c-8bd0-3382c0c03dce Search Administra... Search Administra... ee519543-e311-41fd-a8a4-0b952f731ff8 User Profile Service User Profile Serv... fe6886ab-4a2d-4216-8bcf-5160dad5c037 Business Data Con... Business Data Con... 813bb77c-9eb4-43d0-b2cc-09e8162e58e7 Work Management S... Work Management S... 81dbd284-2506-43a0-be93-2820759bb804 Search Service Ap... Search Service Ap... d641f112-b299-4318-baaf-817ef96107c4

所以我花了一些时间来启用和禁用这些SharePoint服务，并观看DNS查询。看来用户configuration文件服务至less导致查询_ldap._tcp.deecee。

我知道整件事情不是共同点的错; 正如我刚才所说，这些疑问来自全国各地。只是_ldap._tcp.deecee，只是来自我们的SharePoint主机。

这就增加了另一个问题。什么是用户configuration文件服务，导致查找_ldap._tcp.deecee？尽pipe如此，我们剩下的服务器仍然存在问题。

启用netlogondebugging，我发现在我的Win7 SP1机器（域控制器是2008r2SP1）相同的结果。据我所知，这也造成了8秒的处理延迟。看起来像来自netlogon的错误的API调用给我。

您可以通过在工作站上运行以下内容来复制相同的1355错误：

 nltest /dsgetdc:domaincontroller.domain.com

收益：

获取DC名称失败：状态= 1355 0x54b ERROR_NO_SUCH_DOMAIN

显然是因为它用错误的参数调用了dsgetdc。

虽然我同意其他人的看法，但是基础设施很可能没有问题。尽pipe如此，这将是很好的。

无需修复，这些查找正在为您的AD树find相应的LDAP服务器。