Данные для slave домена до сих пор не загружены с dns мастера

Обновлено: 03.07.2024

DNS (система доменных имён) — это система, позволяющая преобразовывать символьные имена доменов в IP-адреса (и наоборот) в сетях TCP/IP.

Zonemaster - Хороший тест правильного делегирования зоны

Такое на обоих серверах. в чём могут быть проблемы? Работа с новыми записями и репликацией - никаких проблем нет.
Кстати оба сервера доступ в инет не имеют а также установлен ещё и WINS.

Добавлено:
Собственно вопрос - что делать? Плюнуть на результаты nslookup?

Содержание файла зоны:

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

Настройка DNS-сиcтемы BIND.
Правила делегирования домена требуют наличия как минимум двух
ответственных за данную зону DNS-серверов. Такие сервера называются
автритативными для конкретной зоны. Один из авторитативных серверов назначается primary,
остальные - secondary. На primary-сервере храниться основной файл зоны, secondary-сервера
получают ( точнее берут ) данные с primary-сервера.
Соответственно и отличаются настройки серверов:

Настройка primary-сервера.
В конфирурационный файл named.conf необходимо добавить запись зоны

Настройка secondary-сервера.
В конфирурационный файл named.conf необходимо добавить запись зоны

где имя_домена - собственно имя зоны, которую необходимо поддерживать
type master; - запись указывает, что это primary-сервер для данной зоны
type slave; - запись указывает, что это secondary-сервер для данной зоны
file "имя_домена"; - здесь необходимо указать путь к файлу , в котором будут
храниться данные зоны. Для простоты использования
рекомендуется называть файл зоны именем зоны, но имя файла может быть
произвольным. primary-сервер будет данные читать из файла,
который указан, secondary-сервера будет загружать с primary-сервера
данные и хранить эти данные в указанном файле (данный файл создается
secondary-сервером).
ip_адрес_ primary-сервера - указывается ip-адрес primary-сервера, на котором
храниться основной файл зоны

Для того, чтобы все пользователи сети INTERNET могли получать данные зоны,
необходимо на всех днс-серверах разрешить прохождение UDP-пакетов на 53-ий
порт. Так же необходимо на primary-сервере разрешить прохождение TCP-пакетов
на 53-ий порт от всех secondary-серверов. Это необходимо для обновления
файла зоны.

Конфигурация файла зоны
Сначала описываются параметры зоны

$TTL 86400
@ IN SOA primary-сервер. e-mail_администратора_домена. (
2005010700 ; Serial
3600 ; Refresh
600 ; Retry
3600000 ; Expire
86400 ) ; Minimum TTL

$TTL 86400- время жизни, директива устанавливает
стандартное время жизни (Time-to-Live - TTL)
для любой записи, в которой значение
времени жизни не задано.
SOA - запись SOA (Start-of-Authority - Начало
полномочий)
primary-сервер.- primary name-сервер
e-mail_администратора_домена.- e-mail лица , ответственно за доменю.
Вместо @ пишется точка
2005010700 ; Serial- Серийный номер. Число, которое необходимо
увеличивать при любом изменении файла зоны. На основе изменений name-сервера
решают, необходимо ли перечитывать конфигурацию зоны. Можно использовать
любое число(главное увеличение этого числа после внесения изменений), но
принято в поле писать текущую дату изменений в формате ГГГГММДДНН
(последние две цифры - порядковый номер изменения за текущие сутки)
3600 ; Refresh- запись предназначена для
secondary-серверов, задает интервал обновлений данных
зоны. Поводом к обновлению служит
изменившийся Serial
600 ; Retry- время повторения попытки обновления (Refresh) после сбоя
3600000 ; Expire- - максимальное время использования данных о
зоне secondary name-серверами при отсутсвии
возможности выполнить Refresh
86400 ) ; Minimum TTL- запись предназначена для кеширующих
серверов, задает минимальное время использования данных зоны
кеширующими серверами

Далее в файле зоны идут записи о ресурсах RR (Resource Record) в формате

<name>- поле имени.
[<ttl>]- время жизни, если необходимо задать
отличное от глобально-заданого
[<class>]- поле класса, задает группу протоколов,
актуальным на данный момент остался один
класс INTERNET (сокращенно IN).
<tipe>- поле типа указывает тип записи RR
Основные типы:
A- IP-адрес, указывает на хост,
которому соотвествует данное имя
MX- почтовый шлюз, обслуживающий
данную зону. После типа необходимо
указать приоритет почтовых шлюзов в
числовом виде, наименьшему значению
соответствует наибольший приоритет.
CNAME- Псевдоним. Удобно использовать при
смене имени хоста.
<data>- поле данных, определяется по-разному в
зависимости от <tipe>

Перейдем к практике, потому как я готов оспорить фразу:
"Знание теории освобождает от знания практики"

Если получаем 3 одинаковых ответа:

Значит name-сервера и зона настроены корректно.
И только после того , как убедились , что зона корректно настроена,
отправляем заявку на регистрацию домена.

Данное руководство не охватывает в полной мере всех настроек BIND, кому
интересно, тот может обратиться к RFC или книгам. Книг написано достаточно
много, есть переведенные на русский и достаточно грамотно. Целью же данного
руководства было описание процесса пошаговой настройки BIND-а.

Что такое glue-record.

как раз и есть glue-record.

Из предыдущего примера.
Запись

будет равносильна записи:

IN NS secondary-ns

будет иметь совсем другое значение.

Домен Windows 2000 mixed, 2 контроллера, один (PDC Emulator & Master for all) - Win2003 Server Corporate Edition SP1; второй - Windows 2000 Server SP3.
Второй параллельно работает как файл-сервер (куча расшаренных папок). Так вот в нем и проблема. Вдруг оказалось, что клиенты на Windows XP SP1 Professional не могут зайти в шары. То, чем заходишь - виснет намертво. Проходит минут 10 пока получается зайти. Интересный факт - запускаешь второе окно и пытаешься снова зайти - заходит моментом в ту же папку, заходишь на другую шару - снова тормозит.
Кроме того некоторые машины (не все, у которых такая проблема) заходят в домен по 10 минут на стадии "Применение параметров компьютера. "

Что делали:
1. Ставили QoS, в отключенном и включенном состоянии - не помогло.
2. Добавляли в hosts.txt строку с IP этого контроллера - не помогло.

Потом вроде помогла комбинация - выключенный QoS и строка в hosts.txt

и 2-ой вопрос:
если есть 2 интерфейсы то можна ли записать

comp IN A 192.0.0.1
comp IN A 193.0.0.3

вообщето эти зоны прописаны. Не трогай их . 255.in-addr.arpa - это вообще нафига надо ?

А в ссылке что ты дал нет ни слова об этом - читай сам.

ходил к ним на сайт. Пишут Reverse DNS lookup for your IP address is failing

в данном случае похоже что там вообще ничего не прописано.

З.Ы и что за параноя ? тяжело айпишник высветить или боишься что тебя сразу поломают ? :)

или тебе надо написать , что прописать в конфигах ?

намед в люом случае сначала бегает по своим зонам, если зона есть - то он дает ответ. Если зоны нет - он поступит так, как ты его отконфигуряешь.
читай доки, forwarders этот называется

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

Сразу оговоримся, что в данном материале речь не идет о серверах, как о программах, которые реализуют функцию сервера доменных имен, например named или сервер доменных имен Windows Server 2000. Мы будем рассматривать серверы, как процессы, которые должны выполнять определенные функции по обслуживанию DNS запросов.

В документах RFC-1034 и RFC-1035 выделяют несколько типов DNS-серверов. В соответствии с типами откликов на запрос к системе доменных имен серверы можно разделить на авторитативные (authoritative) и неавторитативные (non authoritative).

Авторитативный отклик (authoritative response) возвращают серверы, которые являются ответственными за зону, в которой описана информация, необходимая resolver-у (клиент DNS).

Неавторитативный отклик (non authoritative response) возвращают серверы, которые не отвечают за зону, содержащую необходимую resolver информацию.

Авторитативный отклик могут, в свою очередь, вернуть либо master-сервер зоны (primary server), либо slave-сервер (secondary server) зоны. В русскоязычной литературе их называют основным и дублирующим серверами (или первичным и вторичным, соответственно).

Master-сервер (primary, первичный) доменных имен является ответственным (authoritative) за информацию о зоне в том смысле, что читает описание зоны с локального диска компьютера, на котором он функционирует и отвечает в соответствии с этим описанием на запросы resolver-ов. Описание зоны master-сервера является первичным, т.к. его создает вручную администратор зоны. Соответственно, вносить изменения в описание зоны может только администратор данного сервера. Все остальные серверы только копируют информацию с master-сервера. Вообще говоря, такое определение несколько устарело, и позже будет ясно почему. Но при настройках реальных серверов мы будем использовать именно это определение.

Для зоны можно определить только один master-сервер, т.к. первоисточник может и должен быть только один.

Slave-сервер (secondary, вторичный, дублирующий) также является ответственным (authoritative) за зону. Его основное назначение заключается в том, чтобы подстраховать работу основного сервера доменных имен (master server), ответственного за зону, на случай его выхода из строя, а также для того, чтобы разгрузить основной сервер, приняв часть запросов на себя. Так, например, из 13 серверов, которые обслуживают корневую зону, 12 являются slave-серверами.

Администратор slave-сервера не прописывает данные описания зоны. Он только обеспечивает настройку своего сервера таким образом, чтобы его сервер копировал описание зоны с master-сервера, поддерживая его (описание зоны) в актуальном согласованном с master-сервером состоянии.

Обычно, время согласования описания зоны между slave-сервером и master-сервером задается администратором master-сервера в описании зоны. Slave-сервер в момент своего запуска копирует это описание и затем руководствуется им при обновлении информации о зоне. Slave-сервера периодически через заданный интервал времени опрашивают master-сервер на предмет изменения описания зоны. Если изменения имеют место быть, то описание зоны копируется на slave-сервер.

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

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

Рис.1. Схема подключения master и slave серверов зоны

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

Как уже было сказано, slave-сервер копирует описание зоны c master-сервера. В настоящее время существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

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

Так slave-сервером называют сервер, который использует механизм передачи зоны для получения копии зоны, а master-сервером называют сервер, с которого осуществляется копирование зоны. При этом зону можно скопировать с любого сервера, который является авторитативным. Т.е. зону можно скопировать и со slave-сервера, который относительно самой процедуры копирования зоны будет считаться master-сервером. Для того чтобы выделить сервер, который не копирует зоны ни с какого другого сервера, вводят понятие Primary Master. Этот сервер для зоны только один, и он находится в корне процедуры копирования описания зоны.

Типизация серверов относительно процедуры обмена описаниями зон связана с возможностями, которые не описаны в RFC-1034 и RFC-1035, и, соответственно, не поддерживались в ранних версиях программ-серверов доменных имен. Это механизм объявлений об изменениях в описании зоны (RFC-1996), динамическое обновление описания зоны (RFC-2136) и инкрементальное обновление описания зоны (RFC-1995).

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

Сначала о том, что такое уведомления об изменениях описания зоны (DNS NOTIFY). Идея достаточно проста и проистекает из проблемы распространения изменений, внесенных в описание зоны при ее редактировании. Дело в том, что slave-серверы при традиционной работе опрашивают master-сервер (в данном контексте primary master) на предмет изменения в описании зоны через определенные промежутки времени, которые задаются в описании зоны. Возможна ситуация, когда изменения были внесены в зону сразу после ее копирования slave-сервером. В этом случае новая информация появится на всех slave-серверах только при следующем обновлении зоны.

О том, что обозначают другие позиции этих отчетов, мы поговорим тогда, когда будем обсуждать описание зоны (запись SOA), а пока только заметим, что внесение изменений в описание зоны не приводит к появлению возможности мгновенного их использования.

Таким образом, механизм уведомления об изменениях в описании зоны необходим для ускорения введения в жизнь сделанных изменений.

Принцип работы DNS NOTIFY следующий:

В базу данных primary master вносятся изменения (руками с последующей перезагрузкой сервера или динамически по протоколу динамического обновления зоны).
Primary master оповещает свои slave о том, что произошли изменения, сообщая им номер версии описания зоны.
Slave запрашивает с primary master описание зоны и, если номера версии описаний зоны не совпадают (на primary master номер больше), то инициирует процесс обновления описания зоны.
Завершив обновление описания зоны, slave посылает оповещения на известные ему авторитативные сервера зоны.

