Windows Place une demande de DNS pour _ldap._tcp.domaincontroller, c'est normal?

Pour simplifier la compréhension, c'est ce que j'utilise dans mes exemples:

deecee = Mon contrôleur de domaine

dctoo = Un autre contrôleur de domaine

internal.foo.bar = nom complet DNSDomainName Mon domaine Windows.

foo = un court (netbios) Nom de mon domaine Windows.

oursite = Le seul site de notre domaine

Nous incluons la journalisation pour MS DNS Server, Et nous voyons beaucoup NXDOMAIN Pour les demandes de ce formulaire:

        _ldap._tcp.deecee.internal.foo.bar.

      

Notez que je

ne pas

Parlant O.

        _ldap._tcp.internal.foo.bar.

      

Ceux-ci fonctionnent bien. Voici une entrée sur l'erreur du magazine:

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

Notez que le client demande

        _ldap._tcp.deecee.internal.foo.bar.

      

Selon la documentation Microsoft, La demande correcte devrait être

        _ldap._tcp.internal.foo.bar.

      

Les demandes viennent de toutes nos voitures connectées à AD. Ceux-ci inclus Windows 7, Server 2008, 2008 R2, 2012 et 2012 R2.

Sur nos serveurs DNS, il existe des entrées appropriées SRV pour

        _ldap._tcp.internal.foo.bar

      

Et ils sont autorisés correctement. Donc, le problème n'est pas dans cela.

Un employé a ouvert une affaire avec Microsoft, Et dans quelques jours, le technicien a finalement dit que c'était normal. Je ne comprends pas dessus. Pourquoi n'est-il pas mentionné sur ce comportement dans une documentation?

Alors, quelqu'un d'autre voit un tel comportement? Les clients recherchent des entrées SRV pour

        _ldap._tcp.deecee.internal.foo.bar

      

? Si oui, qu'ils obtiennent des résultats NXDOMAIN?

Des idées comment résoudre ce problème?

Merci en avance.

Mettre à jour A - y a-t-il encore plus

Dans mon domaine, je vois ces demandes non valides dans l'ordre du plus commun:

_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  

Mettre à jour B. Quelque chose est dans sharepoint

J'ai allumé le débogage de l'entrée du réseau sur l'une des machines touchées et a trouvé quelque chose d'intéressant. Premièrement, je pense que ceci est une demande réussie envoyée:

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

Mais quel échec échoué ressemble à:

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 

Si je comprends bien (S'il vous plaît corrigez-moi sinon), La première ligne de ce message indique que le processus avec PID 1884 demande netlogon Entrez le domaine nommé «DEECEE». Il pense littéralement le nom de domaine DEECEE. Bien sûr, le fragment précédent (autre) montrez que ce processus pid = 1884, Demandes de processus, dont certaines sont légitimes et certaines ne le sont pas.

Vérifier la liste des processus sur cette machine me dit que c'est

        w3wp

      

traiter. Donc, j'ai appris sur la piscine d'applications:

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)

Ensuite, j'ai vérifié quelles applications fonctionnent dans ce 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

Par conséquent, j'ai passé du temps à inclure et à désactiver ces services. sharepoint et observer comment les demandes vont DNS. Il semble que le service des profils d'utilisateur appelle au moins pour _ldap._tcp.deecee.

je le sais Sharepoint ne pas blâmer; Comme je l'ai dit plus tôt, ces demandes viennent de partout. Cependant, ceux qui sont destinés seulement pour _ldap._tcp.deecee, Venez seulement de nos hôtes sharepoint.

Donc, une autre question se pose. Qu'est-ce que le service de profil utilisateur provoque une recherche? _ldap._tcp.deecee? Cependant, cela laisse toujours la question du reste de nos serveurs.