Когда вы используете интегрированные в Active Directory (AD) серверы и зоны DNS в среде Windows Server 2003 или в более поздних версиях системы, данные индивидуальной зоны DNS могут храниться в одной из трех областей AD. Данные о зоне могут быть реплицированы на: каждый контроллер домена (DC) внутри данного домена; каждый сервер DNS внутри домена; каждый сервер DNS внутри данного леса. Проблема может возникнуть в случае, когда одна зона DNS хранится более чем в одной области и предпринимается попытка репликации. Я коротко расскажу о репликации зон DNS, а затем приведу пример проблемы, связанной с размещением зоны DNS, и опишу процесс ее решения.

Настройки репликации зоны DNS

Настройки репликации зоны DNS устанавливаются с помощью оснастки DNS консоли Microsoft Management Console (откройте меню Start, Administrative Tools, DNS). Мы проанализируем процедуру задания настроек репликации зоны на примере основной зоны town.local. В разделе Forward Lookup Zones консоли DNS правой кнопкой мыши щелкните на элементе town.local zone, затем щелкните на элементе Properties, и на экране появится диалоговое окно domain.local Properties (в нашем примере — town.local). На вкладке General предлагается два варианта: Type, для которого задано значение Active Directory-Integrated, и Replication (в какой области AD будут храниться зоны); для второго варианта задано значение All DNS servers in this domain. Щелкнув на элементе Change, перейдите в диалоговое окно Change Zone Replication Scope, где представлены три из четырех вариантов хранения данных о зоне DNS:

  • на всех серверах DNS в этом лесу: town.local;
  • на всех серверах DNS в этом домене: town.local;
  • на всех контроллерах доменов в этом домене (для совместимости с Windows 2000): town.local;
  • на всех контроллерах доменов в диапазоне этого раздела каталога (этот вариант недоступен для выбора).

Я настоятельно рекомендую заранее определять область AD, где будет храниться информация о зонах перед ее настройкой. Зону _msdcs.domain.local следует хранить в разделе приложений ForestDNSZones. Каждый контроллер домена зарегистрирует в разделе ForestDNSZones глобальный уникальный идентификатор CNMANE, и эти данные должны быть реплицированы на каждый сервер DNS во всем лесу, а не только в домене. Другие зоны прямого просмотра и зоны обратного просмотра можно хранить в зонах ForestDNSZones, но для сохранения единообразия и согласованности с инвертированной топологией дерева DNS, где иерархия имен начинается с имени верхнего уровня и завершается разделенной точками иерархией множественных имен (описанных в документах IETF RFC 1033 и RFC 1034), размещайте все остальные зоны прямого и обратного просмотра в зонах DomainDNSZones внутри раздела приложений системы Windows Server 2008/Windows 2003.

Проблема расположения зон

Теперь давайте посмотрим, что может произойти в случае изменения настроек зоны. Допустим, вы решили разместить _msdcs.domain.local в ForestDNSZones внутри раздела приложений и зону прямого просмотра town.local, а также зону обратного просмотра в 1.268.192. в in-addr.arpa внутри раздела DomainDNSZones. Проходит пара месяцев, и разрешение имен DNS внутри вашей среды AD работает как часы.

Но в этот момент некий пользователь с полномочиями администратора уровня предприятия вносит в среду изменения, оказывающие влияние на местоположение зон DNS. Администратор создал новый контроллер домена, установил DNS и позволил репликации загружать зоны ForestDNSZones и DomainDNSZones, размещенные в разделе приложений, с сервера DNS, уже находящегося в среде домена. По истечении двух недель этот администратор уровня предприятия вернулся к данному серверу DC/DNS и изменил настройку зоны DNS town.local; теперь она должна располагаться не в DomainDNSZones, а в ForestDNSZones. Но для перемещения зоны _msdcs.domain.local из другого раздела DNSDomainZones на другие серверы DC/DNS и переноса town.local в зону ForestDNSZones в процессе репликации AD требовалось время. Возникают ошибки EventID 4521 и EventID 4011, свидетельствующие о том, что при регистрации DNS A, PTR и SRV возникает проблема. Более того, на одном из серверов DNS зоны town.local в консоли DNS не отображаются. Пользователи жалуются, что разрешение DNS выполняется с ошибками.

Возможные решения

Эту проблему можно решать двумя способами. Первый будем считать самым оптимистичным: просто немного подождите — пусть репликация завершится. Состояние репликации можно отслеживать с помощью команды repadmin/showreps или repadmin/showrepl servername.town.local. Обратите внимание, что вы можете поставить в очередь исполнения принудительную репликацию, добравшись до объекта «сервер» и до объекта NTDS в оснастке MMC AD Sites and Services (как это делается, я расскажу ниже).

