Dns сервер завершил цикл очистки без просмотра узлов возможные причины
Timur
Телепаты ушли в отпуск.
Опишите хотя бы конфигурацию машины, установленную ОС, задачи, которые выполняет компьютер.
И дайте полный лог ошибки.
Tert писал(а): Timur
Телепаты ушли в отпуск.
Опишите хотя бы конфигурацию машины, установленную ОС, задачи, которые выполняет компьютер.
И дайте полный лог ошибки.
Даю:
1. ОС: Windows 2003 Server Enterprise, MUI, SP1.
2. Задачи:
-Terminal Server
-File Server
-DNS Server (w/o domain)
-RRAS
-DHCP Server (for RemoteBoot with ThinStation)
-Server DrWebES
-Стройконсультант
-Кодекс
3. PC:
-Intel XEON (2)/1Gb RAM/4x74Gbx2RAID (забыл который зеркало)/DVD-RW/3xLAN (2х1Gb+1х100Mb)
4. Запись в логе:
-----
Тип события: Ошибка
Источник события: Srv
Категория события: Отсутствует
Код события: 2000
Дата: 19.03.2007
Время: 18:28:24
Пользователь: Н/Д
Компьютер: SERVER
Описание:
Неожиданный сбой при вызове системной службы сервером.
Дополнительные сведения можно найти в центре справки и поддержки, в "http://go.microsoft.com/fwlink/events.asp".
Данные:
0000: 00 00 04 00 01 00 54 00 . T.
0008: 00 00 00 00 d0 07 00 c0 . Ð..À
0010: 00 00 00 00 0a 01 00 c0 . À
0018: 00 00 00 00 00 00 00 00 .
0020: 00 00 00 00 00 00 00 00 .
0028: 34 03 bd 00 4.½.
-----
Вот еще другие:
Тип события: Уведомление
Источник события: DNS
Категория события: Отсутствует
Код события: 2502
Дата: 13.03.2007
Время: 8:50:34
Пользователь: Н/Д
Компьютер: SERVER
Описание:
DNS-сервер завершил цикл очистки без просмотра узлов. Возможные причины:
1) Не настроены зоны, очищаемые данным сервером.
2) Цикл очистки начат не ранее 60 минут назад.
3) Ошибка во время очистки.
Следующий цикл очистки запланирован через 168 часов.
Если при выполнении цикла очистки произошла ошибка, код ошибки содержится в данных события.
Дополнительные сведения можно найти в центре справки и поддержки, в "http://go.microsoft.com/fwlink/events.asp".
-----
И вот эта на последок:
Тип события: Предупреждение
Источник события: Userenv
Категория события: Отсутствует
Код события: 1517
Дата: 15.03.2007
Время: 13:50:36
Пользователь: NT AUTHORITY\SYSTEM
Компьютер: SERVER
Описание:
Реестр пользователя SERVER\Пользователь был сохранен в то время, как приложение или служба продолжали использовать его во время выхода из системы. Используемая реестром пользователя память не была освобождена. Реестр будет выгружен, когда он не будет использоваться.
Возможная причина - службы, выполняемые от имени пользователя. Попробуйте изменить настройку служб и задать их выполнение с учетными записями LocalService или NetworkService.
Дополнительные сведения можно найти в центре справки и поддержки, в "http://go.microsoft.com/fwlink/events.asp".
Есть подсеть из которой нет доступа к некоторым серверам по имени, остался доступ по ip
гугол предлагает вывести их контроллер из домена и вернуть обратно, но это какой-то сомнительный способ. Какие ещё есть варианты? Перезапуск служб ничего не дал
в событиях dns встречаются уведомления:
1. Параметр NotifyServers реестра для DNS-cервера недопустим или поврежден. Для устранения неполадки, можно удалить соответствующий параметр DNS-cервера в реестре. Затем можно создать его заново, с использованием DNS-консоли.
3. DNS-сервер завершил цикл очистки без просмотра узлов. Возможные причины:
1) Не настроены зоны, очищаемые данным сервером.
2) Цикл очистки начат не ранее 30 минут назад.
3) Ошибка во время очистки.
Следующий цикл очистки запланирован через 24 часов.
Если при выполнении цикла очистки произошла ошибка, код ошибки содержится в данных события.
это какой-то сомнительный способ.
Что вызывает сомнения? :idontnow:
Это наиболее простое и лобовое решение проблемы с DNS: при выводе контроллера из домена и вводе его обратно происходит перенастройка всех параметров DNS, в т.ч. синхронизации/очистки/обновления.
Другой вопрос, что я лично после вывода контроллера из домена ещё и переустановил бы на нём ОС с нуля. Чисто для уверенности что следов ошибки не останется.
вот это и смущает, что это в лоб как-то. Ещё можно попробовать переписать днс руками наверное
а какие ещё варианты?
а какие ещё варианты?
Ну, если упорно не хотите чинить DNS - остаётся ровно 2 варианта: прописать все компы в файликах hosts ("костыли" DNS) либо вообще отказаться от использования DNS и запоминать IP-адреса.
Боюсь ошибиться, но вообще я всю жизнь думал что за сопоставление имён в локальных зонах отвечают NetBIOS и Wins. :confused:
Самого, если честно, сей вопрос никогда не волновал, ибо всегда обходился айпишниками. :idontnow:
я всю жизнь думал что за сопоставление имён в локальных зонах отвечают NetBIOS и Wins.NetBIOS и WINS работают в пределах "плоского" сегмента сети. Как только речь заходит про Active Directory - без DNS уже не обойтись, особенно если домен расположен в нескольких подсетях с шлюзами/туннелями. Разрешить имена хостов за шлюзом через NetBIOS невозможно в принципе (в силу немаршрутизируемости протокола), через WINS <теоретически>возможно, но для этого требуется весьма нетривиальная настройка.
И, повторюсь, DNS необходим для работы Active Directory.теоретически>
в общем оказалось, что у сервера проблемы с репликацией. в логах появились ошибки DNS 4000, 4015 и Kerberos появился. Что-то всё хуже и хуже становится.
Топология репликации не создается, доменные имена не различает. Походу проще сделать новый dc чем этот лечить.
Ручная репликация не выполняется
при выполнении команды пишет "Главное конечное имя неверно"
в логах ДНС ошибка ID 4000:
DNS-серверу не удалось открыть Active Directory. Без этого он не сможет загружать зону. Данный DNS-сервер настроен для получения и использования информация из каталога для этой зоны. Проверьте, что Active Directory функционирует нормально и перезагрузите зону. Данные события содержат код ошибки.
ещё есть ошибка 4011:
DNS-серверу не удалось добавить или записать обновление имени "ForestDnsZones" домена в зоне svoblgaz.corp в Active Directory. Убедитесь, что Active Directory функционирует нормально и добавьте или обновите имя домена с помощью консоли DNS.
Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера host/asb-srv.svoblgaz.corp. Использовавшееся конечное имя: LDAP/asb-srv.svoblgaz.corp/svoblgaz.corp. Это значит, что пароль, который был использован для шифрования билета службы Kerberos, отличается от пароля на конечном сервере. Обычно это происходит, если в конечной сфере (SVOBLGAZ.CORP) и в сфере клиента имеются учетные записи компьютеров с одинаковыми именами.
ошибка в Dhcp ID 1059
Служба DHCP не смогла обнаружить папку для авторизации сервера.
это поможет или сделает ещё хуже? :help:
это поможет или сделает ещё хуже?Однозначного ответа на вопрос в такой формулировке не даст ни один вменяемый человек.
Так что - на свой страх и риск.
Мой совет был - переустановить контроллер домена.
Оказалось, что если отключить службу Kerberos, то все процессы идут нормально. Правда репликация всё равно не проходит. Есть какие-то мысли у благородного собрания по этому поводу?
Есть подсеть из которой нет доступа к некоторым серверам по имени, остался доступ по ip
гугол предлагает вывести их контроллер из домена и вернуть обратно, но это какой-то сомнительный способ. Какие ещё есть варианты? Перезапуск служб ничего не дал
в событиях dns встречаются уведомления:
1. Параметр NotifyServers реестра для DNS-cервера недопустим или поврежден. Для устранения неполадки, можно удалить соответствующий параметр DNS-cервера в реестре. Затем можно создать его заново, с использованием DNS-консоли.
3. DNS-сервер завершил цикл очистки без просмотра узлов. Возможные причины:
1) Не настроены зоны, очищаемые данным сервером.
2) Цикл очистки начат не ранее 30 минут назад.
3) Ошибка во время очистки.
Следующий цикл очистки запланирован через 24 часов.
Если при выполнении цикла очистки произошла ошибка, код ошибки содержится в данных события.
__________________
Владение русской орфографией - это как владение кунг-фу, настоящие мастера не применяют его без необходимости © Ad
Что вызывает сомнения?
Это наиболее простое и лобовое решение проблемы с DNS: при выводе контроллера из домена и вводе его обратно происходит перенастройка всех параметров DNS, в т.ч. синхронизации/очистки/обновления.
Другой вопрос, что я лично после вывода контроллера из домена ещё и переустановил бы на нём ОС с нуля. Чисто для уверенности что следов ошибки не останется.
__________________
Не засоряйте форум "спасибами"! Для выражения благодарности существуют ПС и репутация! Соблюдайте Правила!
Распространенье наше по планете
Особенно заметно вдалеке:
В общественном парижском туалете
Есть надписи на русском языке
В. Высоцкий
вот это и смущает, что это в лоб как-то. Ещё можно попробовать переписать днс руками наверное
а какие ещё варианты?
__________________
Владение русской орфографией - это как владение кунг-фу, настоящие мастера не применяют его без необходимости © Ad
Ну, если упорно не хотите чинить DNS - остаётся ровно 2 варианта: прописать все компы в файликах hosts ("костыли" DNS) либо вообще отказаться от использования DNS и запоминать IP-адреса.
__________________
Не засоряйте форум "спасибами"! Для выражения благодарности существуют ПС и репутация! Соблюдайте Правила!
Распространенье наше по планете
Особенно заметно вдалеке:
В общественном парижском туалете
Есть надписи на русском языке
В. Высоцкий
Боюсь ошибиться, но вообще я всю жизнь думал что за сопоставление имён в локальных зонах отвечают NetBIOS и Wins.
Самого, если честно, сей вопрос никогда не волновал, ибо всегда обходился айпишниками.
__________________
все "спасибы" - в приват и в репутацию! не засоряйте форум.
~~~~~~~~~~~~~~~~~~~~~~
The time has come it is quite clear, our antichrist is almost already here.
NetBIOS и WINS работают в пределах "плоского" сегмента сети. Как только речь заходит про Active Directory - без DNS уже не обойтись, особенно если домен расположен в нескольких подсетях с шлюзами/туннелями. Разрешить имена хостов за шлюзом через NetBIOS невозможно в принципе (в силу немаршрутизируемости протокола), через WINS <теоретически>возможно, но для этого требуется весьма нетривиальная настройка.
И, повторюсь, DNS необходим для работы Active Directory.теоретически>
__________________
Не засоряйте форум "спасибами"! Для выражения благодарности существуют ПС и репутация! Соблюдайте Правила!
Распространенье наше по планете
Особенно заметно вдалеке:
В общественном парижском туалете
Есть надписи на русском языке
В. Высоцкий
в общем оказалось, что у сервера проблемы с репликацией. в логах появились ошибки DNS 4000, 4015 и Kerberos появился. Что-то всё хуже и хуже становится.
Топология репликации не создается, доменные имена не различает. Походу проще сделать новый dc чем этот лечить.
__________________
Владение русской орфографией - это как владение кунг-фу, настоящие мастера не применяют его без необходимости © Ad
Ручная репликация не выполняется
при выполнении команды пишет "Главное конечное имя неверно"
в логах ДНС ошибка ID 4000:
DNS-серверу не удалось открыть Active Directory. Без этого он не сможет загружать зону. Данный DNS-сервер настроен для получения и использования информация из каталога для этой зоны. Проверьте, что Active Directory функционирует нормально и перезагрузите зону. Данные события содержат код ошибки.
ещё есть ошибка 4011:
DNS-серверу не удалось добавить или записать обновление имени "ForestDnsZones" домена в зоне svoblgaz.corp в Active Directory. Убедитесь, что Active Directory функционирует нормально и добавьте или обновите имя домена с помощью консоли DNS.
Клиент Kerberos получил ошибку KRB_AP_ERR_MODIFIED с сервера host/asb-srv.svoblgaz.corp. Использовавшееся конечное имя: LDAP/asb-srv.svoblgaz.corp/svoblgaz.corp. Это значит, что пароль, который был использован для шифрования билета службы Kerberos, отличается от пароля на конечном сервере. Обычно это происходит, если в конечной сфере (SVOBLGAZ.CORP) и в сфере клиента имеются учетные записи компьютеров с одинаковыми именами.
ошибка в Dhcp ID 1059
Служба DHCP не смогла обнаружить папку для авторизации сервера.
это поможет или сделает ещё хуже?
__________________
Владение русской орфографией - это как владение кунг-фу, настоящие мастера не применяют его без необходимости © Ad
Однозначного ответа на вопрос в такой формулировке не даст ни один вменяемый человек.
Так что - на свой страх и риск.
Мой совет был - переустановить контроллер домена.
__________________
Не засоряйте форум "спасибами"! Для выражения благодарности существуют ПС и репутация! Соблюдайте Правила!
Распространенье наше по планете
Особенно заметно вдалеке:
В общественном парижском туалете
Есть надписи на русском языке
В. Высоцкий
Оказалось, что если отключить службу Kerberos, то все процессы идут нормально. Правда репликация всё равно не проходит. Есть какие-то мысли у благородного собрания по этому поводу?
__________________
Владение русской орфографией - это как владение кунг-фу, настоящие мастера не применяют его без необходимости © Ad
В этой статье описывается, как устранять неполадки на DNS-серверах.
Проверка на наличие проблем с достоверными данными
Проверьте, является ли сервер, который возвращает неверный ответ, основным сервером для зоны (основным сервером-источником для зоны или сервером, который использует интеграцию Active Directory для загрузки зоны) или сервер, на котором размещена дополнительная копия зоны.
Если на сервере размещается дополнительная копия зоны
Изучите зону на сервере-источнике (сервере, с которого этот сервер извлекает зоны).
Вы можете определить, какой сервер является сервером-источником, проверив свойства дополнительной зоны в консоли DNS.
Если на сервере-источнике указано неправильное имя, перейдите к шагу 4.
Если на сервере-источнике указано правильное имя, убедитесь, что серийный номер на сервере-источнике меньше или равен серийному номеру на сервере-получателе. Если это так, измените либо сервер-источник, либо сервер-получатель, чтобы серийный номер на сервере-источнике был больше, чем серийный номер на сервере-получателе.
На сервере-получателе выполните принудительную пересылку зоны с помощью консоли DNS или выполните следующую команду:
Изучите сервер-получатель еще раз, чтобы узнать, правильно ли передана зона. В противном случае у вас, вероятно, возникает проблема с переносом зоны. Дополнительные сведения см. в статье проблемы зонных передач.
Если зона была передана правильно, проверьте, правильно ли указаны данные. В противном случае данные в основной зоне неверны. Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.
Проверка IP-конфигурации
Откройте окно командной строки от имени администратора на клиентском компьютере.
Выполните следующую команду:
Убедитесь, что у клиента есть допустимый IP-адрес, маска подсети и шлюз по умолчанию для сети, к которой он присоединен и используется.
Проверьте DNS-серверы, указанные в выходных данных, и убедитесь, что указанные IP-адреса указаны правильно.
Проверьте в выходных данных DNS-суффикс подключения и убедитесь, что он указан правильно.
Если у клиента нет допустимой конфигурации TCP/IP, используйте один из следующих методов.
Для динамически настроенных клиентов используйте ipconfig /renew команду, чтобы вручную обновить конфигурацию IP-адресов на DHCP-сервере.
Для статически настроенных клиентов измените свойства TCP/IP клиента, чтобы они использовали допустимые параметры конфигурации, или завершите настройку DNS для сети.
Тесты запросов DNS
Если DNS-клиент может проверить связь с компьютером DNS-сервера, попробуйте использовать следующие nslookup команды, чтобы проверить, может ли сервер отвечать на DNS-клиенты. Так как nslookup не использует кэш DNS клиента, разрешение имен будет использовать настроенный клиент DNS-сервер.
Тестирование клиента
Например, если клиентский компьютер имеет имя КЛИЕНТ1, выполните следующую команду:
Если успешный ответ не возвращается, попробуйте выполнить следующую команду:
При выполнении этого теста необходимо включить конечную точку.
если Windows успешно найдет полное доменное имя, но не сможет найти его, проверьте конфигурацию dns-суффикса на вкладке dns расширенного протокола TCP/IP Параметры сетевого адаптера. Дополнительные сведения см. в разделе Настройка разрешения DNS.
Тестирование DNS-сервера
Например, если DNS-сервер называется DC1, выполните следующую команду:
Если предыдущие тесты были успешными, этот тест также должен быть успешным. Если проверка не прошла успешно, проверьте подключение к DNS-серверу.
Тестирование записи, в которой происходит сбой
Проверка общедоступного адреса в Интернете
Чтобы устранить эту проблему, очистите кэш, выполнив ipconfig /flushdns .
Проверка сетевого подключения
Просмотр текущих корневых ссылок
Запустите консоль DNS.
Добавьте или подключитесь к DNS-серверу, который не прошел рекурсивный запрос.
Щелкните правой кнопкой мыши сервер и выберите пункт Свойства.
Щелкните корневые ссылки.
Проверьте наличие базовых подключений к корневым серверам.
Если правильно настроены корневые ссылки, убедитесь, что DNS-сервер, используемый в разрешении имен с ошибками, может проверить связь с корневыми серверами по IP-адресу.
Если корневые серверы не отвечают на проверку связи по IP-адресу, IP-адреса для корневых серверов могли измениться. Однако нередко можно увидеть перенастройку корневых серверов.
Тестирование с помощью запроса nslookup
Выполните следующую команду и проверьте, доступен ли DNS-сервер с клиентских компьютеров.
Если сопоставитель возвращает IP-адрес клиента, у сервера нет проблем.
Если сопоставитель возвращает ответ "сбой сервера" или "Запрос отклонен", зона может быть приостановлена или сервер может быть перегружен. Чтобы узнать, приостановлен ли он, перейдите на вкладку Общие окна свойств зоны в консоли DNS.
Если сопоставитель возвращает ответ "запрос на превышение времени ожидания сервера" или "нет ответа от сервера", возможно, служба DNS не запущена. Попробуйте перезапустить службу DNS-сервера, введя следующую команду в командной строке на сервере:
Если проблема возникает при запуске службы, сервер может не прослушивать IP-адрес, который использовался в запросе nslookup. На вкладке интерфейсы страницы свойств сервера консоли DNS администраторы могут ограничить DNS-сервер прослушиванием только выбранных адресов. Если DNS-сервер настроен для ограничения службы указанным списком настроенных IP-адресов, то возможно, что IP-адрес, используемый для связи с DNS-сервером, отсутствует в списке. Можно попробовать использовать другой IP-адрес в списке или добавить IP-адрес в список.
В редких случаях DNS-сервер может иметь расширенную конфигурацию безопасности или брандмауэра. Если сервер расположен в другой сети, доступной только через промежуточный узел (например, маршрутизатор фильтрации пакетов или прокси-сервер), DNS-сервер может использовать нестандартный порт для прослушивания и получения клиентских запросов. По умолчанию программа nslookup отправляет запросы на DNS-серверы через порт UDP 53. Поэтому, если DNS-сервер использует любой другой порт, запросы nslookup завершатся ошибкой. Если вы считаете, что это может быть проблема, проверьте, используется ли промежуточный фильтр для блокировки трафика на хорошо известных портах DNS. Если это не так, попробуйте изменить фильтры пакетов или правила портов в брандмауэре, чтобы разрешить трафик через порт UDP/TCP 53.
Тестирование неработающего делегирования
Начните тесты в следующей процедуре, запросив допустимый корневой сервер. Этот тест позволяет выполнить запрос всех DNS-серверов из корня к серверу, который тестируется для неработающего делегирования.
В командной строке на тестируемом сервере введите следующее:
Тип записи ресурса — это тип записи ресурса, для которой был выполнен запрос в исходном запросе, а полное доменное имя — полное доменное имя, для которого выполнялись запросы (заканчивающиеся точкой).
Если ответ содержит список записей ресурсов "NS" и "A" для делегированных серверов, повторите шаг 1 для каждого сервера и используйте IP-адрес из записей ресурсов "A" в качестве IP-адреса сервера.
Если ответ не содержит запись ресурса NS, делегирование будет разорвано.
Если ответ содержит записи ресурсов "NS", но нет записей ресурсов "A", введите " задать рекурсию" и выполните запрос по отдельности для записей ресурсов "a" серверов, перечисленных в записях NS. Если вы не нашли по меньшей мере один допустимый IP-адрес записи ресурса "A" для каждой записи ресурса NS в зоне, то у вас есть неработающее делегирование.
Если вы определили, что вы используете неработающее делегирование, исправьте его, добавив или обновив запись ресурса "A" в родительской зоне, используя допустимый IP-адрес для соответствующего DNS-сервера для делегированной зоны.
Проверка неполадок DNS-сервера
Дальнейшие действия
Если разрешение имен по-прежнему не выполняется, перейдите к разделу Устранение неполадок DNS-серверов .
Проверка связи
Убедитесь, что клиент может связаться с предпочитаемым (или альтернативным) DNS-сервером, обратившись к предпочитаемому DNS-серверу по его IP-адресу.
Например, если клиент использует предпочитаемый DNS-сервер 10.0.0.1, выполните следующую команду в командной строке:
Если ни один настроенный DNS-сервер не отвечает на прямую проверку связи с IP-адресом, это означает, что источником проблемы является более вероятное сетевое подключение между клиентом и DNS-серверами. В этом случае выполните основные действия по устранению неполадок сети TCP/IP, чтобы устранить проблему. Помните, что для работы команды ping трафик ICMP должен быть разрешен через брандмауэр.
Проверка IP-конфигурации
Выполните ipconfig /all команду из командной строки и проверьте IP-адрес, маску подсети и шлюз по умолчанию.
Проверьте, является ли DNS-сервер полномочным для имени, которое ищется. Если это так, см. раздел Проверка на наличие проблем с достоверными данными.
Выполните следующую команду.
Если вы получаете ответ об ошибке или истечении времени ожидания, см. раздел Проверка проблем с рекурсией.
Очистка кэша сопоставителя. Для этого выполните следующую команду в окне командной строки с правами администратора:
Или в окне администрирования PowerShell выполните следующий командлет:
Повторите шаг 3.
Проверка проблем с рекурсией
Чтобы рекурсия работала успешно, все DNS-серверы, используемые в пути рекурсивного запроса, должны иметь возможность отвечать и пересылать правильные данные. Если это не так, рекурсивный запрос может завершиться ошибкой по одной из следующих причин:
Время ожидания запроса истекло, прежде чем его можно будет завершить.
Сервер, используемый во время запроса, не отвечает.
Сервер, используемый во время запроса, предоставляет неверные данные.
Начните устранение неполадок на сервере, который использовался в исходном запросе. Проверьте, пересылает ли этот сервер запросы на другой сервер, изучив вкладку серверы пересылки в свойствах сервера в консоли DNS. Если флажок включить серверы пересылки установлен и в списке присутствует один или несколько серверов, этот сервер перенаправляет запросы.
Если этот сервер пересылает запросы на другой сервер, проверьте наличие проблем, влияющих на сервер, на который сервер пересылает запросы. Чтобы проверить наличие проблем, см. раздел Проверка неполадок DNS-сервера. Когда этот раздел предписывает выполнить задачу на клиенте, выполните его на сервере.
Если сервер находится в работоспособном состоянии и может пересылать запросы, повторите этот шаг и проверьте сервер, на который сервер пересылает запросы.
Если этот сервер не перенаправляет запросы на другой сервер, проверьте, может ли этот сервер запрашивать корневой сервер. Для этого выполните следующую команду:
Если сопоставитель возвращает IP-адрес корневого сервера, возможно, имеется разорванное делегирование между корневым сервером и именем или IP-адресом, который вы пытаетесь разрешить. Следуйте инструкциям по тестированию неработающей процедуры делегирования , чтобы определить, где находится неработающее делегирование.
Если сопоставитель возвращает ответ "запрос на превышение времени ожидания сервера", проверьте, указывает ли корневые ссылки на работоспособность корневых серверов. Для этого используйте для просмотра текущей процедуры корневых ссылок . Если корневые ссылки указывают на работающие корневые серверы, возможно, возникла проблема с сетью или сервер может использовать расширенную конфигурацию брандмауэра, которая не позволяет арбитру конфликтов запрашивать сервер, как описано в разделе Проверка проблем DNS-сервера . Также возможно, что рекурсивное время ожидания по умолчанию слишком мало.
Если сервер является сервером-источником
Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление.
Проблемы с зонными ошибками
Выполните следующие проверки:
Проверьте Просмотр событий как для основного, так и для дополнительного DNS-сервера.
Проверьте сервер источника, чтобы узнать, не отправит ли он передачу данных для безопасности.
Проверьте вкладку зонные передачи свойств зоны в консоли DNS. Если сервер ограничит передачу зоны на список серверов, например на вкладке серверы имен в свойствах зоны, убедитесь, что сервер-получатель находится в этом списке. Убедитесь, что сервер настроен на отправку зонных передач.
Проверьте наличие проблем на основном сервере, выполнив действия, описанные в разделе Проверка проблем DNS-сервера . Когда появится запрос на выполнение задачи на клиенте, выполните задачу на сервере-получателе.
Проверьте, не работает ли на сервере-получателе другая реализация сервера DNS, например BIND. Если это так, проблема может быть вызвана одной из следующих причин:
Windows сервер-источник может быть настроен для отправки быстрых зонных передач, но сервер-получатель стороннего производителя может не поддерживать быструю передачу зоны. В этом случае отключите передачу данных с помощью быстрой зоны на сервере-источнике из консоли DNS, установив флажок включить вторичные базы данных-получатели на вкладке Дополнительно свойств сервера.
если зона прямого просмотра на Windows сервере содержит тип записи (например, запись SRV), которую сервер-получатель не поддерживает, то на сервере-получателе могут возникнуть проблемы с извлечением зоны.
Проверьте, запущена ли на сервере-источнике другая реализация сервера DNS, например BIND. если да, то возможно, что зона на сервере источника включает несовместимые записи ресурсов, которые Windows не распознает.
Если на главном или вторичном сервере используется другая реализация DNS-сервера, проверьте оба сервера, чтобы убедиться, что они поддерживают одни и те же функции. сервер Windows можно проверить на консоли DNS на вкладке дополнительно страницы свойства сервера. В дополнение к полю включить вторичные получатели привязок на этой странице содержится раскрывающийся список Проверка имен . Это позволяет выбрать принудительное соответствие требованиям RFC для символов в DNS-именах.
В этой статье рассматривается устранение неполадок DNS-клиентов.
Журнал событий
Проверьте следующие журналы, чтобы узнать, есть ли записанные ошибки:
Читайте также: