Не удалось найти dns зону msdcs интегрированную в active directory

Обновлено: 03.07.2024

Устанавливая очередной (второй, третий и т.д.) контроллер домена в существующем домене и назначая ему роль DNS-сервера, всегда замечал, что зона DNS, интегрированная в Active Directory, появляется на новом DNS-сервере не сразу, а через некоторое время. Может пройти несколько часов, и как ни обновляй информацию в консоли DNS, подключенной к новому серверу, а узлы зон остаются по-прежнему пустые. Разумеется, в свойствах зоны новый DNS-сервер был добавлен в список, и была включена репликация. Казалось бы, зона, интегрированная в AD, должна реплицироваться так же быстро, как происходит репликация AD. На самом деле, здесь происходит более сложный процесс, связанный с формированием раздела (Application Directory Partition) и добавлением нового сервера в структуру репликации.

Недавно пришлось устанавливать второй домен-контроллер в подчиненном домене. И если с установкой роли DC проблем не возникло, то зона DNS отказывалась реплицироваться на только что установленный контроллер домена (и одновременно DNS-сервер). Прошло много часов, а ситуация никак не менялась. Зона не появлялась, DNS-сервер сообщал, что работает только в режиме кеширования, а в системном журнале периодически регистрировалось следующее событие:

Настало время воспользоваться утилитой DNSCMD. Утилита становится доступной, если на сервер установить пакет Support Tools. Будучи запущенной с ключом /enumdirectorypartitions, утилита выводит на экран список всех разделов DNS-зон, интегрированных в Active Directory.

Теперь, зная имена разделов можно посмотреть информацию по конкретному разделу (Application Directory Partition). Для этого следует запустить DNSCMD с ключом /directorypartitioninfo и указать имя интересующего раздела.

Для ускорения процесса перестроения топологии репликации имеет смысл запустить утилиту REPADMIN (тоже из Support Tools) с ключом /kcc.

Их стало две, по числу контроллеров домена. А обновляя информацию в консоли DNS, можно видеть,что домен-контроллер и одновременно DNS-сервер DC2-Kaliningrad теперь содержит DNS-зону своего домена.

Сравнительно недавно случайно заметил, что на рабочих серверах DNS отсутствует зона _msdcs.ForestName. Каких-либо жалоб со стороны пользователей не было , как и не было проблем с доступностью сервисов домена. Поскольку эта зона выполняет достаточно важные функции для работы всего леса AD, я стал разбираться что же с ней не так.

Если вам интересна тематика Windows Server, рекомендую обратиться к рубрике Windows Server на моем блоге.

Назначение зоны _msdcs.ForestName

Главным образом эта зона предназначена для определения расположения ключевых сервисов AD DS, таких как Глобальный каталог (см. Global catalog — Глобальный каталог), PDC (см. PDC emulator — Эмулятор первичного контроллера домена), Kerberos, LDAP, а также для определения GUID контроллеров домена AD (по записи GUID клиенты найдут контроллеры домена в случае переименования домена). В этой области каждый контроллер домена регистрирует SRV-записи собственных служб и отвечает за этот процесс служба Netlogon. Сама область является частью компонента Domain controller locator (Locator) 1 , внедренного в Windows Server 2003:

The Microsoft-specific subdomain enables location of domain controllers that have specific roles in the Active Directory domain or forest. Resource records for the DNS root domain of a new Active Directory forest are stored in a _msdcs zone instead of a subdomain, and that zone is stored in the forest-wide application directory partition.

Дело в том, что в норме для версий Windows Server 2003 и старше эта зона должна располагаться на том же уровне, что и зона корневого домена. Выглядит это примерно так (пример с моей тестовой инфраструктуры):

Но на серверах DNS в продакшене она являлась поддоменом корневого домена и отсутствовала на уровне раздела леса:

