Не удается задать область репликации dns

Обновлено: 07.07.2024

Когда вы используете интегрированные в 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

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

Вариант 2

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

Связь была настроена ещё давно бывшим админом и по dns именам все отлично работало, пока.

По ip пинги между доменами идут, все нормально.

"DNS.
Не удается задать область репликации. Подробнее об этом см. ". " Ошибка:
На сервере произошла авария
"

На ряду с этим всем ошибок event нет, хотя они включены.

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

Добавлено:
ну хоть какие-то варианты.. голова гудит, сижу с книгой пол дня ((

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to rcstool.factory.local timed-out

Добавлено:
пинги между доменами идут по IP, по днс имени не идут, кроме тех, которые прописаны в корне, и то после того, как первый раз пропинговать с точкой, второй уже без нее есть, но суфикс все равно не возвращает. проверка доверия говорит о том, что нет доступных контроллеров домена..

в сети factory.local у меня 2 DC

а разве могут быть такие проблемы из-за неправильной синхры времени?

Жмакни на DC
W32TM /resync /nowait
W32TM /resync /rediscover
затем смотри system eventlog для ошибок W32TIME.

2. Зоны существуют, т.к. связь работала. Создать новую не могу.

В Зоне 12.х запись rcstool есть в 3 вариантах:
как Начальная запись зоны(SOA)
как Указатель(PTR)
как Сервер имен(NS)

В Зоне 13.х аналогично.

3. Это резервный DC, время отличается от времени на rcscomp на 3 минуты. Это реально может быть причиной?

Так вся фишка в том, что между основными DC этих доменов время не отличается.

И вообще за эти 2 дня я переделал кучу всяких переделок с DNS. В последствии добился частичного пинга по dns имени с DC на DC, и с одного DC на прокси другого домена. Но остальные компьютеры все равно не пингуются.. может нужно выждать.. завтра посмотрю.

Походу решается вопрос только через передачу зоны с одного ДНС на другой и настраивается никак не через репликации и dcdiag.

Настроил передачу прямых зон туда и обратно, установил время очистки для всех зон 1 час. Скажи(те), а как я увижу результат, у меня в зонах создадутся все записи с другого домена?

И ещё, как я говорил

Почему я лезу в DNS. Объясняю.. проблема проявилась именно тогда, когда некий хороший человек очистил DNS кеш.

Вот кратко о nltest и netdom (т.е. о том, что они говорят по этому поводу):

The command failed to complete successfully.

Добавлено:
а почему отказано? потому что нет авторизации а почему нет авторизации? потому что нет dns и доверия в общем завязалось все в петлю.. осталось взять мыло и идти вешаться

Добавлено:
А ещё интересно вот ещё что.

ping rcscomp

Ответ от 192.168.13.15: число байт=32 время=22мс TTL=126

ping -a 192.168.13.15

Обмен пакетами с RCSCOMP [192.168.13.15] с 32 байт данных:

dns был настроен так, что связь всегда была.

3-4 мес. наза случился глюк, по dns между доменами связи не было вообще. Исправил полным пересозданием зон с обеих сторон.

Сегодня вообще заглючила и выдается вот такое:

- на сервере домена factory.local (rcstool)

> rcscomp
Server: rcstool.factory.local
Address: 192.168.12.16

Обмен пакетами с RCSCOMP [192.168.13.15] с 32 байт данных:

Ответ от 192.168.13.15: число байт=32 время=20мс TTL=126
Ответ от 192.168.13.15: число байт=32 время=20мс TTL=126
Ответ от 192.168.13.15: число байт=32 время=21мс TTL=126
Ответ от 192.168.13.15: число байт=32 время=20мс TTL=126

т.е. по пингу с возвратом fqdn оно возвращает просто имя, без доменного суфикса

ping -a временами возвращает только имя, временами нифига - просто идет пинг по ай-пи.

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

Добавлено:
могу выложить скрины созданных зон, но все же работало, так что вероятно дело не в схеме, а в каком-то глюке.

PS. Время одинаковое, ошибок DNS нет ни там, ни там

Добавлено:
КАК МОЖЕТ БЫТЬ ТАКОЕ ЧТО NSLOOKUP ВСЕ КОРРЕКТНО ВЫДАЕТ, А PING ТУПИТ (((

flushdns и registerdns делал с обеих сторон

Добавлено:
с сервера rcstool домена factory.local началось что-то непонятное:

Обмен пакетами с rcscomp [192.168.13.15] с 32 байт данных:

Ответ от 192.168.13.15: число байт=32 время=19мс TTL=126

Ответ от 192.168.13.15: число байт=32 время=21мс TTL=126

Добавлено:
DCDIAG на обоих серверах чистый

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

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

Настройка репликации зон, интегрированных в Active Directory

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

Данные DNS для отдельной зоны можно реплицировать среди контроллеров домена различными способами, в зависимости от раздела каталога приложения, где хранятся данные зоны DNS.

Каждый из этих разделов каталога приложений получает имя в соответствии с именем FQDN дочернего домена DNS. Эти разделы можно просмотреть в диспетчере DNS. Кроме того, каждая зона содержит имя DomainDnsZones, указывающее раздел, репликация которого выполняется лишь в локальных доменах.

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

Хранение данных DNS в разделе домена Данные зоны, интегрированной в Active Directory, хранятся в разделе домена вместе с остальными данными домена. В этой конфигурации репликация данных DNS выполняется не только на контроллерах домена, которые также являются DNS-серверами, но и па всех контроллерах локального домена. Однако при использовании этой опции генерируется дополнительный трафик репликации. Ее следует применять для репликации данных DNS на компьютерах Windows Server 2000.

Раздел, в котором хранится зона, эффективно определяет область репликации для этой зоны, интегрированной в Active Directory. При использовании программы Dcpromo для назначения сервера контроллером нового домена в разделе DomainDnsZones автоматически создается новая зона, интегрированная в Active Direcrory. Однако при создании новой зоны с помощью мастера создания новой зоны на странице Область репликации зоны, интегрированной в Active Directory ( Active Directory Zone Replication Scope ), можно выбрать раздел для сохранения зоны.

На странице Область репликации зоны, интегрированной в Active Directory ( Active Directory Zone Replication Scope ), представлены четыре опции.

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

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

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

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

Область репликации созданной зоны можно изменить в любое время. Для этого на вкладке Общие ( General ) щелкните кнопку Изменить ( Change ) напротив параметра репликации.

Откроется диалоговое окно Изменение области видимости зоны репликации (Change Zone Replication Scope), в котором представлены те же опции выбора области репликации, что и на странице мастера создания новой зоны.

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

ПРИМЕЧАНИЕ: Повторное создание зон DomalnDnsZones и ForestDnsZones

Удаленные или поврежденные разделы каталога приложений можно воссоздать в диспетчере DNS , щелкнув правой кнопкой мыши узел сервера и применив команду Создать используемые по умолчанию разделы каталога приложений ( Create Default Application Directory Partitions ).

Создание настраиваемого раздела каталога приложения

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

dnscmd имя_сервера /createdirectorypartition hmp_FQDN

Затем перечислите в разделе другие DNS -серверы с помощью следующей команды:

dnscmd имя_сервера / enlistdirectorypartition имя_ FQDN

Так, чтобы создать раздел каталога приложений DNSpartitionA на компьютере Server 1 в домене Active Directory с именем microsoft . com , введите такую команду:

ПРИМЕЧАНИЕ: Использование точки (.) для указания имени локального сервера

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

Чтобы перечислить в разделе каталога приложений компьютер Server 2, введите такую команду:

ПРИМЕЧАНИЕ: Кто может создавать раздел каталога приложений

Раздел каталога приложений может создать лишь член группы Администраторы предприятия ( Enterprise Admins ).

Созданный раздел каталога приложений появится в раскрывающемся списке на странице Область репликации зоны, интегрированной в Active Directory ( Active Directory Zone Replication Scope ) мастера создания новой зоны и в диалоговом окне Изменение области видимости зоны репликации ( Change Zone Replication Scope ). Чтобы сохранить зону в новом разделе, выберите опцию На все контроллеры домена, указанные в области данного раздела каталога (То А ll Domain Controllers Specified In The Scope Of This Directory Partition ), и в раскрывающемся списке укажите этот раздел.

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

Передача данных для дополнительных зон может быть инициирована в любом из трех случаев.

По умолчанию передача для всех зон отключена. Ее нужно включить на вкладке Передача зон ( Zone Transfers ) окна свойств зоны. Установив флажок разрешения передачи зон, можно выбрать одни из трех параметров передачи.

На вкладке Передача зон (Zone Transfers) можно также настроить уведомление, которое будет отправлено дополнительным серверам в случае изменений в основной зоне. Поскольку передача зон представляет собой операции PULL, их нельзя конфигурировать для переноса новых данных на дополнительные серверы. Вместо этого при модификации данных основная зона отправляет уведомление на все указанные серверы, управляющие дополнительными зонами. Дополнительная зона, получившая уведомление, инициирует передачу зоны.

Для настройки уведомлений на вкладке Передача зон ( Zone Transfers ) щелкните кнопку Уведомить ( Notify ). Откроется диалоговое окно Уведомление ( Notify ), где можно указать дополнительные серверы, которые будут оповещаться при обновлении зоны на локальном главном сервере.

По умолчанию при включении передачи зон все серверы, перечисленные на вкладке Серверы имен ( Name Servers ), автоматически уведомляются об обновлениях зоны.

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

Перезагружается дополнительная зона из локального хранилища.

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

Выполняется передача зоны с главного сервера дополнительной зоны независимо от серийного номера в записи SOA дополнительной зоны.

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

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

Предположим, вы работаете администратором DNS -сервера Dns 1. microsoft . com , который уполномочен для зоны Microsoft . com . Ваша компания имеет дочерний домен Active Directory с именем India . microsoft . com , для которого выполняется делегирование. При начальном делегировании дочерняя зона, интегрированная и Active Directory , содержит только два полномочных DNS -сервера - 192.168.2.1 и 192.168.2.2. Позже администраторы домена India . microsoft . com развертывают дополнительные контроллеры домена и устанавливают роль DNS -сервер ( DNS Server ) на новых контроллерах. Однако администраторы не уведомили вас о том, что добавили полномочные DNS -серверы на свой домен. В результате на сервере Dns 1. microsoft . com оказались не отконфигурированными записи новых DNS -серверов, уполномоченных для домена lndia . microsoft . com , и запросы продолжают пересылаться лишь на два DNS -сервера, заданный в начальном делегировании.

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

Устанавливая очередной (второй, третий и т.д.) контроллер домена в существующем домене и назначая ему роль 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-зону своего домена.

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