На рисунке пояснется работы приведенной выше схемы:

Рис.2. Схема работы DNS NOTIFY

На рисунке 2 primary master является для обоих slave-серверов master-сервером c точки зрения процедуры передачи зоны. Но в принципе, для одного из серверов он может быть и не определен в качестве master-сервера. В этом случае появляется дополнительное звено в дереве зависимости обмена данными зоны. В этом случае изменения будут передаваться от сервера к серверу так, как это показано на рисунке 3:

Рис.3. Схема работы DNS NOTIFY при двухзвенном оповещении об изменении описания зоны.

Теперь поясним механизм динамического обновления описания зоны (Dynamic Updates или DNS UPDATE). Изначально описание зоны было, да и до сих пор в большинстве случаев остается, статическим. Это значит, что есть на Primary master файл описания зоны, в который администратор вручную или при помощи скриптов изменения содержания файла вносит изменения. Для того чтобы они стали актуальными, т.е. их увидели resolver-ы, необходима перезагрузка сервера. Идея динамического обновления описания зоны состоит в том, чтобы, во-первых, вносить изменения в описание зоны без перезагрузки сервера, а, во-вторых, делать это удаленно, т.е. администратору не нужно получать доступ к файлам описания зон ни для ручного редактирования, ни для скриптов. Тем самым класс клиентов в модели "клиент-сервер" в рамках DNS обмена расширяется на группу клиентов администрирования.

Когда актуально динамическое обновление зоны? Чаще всего необходимость динамического обновления связывают с работой по протоколу DHCP (Dynamic Host Configuration Protocol, RFC-1541). DHCP Позволяет динамически назначать компьютерам IP-адреса, маски, IP-адреса шлюзов, доменные имена и т.п., т.е. передавать хостам данные без которых невозможна работа в сетях TCP/IP.

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

Динамическое обновление позволяет авторизованным клиентам посылать запросы на динамическое обновление описания зоны серверам, которые являются авторитативными для соответствующей зоны. Обратите внимание, что запросы могут направляться как master-серверам, т.к. slave-серверам.

Если сервер не является Primary master-сервером зоны, то он отправляет (ретранслирует) запрос на обновление своему master-серверу. Таким образом запрос на обнавление достигает Primary master-сервера зоны.

Как только Primary master-сервер совершит обновление описания зоны, он может по механизму DNS NOTIFY оповестить об этом slave-серверы, которые, в свою очередь, обновят свои описания зоны.

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

Для того, чтобы успешно выполнялись обмены со slave-серверами, при каждом изменении зоны изменяется и номер ее версии. Это позволяет slave-серверам поддерживать свои описания зоны в актуальном, согласованном с Primary master-сервером состоянии.

Динамическое обновление описания зоны порождает другую проблему - многократную передачу по сети описания зоны между master-серверами и slave-серверами. Если описание зоны большое, то и объем трафика, который передается по сети, будет немаленький.

При этом стоит отметить, что собственно сами изменения описания зоны не столь и велики, т.к., например, при DHCP при каждом изменении добавляется/удаляется одна-две записи описания ресурсов. Каждое такое изменение будет порождать обмен описанием зоны.

При традиционном обмене описанием зоны (AXFR) Между master-сервером и slave-сервером передается полное описание зоны.

Для того, чтобы не передавать всю зону, а передавать только изменения предназначен механизм инкрементальной передачи описания зоны (IXFR, RFC-1995). В рамках обмена передаются номера версий описаний зон и записи, которые нужно добавить или удалить. Принцип простой - сначала идут номер старой версии и список записей, которые нужно удалить, а потом номер более свежей версии и записи, которые нужно добавить.

Мы более подробно остановимся на этом вопросе в разделе, посвященном настройкам BIND и файлам описания зон.

В контексте рассмотрения обмена описаниями зоны между master-серверами и slave-серверами следует упомянуть о "невидимых" серверах (stealth, см. RFC-1996). Суть такого сервера в том, что он не упоминается в описании зоны. Таким образом, его никто не видит, т.к. в рамках DNS-обмена данными информацию о нем получить нельзя ни путем простых запросов, ни путем копирования описания зоны.