На самом деле в этом нет ничего плохого, поскольку во всем лесу у меня существует лишь один домен, но если доменов будет больше, это может вызвать проблемы. В BPA (Best Practices Analyzer) при этом вылезали ошибки отсутствия зоны (скриншоты для Windows Server 2012 R2 и 2008 R2 соответственно):

Почему так произошло? Дело в том, что в версиях Windows Server старше 2003 все устроено несколько иным образом и зона _msdcs действительно должна находиться на уровне поддомена корневого домена AD и при миграции с 2000 на 2003 должна быть перенастроена. По крайней мере это единственная известная мне причина 2 .

Пришло время все привести к тому виду, в котором оно и должно быть.

Перенастройка зоны _msdcs.ForestName

Начать необходимо с создания зоны прямого просмотра с нужным нам именем (нужны права администратора предприятия). Подробно весь процесс расписан на скриншотах ниже:

После того как зона создана, необходимо зайти в её свойства и добавить серверы DNS, которые будут обслуживать эту зоны:

Также вместо существовавшей зоны _msdcs на уровне поддомена должна появиться запись делегирования. У меня это произошло без моего участия, но если вдруг у вас эта зона автоматически не создалась (у меня так было на тестовой инфраструктуре. Возможно из-за нехватки терпения), можно её создать вручную. Для этого:

В этой статье устраняется ИД события 4013, войдите в журнал событий DNS контроллеров доменов, которые после Windows будут размещены роли сервера DNS.

Применяется к: Windows Server 2012 R2
Исходный номер КБ: 2001093

Симптомы

Следующий DNS Event ID 4013 входит в журнал событий DNS контроллеров доменов, которые после Windows начинаются:

Примеры сценариев клиентов

Несколько контроллеров домена на сайте Active Directory, которые одновременно перезагружаются.

В том же центре обработки данных развернут домен контроллера с двумя доменами.
Роль сервера DNS установлена на обоих контроллерах домена, и в ней размещены встроенные в AD копии _msdcs.<forest root domain> и доменные зоны Active Directory.
DC1 настроен для использования DC2 для предпочтительной DNS и для альтернативной DNS.
DC2 настроена на использование DC1 для предпочтительной DNS и себя для альтернативной DNS.
Все контроллеры домена имеют бесперебойное питание (UPS) и резервные копии электрогенератора.
Центр обработки данных испытывает частые отключения электроэнергии от 2 до 10 часов. Устройства UPS держат контроллеры домена в работе до тех пор, пока генераторы не поставляют питание, но не могут запустить систему HVAC. Защита от температуры, встроенная в компьютеры класса сервера, закрывает контроллеры домена, когда внутренние температуры достигают пределов производителя.
Когда питание в конечном итоге восстановлено, контроллеры домена висят в течение 20 минут. Эта проблема возникает после отображения сетевых подключений и перед отображением запроса logon.
DNS Event ID 4013 входит в журнал событий DNS.

Связаться <computername> с сервером не удалось. Ошибка была: сервер недоступен. Хотите добавить его в любом случае?

Сведения о именова-именах не могут быть расположены

Единые контроллеры домена на сайте Active Directory

Один контроллер домена развернут на сайте.

Установлена роль DNS Server, в ней размещены встроенные в AD копии _msdcs.<forest root domain> и доменные зоны Active Directory.

Контроллер домена указывает на себя для предпочтительного DNS.

Контроллер домена не имеет альтернативного DNS-сервера, указанного или указывает на контроллер домена по ссылке широкой сети (WAN).

Контроллер домена перезапущен из-за отключения электроэнергии.

Во время перезапуска может не работать ссылка WAN.

Когда контроллер домена запущен, он может висеть в течение 20 минут. Эта проблема возникает после отображения сетевых подключений и перед отображением запроса logon.

DNS Event ID 4013 входит в журнал событий DNS.

Связаться <computername> с сервером не удалось. Ошибка была: сервер недоступен. Хотите добавить его в любом случае?

