web-dev-qa-db-ja.com

Windowsは_ldap._tcp.domaincontrollerのDNSクエリをホストしますが、これは正常ですか？

これで頭を包みやすくするために、例で使用しているものを次に示します。

deecee =私のドメインコントローラー
dctoo =別のドメインコントローラー
internal.foo.bar =私のWindowsドメインの完全なDNSDomainName。
foo =私のWindowsドメインの短い（netbios）名。
oursite =私たちのドメインで唯一のサイト

MS DNSサーバーのすべてのログがオンになっており、このフォームのリクエストに対して多くのNXDOMAINが表示されます。_ldap._tcp.deecee.internal.foo.bar.私はnot_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、および2012R2が含まれます。

私たちのDNSサーバーには_ldap._tcp.internal.foo.barの適切なSRVエントリがあり、正しく解決されます。だからそれは問題ではありません。

同僚がマイクロソフトとの訴訟を起こし、技術者は数日後にこれは正常であると最終的に主張しました。私はそれを買わない。ドキュメントにこの動作についてまったく言及されていないのはなぜですか？

それで、他の誰かがこの振る舞いを見ますか？ _ldap._tcp.deecee.internal.foo.barのSRVレコードを検索しているクライアント？もしそうなら、彼らは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に何かがあります

影響を受けたマシンの1つで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

私の理解が正しければ（そうでない場合は訂正してください）、この最初の行は、PID1884のプロセスが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クエリが送信されるのを監視することに時間を費やしました。 User ProfileServiceが少なくとも_ldap._tcp.deeceeのクエリを引き起こしているようです。

私はすべてがSharePointのせいではないことを知っています。前に言ったように、これらのクエリはいたるところから来ています。ただし、_ldap._tcp.deeceeだけのものは、SharePointホストからのみ取得されます。

だから、それは別の質問を追加します。 _ldap._tcp.deeceeへのルックアップを引き起こしているユーザープロファイルサービスは何ですか？ただし、残りのサーバーにはまだ疑問が残ります。

domain-name-systemactive-directoryldapsharepointnetlogon
2
Keith Twombley

これはバグです。

マイクロソフトは（Win2000以降）長い間それについて知っていましたが、誰もそれを修正するように説得していません。

2
Ryan Ries

Netlogonデバッグを有効にすると、Win7 SP1マシンでも同じ結果が得られました（ドメインコントローラーは2008r2SP1です）。また、私が知る限り、処理に8秒の遅延が発生しました。 netlogonからのAPI呼び出しに問題があるようです。

ワークステーションで以下を実行することにより、同じ1355エラーを再現できます。

nltest /dsgetdc:domaincontroller.domain.com

戻り値：

DC name failed：Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

明らかに、間違ったパラメーターでdsgetdcを呼び出しているためです。

私は他のすべての人に同意しますが、おそらくインフラストラクチャに問題はありません。しかし、それの底に到達するのは素晴らしいことです。

1
Andrew Robinson

修正する必要はありません。これらのルックアップは、ADツリーに対応するLDAPサーバーを見つけるために実行されています。

0
vautee