Тем не менее, существуют еще файлы статической настройки (конфигурации) серверов доменных имен, где такой сервер может быть прописан. Его можно прописать в качестве master-сервера для slave или сконфигурировать таким образом, что он будет работать в качестве slave для конкретной зоны.

Для чего нужен такой невидимый сервер. Например, для того, чтобы вносить обновления в зону, находясь под защитой firewall. В этом случае Primary master можно сделать невидимым, а все остальные, в том числе и заявленные при регистрации домена, slave-серверами зоны. Это позволяет нейтрализовать атаки на зону, т.к. обновление всегда будет производиться с "невидимого" Primary master:

Рис.4. Схема организации DNS-серверов с невидимым primary master сервером

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

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

Кэш-сервер не поддерживает описаний зон и, соответственно, не посылает resolver-ам авторитативных откликов:

Выше приведен типичный отклик кэширующего сервера на запрос nslookup об адресе www.w3.org. Если бы сервер был авторитативным, то строчки "Non-authoritative answer" в отклике мы бы не увидели.

Мы не обсудили еще один тип серверов - это сервера, которые обслуживают корневую зону (Root servers). Их место в получении отклика на запрос к системе доменных имен ключевое. Именно к одному из корневых серверов обращается локальный сервер доменных имен, если не находит в зоне своей ответственности или в своем кэше соответствия между доменным именем и IP-адресом.

Список этих серверов можно получить достаточно просто. Ниже приведен отчет программы nslookup:

> .
Server: [144.206.192.60]
Address: 144.206.192.60

И еще несколько слов о root серверах в заключении этого раздела. Существует такая организация - IEPG (Internet Operational Group), задача которой помогать Интернет Сервис Провайдерам взаимодействовать в Сети Интернет. В 1999 году на очередной встрече этой группы обсуждались проблемы DNS И приводилась некоторая статистика по запросам к root серверам:

Средние цифры таковы:

Распределение запросов по типам:

Поиск IP-адреса(A) 77%
Поиск сервера доменных имен (NS) 15%
Поиск почтового шлюза(MX) 5%

Статистика обслуживания запросов, которая названа ужасающей(Scary statistics):

- Только 26% правильных(valid) запросов к корневой зоне.

- 66% запросов к несуществующим доменам верхнего уровня (non existent TLDs)

По поводу последней цифры автор BIND Paul Vixie предположил, что это обращения к группам Windows NT, и при отсутствие негативного кэширования в Windows эти запросы повторяются до 10 раз за секунду.
Приведенные цифры должны дать представление о степени нагрузки на root серверы и цену тиражировании программного обеспечения, содержащего неточности приреализации протоколов.

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

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

В нашей настройке у нас есть первичный DNS-сервер с IP-адресом 172.16.10.2 и доменным именем ns1.infoit.local .

Мы настраиваем вторичный сервер с 172.16.10.10 и ns2.infoit.local .

Конфигурация на Bind Master DNS

Для настройки Master-Slave нам необходимо настроить главный DNS-сервер и включить передачу зоны на вторичный сервер имен.

Мы будем редактировать /etc/named.conf.local файл на первичном сервере (ns1.infoit.local) и добавить allow-transfer и also-notify параметры.

Это будет сделано как для прямого, так и для обратного ввода.

allow-transfer Параметр позволяет передавать файлы зоны от ведущего к ведомому DNS в то время как also-notify помогает предупредить подчиненный , когда есть обновление файлов зона от мастера.

Мы должны перезапустить службу DNS на ns1.infoit.local:

Настройте подчиненный DNS

Установите необходимые пакеты:

Отредактируйте файл в /etc/bind/ named.conf.local и добавьте параметры прямой и обратной зоны:

Перезапустите службу DNS:

Тестовый ведомый DNS

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

Затем мы можем использовать dig команду для проверки DNS.

езультат показывает, что подчиненный DNS может обрабатывать запросы. Это подразумевает, что настройка DNS «главный-подчиненный» работает должным образом.

Вывод

Вы успешно настроили подчиненный DNS-сервер в Ubuntu 20.04 с помощью BIND9. Поделитесь своим мнением в комментариях.

В этой статье устраняется ИД события 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 секунда была потрачена на ожидание:

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