Сведения о именова-именах не могут быть расположены.

Причина

Копия Active Directory в некоторых контроллерах домена содержит ссылки на другие контроллеры домена в лесу. Эти контроллеры домена пытаются реплицировать все локальные разделы каталогов во время Windows запуска, в рамках начальной синхронизации или синхронизации init.

В попытке загрузки с последним контентом зоны DNS серверы Microsoft DNS, на которые встроены AD-копии зон DNS, задерживают запуск службы DNS на несколько минут после Windows запуска. Задержка не произойдет, если Active Directory выполнил первую синхронизацию во время Windows запуска. Тем временем Active Directory задерживается из-за входящие разделы репликации каталогов. Репликация отложена до тех пор, пока она не сможет разрешить GUID CNAME своего контроллера исходных доменов на IP-адрес на DNS-серверах, используемых контроллером домена назначения для разрешения имен. Длительность зависания при подготовке сетевых подключений зависит от количества локальных разделов каталогов, проживающих в копии Active Directory контроллера домена. Большинство контроллеров домена имеют по крайней мере следующие пять разделов:

схема
configuration
domain
раздел приложения DNS в лесу
раздел приложения DNS для всей области домена

И эти контроллеры домена могут испытывать задержку запуска на 15-20 минут. Наличие дополнительных разделов увеличивает задержку запуска.

DNS Event ID 4013 в журнале событий DNS указывает на задержку запуска службы DNS. Это происходит из-за того, что входящие репликации разделов Active Directory не происходили.

Несколько условий могут усугубить следующие проблемы:

медленное Windows запуска
ведение журнала событий DNS 4013 на DNS-серверах, настроенных для зоны, интегрированной с AD, которые неявно находятся на компьютерах, действующих в качестве контроллеров домена.

К этим условиям относятся следующие условия:

Настройка DNS-сервера, на который размещены зоны DNS, интегрированные с AD. Его копия Active Directory содержит знания других контроллеров домена в лесу, чтобы указать на себя исключительно для разрешения имен DNS.
Настройка DNS-сервера, на который размещены зоны DNS, интегрированные с AD. Его копия Active Directory содержит знания о других контроллерах домена в лесу, чтобы указать DNS-серверы, которые либо не существуют, в настоящее время находятся в автономном режиме, не доступны в сети, либо не содержат необходимые зоны и записи, необходимые для входящие репликации Active Directory. Примеры включают запись GUID контроллера домена CNAME и соответствующую запись A или AAAA потенциальных контроллеров домена источника.
Загрузка контроллера домена и DNS-сервера с зонами DNS, интегрированными с AD. Его копия Active Directory содержит знания других контроллеров домена о том, что является эффективной изолированной сетью, так как:
- Сетевой адаптер или сетевой стек на вызываемом или целевом компьютере отключен или нефункционарен.
- Контроллер домена загружается в изолированную сеть.
- Копия Active Directory локального контроллера домена содержит ссылки на устаревшие контроллеры домена, которые больше не существуют в сети.
- Копия Active Directory локального контроллера домена содержит ссылки на другие контроллеры домена, которые в настоящее время отключены.
- Существует проблема в контроллере домена источника, контроллере домена назначения или DNS или сетевой инфраструктуре. Таким образом, копия Active Directory контроллера домена локального домена содержит ссылки на другие контроллеры домена, которые находятся в Интернете и доступны, но не могут быть успешно реплицированы из.
В Windows Server 2003 и Windows 2000 Server SP3 или более поздней модели контроллеры домена, принимающие главные роли операций, также должны успешно реплицировать входящие изменения в раздел каталога, который поддерживает состояние роли магистрали операций. Перед выполнением операций, зависящих от FSMO, необходимо выполнить успешную репликацию. Такие начальные синхронизации были добавлены, чтобы убедиться, что контроллеры домена были в согласии с владением ролью FSMO и состоянием ролей. Начальные требования к синхронизации, необходимые для работы ролей FSMO, отличаются от начальной синхронизации, о которой говорится в этой статье, когда Active Directory должен входящие репликации, чтобы немедленно запустить службу DNS Server.

Решение

Некоторые microsoft и внешний контент рекомендовали установить значение реестра до 0, чтобы обойти начальные требования к синхронизации Repl Perform Initial Synchronizations в Active Directory. Подкайка конкретного реестра и значения для этого параметра являются следующими:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Имя значения: Repl Perform Initial Synchronizations
Тип значения: REG_DWORD
Данные значения: 0

Это изменение конфигурации не рекомендуется использовать в производственных средах или в любой среде на постоянной основе. Использование следует Repl Perform Initial Synchronizations использовать только в критических ситуациях для решения временных и конкретных проблем. Параметр по умолчанию должен быть восстановлен после решения таких проблем.

Другие возможные варианты:

Удалите ссылки на устаревшие контроллеры домена.

Сделайте автономные или не функционируют контроллеры домена рабочими.

Контроллеры домена, принимающие зоны DNS, интегрированные с AD, не должны указать на один контроллер домена и особенно только на себя в качестве предпочтительного DNS для разрешения имен.

Настройка контроллеров домена, указывающих на IP-адрес одного сервера DNS, включая адрес 127.0.0.0.1, представляет собой одну точку сбоя. Этот параметр допустим в лесу только с одним контроллером домена, но не в лесах с несколькими контроллерами домена.

Контроллеры домена hub-site должны указать на DNS-серверы на том же сайте, что и для предпочитаемого и альтернативного DNS-сервера, а затем в качестве другого альтернативного DNS-сервера.

Контроллеры домена веб-сайтов филиала должны настроить предпочтительный IP-адрес DNS-сервера, чтобы указать на сервер DNS-узла, альтернативный IP-адрес DNS-сервера, чтобы указать на сервер DNS на месте или на ближайший доступный сайт, и, наконец, на себя с помощью 127.0.0.0.1 или текущего статического IP-адреса.

Указать на серверы DNS-узлового узла уменьшает количество переходов, необходимых для полной регистрации критически важных записей контроллера домена SRV и HOST. Контроллеры домена на сайте концентратора, как правило, получают наибольшее административное внимание, как правило, имеют самую большую коллекцию контроллеров домена на том же сайте. Поскольку они на одном сайте, происходят изменения репликации между собой:
- каждые 15 секунд в Windows Server 2003 или более поздней
- каждые пять минут в Windows 2000 Server
Такое поведение делает такие записи DNS хорошо известными.

Динамический контроллер домена SRV и регистрации записей A и AAAA не могут сделать его отключенным, если регистрируемый контроллер домена на сайте филиала не сможет реплицировать исходящий.

Компьютеры и серверы-члены должны по-прежнему указать на оптимальные для сайта DNS-серверы в качестве предпочтительных DNS. Кроме того, они могут указать на серверы DNS вне сайта для дополнительной допуска неисправности.

Ваша конечная цель состоит в том, чтобы предотвратить все, что может вызвать отказ в обслуживании, а также балансировать затраты, риски и использование сети, например:
- Задержки репликации и сбои репликации
- сбои оборудования, сбои программного обеспечения
- операционные практики
- кратковременные и долгосрочные отключения электроэнергии
- пожар, кража, наводнение и землетрясения
- террористические события
Убедитесь, что контроллеры домена назначения могут разрешать контроллеры исходных доменов с помощью DNS (например, избежать ошибок).

Необходимо убедиться, что контроллеры домена могут успешно разрешать управляемые записи CNAME для хозяйных записей текущих и потенциальных контроллеров домена. Это позволяет избежать высокой задержки, которая введена логикой отката разрешения имен.

Контроллеры домена должны указать на DNS-серверы, которые:

Недостающие, дублирующие или устаревшие записи CNAME и хост-записей способствуют этой проблеме. Очистка не включена на серверах Microsoft DNS по умолчанию, что повышает вероятность устаревших записей хост-серверов. В то же время очистка DNS может быть настроена слишком агрессивно, что приводит к преждевременной очистке допустимых записей из зон DNS.

Оптимизация контроллеров домена для отката разрешения имен.

Неумело настраивать DNS правильно, чтобы контроллеры домена могли разрешать записи GUID домена CNAME для хозяйских записей в DNS. Чтобы обеспечить точную репликацию разделов Active Directory, Windows 2003 SP1 и более поздние контроллеры домена были изменены для выполнения отката разрешения имен:
- от контроллера домена CNAME GUID до полноквалифицированного имени хост-кодов.
- от полностью квалифицированного имени хост-имени до имени компьютера NetBIOS.
В журналах событий службы каталогов репликация событий NTDS 2087 и 2088 указывают на то, что:
- контроллер домена назначения не смог разрешить запись GUID GUID контроллера домена CNAME в хост-запись.
- Происходит откат разрешения имен.
Можно настроить файлы WINS, HOST и LMHOST. Так контроллеры домена назначения могут разрешить имена текущих и потенциальных контроллеров домена источника. Из трех решений использование WINS более масштабируемо, так как WINS поддерживает динамические обновления.

IP-адреса и имена компьютеров неизбежно становятся устаревшими. Из-за этой проблемы статичные записи в файлах HOST и LMHOST со временем становятся недействительными. Когда возникает эта проблема, запросы для одного контроллера домена могут быть неправильно разрешены другому контроллеру домена. И запрос имени не наблюдается в сетевом следе.

Измените значение запуска для службы DNS-сервера вручную при загрузке в известной плохой конфигурации.

Если загрузка контроллера домена в известной плохой конфигурации, которая обсуждается в этой статье, выполните следующие действия:
1. Установите значение запуска службы DNS Server вручную.
2. Перезагружайся, подождите, пока контроллер домена будет рекламироваться.
3. Перезапустите службу DNS Server.
Если значение запуска службы для службы DNS Server установлено вручную, Active Directory не ждет запуска службы DNS Server.

Дополнительные рекомендации

Избегайте единичек сбоя.

Примеры одиночных точек сбоя:
- Настройка доменного тока для указать на IP-адрес сервера с одним DNS-сервером.
- Размещение всех DNS-серверов на гостевом виртуальном компьютере на одном физическом хост-компьютере
- Размещение всех DNS-серверов на одном физическом сайте
- Ограничение сетевых подключений таким образом, что контроллеры домена назначения имеют только один сетевой путь для доступа к KDC или DNS Server
Установите достаточноЕ количество DNS-серверов для локальных, региональных и корпоративных показателей избыточности, но не так много, что управление становится бременем. DNS обычно является легкой операцией, которая высоко кэшется клиентами DNS и DNS-серверами.

Каждый сервер Microsoft DNS, работающий на современном оборудовании, может удовлетворять 10 000-20 000 клиентов на каждый сервер. Установка роли DNS на каждом контроллере домена может привести к чрезмерному числу DNS-серверов в вашем предприятии. И это увеличит затраты.

Ошеломляйте перезагрузку DNS-серверов в вашем предприятии, когда это возможно.
- Для установки некоторых хотфиксов, пакетов служб и приложений может потребоваться перезагрузка.
- Некоторые клиенты перезагружают контроллеры домена по расписанию (каждые семь дней, каждые 30 дней).
- Запланировать перезагрузку и установку программного обеспечения, требуемого для перезагрузки, с умом. Это необходимо для предотвращения одновременной перезагрузки только DNS-сервера или потенциального партнера репликации источника, на который указывает контроллер домена назначения для разрешения имен.
Если Windows обновления или программного обеспечения управления устанавливается программное обеспечение, которое требует перезагрузки, ошеломляйте установки на целевых контроллерах домена, чтобы половина доступных DNS-серверов, которые контроллеры домена указывают на перезагрузку разрешения имен одновременно.

Установка устройств UPS в стратегически важных местах для обеспечения доступности DNS во время кратковременных отключений электроэнергии.

Уполномойте серверы DNS на основе UPS с помощью генераторов на месте.

Дополнительная информация

Тестирование 10 мая 2010 г. командой разработчиков Active Directory:

DNS ждет NTDS, и он не может начаться до завершения начальной репликации каталога. Это потому, что последние данные DNS еще не могут быть реплицированы на контроллер домена. С другой стороны, NTDS необходимо DNS для решения IP-адреса контроллера домена источника для репликации. Предположим, что DC1 указывает на DC2 в качестве DNS-сервера, а DC2 — на DC1 в качестве DNS-сервера. При одновременной перезагрузке DC1 и DC2 запуск будет медленным из-за этой взаимной зависимости. Основной причиной этого медленного запуска является DNSQueryTimeouts.

Если служба DNS Server работает хорошо при запуске NTDS, NTDS принимает только два запроса DNS для решения IP-адреса контроллера домена источника:

И эти DNS-запросы возвращаются практически мгновенно.
- четыре для имени на основе GUID
- четыре для полноквалифицированного имени
- два для однометного имени
Задержка для каждого запроса DNS контролируется DNSQueryTimeouts. По умолчанию для DNSQueryTimeouts установлено значение 1 1 2 4 4. Это означает, что клиент DNS будет ждать 12 (1 + 1 + 2 + 4 + 4) секунд для ответа сервера DNS. Каждый источник контекста именования занимает 120 секунд для решения IP-адреса. Предположим, что существует пять контекстов именования (Конфигурация, Схема, домен, ForestDnsZones, DomainDnsZones) и один источник репликации. В этом сценарии для завершения начальной репликации NTDS требуется 850 (170 X 5) секунд или более 14 минут.

Для проверки вышеуказанного поведения было сделано несколько тестов.

Перезагрузка контроллера домена, когда DNS-сервер является третьим контроллером домена, который находится в Интернете. Для каждого контекста именования каждого источника у нас есть два запроса DNS, и они завершались практически мгновенно:

Перезагрузка DC1 и DC2 одновременно. DC1 использует DC2 для DNS DC2, а DC1 — для DNS. Для каждого контекста именования каждого источника у нас есть 10 запросов DNS и каждый запрос занимает около 12 секунд:

Чтобы дополнительно изучить связь между DNSQueryTimeouts и медленным запуском, DNSQueryTimeouts были назначены 1 1 2 4 4, чтобы клиент DNS ждал 31 (1 + 1 + 2 + 4 + 4) секунды. В этом тесте 31 секунда была потрачена на ожидание:

Когда вы используете интегрированные в Active Directory (AD) серверы и зоны DNS в среде Windows Server 2003 или в более поздних версиях системы, данные индивидуальной зоны DNS могут храниться в одной из трех областей AD.

Когда вы используете интегрированные в 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 (как это делается, я расскажу ниже).

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

Объект 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

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

Итак. в предыдущей статье мы установили первый контролер домена, или еще можно сказать что мы подняли сервер до уровня контроллера домена. а это значит что установили Active Directory, так как мы знаем что контроллер домена хранит всю информацию о Active Directory и одновременно с установкой Active Directory установили и DNS сервер.

Давайте теперь пройдемся по его настройкам и в конце посмотрим способы проверки его работоспособности.

Заходим в Пуск/Программы/Администрирование и открываем консоль DNS. Смотрите рисунок 1.

Открытая консоль DNS сервера которого мы настраивали в предыдущей теме показана на рисунке 2.

Если копнуть еще глубже, смотрите рисунок 3, то у нас еще создаются такие каталоги как DomainDnsZones и ForestDnsZones.

Акцентирую, эти каталоги создаются в Active Directory при установки DNS интегрированного с Active Directory. И данные каталоги хранятся в разделе приложений Active Directory. Это не совсем понятно на этом рисунке и это можно удивить через оснастку "ADSF Edit", и приведена на рисунке 4 в основном для любознательных. Пока просто запомните что эти два каталога DomainDnsZones и ForestDnsZones хранятся в разделе приложений в Active Directory. Мы еще к обсуждению этих понятий вернемся.

Зачем я затронул эти два раздела как DomainDnsZones и ForestDnsZones? Да потому что каждый из них связан со своим видом репликации, то есть распространяется каждый раздел по своему. Сейчас поймете.

Хотя мы уже установили наши зоны прямого просмотра в прошлой статье мы можем потом вернутся и или проверить или что либо изменить в конфигурации этих зон.

Что бы это сделать мы становимся на интересующей нас зону и нажимая правую кнопку мыши смотрим открывшиеся контекстную меню, рисунок 5.

В этом контекстном меню выбираем "Свойства" и нам откроется картина показанная на рисунке 6.

Из рисунка 6 мы видим 6 вкладок. Пройдемся по ними. На вкладке "Общее"показанная на рисунке 6 мы видим что наша DNS зона работает и это видно возле надписи "Состояние", рядом стоит кнопка "Пауза", и что она делает думаю что объяснять не стоит.

Чуть ниже стоит надпись "Тип" и рядом описывается тип нашей зоны. В нашем случае она интегрирована в AD. Если нам нужно поменять тип зоны то мы жмем кнопку "Изменить", и перед нами появляется картина показанная на рисунке 7.

В открывшимся окне нам предлагается выбрать тип зоны в зависимости от того что нам требуется и показаны типы зон. О типах зон мы уже говорили в прошлых темах поэтому считаю что вы это знаете, а если хотите вспомнить смотрите здесь. Так же здесь мы можем указать что зону надо хранить в Active Directory или нет.

Идем дальше. тут же на этой вкладке "Общее" (рис 6) мы можем изменить область репликации. Если нажмем на кнопку "Изменит" появится такое окно показанная на рисунке 8.

Здесь мы должны выбрать то что нам нужно. Но изменение области репликации возможно лишь в том случае если зона интегрирована в Active Directory. В противном случае у нас такой возможности не будет.

Так вот что бы не забыть совсем, хочу вернутся к нашим двум зонам который создал Мастеру установки Active Directory и показать в чем их разница.

Так, после того как мы поиграли в "найди различие". тут мы слегка еще остановимся и необходимо обсудить область распространения содержимого зон. Перечень значений и как их надо понимать приведено в таблице показанной на рисунке 11.

Хочется отметить, а вам желательно запомнить что - раздел приложений Active Directory для DNS создается только в том случае, если мы устанавливаем первый контролер домена в новом лесу с установкой соответственно и интегрированного а AD DNS сервера.

Если вы хотите воспользоваться преимуществами раздела приложений каталога Active Directory для DNS после того, как установили контроллер домена, необходимо вручную создать раздел перед его использованием. Для создания раздела применяется консоль DNS или команда DnsCmd в командной строке.

При использовании консоли DNS щелкните правой кнопкой мыши на имени сервера DNS, в нашем случае это SERVER1 и из открывшегося контекстного меню выберите "Создать используемые по умолчанию разделы каталога приложений. " смотрите рисунок 12.

При использовании инструмента DnsCmd.exe откройте командную строку Cmd.exe (если правильно написать то нужно не командную строку а командный процессор Cmd.exe) в разделе "Выполнить" меню "Пуск" и наберите DnsCmd /? что бы увидеть все параметры данной команды, смотрите рисунок 13.

Наберите в командной строке >dnscmd <имяDNSсервера>/CreateBuiltinDirectoryPartitions/forest. В результате будет создан раздел ForestDnsZones. Чтобы создать раздел DomainDnsZones, используйте в конце этой команды вместо « /forest » параметр « /domain » в качестве последнего параметра в команде. Поскольку эта команда изменяет раздел конфигурации каталога в Active Directory, вы должны входить в систему как член группы Администраторы.

Да. забыл сказать что команда DnsCmd при установки операционной системы не устанавливается. Для того что бы ее использовать нам нужно установить ее с загрузочного диска с операционной системой. Для этого заходим на наш компакт диск находим папку "SUPPORT", а в данной папке, папку "TOOLS", и запускаем файл установки дополнительных инструментов под названием "SUPTOOLS.MSI", смотрите рисунок 14.

И еще. какие преимущества, что нам по сути дают эти два раздела ForestDnsZones и DomainDnsZones в составе DNS сервера хранящиеся в разделе приложений Active Directory.

• Службу DNS, интегрированную с Active Directory, можно использовать на уровне леса, так как раздел приложений уровня леса допускает репликацию данных за пределы домена. Прибегать к обычному переносу зоны DNS для репликации файла с информацией о зоне на DNS-серверы, находящиеся за пределами домена, не требуется.

• Репликация уровня домена позволяет уменьшить сетевой трафик. Администратору достаточно указать контроллеры домена с работающей службой DNS, которые должны получить информацию о зоне DNS

• Репликация уровня леса позволяет уменьшить сетевой трафик, так как данные DNS больше не реплицируются в глобальный каталог.

Еще на этой вкладке "Общие" есть поле для выбора типа динамического обновления. О динамическом обновлении мы говорили, кто забыл читайте здесь. Тем не менее еще раз остановимся и посмотрим какой у нас выбор.

С помощью скажем так переключателя мы можем выбрать следующие механизмы динамического обновления. Смотрите рисунок 15.

Выбор "Никакие" (то есть запрет на динамическое обновление) рекомендуется если зона не интегрирована с Active Directory.

Выбор "Небезопасные и безопасные" — позволяет обновлять записи ресурса DNS всем клиентам.

Разрешить "Только безопасные" динамические обновления, думаю понятно. Но. этот выбор. скажем так. не совсем уместен если зона интегрирована с Active Directory, потому как мы вправе ограничить список клиентов, которым разрешено выполнять динамические обновления, посредством списков управления доступом. В конечном итоге решает какой механизм динамического обновления выбрать сетевой админ исходя из требований диктуемые конкретно его окружения то есть сетью.

Еще на данной вкладке есть настройка очистки. Я уже говорил об этом но напомню. Механизм динамической регистрации не только регистрирует доменные имена, но так же освобождает их путем их удаления из файла зоны. Если работа системы была завершена некорректно по той или иной причине, к примеру зависла, то такие ресурсные записи могут остается в файле зоны. Или запись не была обновлена на протяжении определенного периода времени. Подобные записи называются устаревшими или фантомами. Наличие таких фантомов в файле зоны не желательно, так как клиенты получают неактуальную информацию. Поэтому DNS сервер имеет механизм очистки (scavenging) от таких устаревших фантомных записей.

Что бы настроить очистку от устаревших записей и используется кнопка "Очистка. " показанная на рисунках 6 и 15. Если ее нажать то открывается окно показное на рисунке 16.

Когда мы говорили о ресурсных записях (и еще будем говорить) то мы знаем, или пока запомним, что ресурсные записи содержат в себе такой атрибут как штамп времени. Пользуясь этим атрибутом из ресурсной записи DNS сервер, на основе настроек, принимает решение об удалении записи из зоны или нет. Вот в этом окне мы и можем указать серверу DNS как обращается с ресурсными записями на основе штампа времени содержащийся в ресурсной записи. К ресурсным записям мы еще вернемся.

С настройкам DNS зоны на вкладке "Общие" мы закончили. В следующих темах мы обсудим остальные способы и механизмы настройки DNS сервера.

Читайте также: