Для создания этого легче перенести мою голову вот то, что я использую в своих примерах:
deecee = мой контроллер домена
dctoo = другой контроллер домена
internal.foo.bar = полный DNSDomainName моего домена окон.
нечто = короткое (netbios) название моего домена окон.
oursite = единственный сайт в нашем домене
Мы имеем весь вход, включенный для DNS-сервера MS, и видим много NXDOMAINs для запросов этой формы: _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, Сервер 2008, 2 008 R2, 2012, и 2 012 R2.
Наши серверы DNS действительно имеют соответствующие записи SRV для _ldap._tcp.internal.foo.bar
и они действительно решают правильно. Таким образом, это не проблема.
Коллега открыл случай с Microsoft и технологией, наконец требуемой после нескольких дней, что это нормально. Я не покупаю его. Почему не там никакое упоминание об этом поведении вообще ни в какой документации?
Так, кто-либо еще видит это поведение? Клиенты, ищущие SRV, записывают для _ldap._tcp.deecee.internal.foo.bar
? Если так, они получают результаты NXDOMAIN?
Какие-либо идеи, как зафиксировать это?
Заранее спасибо.
В моем домене я вижу эти недопустимые запросы в порядке наиболее распространенного:
_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
Я включил отладку сетевого входа в систему на одной из затронутых машин и нашел некоторый интересный материал. Во-первых, это - то, чему я верю, успешный отправляемый запрос:
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 просит, чтобы сетевой вход в систему вошел в систему домена под названием "DEECEE". Это буквально думает, что доменное имя является DEECEE. Конечно, предыдущий отрывок (и другие) показывает, что этот процесс, pid=1884, является shotgunning, запрашивает, некоторые из которых законны, и некоторые не.
Проверка списка процессов на той машине говорит мне, что это - a 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? Это все еще оставляет вопрос для остальной части наших серверов, все же.
Исправлять не нужно, эти поиски выполняются, чтобы найти соответствующий сервер LDAP для вашего дерева AD.
Это ошибка.
Microsoft знала об этом давно (начиная с Win2000), но никто не убедил их исправить это.
При включенной отладке netlogon я нашел такой же результат на машинах Win7 SP1 (контроллеры домена 2008r2SP1). Это также вызвало задержку обработки на 8 секунд, насколько я могу судить. Похоже на ошибочный вызов API из netlogon.
Вы можете повторить ту же ошибку 1355, запустив на рабочей станции:
nltest /dsgetdc:domaincontroller.domain.com
return:
Getting DC name failure: Статус = 1355 0x54b ERROR_NO_SUCH_DOMAIN
явно потому, что он вызывает dsgetdc с неправильным параметром.
Хотя я согласен со всеми остальными, скорее всего, в вашей инфраструктуре нет ничего плохого. Хотя было бы неплохо докопаться до сути.