Para tornar isso mais fácil de entender, aqui está o que estou usando em meus exemplos:
deecee = my domain controller
dctoo = another domain controller
internal.foo.bar = the full DNSDomainName of my windows domain.
foo = the short (netbios) name of my windows domain.
oursite = The only site in our domain
Temos todo o registro em log ativado para o MS DNS Server e vemos vários NXDOMAINs para solicitações desse formato: _ldap._tcp.deecee.internal.foo.bar. Observe que eu sou não falando sobre _ldap._tcp.internal.foo.bar. Esses estão funcionando bem . Aqui está uma entrada de erro do log:
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
Observe que o cliente está solicitando _ldap._tcp.deecee.internal.foo.bar. . De acordo com a documentação da Microsoft, a solicitação apropriada deve ser _ldap._tcp.internal.foo.bar.
Os pedidos vêm de todas as nossas máquinas associadas à AD. Eles incluem o Windows 7, Server 2008, 2008 R2, 2012 e 2012 R2.
Nossos servidores DNS possuem as entradas SRV apropriadas para _ldap._tcp.internal.foo.bar e resolvem corretamente. Então esse não é o problema.
Um colega de trabalho abriu um processo com a Microsoft e o técnico finalmente afirmou depois de alguns dias que isso é normal. Eu não compro. Por que não há menção a esse comportamento em alguma documentação?
Então, alguém mais vê esse comportamento? Clientes procurando registros SRV para _ldap._tcp.deecee.internal.foo.bar ? Em caso afirmativo, eles estão obtendo resultados NXDOMAIN?
Alguma idéia de como corrigir isso?
Obrigado antecipadamente.
Atualização A - Há mais
No meu domínio, estou vendo essas consultas inválidas na ordem das mais comuns:
_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
Atualização B - Há algo no sharepoint
Liguei a depuração do netlogon em uma das máquinas afetadas e encontrei algumas coisas interessantes. Primeiro, isso é o que acredito ser uma consulta bem-sucedida:
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
E aqui está uma consulta mal-sucedida enviada:
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
Se meu entendimento estiver correto (por favor, corrija-me, caso contrário), a primeira linha indica que o processo com o PID 1884 está pedindo ao netlogon para efetuar login em um domínio chamado "DEECEE". Ele literalmente acha que o nome de domínio é DEECEE. É claro que o trecho anterior (e outros) mostra que esse processo, pid = 1884, é um tiro de pedidos, alguns dos quais são legítimos, e outros não.
Verificar a lista de processos nessa máquina indica que é um processo w3wp . Então eu descobri o pool de aplicativos:
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)
Em seguida, verifiquei quais aplicativos estão sendo executados nesse pool:
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
Então, passei algum tempo ativando e desativando esses serviços do SharePoint e observando as consultas do DNS. Parece que o serviço de perfil de usuário está causando as consultas por pelo menos _ldap._tcp.deecee.
Eu sei que a coisa toda não é culpa do sharepoint; Como eu disse anteriormente, essas consultas estão vindo de todos os lugares. Os que são apenas para _ldap._tcp.deecee, no entanto, são provenientes apenas dos nossos hosts do sharepoint.
Então, isso adiciona outra pergunta. Qual é o serviço de perfil de usuário que está causando as pesquisas para _ldap._tcp.deecee? Ainda deixa a questão para o resto dos nossos servidores, no entanto.