При неполадках в разрешении имен DNS в среде Microsoft Active Directory (AD) нередко возникают проблемы. DNS — краеугольный камень для среды AD, и без корректного разрешения имен операции могут прерваться или застопориться. Вероятно, проблема разрешения имен появилась со временем из-за постепенного отхода от надежной древовидной иерархической схемы. Ниже приводятся основные рекомендации и описываются средства диагностики, позволяющие предотвращать или решать проблемы DNS.

Рекомендация 1. Пространство имен DNS должно отражать смежную древовидную иерархию

Пространство имен DNS Интернета имеет древовидную иерархическую организацию, управление которой делегировано администраторам службы DNS, отвечающим за различные «ветви» пространства имен DNS (IETF RFC 1034, RFC 1032). Подобно своим собратьям по Интернету, администраторы DNS корпоративных сетей должны следовать иерархической древовидной концепции. Наличие фрагментарности или несвязностей в пространстве имен корпоративной сети порождает сложности в виде добавления серверов пересылки, зон-заглушек и/или дополнительных зон.

Рассмотрим случай, когда одна компания приобретает другую и каждая из них имеет независимое пространство имен. Эти пространства должны быть функционально объединены с использованием доверительных отношений Windows Server. Предлагаемый подход заключается в создании безопасной виртуальной частной сети (VPN) между средами двух компаний в корне каждого отдельного непрерывного пространства имен. Передача запросов об именах по сети VPN в пространство имен на противоположном конце «VPN-туннеля» осуществляется с использованием серверов пересылки, как показано на рисунке. Любые запросы, не удовлетворяющие критериям условий сервера пересылки, направляются на серверы DNS поставщика услуг Интернета (ISP). Серверы DNS, настроенные на пересылку по условию и расположенные на корневом уровне одного из двух непрерывных пространств имен, направляют запросы на конкретный сервер DNS, расположенный в другом непрерывном пространстве имен. На этом сервере DNS в кэше накапливается информация о пространстве имен, что снижает необходимость в рекурсии.

 

Рисунок. Использование пересылки по условию между раздельными пространствами имен DNS корпоративной сети

Вместо использования серверов пересылки некоторые администраторы предпочитают создавать зоны-заглушки на серверах DNS в доменах верхнего уровня корпоративной сети, например domain1.local и domainA.local. Зоны-заглушки содержат только те записи, которые необходимы для определения доверительных серверов DNS для подчиненной зоны, и имеют значение скорее тогда, когда зоны не хранятся в AD. Зоны-заглушки имеют значение, когда необходимо поддерживать информированность сервера DNS в родительской зоне о доверительных серверах DNS в дочерней зоне. Зоны-заглушки повышают сложность, поскольку ответ службы DNS такой зоны на запрос об имени содержит информацию обо всех заслуживающих доверия серверах DNS в домене. Цель же состоит в организации работоспособной и простой для диагностики инфраструктуры DNS.

Рекомендация 2. Нужно знать, где хранится информация DNS

Данные зоны DNS могут размещаться в хранилище AD или в файловой системе в папке c:\%systemroot%\system32\dns. Настоятельно рекомендуется сохранять информацию зоны в AD, а затем выполнять ее репликацию на каждом сервере DNS в домене (DomainDNSZones) или в лесу (ForestDNSZones). Оптимальный вариант — сохранение данных DNS на каждом сервере DNS домена с последующей передачей этой информации в родительскую зону. Пересылка данных DNS настраивается так, чтобы серверы DNS доменов child1.domain1.local и child2.domain1.local направляли данные на серверы DNS домена domain1.local. В родительском домене осуществляется делегирование для каждого дочернего домена.

Рекомендация 3. Определить, относится ли проблема DNS к сфере регистрации или к сфере разрешения имен

Для разрешения имени необходимо, чтобы это имя было зарегистрировано в какой-либо зоне на сервере DNS. В среде Windows разные службы регистрируют различные записи. В Windows 7, Windows Vista, Windows Server 2008 R2 и Server 2008 записи A и PTR регистрирует служба клиента DNS. В Windows XP и Windows Server 2003 эти записи регистрирует служба клиента DHCP.

Интервал регистрации — 24 часа, за исключением случаев, когда регистрацию выполняет сервер DHCP; в таких случаях регистрация должна выполняться при обновлении аренды адреса клиента DHCP.

В случае Server 2008 R2, Server 2008 и 2003 за регистрацию некоторых дополнительных записей отвечает служба Netlogon. Журнал записей, регистрируемых службой Netlogon, хранится в папке %SystemRoot%\System32\Config\Netlogon.dns. В случае Server 2008 контроллеры домена (DC) динамически регистрируют от 15 до 30 записей SRV каждый час, а в случае 2003 служба Netlogon выполняет регистрацию каждые 24 часа.

В Server 2008 служба кластеров регистрирует ресурс «сетевое имя» кластера при включении этого ресурса в работу. Запись обновляется как минимум один раз каждые 24 часа. Чтобы определить, все ли IP-адреса ресурса «сетевое имя» зарегистрированы в DNS, можно использовать параметр RegisterAllProvidersIP. Более подробную информацию можно найти в статье Microsoft по адресу support.microsoft.com/kb/947048.

Проблема относится к сфере регистрации DNS. Если в DNS отсутствуют записи DNS, с помощью интерфейса редактора Active Directory (ADSI Edit) выясните, не связано ли это просто c отсутствием их отображения в графическом окне консоли DNS или AD. Убедитесь в существовании записей в AD, следуя шагам, описанным в статье по адресу support.microsoft.com/kb/867464. Если записи отсутствуют, установите сетевой монитор на системе, выполняющей регистрацию записей DNS, и выполните сетевую трассировку при попытке зарегистрировать записи A, PTR или SRV. Чтобы инициировать регистрацию записей A и PTR, введите команду

ipconfig/registerdns

Для регистрации записи SRV введите команду

c:\net stop netlogon && net start netlogon

Остановите сетевую трассировку и выполните фильтрацию трафика DNS. При отсутствии регистрационных данных сетевой трассировки проверьте, запущена ли служба, отвечающая за регистрацию (клиент DHCP, клиент DNS, Netlogon, Cluster), и проанализируйте журналы событий. Если это не поможет, обратитесь в группу технической поддержки Microsoft.

Проблема относится к сфере разрешения DNS. Если техническая проблема не относится к сфере регистрации записей DNS, смените метод диагностики и проанализируйте разрешение имен DNS. Выполните проверку связи с целевым объектом по полному доменному имени (FQDN) на предмет успеха или отказа. В случае отказа связи по имени, но не по IP-адресу, убедитесь в правильности настроек сервера DNS в свойствах протокола TCP/IP системы, инициирующей запрос. Затем запустите сетевую трассировку и очистите кэш распознавателя с помощью команды

c:\ipconfig/flushdns

Вновь проверьте связь с целевым объектом по FQDN (например, ping server.domain1.local), остановите сетевую трассировку и проверьте наличие исходящего запроса DNS и/или входящего ответа DNS. Задача состоит в том, чтобы определить, связана ли проблема с доставкой запроса на сервер DNS, либо, если сервер DNS получает запрос — c отсутствием ответа или же с его доставкой инициатору запроса DNS.

Рекомендация 4. Использование средств диагностики DNS

Для анализа проблем в DNS необходимо иметь следующие средства диагностики: DNSLint, DCDiag и NSlookup.

DNSLint. Утилита DNSLint реализует три функциональных теста с выдачей результатов в отчете в формате HTML. Тесты предназначены для выявления проблемы некорректного делегирования зон (lame delegation), проверки записей DNS, необходимых для успешного выполнения репликации AD, и контроля определяемого пользователем набора записей DNS на нескольких серверах DNS. Для тестирования доменных имен и получения результатов для диагностики проблемы некорректного делегирования в команде dnslint укажите параметр /d. Для задания IP-адреса сервера DNS, который является доверительным для данного домена, укажите /s. Для определения возможности разрешения записи DNS, для которой требуется репликация в лесу AD, укажите /ad. Более подробную информацию можно найти в статье «Description of the DNSLint utility» по адресу support.microsoft.com/kb/321045.

DCDiag. Команду dcdiag можно запустить с использованием параметра /test: DNS. Варианты теста включают основной тест DNS и тесты для серверов пересылки и корневых ссылок, делегирования, динамических обновлений DNS, регистрации записей DNS и имен Интернета.

Проверьте состояние работоспособности контроллера домена:

DCDIAG/TEST: DNS/v/s:
   /f:

Проверьте состояние работоспособности всех контроллеров домена в лесу:

DCDIAG/TEST: DNS/f/e/f:

Проверьте способность контроллера домена регистрировать записи DNS-локатора DC:

DCDIAG/TEST: RegisterInDNS
   /DnsDomain:
   /v/f:

В приведенных выше командах параметр /v задает вывод детальных данных, /s — локальное выполнение, /f — прямой вывод в файл, /e — тестирование всех серверов.

Для Windows Server 2003 SP2 следует пользоваться утилитой DCDiag, включенной в SP2, в соответствии с описанием (support.microsoft.com/kb/926027). Для Server 2008 и Server 2008 R2 выполните установку DCDiag: пройдя по пунктам меню Server Manager, Features, Add Features, Remote Server Administration Tools, Role Administration Tools, Select DNS Server Tools, Next, Install.

NSlookup. Хорошо известная команда диагностики DNS. Для просмотра вариантов синтаксиса NSlookup нужно запустить команду NSlookup из командной строки, а затем ввести help. Следует иметь в виду, что NSlookup имеет собственный встроенный разрешитель имен в исполняемом файле, поэтому не использует разрешитель операционной системы.

Рекомендация 5. Соответствие рекомендациям Microsoft относительно DNS

Контроль состояния работоспособности среды DNS для Server 2008 R2 следует осуществлять с использованием анализатора соответствия рекомендациям Microsoft Best Practices Analyzer (BPA) в составе пакета Server 2008 R2. Этот инструмент представлен в двух вариантах: один для проверки соответствия рекомендациям по конфигурации DNS, второй — для DNS. BPA представляет собой полезный инструмент сканирования среды DNS для Server 2008 R2 и анализа потенциальных проблем конфигурации DNS.

Чтобы открыть BPA, выполните следующие действия.

  1. В меню Start выберите Administrative Tools и далее Server Manager.
  2. На древовидном представлении откройте Roles и выберите роль, для которой нужно запустить BPA.
  3. На панели подробностей в разделе Summary откройте область анализатора соответствия рекомендациям Best Practices Analyzer.

Для Windows Server 2008 в анализаторе базовых настроек конфигурации Microsoft (MBCA) существует модель DNS. MBCA сравнивает настройки серверов DNS с рекомендациями для DNS, изложенными в модели DNS из MBCA 2.0.

Загрузку MBCA можно осуществить по ссылке http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=1b6e9026-f505-403e-84c3-a5dea704ec67.

Исправность DNS — работоспособное состояние AD

В случае неполадок в разрешении имен в среде Windows AD могут возникать различные проблемы. Определите источник проблемы: система, подсеть или сеть. Затем установите, относится ли данная проблема к сфере регистрации или к сфере разрешения имен DNS. При необходимости воспользуйтесь средствами Microsoft для диагностики и поддержания работоспособности среды DNS.

Бойд Гербер (boydg@microsoft.com) — инженер из отдела технической поддержки в Microsoft Networking Escalation. Специализируется на поддержке и настройке DNS