Если первый метод не обеспечивает решения проблемы, примените следующий способ: в оснастке ADSI Edit просмотрите три области AD, где могут храниться сведения о зонах, — речь идет о просмотре областей ForestDNSZones и DomainDNSZones в разделе приложений и контекста именования доменов (область хранения данных в Windows 2000). Подробную информацию о том, как выполняется такой просмотр, можно найти в статье Microsoft «Event ID 4515 is logged in the DNS Server log in Windows Server 2003» по адресу support.microsoft.com/kb/867464.

Необходимо определить, где расположена зона town.local. Расположена ли она в двух различных областях хранения данных — скажем, в ForestDNSZones и в DomainDNSZones? А может быть, зона town.local размещается в ForestDNSZones на одном сервере Server 2008 DC/DNS и в DomainDNSZones на другом сервере Server 2008 DC/DNS?

Вскоре после выхода в свет системы Windows 2003 корпорация Micro­soft задокументировала проблему, связанную с программой dns.exe. Речь шла о конфликтах, возникающих из-за того, что контейнер Microsoft DNS создавался до полной репликации раздела приложений (см. support.microsoft.com/kb/836534). Проблема была решена в версии dns.exe 5.2.3790.125 и в более поздних редакциях. На экране показано, как отображается такой тип конфликта на сервере Server 2008 при использовании оснастки ADSI Edit.

Экран.Просмотр сведений о зоне town.local в редакторе ADSI Edit

Объект CNF (conflict) указывает на наличие конфликта. Как мы видим на экране, DC=town.local размещается и в разделе ForestDNSZones, и в разделе DomainDNSZones. В разделе DomainDNSZones обратите внимание на объект DC=..InProgress-57548AC124357A8town.local, расположенный в разделе DC=domaindnszones, dc=town, dc=local, а также на объект CN=MicrosoftDNS0CNF54ce21bc-81e8–5af5d112ebc8115, указывающий на наличие конфликта.

Чтобы устранить конфликт, следует первым делом бегло просмотреть сведения о зоне, хранящиеся в объекте MicrosoftDNS0CNF. В этом объекте CNF просмотрите содержимое объектов town.local и 1.168.192. in-addr.arpa и сравните его с содержимым объектов InProgress и town.local объекта MicrosoftDNS. Если объект CNF зоны DomainDNSZones содержит все необходимые объекты записей, а объект DC=town.local зоны ForestDNSZomes содержит только несколько объектов записей, выполните действия, перечисленные ниже (вариант 1 или вариант 2).

Вариант 1

  1. Удостоверьтесь, что у вас имеется успешно выполненная ранее полная системная резервная копия контроллера домена и что в случае необходимости зона town.local может быть считана с помощью средств восстановления режима Active Directory Restore.
  2. В зоне domaindnszones.town.local удалите контейнер объектов CN=MicrosoftDNS. Примечание: вместо удаления можно применить не столь радикальную меру — переименовать контейнер объектов, присвоив ему имя вроде CN=MicrosoftDNSBackupDateTime, а затем удалить его после выполнения этапа 5, убедившись, что DNS функционирует для данной зоны и что репликация зоны DNS успешно завершена.
  3. В зоне domaindnszones.town.local переименуйте объект CN=MicrosoftDNS0CNF54ce21bc-81e8–5af5d112ebc8115, присвоив ему имя CN=MicrosoftDNS.
  4. Выполните принудительную репликацию с помощью оснастки AD Sites and Services или используя следующий синтаксис: repadmin/replicate Server4W2K8.town.local Server3W2K.town.localdc=town, dc=local.
  5. Проверьте состояние репликации, выполнив команду repadmin/showrepl Server3W2 K.town.local.

Вариант 2

Создайте резервную копию состояния системы и восстановите зону town.local с резервной копии, успешно снятой в предыдущий раз. Все записи ресурсов серверов, не представленные в резервной копии зоны town.local, могут быть зарегистрированы указанием незарегистрированного сервера на сервер DNS. Затем из командной строки запустите последовательно команды (будьте внимательны: запускать очередную команду можно лишь после того, как вы убедитесь, что предыдущая команда успешно выполнена):

ipconfig registerdns
net stop netlogon && netstart Netlogon
net stop dns && net start dns

Помните о том, что следует заранее определять, где именно вы намереваетесь хранить сведения о зонах DNS. Зона _msdcs.domain.local должна находиться в зоне ForestDNSZones внутри раздела приложений, и обязательно размещайте зоны прямого и обратного просмотра в зоне DomainDNSZones внутри раздела приложений. Необходимо всегда иметь под рукой актуальную резервную копию данных о состоянии системы, включая зоны DNS — просто на всякий случай. Определить, где именно в AD хранятся сведения о зонах, можно с помощью редактора ADSI Edit. Изучите свою среду DNS и ознакомьтесь с используемой в сети иерархией DNS, а также узнайте, как настроены ваши серверы DNS.

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