为了让我更容易理解这一点，我在示例中使用了以下内容：
deecee = 我的域控制器
dctoo = 另一个域控制器
internal.foo.bar = 我的 Windows 域的完整 DNSDomainName。foo
= 我的 Windows 域的简称 (netbios)。oursite
= 我们域中的唯一站点
我们已为 MS DNS 服务器开启了所有日志记录，并看到大量 NXDOMAIN 请求，请求形式如下：_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 R Q [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.根据 Microsoft 的文档，正确的请求应该是_ldap._tcp.internal.foo.bar.
这些请求来自我们所有加入 AD 的机器。其中包括 Windows 7、Server 2008、2008 R2、2012 和 2012 R2。
我们的 DNS 服务器确实有适当的 SRV 条目，_ldap._tcp.internal.foo.bar并且它们确实能正确解析。所以这不是问题所在。
一位同事向微软提出了一个问题，几天后技术人员终于声称这是正常现象。我不相信。为什么任何文档中都没有提到这种行为？
那么，还有人看到这种行为吗？客户端在查找 SRV 记录吗_ldap._tcp.deecee.internal.foo.bar？如果是，他们是否获得了 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 中存在一些问题
我在其中一台受影响的机器上打开了 netlogon 调试，发现了一些有趣的东西。首先，我认为这是一个成功发送的查询：
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 的进程正在请求 netlogon 登录到名为“DEECEE”的域。它确实认为域名是 DEECEE。当然，前面的代码片段（和其他代码片段）显示，这个进程 pid=1884 正在发送大量请求，其中一些是合法的，而另一些则不是。
检查该机器上的进程列表告诉我这是一个w3wp进程。所以我找到了应用程序池：
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 查询的发出情况。看来用户配置文件服务至少引发了 _ldap._tcp.deecee 的查询。
我知道这并非 SharePoint 的错；正如我之前所说，这些查询来自各个地方。但仅针对 _ldap._tcp.deecee 的查询仅来自我们的 SharePoint 主机。
所以这又带来了一个问题。用户配置文件服务在做什么，导致查找 _ldap._tcp.deecee？不过，这仍然给我们其余的服务器留下了一个问题。
答案1
这是一个错误。
微软很早就知道这个问题（自 Win2000 以来），但没有人说服他们修复它。
答案2
启用 netlogon 调试后，我在 Win7 SP1 机器上发现了同样的结果（域控制器是 2008r2SP1）。据我所知，它还导致处理延迟 8 秒。在我看来，这似乎是 netlogon 的一个错误 API 调用。
您可以通过在工作站上运行以下命令来复制相同的 1355 错误：
nltest /dsgetdc:domaincontroller.domain.com
返回：
获取 DC 名称失败：状态 = 1355 0x54b ERROR_NO_SUCH_DOMAIN
显然是因为它使用错误的参数调用了 dsgetdc。
虽然我同意其他人的意见，但您的基础设施很可能没有问题。不过，如果能彻底查明原因就更好了。
答案3
无需修复，这些查找是为了找到您的 AD 树对应的 LDAP 服务器。