Не удалось выгрузить псевдоним корня dns для dn

Обновлено: 03.07.2024

Иногда при установке служб Microsoft Active Directory Domain Services (AD DS) в среде Windows Server 2008 или Server 2008 R2 возникают две проблемы. Одна из них относится к процессу установки; другая связана с рекомендациями компании Microsoft по запуску контроллеров домена (DC) на виртуальных машинах. Эти проблемы известны опытным администраторам. Но начинающим специалистам, которым необходимо заменить операционную систему контроллера домена с Windows Server 2003 на Server 2008 R2, будет очень полезна эта статья, в которой я планирую рассмотреть все возможные трудности и пути их преодоления

Иногда при установке служб Microsoft Active Directory Domain Services (AD DS) в среде Windows Server 2008 или Server 2008 R2 возникают две проблемы. Одна из них относится к процессу установки; другая связана с рекомендациями компании Microsoft по запуску контроллеров домена (DC) на виртуальных машинах.

Эти проблемы известны опытным администраторам. Но начинающим специалистам, которым необходимо заменить операционную систему контроллера домена с Windows Server 2003 на Server 2008 R2, будет очень полезна эта статья, в которой я планирую рассмотреть все возможные трудности и пути их преодоления.

Ошибки, связанные с Adprep

Adprep — утилита для подготовки существующей среды Active Directory (AD) для первого DC, функционирующего с новой операционной системой, например Server 2008 R2. Если все контроллеры домена в среде AD работают с Server 2008 или Windows 2003 и требуется добавить первый DC с операционной системой Server 2008 R2, необходимо выполнить определенные команды Adprep.

  1. Выполните adprep/forestprep на хозяине схемы.
  2. Выполните adprep/domainprep на каждом хозяине инфраструктуры домена.
  3. Если предполагается установить доступный только для чтения DC (RODC — новшество Server 2008), следует также выполнить adprep/rodcprep для каждого домена с RODC.

Этот достаточно простой процесс подробно описан в Интернете, но тем не менее у администраторов часто возникают вопросы:

  • какие именно действия выполняет Adprep?
  • как убедиться, что все необходимые команды Adprep выполнены успешно?
  • как исправлять возникающие ошибки?

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

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

Ошибка делегирования DNS

Ошибка делегирования DNS
Экран 1. Ошибка делегирования DNS

До появления Server 2008 многие проблемы с AD были вызваны внутренними неполадками в инфраструктуре DNS, в частности отсутствующими или неправильными записями делегирования DNS. Одной из целей специалистов Microsoft при совершенствовании установки служб AD DS в Server 2008 было помочь потребителям в начальной настройке правильной инфраструктуры DNS, а затем облегчить обслуживание данной конфигурации.

  • утилита Dcpromo настроена для установки роли DNS-сервера;
  • слишком мало отношений делегирования существует между DNS-серверами и непосредственной родительской зоной DNS и поддоменом, в котором устанавливается новый DC;
  • устанавливаемый DC не может создать делегирование поддомену DNS на DNS-сервере для родительской зоны.

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

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

  • На родительском DNS-сервере должна функционировать служба Microsoft DNS Server.
  • DNS-сервер Microsoft в родительском домене должен быть подключен к сети и доступен с устанавливаемого контроллера домена.
  • Пользователь, запускающий утилиту Dcpromo на устанавливаемом контроллере домена, должен иметь учетные данные Domain Admins, Enterprise Admins или DNS Admin в родительской зоне DNS.

Виртуальные DC и возврат USN

Только поддерживаемые решения резервного копирования, такие как Windows Server Backup, могут быть использованы для восстановления контроллера домена. Недавно компания Microsoft пересмотрела рекомендации по запуску контроллеров домена на виртуальных машинах, в частности объяснено функционирование USN и способы предотвращения возврата USN. Благодаря этим изменениям информация представлена в более краткой и ясной форме, и администраторам будет проще избежать проблем.

Ошибка The Specified User Already Exists

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

  1. Если выполняется замена ранее пониженного DC новым контроллером домена с тем же именем, обязательно удалите метаданные старого DC. В Server 2008 и более новых версиях самый простой способ удаления метаданных — через оснастки AD. При необходимости можно воспользоваться и старым методом — Ntdsutil.
  2. Если по-прежнему происходят сбои Dcpromo с этой ошибкой, выясните в файле dcpromoui.log имя исходного DC (он же вспомогательный DC), используемого новым DC для репликации. Найдите в файле раздел, который начинается с метки A в листинге 2. Имя исходного DC показано во фрагменте с меткой B.
  3. Убедитесь, что исходный DC выполнил входящую репликацию удаления метаданных DC (то есть конфликтующих учетной записи компьютера DC и объектов параметров NTDS). Если учетная запись контроллера домена все еще существует, определите причину:
  • простая задержка репликации; например, DC находится на расстоянии нескольких переходов от DC, запустившего операцию очистки метаданных;
  • сбой входящей репликации на вспомогательном DC или на исходном DC, с которого вспомогательный DC получает изменения;
  • вспомогательный DC в «сайте задержки» преднамеренно настроен на входящую репликацию изменений в AD с задержкой.

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

Таблица 1. Возможные строки расширения ошибок
Возможные строки расширения ошибок

Еще одна распространенная причина сбоя установки AD заключается в том, что группе Administrators не назначено право Enable computer and user accounts to be trusted for delegation («Разрешение доверия к учетным записям компьютеров и пользователей при делегировании»). Это право — параметр групповой политики, включенный для группы Administrators по умолчанию в политике контроллеров домена. Если DC выбран в качестве партнера репликации в ходе повышения уровня реплицируемого DC, выбранному DC требуется доступ к ресурсам повышаемого компьютера. Если право Enable computer and user accounts to be trusted for delegation не назначено группе безопасности Administrators, то каждый запрос доступа к ресурсу завершается неудачей с пояснением «отказано в доступе», как показано на экране 2.

Ошибка «отказано в доступе»
Экран 2. Ошибка «отказано в доступе»

Чтобы устранить ошибку, используйте консоль управления групповой политики (GPMC) и инструмент Group Policy Results (Gpresult) для проверки, назначено ли группе Administrators право Enable computer and user accounts to be trusted for delegation в политике Default Domain Controllers Policy. Путь в редакторе групповой политики — \Computer Configuration\Policies\Windows Settings\SecuritySettings\Local Policies\UserRights Assignment\Enable computer and user accounts to be trusted for delegation.

После того как DC начинает работать с 2008 R2, можно запустить анализатор AD DS Best Practices Analyzer (BPA) для обнаружения любых ошибок в настройках политики. Соответствующее правило BPA не входит в изначальный набор правил, но имеется в дополнительном наборе правил, поставляемом через службу Windows Update. Это правило применяется к DC, работающему с Server 2008 R2.

При запуске AD DS BPA другое правило из того же дополнительного набора поможет предотвратить две типичные ошибки в настройках групповой политики, которые являются коренными причинами отказа репликации DC: непредоставление права Access this computer from the network («Доступ к компьютеру из сети») группам безопасности Administrators, Enterprise Domain Controllers или Authenticated Users либо назначение группам безопасности Enterprise Domain Controllers, Everyone, Administrators или Authenticated Users права Deny access to this computer from network («Запрет доступа к компьютеру из сети»). Отказ может случиться на любом DC, пытающемся выполнить репликацию из DC с одной из упомянутых выше настроек. Пользователи и компьютеры также могут столкнуться с отказами при применении объектов групповой политики (GPO).

Чтобы устранить эту ошибку, убедитесь в анализаторе BPA, что контроллеры домена назначили это право соответствующему участнику безопасности. Используйте настройки GPMC и Gpresult из таблицы 2, чтобы проверить правильность параметров групповой политики.

Таблица 2. Параметры GPMC и Gpresult
Параметры GPMC и Gpresult

Особенности Adprep

Когда в Windows Server 2003 впервые появилось требование выполнения команды adprep/forestprep, компания Microsoft и некоторые партнеры рекомендовали в целях предосторожности изолировать хозяина схемы (например, временно поместить его в отдельную сеть) для лучшего управления процессом обновления схемы. С тех пор специалисты службы поддержки пользователей Microsoft пришли к выводу, что в большинстве компаний такой подход скорее вызывает проблемы, чем устраняет. Поэтому специалисты Microsoft больше не рекомендуют отключать от сети хозяина схемы перед запуском adprep/forestprep.

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

    image


    Внимательный читатель найдет на этой картинке IPv6

    Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.

    Что такое DNS

    DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.

    Базовые штуки

    Давайте взглянем на маппинг между именем и адресом:

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

    Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:

    dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов — AAAA . Давайте взглянем на ответ:

    Тут говорится, что у хоста web01.bugsplat.info. есть один адрес A : 192.241.250.244 . Число 300 это TTL , или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet . Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA's DNS Parameters.

    Оставшаяся часть ответа описывает сам ответ:

    В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес ( 192.168.1.1 ), на какой порт стучался dig ( 53 , DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.

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

    Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig 'у, если бы информация не был закэширована:

    Информация выводится в иерархической последовательности. Помните как dig вставил точку . после хоста, web01.bugsplat.info ? Так вот, точка . это важная деталь, и она означает корень иерархии.

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

    Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS- записи. NS -запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS -записи для вас.

    В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера ( 192.5.5.241 ). Так какой именно корневой сервер это был? Давайте узнаем!

    Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!

    Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.

    Другие типы

    Заметьте, что MX -запись указывает на имя, а не на IP-адрес.

    Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:

    Что не так с CNAME

    Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.

    Запросы к другим серверам

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

    Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .

    Типичные ситуации

    Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.

    Редирект домена на www


    CNAME для Heroku или Github

    С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию.

    Wildcards

    Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info . Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:

    Заключение

    Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:

    Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.

    Какой процесс необходим для настройки среды Windows, чтобы я мог использовать DNS CNAME для ссылок на серверы?

    Я хочу сделать это так, чтобы я мог назвать свои серверы как-то как SRV001, но все еще иметь \\file указатель на этот сервер, поэтому, когда SRV002 заменяет его, мне не нужно обновлять какие-либо ссылки, которые есть у людей, просто обновите DNS CNAME и все будет указывать на новый сервер.

    Мы используем эту технику как документированный теплый режим ожидания . Ты гораздо лучше справился с задокументированием, чем я. Я не знал об опции обратного соединения. И мы уменьшаем наше пространство для атак, не используя netBIOS. Мы также не используем SPN. Спасибо! Для справки, мы ежедневно используем в моей организации общий доступ к файлам Windows с псевдонимами ДНК на серверах 2003 и 2008 годов без необходимости вносить какие-либо из этих изменений. Это просто работает. Следует также отметить, что текст в KB926642 предупреждает, что «безопасность снижается, когда вы отключаете проверку петли проверки подлинности и открываете сервер Windows Server 2003 для атак« человек посередине »(MITM) на NTLM». Большое спасибо. Это работало на Server 2008 R2 с клиентами XP Pro, пытающимися подключиться к общей папке. У меня был 10-летний сервер HP (Server 2000), поэтому я создал виртуальный сервер, восстановил на нем файлы и воссоздал общие ресурсы. Клиенты XP Pro не могли соединиться с ошибками variuos, но я применил вышеупомянутый regedit, перезагрузил компьютер, и все это работает, еще раз спасибо.

    Чтобы упростить схемы аварийного переключения, распространенным методом является использование записей DNS CNAME (псевдонимы DNS) для разных ролей компьютера. Затем вместо того, чтобы изменить имя компьютера в Windows на фактическое имя компьютера, можно переключить запись DNS, чтобы указать на новый хост.

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

    1. Проблема
    2. Решение
      • Разрешение другим машинам использовать общий доступ к файлам через псевдоним DNS (DisableStrictNameChecking)
      • Разрешение серверу компьютера использовать общий доступ к файлам через псевдоним DNS (BackConnectionHostNames)
      • Предоставление возможностей просмотра для нескольких имен NetBIOS (OptionalNames)
      • Зарегистрируйте имена участников службы Kerberos (SPN) для других функций Windows, таких как Печать (setspn)
    3. Рекомендации

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

    Разрешение другим машинам использовать общий доступ к файлам через псевдоним DNS (DisableStrictNameChecking)

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

    Отредактируйте раздел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters и добавьте значение DisableStrictNameChecking типа DWORD, равное 1.

    Отредактируйте раздел реестра (в 2008 R2) HKLM\SYSTEM\CurrentControlSet\Control\Print и добавьте значение DnsOnWire типа DWORD, равное 1

    Разрешение серверу компьютера использовать общий доступ к файлам через псевдоним DNS (BackConnectionHostNames)

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

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

    1. В подраздел реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 добавьте новое значение Multi-String. BackConnectionHostNames
    2. В поле «Значение» введите CNAME или псевдоним DNS, который используется для локальных общих папок на компьютере, и нажмите кнопку ОК.
      • Примечание. Введите каждое имя хоста в отдельной строке.

    Предоставление возможностей просмотра для нескольких имен NetBIOS (OptionalNames)

    Позволяет видеть сетевой псевдоним в списке просмотра сети.

    Зарегистрируйте имена участников службы Kerberos (SPN) для других функций Windows, таких как Печать (setspn)

    ПРИМЕЧАНИЕ: не нужно делать это для работы основных функций, документированных здесь для полноты. У нас была одна ситуация, когда псевдоним DNS не работал, потому что вмешивалась старая запись SPN, поэтому, если другие шаги не работают, проверьте, есть ли какие-либо ошибочные записи SPN.

    Вы должны зарегистрировать имена участников службы (SPN) Kerberos, имя хоста и полное доменное имя (FQDN) для всех новых записей псевдонимов DNS (CNAME). Если вы этого не сделаете, запрос билета Kerberos для записи псевдонима DNS (CNAME) может завершиться с ошибкой и вернуть код ошибки KDC_ERR_S_SPRINCIPAL_UNKNOWN .

    Чтобы просмотреть имена участников-служб Kerberos для новых записей псевдонимов DNS, используйте средство командной строки Setspn ( setspn.exe ). Средство Setspn входит в состав средств поддержки Windows Server 2003. Инструменты поддержки Windows Server 2003 можно установить из папки Support \ Tools на загрузочном диске Windows Server 2003.

    Как использовать инструмент для вывода списка всех записей для имени компьютера:

    Чтобы зарегистрировать имя участника-службы для записей псевдонимов DNS (CNAME), используйте инструмент Setspn со следующим синтаксисом:

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