Днс можно ли восстановить порядок

Обновлено: 21.11.2024

Если вы не продлили домен до окончания периода позднего продления или случайно удалили домен, некоторые реестры доменов верхнего уровня (TLD) позволяют восстановить домен до того, как он станет доступен для других. зарегистрироваться.

Когда домен удаляется или заканчивается период позднего продления, он больше не отображается в консоли Amazon Route 53.

Стоимость восстановления домена обычно выше, а иногда и намного выше, чем стоимость регистрации или продления домена. Текущую стоимость восстановления домена см. в столбце «Цена восстановления» в разделе Цены на регистрацию домена Amazon Route 53 .

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

Чтобы попытаться восстановить регистрацию домена, если домен был удален или истек период позднего продления

Определите, поддерживает ли реестр TLD домена восстановление доменов, и если да, то укажите период, в течение которого разрешено восстановление.

Найдите TLD для своего домена и проверьте значения в разделе "Сроки продления и восстановления доменов".

Мы перенаправляем запросы на восстановление в компанию Gandi, которая обрабатывает запросы в рабочее время с понедельника по пятницу. Ганди базируется в Париже, где время UTC/GMT +1 час. В результате, в зависимости от того, когда вы отправите свой запрос, в редких случаях обработка запроса может занять неделю или больше.

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

Укажите следующие значения:

Примите значение по умолчанию для Account and Billing Support.

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

Примите значение по умолчанию для проблемы с регистрацией доменного имени.

Введите Восстановить домен с истекшим сроком действия или Восстановить удаленный домен.

Описание

Предоставьте следующую информацию:

Домен, который вы хотите восстановить

12-значный идентификатор учетной записи AWS, на которую был зарегистрирован домен

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

"Я согласен на цену $____ за восстановление моего домена."

Замените пробел ценой, найденной на шаге 2.

Укажите способ связи и, если вы выбрали «Телефон», введите соответствующие значения.

Выберите «Отправить».

Когда мы узнаем, удалось ли нам восстановить ваш домен, с вами свяжется представитель службы поддержки AWS. Кроме того, если нам удалось восстановить ваш домен, домен снова появится в консоли. Срок действия зависит от того, истек ли срок действия домена или он был случайно удален:

Новая дата истечения срока действия обычно наступает через один или два года (в зависимости от TLD) после старой даты истечения срока действия.

Новая дата истечения срока действия не рассчитывается с даты восстановления домена.

Восстановить первый доступный для записи контроллер домена в каждом домене

Начав с доступного для записи контроллера домена в корневом домене леса, выполните действия, описанные в этом разделе, чтобы восстановить первый контроллер домена. Корневой домен леса важен, поскольку в нем хранятся группы администраторов схемы и администраторов предприятия. Это также помогает поддерживать иерархию доверия в лесу. Кроме того, корневой домен леса обычно содержит корневой сервер DNS для пространства имен DNS леса. Следовательно, интегрированная в Active Directory зона DNS для этого домена содержит записи ресурсов псевдонимов (CNAME) для всех других контроллеров домена в лесу (которые необходимы для репликации) и записи ресурсов DNS глобального каталога.

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

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

Затем выполните следующие действия. Процедуры для выполнения определенных шагов находятся в AD Forest Recovery — Процедуры.

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

Поскольку это первый доступный для записи контроллер домена в домене, необходимо выполнить неавторизованное восстановление доменных служб Active Directory и принудительное восстановление SYSVOL.Операция восстановления должна быть завершена с помощью приложения резервного копирования и восстановления с поддержкой Active Directory, такого как Windows Server Backup (то есть вам не следует восстанавливать контроллер домена с помощью неподдерживаемых методов, таких как восстановление моментального снимка виртуальной машины).

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

Выполняйте принудительную (или первичную) операцию восстановления SYSVOL только для первого восстанавливаемого контроллера домена в корневом домене леса. Неправильное выполнение первичных операций восстановления SYSVOL на других контроллерах домена приводит к конфликтам репликации данных SYSVOL.

Существует два варианта выполнения неавторизованного восстановления доменных служб Active Directory и принудительного восстановления SYSVOL:
Выполните полное восстановление сервера, а затем принудительно выполните принудительную синхронизацию SYSVOL. Подробные процедуры см. в разделах Выполнение полного восстановления сервера и Выполнение авторитетной синхронизации SYSVOL, реплицированного DFSR.
Выполните полное восстановление сервера с последующим восстановлением состояния системы. Этот вариант требует, чтобы вы заранее создали оба типа резервных копий: полную резервную копию сервера и резервную копию состояния системы. Подробные процедуры см. в разделах Выполнение полного восстановления сервера и Выполнение неавторизованного восстановления доменных служб Active Directory.

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

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

HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Выполнить начальную синхронизацию

Создайте запись с типом данных REG_DWORD и значением 0. После полного восстановления леса вы можете сбросить значение этой записи до 1, что требует перезапуска контроллера домена и удержания ролей хозяина операций для успешного выполнения. Входящая и исходящая репликация AD DS с известными партнерами по реплике, прежде чем она объявит себя контроллером домена и начнет предоставлять услуги клиентам. Дополнительные сведения о требованиях к начальной синхронизации см. в статье 305476 базы знаний.

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

Если вы подозреваете, что сбой в масштабах леса был связан со вторжением в сеть или злонамеренной атакой, сбросьте пароли учетных записей для всех административных учетных записей, включая членов групп «Администраторы предприятия», «Администраторы домена», «Администраторы схемы», «Операторы сервера», «Операторы учетных записей» и т. и так далее. Сброс паролей учетной записи администратора необходимо выполнить до установки дополнительных контроллеров домена на следующем этапе восстановления леса.

На первом восстановленном контроллере домена в корневом домене леса захватите все роли хозяина операций на уровне домена и леса. Учетные данные администраторов предприятия и администраторов схемы необходимы для захвата ролей хозяина операций в масштабах леса.

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

Очистите метаданные всех других доступных для записи контроллеров домена в корневом домене леса, которые вы не восстанавливаете из резервной копии (все доступные для записи контроллеры домена в домене, кроме этого первого контроллера домена). Если вы используете версию Active Directory Users and Computers или Active Directory Sites and Services, которая входит в состав Windows Server 2008 или более поздней версии или RSAT для Windows Vista или более поздней версии, очистка метаданных выполняется автоматически при удалении объекта DC. Кроме того, объект сервера и объект компьютера для удаленного контроллера домена также удаляются автоматически. Дополнительные сведения см. в разделе Очистка метаданных удаленных контроллеров домена с возможностью записи.

Очистка метаданных предотвращает возможное дублирование объектов параметров NTDS, если службы AD DS установлены на контроллере домена на другом сайте. Потенциально это также может избавить средство проверки согласованности знаний (KCC) от процесса создания ссылок репликации, когда сами контроллеры домена могут отсутствовать.Более того, в рамках очистки метаданных записи ресурсов DNS локатора контроллеров домена для всех остальных контроллеров домена в домене будут удалены из DNS.

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

Если у вас есть зоны DNS, которые хранятся в доменных службах Active Directory, убедитесь, что локальная служба DNS-сервера установлена и работает на восстановленном контроллере домена. Если этот контроллер домена не был DNS-сервером до сбоя леса, необходимо установить и настроить DNS-сервер.

Если восстановленный контроллер домена работает под управлением Windows Server 2008, вам необходимо установить исправление в статье базы знаний 975654 или временно подключить сервер к изолированной сети, чтобы установить DNS-сервер. Исправление не требуется ни для каких других версий Windows Server.

В корневом домене леса настройте восстановленный контроллер домена с собственным IP-адресом (или петлевым адресом, например 127.0.0.1) в качестве предпочитаемого DNS-сервера. Этот параметр можно настроить в свойствах TCP/IP адаптера локальной сети (LAN). Это первый DNS-сервер в лесу. Дополнительные сведения см. в разделе Настройка TCP/IP для использования DNS.

В каждом дочернем домене настройте восстановленный контроллер домена с IP-адресом первого DNS-сервера в корневом домене леса в качестве предпочитаемого DNS-сервера. Этот параметр можно настроить в свойствах TCP/IP адаптера локальной сети. Дополнительные сведения см. в разделе Настройка TCP/IP для использования DNS.

В зонах _msdcs и DNS домена удалите записи NS для контроллеров домена, которые больше не существуют после очистки метаданных. Проверьте, были ли удалены записи SRV очищенных контроллеров домена. Чтобы ускорить удаление записи DNS SRV, выполните:

Увеличьте значение доступного пула RID на 100 000. Дополнительные сведения см. в разделе Увеличение значения доступных пулов RID. Если у вас есть основания полагать, что увеличение пула RID на 100 000 недостаточно для вашей конкретной ситуации, вам следует определить наименьшее увеличение, которое все еще безопасно использовать. RID — это ограниченный ресурс, который не следует использовать без необходимости.

Если новые участники безопасности были созданы в домене после резервного копирования, которое вы используете для восстановления, эти участники безопасности могут иметь права доступа к определенным объектам. Эти субъекты безопасности больше не существуют после восстановления, так как восстановление было возвращено к резервной копии; однако их права доступа могут по-прежнему существовать. Если доступный пул RID не будет создан после восстановления, новые пользовательские объекты, созданные после восстановления леса, могут получить идентичные идентификаторы безопасности (SID) и иметь доступ к этим объектам, что изначально не предполагалось.

Для иллюстрации рассмотрим пример новой сотрудницы по имени Эми, упомянутой во введении. Пользовательский объект для Amy больше не существует после операции восстановления, поскольку он был создан после резервного копирования, которое использовалось для восстановления домена. Однако любые права доступа, назначенные этому пользовательскому объекту, могут сохраняться после операции восстановления. Если SID для этого пользовательского объекта будет переназначен новому объекту после операции восстановления, новый объект получит эти права доступа.

Отменить текущий пул RID. Текущий пул RID становится недействительным после восстановления состояния системы. Но если восстановление состояния системы не было выполнено, текущий пул RID необходимо аннулировать, чтобы предотвратить повторную выдачу восстановленным контроллером домена RID из пула RID, который был назначен во время создания резервной копии. Дополнительные сведения см. в разделе Аннулирование текущего пула RID.

При первой попытке создать объект с SID после того, как вы аннулируете пул RID, вы получите сообщение об ошибке. Попытка создать объект инициирует запрос на новый пул RID. Повторная попытка операции завершается успешно, так как будет выделен новый пул RID.

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

Два раза сбросьте пароль krbtgt. Дополнительные сведения см. в разделе Сброс пароля krbtgt.

Поскольку история паролей krbtgt состоит из двух паролей, сбросьте пароли дважды, чтобы удалить из истории паролей исходный (предварительно неверный) пароль.

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

Если в лесу несколько доменов, а восстановленный контроллер домена был сервером глобального каталога до сбоя, снимите флажок "Глобальный каталог" в свойствах параметров NTDS, чтобы удалить глобальный каталог из контроллера домена. Исключением из этого правила является распространенный случай леса только с одним доменом.В этом случае удалять глобальный каталог не требуется. Дополнительные сведения см. в разделе Удаление глобального каталога.

При восстановлении глобального каталога из резервной копии, которая является более поздней, чем другие резервные копии, используемые для восстановления контроллеров домена в других доменах, вы можете добавить устаревшие объекты. Рассмотрим следующий пример. В домене A DC1 восстанавливается из резервной копии, созданной в момент времени T1. В домене B DC2 восстанавливается из резервной копии глобального каталога, созданной во время T2. Предположим, что T2 более новый, чем T1, и некоторые объекты были созданы между T1 и T2. После восстановления этих контроллеров домена DC2, который является глобальным каталогом, содержит более новые данные для частичной реплики домена A, чем сам домен A. В этом случае DC2 содержит устаревшие объекты, поскольку эти объекты отсутствуют на DC1.

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

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

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

Настройка службы времени Windows. В корневом домене леса настройте эмулятор основного контроллера домена для синхронизации времени из внешнего источника времени. Дополнительные сведения см. в разделе Настройка службы времени Windows на эмуляторе PDC в корневом домене леса.

Повторно подключите каждый восстановленный контроллер домена с возможностью записи к общей сети

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

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

После проверки присоедините контроллеры домена к рабочей сети и выполните действия, необходимые для проверки работоспособности репликации леса.

Чтобы исправить разрешение имен, создайте записи делегирования DNS и при необходимости настройте переадресацию DNS и корневые ссылки. Запустите repadmin /replsum, чтобы проверить репликацию между контроллерами домена.
Если восстановленные контроллеры домена не являются прямыми партнерами репликации, восстановление репликации будет намного быстрее за счет создания между ними временных объектов соединения.
Чтобы проверить очистку метаданных, запустите Repadmin /viewlist \* для получения списка всех контроллеров домена в лесу. Запустите Nltest /DCList: для получения списка всех контроллеров домена в домене.
Чтобы проверить работоспособность контроллера домена и DNS, запустите DCDiag /v, чтобы сообщить об ошибках на всех контроллерах домена в лесу.

Добавить глобальный каталог на контроллер домена в корневом домене леса

Глобальный каталог необходим по этим и другим причинам:

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

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

Контроллер домена не будет объявлен сервером глобального каталога, пока он не завершит полную синхронизацию всех разделов каталога в лесу. Следовательно, контроллер домена должен быть принудительно реплицирован с каждым из восстановленных контроллеров домена в лесу.

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

HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Продвижение глобального каталога завершено

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

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

Один из способов установить это право — выполнить авторизационное восстановление AD DS, поскольку предпочтительный метод Microsoft для резервного копирования DNS-сервера — выполнение резервного копирования состояния системы. Однако это трудоемкий и сложный процесс, в котором необходимо перезапустить контроллеры домена, чтобы изменения вступили в силу, а также в конечном итоге вам потребуется восстановить реестр, базу данных Active Directory и ряд других компонентов. Это приводит к увеличению времени простоя, что отрицательно сказывается на производительности. К счастью, можно сделать резервную копию вашего DNS-сервера независимо, используя альтернативные методы. Однако вы должны выбрать метод, который соответствует типу резервируемой зоны (т. е. зона, интегрированная с AD, или стандартная зона).

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

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

Резервное копирование с помощью инструмента командной строки DNSCMD.exe:

DNSCMD (Export-DnsServerZone в PowerShell) восстановление занимает несколько минут, чтобы восстановить зону, если в записи были внесены изменения, влияющие на среду, эту команду нельзя использовать для переноса зоны на новый сервер. так как эта команда не создает значения реестра и другие файлы конфигурации, необходимые для правильного функционирования DNS.

Примечание:
1. Команда создает файл, содержащий записи ресурсов для зоны, интегрированной с Active Directory, для устранения неполадок. Резервное копирование состояния системы следует делать через регулярные промежутки времени в качестве отказоустойчивого, чтобы избежать аварийного сценария.

Резервное копирование интегрированной зоны DNS без AD.

Резервное копирование основных и дополнительных зон независимо от состояния системы – довольно простой процесс. Вы можете использовать команду xcopy для резервного копирования всех текстовых файлов зоны на DNS-сервере. Эта команда создаст резервную копию содержимого папки DNS по умолчанию в папке «D:\backups\dns»:

xcopy %systemroot%\system32\dns d:\backups\dns /y

Резервное копирование интегрированной в AD зоны DNS

A) На основе графики:

<р>1. Откройте консоль диспетчера DNS.

<р>2. Разверните сервер, затем щелкните правой кнопкой мыши «Зона прямого просмотра» и выберите «Новая зона».

<р>3. В мастере создания новой зоны нажмите «Далее».

<р>4. В Мастере типов зон выберите Основная зона и снимите флажок Сохранить зону в Active Directory (доступно только в том случае, если DNS-сервер является контроллером домена с возможностью записи)

<р>8. На странице мастера динамического обновления выберите «Не разрешать динамические обновления» и нажмите «Далее».

<р>9. На странице "Завершение работы мастера создания новой зоны" нажмите "Готово".

<р>12. На странице «Изменить тип зоны» убедитесь, что выбрана основная зона, выберите параметр «Сохранить зону в Active Directory» (доступен только в том случае, если DNS-сервер является контроллером домена) и нажмите «ОК».

<р>13. В диалоговом окне DNS нажмите Да, чтобы принять изменение.

<р>15. Наконец, у нас должна быть настроена и работает наша DNS-зона..

B) На основе команды:

Обратите внимание, что файл резервной копии должен находиться в папке %systemroot%\system32\dns, чтобы его можно было правильно обнаружить.

Переключатель /load указывает команде загрузить конфигурацию из существующего файла. Без него команда создаст новый файл данных зоны, который перезапишет содержимое файла резервной копии.

После добавления зоны на DNS-сервер вы можете преобразовать ее в зону, интегрированную с AD, выполнив:

Теперь вы можете включить безопасные динамические обновления для зоны, выполнив:

Эта команда настраивает зону на прием только безопасных динамических обновлений, как указано значением allowupdate, равным 2 (используйте 0, чтобы указать отсутствие динамических обновлений, 1, чтобы указать небезопасные и безопасные динамические обновления).

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

A) Сценарий Power-Shell: резервное копирование зон DNS

B) Сценарий Powershell — как восстановить зоны DNS

Небольшое объяснение восстановления:

Первая часть скрипта используется для определения некоторых переменных. Мы просто определяем, где скрипт должен искать файлы резервных копий и «специальный» текстовый файл с именем input.csv. Этот файл содержит ценную информацию о DNS-зонах, которые вы собираетесь восстановить. Он сообщит сценарию, нужно ли вам восстановить интегрированную зону AD или дополнительную зону….

В средней части мы просто используем команду import-csv для сбора информации, содержащейся в файле input.csv

Заключительная часть сценария анализирует файл input.csv и в зависимости от типа зоны (интегрированная с AD или нет) процедура сценария запускает утилиту командной строки dnscmd с использованием различных параметров в зависимости от необходимого формата зоны. восстановить (первичную, вторичную, заглушку или зоны пересылки)

Заключительные комментарии

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

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

Если в окне браузера пользователя появляется пустое сообщение о том, что «не удается найти DNS-адрес сервера», это сигнализирует об ошибке DNS, требующей вашего немедленного внимания. Отсутствие доступа к Интернету или определенным сайтам может оказать непосредственное негативное влияние на бизнес. Устранение неполадок с DNS может стать головной болью для поставщиков управляемых услуг (MSP), но крайне важно, чтобы они понимали все тонкости DNS и имели готовое решение по мере необходимости.

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

Почему возникает ошибка DNS?

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

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

Основные способы устранения проблем с DNS

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

Проверьте кабели и соединения. Если у вас проводное соединение, убедитесь, что все подключено правильно. Если вы находитесь в беспроводной сети, убедитесь, что ваш Wi-Fi включен и вы подключены. Убедитесь, что маршрутизатор подключен и работает.
Перезагрузите маршрутизатор. Подождите минуту, прежде чем снова включить его, и подождите, пока индикаторы не перестанут мигать, прежде чем пытаться подключиться.
Запустите сканирование на наличие вредоносных программ. В некоторых случаях вирус может блокировать доступ в Интернет. В этом случае у вас могут возникнуть более серьезные проблемы, которые нужно решить, прежде чем решать проблемы IP-подключения.
Проверьте сайт. Если у вас возникли проблемы с доступом к определенному веб-сайту (своему или чужому), убедитесь, что проблема связана с DNS, а не с самим сайтом. Один из способов сделать это — использовать такой веб-сайт, как DownForEveryoneOrJustMe. Точно так же вы можете выполнить команду ping для своего веб-адреса с помощью командной строки. Если он отвечает, это означает, что сайт работает, и вы просто не можете получить к нему доступ, что говорит о том, что проблема действительно связана с вашим DNS. Если результатом проверки связи является "запрос не может найти хост", это означает, что веб-сайт не работает, что не обязательно связано с проблемой DNS.

В чем проблема с DNS?

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

Как исправить DNS-сервер, который не отвечает?

Если ваш DNS-сервер Windows по-прежнему не отвечает, возможно, потребуется более глубокое исследование, чтобы понять ошибки или неверные настройки, которые могут вызывать проблемы. Для этого вам может понадобиться использовать nslookup, инструмент, встроенный в Windows (который обычно используется хакерами для зондирования DNS). Nslookup является неотъемлемой частью различных программных решений, включая удаленный мониторинг и управление SolarWinds, и вы можете использовать команды устранения неполадок DNS nslookup для определения конкретных внутренних или внешних проблем.

Nslookup был одним из первых средств диагностики DNS. Он доступен как в интерактивном, так и в неинтерактивном режимах. Для наших целей, как правило, удобнее интерактивный режим. Чаще всего его можно использовать для подтверждения как вашего IP-адреса, так и адреса DNS-сервера, на котором вы находитесь. Чтобы узнать IP-адрес хоста, введите в командной строке nslookup, а затем укажите свой домен. Скорее всего, это вернет локальный сервер. Чтобы найти авторитетный сервер, установите тип запроса NS и введите доменное имя.

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

Запись A. Записи A — это самые основные данные DNS, которые сопоставляют домен с IP-адресом. Чтобы проверить запись A, используйте команду nslookup, за которой следует домен. Затем вы можете подтвердить, что домен переходит на правильный IP-адрес и наоборот. Запись AAAA аналогична записи A, но для IPv6.
CNAME: CNAME означает каноническое имя. Эта запись используется для указания одного доменного имени на другое доменное имя. (Последнее доменное имя предположительно будет иметь запись A, указывающую на IP-адрес.) Записи CNAME иногда могут вызывать проблемы с электронной почтой. В любом случае убедитесь, что домены указывают на нужные места. Для nslookup используется команда set type=cname, за которой следует ваш домен.
MX: запись почтового обмена (MX) направляет электронную почту из вашего домена на хост-сервер. Если это неверно, это может объяснить, почему у пользователей возникают проблемы с отправкой электронной почты на адреса в вашем домене. Убедитесь, что MX соответствует вашему домену (запись A или AAAA), а не запись CNAME. Это команда «set type=mx», за которой следует ваш домен.

Каковы наиболее распространенные причины проблем с DNS?

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

1) Время жизни (TTL)

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

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

Если вы планируете обновлять записи DNS, перед этим временно уменьшите значение TTL, чтобы пользователи быстро получали обновленные данные. Серверы иногда не распознают TTL менее 30 секунд; пять минут (300 сек.) — типичный короткий TTL.

Как правило, используйте короткие значения TTL для часто обновляемых записей и более длинные значения TTL для более устойчивых записей. Записи, которые редко изменяются и должны иметь более длительный срок жизни в день (86 400 с), включают MX и TXT.

2) Задержка DNS

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

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

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

3) DDOS-атака

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

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

Проблемы с DNS – это лишь один из типов проблем, которые могут прервать работу службы. Нужна помощь не только в устранении неполадок DNS? Прочую информацию по устранению неполадок можно найти в нашем центре ресурсов.

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