Новые возможности — новые проблемы: разрешение имён в Windows

Не секрет, что с течением времени появлением новых версий Windows расширяются возможности настройки подсистемы разрешения имён(resolver) в этой ОС. Становится возможным штатным образом делать такие вещи, которые раньше требовали хитрой настройки, если вообще были возможны. Но эти новые возможности несут в себе и потенциал новых проблем, вызванных неправильной их настройкой. И проблемы эти не так то просто обнаружить традиционными инструментами, к которым администраторы привыкли за долгие годы работы. Недавно я как раз занимался обсуждением на русском форуме Technet темы, которая служит хорошей иллюстрацией такого положения дел.

Дело обстояло следующим образом. У автора темы внезапно сервер-член домена (под управлением Windows Server 2012 R2) перестал находить контроллер домена через DNS. В журнале событий при этом имелась соответствующая случаю диагностика в виде довольно часто возникающих предупреждений с Event ID 1014 и источником Microsoft Windows DNS Client: «Разрешение имен для имени _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs… истекло после отсутствия ответа от настроенных серверов DNS», а также — ряда других событий,  в частности — сообщений о проблеме обработки групповой политики из-за невозможности найти контроллер домена.

Диагностика контроллера домена с помощью dcdiag на нём самом никаких проблем при этом не выявила. Не было у автора и «детских» ошибок с настройкой серверов DNS в сетевых подключениях — указания там «левых» серверов, не знающих о домене AD (это тоже было проверено). Более того, проверка автором вопроса по моей просьбе разрешения имени записи типа SRV из сообщения с помощью команды давно известной nslookup — nslookup -type=SRV _ldap._tcp.dc._msdcs… — эту запись на том сервере, где возникала ошибка, успешно находила. Но вот попытка разрешения этого имени с помощью появившегося в Windows Server 2012 командлета Powershell — Resolve-DNSName -Name ‘_ldap._tcp.dc._msdcs… ‘ -Type ‘SRV’ — была неудачной: возвращалась ошибка ERROR_TIMEOUT.

Кажущийся парадокс между результатами nslookup и Resolve-DNSName объясняется просто: nslookup, в отличие от Resolve-DNSName (а также — компонентов ОС, и других выполняющихся на ней программ) не использует системную процедуру разрешения имён DNS (resolver), а использует свою собственную, самостоятельно посылая запросы на разрешение имён серверам DNS и интерпретируя их ответы. И эта собственная процедура nslookup не включает в себя те новые механизмы, которые есть в современных версиях Windows, в частности — Name Resolution Policy Table (NRPT). Механизм этот основан на дополнительной таблице, распространяемой обычно через групповую политику (раздел Computer Configuration\Policies\Windows Settings\Name Resolution Policy). Он, в числе прочего, даёт возможность посылать запросы к именам из указанных в таблице доменов DNS тем серверам DNS, которые указаны в этой таблице, а не тем, которые настроены для сетевых подключений. Эта возможность активно используется, например, при развёртывании Direct Access.

Поэтому на основании обнаруженных симптомов я посоветовал автору вопроса поискать, нет ли у него такой политики. Оказалось, что дело — как раз в этом: его сервер стал жертвой неудачного эксперимента по развёртыванию Direct Access. После устранения сервера из лишних политик и очистки следов их применения в реестре на сервере (под ключом ‘HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig) проблема исчезла.

Реклама
  1. No trackbacks yet.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: