Лучший отвечающий
Делегирование зон DNS дочерних доменов Active Directory. Пропадают записи об IP-адресах серверов DNS.

Вопрос
-
Есть дерево ActiveDirectory с несколькими десятками дочерних доменов третьего уровня. Прямая зона DNS каждого дочернего домена хранится в ActiveDirectory на контроллерах только этого дочернего домена (в разделе DomainDnsZones). Контроллеры домена так же являются DNS-серверами. Прямая зона корневого домена второго уровня хранится также в AD и реплицируется на все контроллеры всех доменов в лесу (раздел ForestDnsZones). В прямой зоне корневого домена второго уровня настроено делегирование прямых зон DNS дочерних доменов на соответствующие DNS-сервера. На всех КД установлена ОС Windows Server 2003 Std.
Для наглядности:
корневой домен - dom.org
дочерние домены - a.dom.org (контроллеры dca1.a.dom.org dca2.a.dom.org), b.dom.org (контроллеры dcb1.b.dom.org dcb2.b.dom.org),....., z.dom.org (контроллеры dcz1.z.dom.org dcz2.z.dom.org).
прямая зона a.dom.org хранится на dca1.a.dom.org и dca2.a.dom.org
прямая зона b.dom.org хранится на dcb1.b.dom.org и dcb2.b.dom.org
прямая зона z.dom.org хранится на dcz1.z.dom.org и dcz2.z.dom.org
зона dom.org хранится на всех контроллерахВ зоне dom.org прописано делегирование доменов:
a.dom.org на сервера dca1.a.dom.org и dca2.a.dom.org
b.dom.org на сервера dcb1.b.dom.org и dcb2.b.dom.org
z.dom.org на сервера dcz1.z.dom.org и dcz2.z.dom.orgВсё это прекрасно работает, но периодически в свойствах делегирования некоторых дочерних доменов (не всех) пропадают записи об IP-адерсах DNS-серверов, которым делегирована зона. Т.е. заходишь в свойства делегирования и видишь в списке серверов имён следующую картину:
Полное доменное имя (FQDN) сервера IP-адрес
dca1.a.dom.org нет данных
dca2.a.dom.org нет данныхСоответственно, перестают разрешаться имена хостов этих дочерних доменов, не проходит репликация, авторизация и т.д. и т.п.
Никаких зависимостей найти не удалось - адреса могут не пропадать 2 месяца, иногда пропадают раз в неделю. Удаление делегирования и создание его заново проблему не решает. Анализ системных логов на предмет поиска причин потери IP-адресов не дал никаких результатов. Есть какие-нибудь мысли, как найти причину потери IP-адресов в делегировании? Буду премного благодарен за любые наводки.
- Изменено Valery Cook 15 марта 2013 г. 13:41
15 марта 2013 г. 13:28
Ответы
-
Для начала можно попробовать понять, когда именно и на каком контроллере домена было произведено удаление записи в DNS. Для этого следует посмотреть метаданные репликации для удаленной учетной записи, а именно - время и источник модификации атрибута dNSTombstoned: при удалении записи DNS его значение меняется на TRUE.
Смотреть метаданные для зоны с областью репликации "все серверы DNS в лесу" можно с помощью утилиты repadmin (входит в состав Support Tools) с любого КД
repadmin /showobjmeta . DC=имя_хоста,DC=имя_зоны,CN=MicrosoftDNS,DC=ForestDNSZones,DC=Корневойдоменлеса
В вашем примере команда будет выглядеть так:
repadmin /showobjmeta . DC=dca1.a.dom.org,DC=a.dom.org,CN=MicrosoftDNS,DC=ForestDNSZones,DC=dom,DC=org
От этой печки уже можно будет начать танцевать.
PS Если подозреваете, что запись кто-то удаляет вручную, то это можно проверить с помощью аудита: http://blogs.msdn.com/b/anthonw/archive/2006/08/23/715983.aspx
PPS А можно ничего не проверять, а запретить изменение атрибута dNSTombstoned с помощью разрешений для записи (вкладка Securuty свойств записи A в DNS в режиме View/Advanced).
Слава России!
- Изменено M.V.V. _ 17 марта 2013 г. 22:41
- Помечено в качестве ответа Valery Cook 18 марта 2013 г. 11:40
17 марта 2013 г. 22:36
Все ответы
-
Покажите вывод dcdiag /test:dns на домен-контроллере корневого домена и на домен-контроллере одного из дочерних доменов, в котором проявлялась описываемая проблема.17 марта 2013 г. 18:22Модератор
-
Для начала можно попробовать понять, когда именно и на каком контроллере домена было произведено удаление записи в DNS. Для этого следует посмотреть метаданные репликации для удаленной учетной записи, а именно - время и источник модификации атрибута dNSTombstoned: при удалении записи DNS его значение меняется на TRUE.
Смотреть метаданные для зоны с областью репликации "все серверы DNS в лесу" можно с помощью утилиты repadmin (входит в состав Support Tools) с любого КД
repadmin /showobjmeta . DC=имя_хоста,DC=имя_зоны,CN=MicrosoftDNS,DC=ForestDNSZones,DC=Корневойдоменлеса
В вашем примере команда будет выглядеть так:
repadmin /showobjmeta . DC=dca1.a.dom.org,DC=a.dom.org,CN=MicrosoftDNS,DC=ForestDNSZones,DC=dom,DC=org
От этой печки уже можно будет начать танцевать.
PS Если подозреваете, что запись кто-то удаляет вручную, то это можно проверить с помощью аудита: http://blogs.msdn.com/b/anthonw/archive/2006/08/23/715983.aspx
PPS А можно ничего не проверять, а запретить изменение атрибута dNSTombstoned с помощью разрешений для записи (вкладка Securuty свойств записи A в DNS в режиме View/Advanced).
Слава России!
- Изменено M.V.V. _ 17 марта 2013 г. 22:41
- Помечено в качестве ответа Valery Cook 18 марта 2013 г. 11:40
17 марта 2013 г. 22:36 -
Спасибо за наводку! С помощью оснастки adsiedit.msc нашёл в DC=dom.org,CN=MicrosoftDNS,DC=ForestDNSZones,DC=dom,DC=org все записи со значением атрибута dNSTombstoned=TRUE. Таких записей оказалой около 10 штук. После этого посмотрел repadmin-ом источник, дату и время изменения атрибута dNSTombstoned. Для всех записей, которые я нашёл через оснастку adsiedit.msc, источник изменения атрибута оказался один и тот же (один из контроллеров домена). И даже дата/время изменения у всех записей оказалась одна и та же с точностью до секунды! Сомневаюсь, что кто-то это делает вручную. Попробую включить аудит удаления записей DNS на том контроллере. Можно конечно последовать Вашему совету и запретить изменение атрибута dNSTombstoned, но хотелось бы для начала докопаться до истины и найти причину удаления записей на том контроллере.18 марта 2013 г. 8:58
-
А вот, собственно, и оно:
===========================================
Тип события: Уведомление
Источник события: DNS
Категория события: Отсутствует
Код события: 2501
Дата: 14.03.2013
Время: 13:22:37
Пользователь: Н/Д
Компьютер: DCM1
Описание:
DNS-сервер завершил цикл очистки.
Просмотрено зон = 3,
Просмотрено узлов = 359,
Очищено узлов = 26,
Очищено записей = 23.
Цикл продолжался 0 секунд.
Следующий цикл очистки запланирован через 24 часов.
Если при выполнении цикла очистки произошла ошибка, код ошибки указывается в данных события.Дополнительные сведения можно найти в центре справки и поддержки, в ".....".
===========================================
Время этого события совпадает со временем изменения записей.Кто-то из админов поставил в настройках DNS-сервера на этом КД на вкладке "Дополнительно" галку "Разрешить автоматическое удаление устаревших записей". Проблема локализована.
Благодарю за помощь!- Изменено Valery Cook 18 марта 2013 г. 11:57
18 марта 2013 г. 11:32