Делегирование dns сервера windows server 2012 r2

Как настроить DNS сервер в windows server 2012R2-2 часть. Настройка дополнительной зоны. Создание и настройка заглушки.

Обновлено 29.08.2016

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

Настройка dns windows server 2012 r2

Настройку dns windows server 2012 r2 мы начнем с открывания оснастки Диспетчер DNS. Как видите, contoso.com еще пустая.

Как настроить DNS сервер в windows server 2012R2-2 часть--08

Как настроить DNS сервер в windows server 2012R2-2 часть—08

Для этого идем на ваш Контроллер домена, у меня это dc. Выбираем свойства нужной зоны

Как настроить DNS сервер в windows server 2012R2-2 часть--09

Как настроить DNS сервер в windows server 2012R2-2 часть—09

Идем на вкладку сервера имен. Нажимаем Добавить

Как настроить DNS сервер в windows server 2012R2-2 часть--11

Как настроить DNS сервер в windows server 2012R2-2 часть—11

пишем имя нужного сервера, у меня это sccm

Как настроить DNS сервер в windows server 2012R2-2 часть--12

Как настроить DNS сервер в windows server 2012R2-2 часть—12

В итоге у меня получился вот такой список.

Как настроить DNS сервер в windows server 2012R2-2 часть--13

Как настроить DNS сервер в windows server 2012R2-2 часть—13

Дальше идем на вкладку передачи зон и смотрим чтобы стаяла галка Разрешить передачу зон и только на сервера из списка серверов имен.

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

Передача зон, по сути, представляет собой извлечение данных, инициируемое в дополнительных зонах, копирование данных главной зоны, которая сама по себе может быть основной или еще одной дополнительной зоной. Главной зоне необязательно даже быть стандартной по отношению к дополнительной зоне — вы можете отконфигурировать дополнительную зону для основной зоны, интегрированной в Active Directory. К примеру, у вас есть два сайта — один в Нью-Йорке, другой в Лос-Анджелесе, причем каждый сайт принадлежит  отдельному домену Active Directory. В каждом домене можно обеспечить разрешение имен для противоположного домена, не устанавливая новый контроллер домена и не управляя трафиком репликации между двумя сайтами.

Включение передачи зон

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

■ По истечении интервала обновления начальной записи SOA основной зоны.

■ При загрузке дополнительной зоны сервером.

■ В результате изменения конфигурации основной зоны, если эта зона настроена для уведомления дополнительной зоны об обновлениях.

По умолчанию передача для всех зон отключена. Ее нужно включить на вкладке Передача зон (Zone Transfers) окна свойств зоны. Установив флажок разрешения передачи зон, можно выбрать одни из трех параметров передачи.

■ На любой сервер (To Any Server) Этот параметр обеспечивает минимальную безопасность. Поскольку передача зоны представляет собой копирование данных зоны, этот параметр позволяет кому угодно с сетевым доступом к DNS-серверу просмотреть содержимое зоны, включая имена всех серверов и компьютеров с их IP-адресами. Поэтому данный параметр следует  использовать только в частных сетях с высоким уровнем безопасности.

■ Только на серверы, перечисленные на странице серверов зон (Only To ServersListed On The Name Servers Tab) Этот параметр позволяет выполнять передачу зон с записью NS только на те дополнительные DNS-серверы, которые полномочны для данных зон.

■ Только на серверы из этого списка (Only To The Following Servers) Этот параметр позволяет указать список дополнительных серверов, на которые будет выполняться передача зон. Для этих дополнительных серверов не требуется идентификация с помощью записи NS в зоне.

Настройка уведомлений

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

Для настройки уведомлений на вкладке Передача зон (Zone Transfers) щелкните кнопку Уведомить (Notify). Откроется диалоговое окно Уведомление  (Notify), где можно указать дополнительные серверы, которые будут оповещаться при обновлении зоны на локальном главном сервере.

По умолчанию при включении передачи зон все серверы, перечисленные на вкладке Серверы имен (Name Servers), автоматически уведомляются об обновлениях зоны.

Обновление дополнительной зоны вручную

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

Перезагрузка (Reload)

Перезагружается дополнительная зона из локального хранилища.

Передать зону с основного сервера (Transfer From Master)

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

Перезагрузить повторно зону с основного сервера (Reload From Master)

Выполняется передача зоны с главного сервера дополнительной зоны независимо от серийного номера в записи SOA дополнительной зоны.

Выбираем Передать зону с основного сервера

Как настроить DNS сервер в windows server 2012R2-2 часть--14

Как настроить DNS сервер в windows server 2012R2-2 часть—14

Как видим если нажать F5 зона передалась

Как настроить DNS сервер в windows server 2012R2-2 часть--15

Как настроить DNS сервер в windows server 2012R2-2 часть—15

Все записи прилетели, единственное они не редактируемые.

Как настроить DNS сервер в windows server 2012R2-2 часть--16

Как настроить DNS сервер в windows server 2012R2-2 часть—16

Иногда может не получиться, тогда перезапустите службу на сервере DNS где дополнительная зона, сто процентов проканает.

Зона-заглушка

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

Зоны-заглушки можно использовать в следующих целях:

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

Существует два списка DNS-серверов, участвующих в загрузке и поддержке зоны-заглушки:

  • Список главных серверов, из которого DNS-сервер загружает и обновляет зону-заглушку. Главный сервер может быть главным или дополнительным DNS-сервером для зоны. В обоих случаях он будет располагать полным списком DNS-серверов для зоны.
  • Список полномочных DNS-серверов для зоны. Список содержится в зоне-заглушке с использованием записей ресурсов сервера имен (NS).

Создадим зону заглушку или как еще ее называют stub zone.

Щелкаем правым кликом по зоны прямого просмотра и выбираем создать

Как настроить DNS сервер в windows server 2012R2-2 часть--17

Как настроить DNS сервер в windows server 2012R2-2 часть—17

Откроется мастер создания зоны.

Как настроить DNS сервер в windows server 2012R2-2 часть--18

Как настроить DNS сервер в windows server 2012R2-2 часть—18

Выбираем зона заглушка

Как настроить DNS сервер в windows server 2012R2-2 часть--19

Как настроить DNS сервер в windows server 2012R2-2 часть—19

задаем имя зоны

Как настроить DNS сервер в windows server 2012R2-2 часть--20

Как настроить DNS сервер в windows server 2012R2-2 часть—20

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

Как настроить DNS сервер в windows server 2012R2-2 часть--21

Как настроить DNS сервер в windows server 2012R2-2 часть—21

Пишем имя главного dns с которого будем запрашивать зону

Как настроить DNS сервер в windows server 2012R2-2 часть--22

Как настроить DNS сервер в windows server 2012R2-2 часть—22

Готово

Как настроить DNS сервер в windows server 2012R2-2 часть--23

Как настроить DNS сервер в windows server 2012R2-2 часть—23

Видим что файл зоны заглушки лежим в папке windowssystem32dns

Как настроить DNS сервер в windows server 2012R2-2 часть--24

Как настроить DNS сервер в windows server 2012R2-2 часть—24

Файл кстати открывается любым текстовым редактором.

Как настроить DNS сервер в windows server 2012R2-2 часть--25

Как настроить DNS сервер в windows server 2012R2-2 часть—25

Пример зоны-заглушки

Предположим, вы работаете администратором DNS-сервера Dns1.microsoft.com, который уполномочен для зоны Microsoft.com. Ваша компания имеет дочерний домен Active Directory с именем India.microsoft.com, для которого выполняется делегирование. При начальном делегировании дочерняя зона, интегрированная иActive Directory, содержит только два полномочных DNS-сервера — 192.168.2.1 и 192.168.2.2. Позже администраторы домена India.microsoft.com развертывают дополнительные контроллеры домена и устанавливают роль DNS-сервер (DNSServer) на новых контроллерах. Однако администраторы не уведомили вас о том, что добавили полномочные DNS-серверы на свой домен. В результате на сервереDns1.microsoft.com оказались не отконфигурированными записи новых DNS-серверов, уполномоченных для домена lndia.microsoft.com, и запросы продолжают пересылаться лишь на два DNS-сервера, заданный в начальном делегировании.

Эту проблему можно устранить, создав зону-заглушку на сервере Dns1. microsoft.com для домена India.microsoft.com. С помощью новой зоны-заглушки компьютер Dns1 посредством передачи зон изучает новые серверы имен, уполномоченные для родительской зоны India.microsoft.com. Таким образом, сервер Dns1 сможет направлять запросы пространства имен Inclia.microsoft.com на все полномочные DNS-серверы дочерней зоны.

В следующей статье мы поговорим про дополнительные настройки и вкладки DNS сервера windows server 2008R2-2012R2

DNS (Domain Name System, Система Доменных имен) – система, позволяющая преобразовать доменное имя в IP-адрес сервера и наоборот.

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

Как настроить DNS-сервер:

  • Настройка сетевого адаптера для DNS-сервера
  • Установка роли DNS-сервера
  • Создание зоны прямого просмотра
  • Создание зоны обратного просмотра
  • Создание A-записи
  • Описание функции Domain Name System (DNS), которые являются новыми или измененными в Windows Server 2016.

Настройка сетевого адаптера для DNS-сервера

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

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

Проверьте присоединенную сеть

Наведя курсор на значок сети в системном трее, можно вызвать всплывающую подсказку с краткими сведениями о сетях. Из примера выше видно, что присоединённая сеть это Network 3.

Далее предстоит проделать цепочку действий:

  • Нажать правой клавишей мыши Пуск, в выпадающем меню выбрать пункт Сетевые подключения;
  • Правой кнопкой мыши нажать на необходимый сетевой адаптер, в меню выбрать Свойства;
  • В окне свойств выбрать IPv4 и нажать на кнопку Свойства;
  • Заполнить соответствующие поля необходимыми данными:

Вот как наглядно должна выглядеть данная цепочка действий

Здесь в качестве предпочитаемого DNS-сервера машина назначена сама себе, альтернативным назначен dns.google [8.8.8.8].

Установка роли DNS-сервера

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

На верхней навигационной панели Диспетчера сервера справа откройте меню Управление, выберите опцию Добавить Роли и Компоненты:

Нажмите

Откроется окно Мастера, в котором рекомендуют убедиться что:

1. Учётная запись администратора защищена надёжным паролем.

2. Настроены сетевые параметры, такие как статические IP-адреса.

3. Установлены новейшие обновления безопасности из центра обновления Windows.

Убедившись, что все условия выполнены, нажимайте Далее;

Выберите Установку ролей и компонентов и нажмите Далее:

После этого вы перейдете к следующему окну

Выберите необходимы сервер из пула серверов и нажмите Далее:

58_screenshot_15_2

Отметьте чек-боксом роль DNS-сервер и перейдите Далее:

Далее вы перейдете в Роли Сервера

Проверьте список компонентов для установки, подтвердите нажатием кнопки Добавить компоненты:

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

Оставьте список компонентов без изменений, нажмите Далее:

Далее вы перейдете к настройке DNS-сервера

Прочитайте информацию и нажмите Далее:

Анализируем информации и нажимаем далее

В последний раз проверьте конфигурацию установки и подтвердите решение нажатием кнопки Установить:

Подтверждаем

Финальное окно Мастера сообщит, что установка прошла успешно, Мастер установки можно закрыть:

Закрываем мастер установки

Создание зон прямого и обратного просмотра

Доменная зона — совокупность доменных имён в пределах конкретного домена.

Зоны прямого просмотра предназначены для сопоставления доменного имени с IP-адресом.

Зоны обратного просмотра работают в противоположную сторону и сопоставляют IP-адрес с доменным именем.

Создание зон и управление ими осуществляется при помощи Диспетчера DNS.

Перейти к нему можно в правой части верхней навигационной панели, выбрав меню Средства и в выпадающем списке пункт DNS:

Выбираем DNS

Создание зоны прямого просмотра

  • Выделите каталог Зоны Прямого Просмотра, запустите Мастер Создания Новой Зоны с помощью кнопки Новая зона на панели инструментов сверху:

Выбираем Новую зону

  • Откроется окно Мастера с приветствием, нажмите Далее:

Открываем окно мастера и продолжаем

  • Из предложенных вариантов выберите Основная зона и перейдите Далее:

Выбираем Основная зона и продолжаем

  • Укажите имя зоны и нажмите Далее:

Указываем имя зоны и продолжаем

  • При необходимости поменяйте название будущего файла зоны и перейдите Далее:

Меняем название будущего файла зоны

  • Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:

Разрешаем или не разрешаем динамические обновления

  • Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:

Завершаем настройку

Создание зоны обратного просмотра

  • Выделите в Диспетчере DNS каталог Зоны Обратного Просмотра и нажатием кнопки Новая зона на панели инструментов сверху запустите Мастер Создания Новой Зоны:

Создаем новой зоны

  • Выберите тип Основная Зона, перейдите Далее:

Выбираем тип зоны и продолжаем

  • Выберите назначение для адресов IPv4, нажмите Далее:

Выбираем значение адресов Ipv4 и продолжаем

  • Укажите идентификатор сети (первые три октета сетевого адреса) и следуйте Далее:

Указываем идентификатор сети

  • При необходимости поменяйте название будущего файла зоны и перейдите Далее:

Меняем название будущего файла зоны и продолжаем

  • Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:

Выбираем динамические разрешения

  • Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:

Проверяем правильность выбранной конфигурации и завершаем настройку

Создание A-записи

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

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

Запись A — запись, позволяющая по доменному имени узнать IP-адрес.

Запись PTR — запись, обратная A записи.

  • В Диспетчере DNS выберите каталог созданной ранее зоны внутри каталога Зон Прямого Просмотра. В правой части Диспетчера, где отображается содержимое каталогов, правой кнопки мыши вызовите выпадающее меню и запустите команду «Создать узел (A или AAAA)…»:

Создаем узел

  • Откроется окно создания Нового Узла, где понадобится вписать в соответствующие поля имя узла (без доменной части, в качестве доменной части используется название настраиваемой зоны) и IP-адрес. Здесь же имеется чек-бокс Создать соответствующую PTR-запись — чтобы проверить работу обеих зон (прямой и обратной), чек-бокс должен быть активирован:

Вписываем в соответствующие поля имена домена

Если поле имени остается пустым, указанный адрес будет связан с именем доменной зоны.

  • Также можно добавить записи для других серверов:

Добавляем записи для других серверов

  • Добавив все необходимые узлы, нажмите Готово.

Проверка

  • Проверьте изменения в каталогах обеих зон (на примере ниже в обеих зонах появилось по 2 новых записи):

Проверяем изменения в каталоге первой зоны

Проверяем изменения в каталоге второй зоны

  • Откройте командную строку (cmd) или PowerShell и запустите команду nslookup:

Запускаем команду nslook

Из вывода команды видно, что по умолчанию используется DNS-сервер example-2012.com с адресом 10.0.1.6.

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

  • Запрос по домену;
  • Запрос по IP-адресу:

Отправляем запросы для проверки зон

В примере получены подходящие ответы по обоим запросам.

  • Можно попробовать отправить запрос на какой-нибудь внешний ресурс:

Отправляем запрос на внешний ресурс

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

Для сравнения все те же запросы выполнены на сервере, где не были настроены прямая и обратная зоны:

Сравниваем запросы

Здесь машина сама себе назначена предпочитаемым DNS-сервером. Доменное имя DNS-сервера отображается как неопознанное, поскольку нигде нет ресурсных записей для IP-адреса (10.0.1.7). По этой же причине запрос 2 возвращает ошибку (Non-existent domain).

Описание функции Domain Name System (DNS), которые являются новыми или измененными в Windows Server 2016.

В Windows Server 2016 DNS-сервер предлагает обновления в следующих областях:

  • Политики DNS-серверов
  • Ограничение скорости отклика (RRL)
  • Аутентификация именованных объектов на основе DNS (DANE)
  • Поддержка неизвестных записей
  • Корневые подсказки IPv6
  • Доработка поддержки Windows PowerShell

Политики DNS-серверов

Теперь вы сможете использовать:

  • DNS-политики для управления трафиком на основе геолокации
  • Интеллектуальные ответы DNS в зависимости от времени суток, для управления одним DNS-сервером, настроенным для развертывания с разделением
  • Применять фильтры к DNS-запросам и многое другое.

Конкретное описание данных возможностей:

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

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

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

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

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

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

Вы также можете использовать политики DNS для зон DNS, интегрированных с Active Directory.

Ограничение скорости отклика (RRL)

Теперь вы cможете настроить параметры RRL, чтобы контролировать, как отвечать на запросы к DNS-клиенту, когда ваш сервер получает несколько запросов, направленных на одного и того же клиента. Сделав это, вы можете предотвратить отправку атаки типа «Отказ в обслуживании» (Dos) с использованием ваших DNS-серверов.
Например, бот-сеть может отправлять запросы на ваш DNS-сервер, используя в качестве отправителя IP-адрес третьего компьютера. Без RRL ваши DNS-серверы могут отвечать на все запросы, переполняя третий компьютер. При использовании RRL вы можете настроить следующие параметры:

Количество ответов в секунду. Это максимальное количество раз, когда один и тот же ответ дается клиенту в течение одной секунды.

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

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

Скорость утечки. Это то, как часто DNS-сервер отвечает на запрос во время приостановки ответов. Например, если сервер приостанавливает ответы клиенту на 10 секунд, а уровень утечки равен 5, сервер по-прежнему отвечает на один запрос на каждые 5 отправленных запросов. Это позволяет обычным клиентам получать ответы, даже если DNS-сервер применяет ограничение скорости ответов в их подсети или полном доменном имени.

TC rate. Эта функция используется, чтобы сообщить клиенту о попытке соединения с TCP, когда ответы клиенту приостановлены. Например, если скорость TC равна 3, и сервер приостанавливает ответы данному клиенту, сервер выдает запрос на TCP-соединение для каждых 3 полученных запросов. Убедитесь, что значение скорости TC ниже, чем скорость утечки, чтобы дать клиенту возможность подключиться через TCP перед утечкой ответов.

Максимум откликов. Это максимальное количество ответов, которые сервер выдает клиенту, пока ответы приостановлены.

Белые домены. Это список доменов, которые нужно исключить из настроек RRL.

Белые подсети. Это список подсетей, которые необходимо исключить из настроек RRL.

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

Аутентификация именованных объектов на основе DNS (DANE)

Теперь вы сможете использовать поддержку DANE (RFC 6394 и 6698), чтобы указать своим DNS-клиентам, от какого CA они должны ожидать выдачи сертификатов для доменных имен, размещенных на вашем DNS-сервере.
Это предотвращает форму атаки «main in the middle», когда кто-то может повредить кэш DNS и указать DNS-имя на свой собственный IP-адрес.

Поддержка неизвестных записей

«Неизвестная запись» — это RR, формат RDATA которой неизвестен DNS-серверу. Недавно добавленная поддержка неизвестных типов записей (RFC 3597) означает, что вы cvожете добавлять неподдерживаемые типы записей в зоны DNS-сервера Windows в двоичном формате по сети.
Распознаватель кэширования Windows уже имеет возможность обрабатывать неизвестные типы записей. DNS-сервер Windows не выполняет никакой конкретной обработки неизвестных записей, но отправляет их обратно в ответах, если для них получены запросы.

Корневые подсказки IPv6

Корневые подсказки IPV6, опубликованные IANA, были добавлены на DNS-сервер Windows. Запросы имен в Интернете теперь могут использовать корневые серверы IPv6 для разрешения имен.

Доработка поддержки Windows PowerShell

В Windows Server 2016 представлены следующие новые командлеты (cmdlets) и параметры Windows PowerShell:

Add-DnsServerRecursionScope — Этот командлет создает новую область рекурсии на DNS-сервере. Области рекурсии используются политиками DNS для указания списка серверов пересылки, которые будут использоваться в запросе DNS.

Remove-DnsServerRecursionScope — Этот командлет удаляет существующие области рекурсии.

Set-DnsServerRecursionScope — Этот командлет изменяет параметры существующей области рекурсии.

Get-DnsServerRecursionScope — Этот командлет извлекает информацию о существующих областях рекурсии.

Add-DnsServerClientSubnet — Этот командлет удаляет существующие подсети DNS-клиентов.

Set-DnsServerClientSubnet — Этот командлет изменяет параметры существующей подсети DNS-клиента.

Get-DnsServerClientSubnet — Этот командлет извлекает информацию о существующих подсетях DNS-клиентов.

Add-DnsServerQueryResolutionPolicy — Этот командлет создает новую политику разрешения запросов DNS. Политики разрешения запросов DNS используются для указания того, как и следует ли отвечать на запрос на основе различных критериев.

Remove-DnsServerQueryResolutionPolicy — Этот командлет удаляет существующие политики DNS.

Set-DnsServerQueryResolutionPolicy — Этот командлет изменяет параметры существующей политики DNS.

Get-DnsServerQueryResolutionPolicy — Этот командлет извлекает информацию о существующих политиках DNS.

Enable-DnsServerPolicy — Этот командлет включает существующие политики DNS.

Disable-DnsServerPolicy — Этот командлет отключает существующие политики DNS.

Add-DnsServerZoneTransferPolicy — Этот командлет создает новую политику передачи зоны DNS-сервера. Политики передачи зоны DNS определяют, следует ли отклонять или игнорировать передачу зоны на основе различных критериев.

Remove-DnsServerZoneTransferPolicy — Этот командлет удаляет существующие политики передачи зон DNS-сервера.

Set-DnsServerZoneTransferPolicy. — Этот командлет изменяет параметры существующей политики переноса зоны DNS-сервера.

Get-DnsServerResponseRateLimiting — Этот командлет извлекает параметры RRL.

Set-DnsServerResponseRateLimiting — Этот командлет изменяет настройки RRL.

Add-DnsServerResponseRateLimitingExceptionlist — Этот командлет создает список исключений RRL на DNS-сервере.

Get-DnsServerResponseRateLimitingExceptionlist — Этот командлет извлекает списки исключений RRL.

Remove-DnsServerResponseRateLimitingExceptionlist — Этот командлет удаляет существующий список исключений RRL.

Set-DnsServerResponseRateLimitingExceptionlist — Этот командлет изменяет списки исключений RRL.

Add-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

Get-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

Remove-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

Set-DnsServerResourceRecord — Этот командлет был обновлен для поддержки неизвестного типа записи.

С дополнительными сведениями вы можете ознакомится в следующих разделах справочника по командам Windows PowerShell для Windows Server 2016 от Microsoft:
Powershell DNS Server
Powershell DNS Client

Содержание

Понятие роли DNS Server
Установка DNS
Конфигурирование автономного DNS-cepвepa
Интеграция с другими DNS-серверами
Реализация зон для управления пространствами имен
Типы записей
Управление клиентами DNS и преобразованием имен
Система DNS в Active Directory
Автоматическое конфигурирование DNS
Записи SRV и клиенты
Дополнительные компоненты Windows Server 2012 R2
Поддержка преобразования имен DNS на основе Интернета 
Поддержка внешних доменов DNS
Преобразование внешних пространств имен
Администрирование и устранение неполадок с помощью инструментов DNS
Администрирование DNS-cepвepa с помощью консоли управления DNS и PowerShell
Использование NsLookup и DcDiag
Полезные ссылки по устранению неполадок в DNS

Компьютеры взаимодействуют друг с другом с использованием IР-адресов,
либо 1 Pv4, либо 1 Pv6. Тем не менее, большинству людей трудно запомнить
IР-адрес излюбленного веб-сайта или файлового сервера. Людям нравится приме­
нять дружественные текстовые имена. Таким образом, для преобразования этих дру­жественных имен компьютеров в назначенные им I Р-адреса реализуются системы имен. Система доменных имен (Domain Name System — DNS) — это система имен, используемая серверами Windows Server 2012 R2. Система DNS не только помогает пользователям легко идентифицировать устройства, она является обязательной для множества служб, таких как Active Directory, чтобы клиенты и серверы могли взаи­модействовать с контроллерами доменов.
В этой главе вы изучите следующие темы:
• фундаментальные компоненты и процессы DNS;
• конфигурирование DNS для поддержки среды Active Directory;
• управление и устранение неполадок с преобразованием имен DNS для внут­
ренних и внешних имен.

Система DNS существовала на протяжении десятилетий до того, как в Microsoft
разработали свою первую редакцию DNS в Windows NT 4.0. Существует много раз­
новидностей реализаций DNS, которые поддерживают компоненты и процессы, оп­ределяющие DNS. В этом разделе мы раскроем концепции системы доменных имен от Microsoft и покажем, как она применяется в операционных системах Windows.
Система DNS реализована внутри ОС Windows Server 201 2 R2 для управления
преобразованием имен в I Р-адреса. После установки на сервере службе DNS по­
надобится взаимодействовать с другими серверами имен DNS, что достигается с
использованием множества разных методов, таких как переадресация, корневые
подсказки и делегирование. Служба DNS будет также поддерживать базы данных,
называемые зонами, для внутреннего домена Active Directory или других пространств имен. Компьютерам домена необходимо будет опрашивать эту службу DNS, поэто­му вам придется сконфигурировать отдельные компьютеры, чтобы обеспечить эф­фективное и быстрое преобразование имен.
Windows Server 2012 R2 и предыдушие выпуски ОС Windows Server предлагают
встроенную роль DNS Server (DNS-cepвep). Система Windows Server 201 2 R2 DNS
совместима со старыми версиями DNS вплоть до Windows Server 2003; однако вер­сии, более ранние, чем Windows Server 2008, не поддерживают 1Pv6 и функциониру­ют только с адресами IPv4.
Ниже приведена краткая сводка по фундаментальным концепциям DNS, имею­
щим отношение к данной главе.
• Имя хоста (hostname). Это (дружественное) имя компьютера. Согласно стан­
дартам DNS, оно может иметь длину до 255 символов. Имя хоста эквиваflент­
но первому имени компьютера, например, ECOl.
• Пространство имен (namespace). Это имя домена, хотя и не обязательно доме­
на Active Directory. Пространство имен представляет собой логический набор
хостов, обозначенных именем, которое управляется набором серверов имен.
Это эквивалент второго имени компьютера; все они являются частью одного
семейства. Например, Bigfirm. com — пространство имен для хостов в домене
Bigfirm. com.
• Полное имя домена (Fully Qualified Domain Name — FQDN). Ичя FQDN —
это имя хоста, к которому добаrшено пространство имен домена, такое как
ECOl . Bigfirm. com.
• Файл ноsтs. Это текстовый файл, в котором имена хостов статически отоб­
ражаются на IР-адреса. Файл HOSTS расположен в с : windowssystem32
driversetc для стандартных установок Windows Server 2012 R2 и может при­
меняться в качестве простейшей альтернативы DNS-cepвepy для преобразо­
вания имен в небольших средах. Тем не менее, не пытайтесь управлять круп­
ными производственными средами с помощью записей в статическом файле
ноsтs, поскольку это быстро превратится в кошмар администрирования!
• Сервер имен (name server). Это DNS-cepвep, который будет преобразовывать
имена FQDN в IР-адреса. Серверы имен также управляют пространствами
имен для указанных доменов. Они будут обрабатывать запросы для этих про­
странств имен, поступающие от клиентов DNS через сеть.
• Иерархическая структура имен (blerarchical naming stгucture). Пространство имен создано, поэтому левой частью имени является подмножеством правой части
имени, как можно видеть в FQDN. С учетом этого сервера имен могут начи­
нать с правой части имени, а ответы от серверов имен направят его на коррек­
тный сервер имен для заданноrо пространства имен. Например, как показано
на рис. 6. 1 , Ес0 1 . Ecoast . Bigfirm. com является именем FQDN для сервера в домене Ecoast . Bigfirm. com. Данный домен в действительности представ­ляет собой подмножество, или поддомен, находящееся под контролем домена Bigfirm. com. То же самое можно сказать
о Bigfirm. com в отношении имени доме­
на верхнего уровня . com. Достоинство за­
ключается в том, что вы можете запросить
у сервера доменных имен . com, где на­
ходится сервер имен Bigfirm. com. То же
самое можно делать для сервера Ecoast .
Bigfirm. com и т.д. Имя FQDN направля­
ет запрос правильному серверу имен пос­
редством процесса, который называется
рекурсией.
Домен .com
Д о мен Bi g firm.com
+ Рекурсия (recursion). Это управляемый
сервером процесс преобразования имени
FQDN. Если сервер не может распознать
имя FQDN посредством собственной ин-
формации, он отправит запрос другим
Рис. 6.1 . Иерархическое именова-
ние DNS
серверам имен. В процесс рекурсии вовле-
чены корневые серверы и серверы имен доменов. Корневые серверы находят­
ся на верхушке иерархической структуры имен. Корневые серверы содержат
списки серверов имен, которые управляют именами доменов верхнего уровня,
такими как . com, . gov и . edu. Серверы доменов верхнего уровня управля­
ют реестром поддоменов, расположенных в иерархии ниже доменов верхнего
уровня. Например, серверы имен для поддомена Sybex. com зарегистрированы
на серверах домена . com. Н иже описаны действия, которые происходят при
поступлении запроса имени (рис. 6.2).
Корневой («.») DNS-cepвep
DNS-cepвep Sybex.com
www .Sybex.com
DNS-клиент
Рис. 6.2. Процесс рекурсии в DNS

. Клиент DNS запрашивает у DNS-cepвepa имя, подобное www . Sybex . com.
2. Через процесс рекурсии DNS-cepвep запрашивает у корневых серверов сер­
веры имен домена . com.
3. Корневые серверы предостамяют список серверов имен Дll Я домена . com.
4. DNS-cepвep запрашивает у серверов домена . com серверы имен ДllЯ Sybex .
com.
5. Он получает еще один список серверов имен Дll Я домена Sybex. com.
6. DNS-cepвep запрашивает у предоставленных серверов имен FQDN-имя
www. Sybex . com.
7. DNS-cepвep Sybex . com выдает I Р-адрес веб-сервера исходному DNS­
cepвepy.
8. Исходный DNS-cepвep передает IР-адрес клиенту.
9. Располагая этим 1 Р-адресом, клиент подключается к веб-серверу www .
Sybex . com.
• Делеrирование (delegation). Это означает разрешение другому серверу имен
управлять поддоменом заданного пространства имен. Например, серве­
ры имен Bigfirm. com могут делегировать управление пространством имен
Ecoast . Bigfirm. com другому серверу.
• Переадресация (forwarding). Это является альтернативой процессу рекурсии.
Переадресация представляет собой ответвленный запрос к другому серверу
имен внугри сети. Сервер, на который бьша произведена переадресация, полу­
чает ответ и ретранслирует его исходному серверу имен.
• Итерация (iteration). Это управляемый клиентом процесс преобразования име­
ни FQDN. Если клиент получает отрицательный ответ от сервера имен, он бу­
дет запрашивать другой сервер имен.
• Система имен NetBIOS (NetBIOS naming system). Эта унаследованная система
имен использовалась главным образом в старых сетях Microsoft NT 4.0. Тем не
менее, ее процессы по-прежнему являются частью современных операцион­
ных систем Windows, особенно когда применяются компьютеры, входящие не
в домен, а в рабочую группу.
• Записи служб (service records). Записи служб (SRV) представляют собой записи
внутри пространства имен DNS, предназначенные мя преобразования службы
в имя хоста. Они являются неоrьемлемой частью поддержки DNS мя Active
Directory.
• Динамическое обновление DNS (dynamic DNS update). Динамическое обновле­
ние DNS (Dynamic DNS — DDNS) — это процесс, который позволяет кли­
ентам DNS регистрировать свои имена хостов в назначенном пространстве
имен, Т’Jком как DHCP. Это сокращает необходимость ручного ввода записей
администраторами в базы данных серверов имен. Динамическое обновление
DNS является еше одной неотъемлемой частью поддержки DNS для Active
Directory.

Установка DNS

Роль DNS для Windows Server 2012 R2 может быть развернута в нескольких от­личающихся конфиrурациях, зависящих от выбранного сценария. Можно устано­вить автономный DNS-cepвep на компьютере, не присоединенном к домену, или же можно развернуть его либо на серверах-членах домена, либо на серверах, явля­ющихся контроллерами домена Active Directory. Какой бы сценарий не был выбран, установка роли DNS проста. Сначала мы покажем, что понадобится сделать для ручного развертывания DNS на компьютере, не присоединенном к домену, в авто­номной конфиrурации. Затем мы объясним, как автоматически сконфиrурировать DNS для интеграции с Active Directory, чтобы обеспечить гладкое выполнение пре­образования имен внутри среды домена.

Конфигурирование автономного DNS-cepвepa

Самое важное: вы должны выделить серверу, на котором хотите установить
роль DNS, статический IР-адрес, поскольку попадать в движущуюся цель клиенту
DNS будет очень непросто! Если на рабочем столе вы нажмете комбинацию кла­
виш <Ctrl+R>, а затем введете ncpa. cpl и нажмете , откроется окно Network
Connections (Подключения к сети). В этом окне можно щелкнуть правой кнопкой на сетевом адаптере и выбрать в контекстном меню пункт Properties (Свойства), чтобы открыть окно конфигурирования. Если вы дважды щелкнете на элементе lnternet Protocol Version 4 (TCP/1Pv4) (Протокол Интернета версии 4 ((TCP/1Pv4))), откроется
диалоговое окно lnternet Protocol Version 4 (TCP/1Pv4) Properties (Свойства протокола Интернета версии 4 (TCP/1Pv4)). В нем можно назначить статический IР-адрес, как показано на рис. 6.3.
После назначения статического 1 Р-адреса вы должны добавить первичный DNS­
суффикс, такой как Bigf i rm . com, в диалоговом окне Advanced TCP/1Pv4 Settings
(Расширенные настройки TCP/1Pv4), как показано на рис. 6.4.

Добавление первичного DNS-суффикса требуется не всегда. Он модифицируется
автоматически, когда компьютер присоединяется к домену. Если по плану сервер
должен функционировать как часть рабочей группы (в рассматриваемом примере
так и есть), первичный DNS-суффикс необходимо добавить, чтобы другие DNS­
cepвepы могли находить этот сервер внутри структуры DNS, а служба DNS была
корректно сконфигурирована во время установки.
После указания статического IР-адреса и DNS-суффикса на сервере, не при­
соединенном к домену, выполните перечисленные ниже шаги для установки роли DNS.
l . Откройте диспетчер серверов щелкните на элементе Dashboard (Управляющая
панель) и затем щелкните на ссылке Add Roles and Features (Добавить роли и
компоненты),

2. На экране Before You Begin (Прежде чем начать) мастера добавления ролей и
компонентов (Add Roles and Features Wizard) щелкните на кнопке Next (Далее),
чтобы продолжить.
3. На экране Select lnstallation Туре (Выбор типа установки) выберите переклю­
чатель Role-Based or Feature-Based installation (Установка на основе ролей или
на основе компонентов) и щелкните на кнопке Next.
4. На экране Select Destination Server (Выбор сервера назначения) мастера вы­берите переключатель Select а Server from the Server Pool (Выбрать сервер из пула серверов) и удостоверьтесь в том, что ваш сервер отмечен; щелкните на кнопке Next.
5. На экране Select Server Roles (Выбор серверных ролей) мастера отметьте фла­жок возле роли DNS Server (DNS-cepвep) и, если после выбора роли DNS
Server откроется диалоговое окно, щелкните в нем на кнопке Add Features
(Добавить компоненты), как показано на рис. 6.6.
6. На всех последующих экранах щелкайте на кнопке Next, пока не достигнете
экрана Confirm lnstallation Selections (Подтверждение выбранных настроек для
установки). Проверьте, все ли выбранные настройки корректны, и щелкните
на кнопке lnstall (Установить), чтобы начать процесс установки.

7. После завершения установки роли DNS Server щелкните на кнопке Close Закрыть) для закрытия окна мастера.
Установка роли подобным образом приводит к созданию изолированного серве­
ра имен DNS, который взаимодействует только с корневыми серверами Интернета.
Он может поддерживать среду локальной вычислительной сети для преобразова­
ния имен Интернета, но на этом и все. Система доменных имен использует другие серверы имен для преобразования имен по всей структуре DNS. По этой причине вы должны будете сконфигурировать сервер на взаимодействие с другими DNS­ серверами, которые существуют во внутренней сети. Хотя настройка DNS-cepвepa в автономной конфиrурации без присоединения к домену может иметь свои преимущества (вроде его развертывания в средах, где управление многочисленными ста­тическими файлами ноsтs на серверах становится мучительным), действительная мощь системы Windows Server 201 2 R2 DNS проявляется при ее применении с Active Directory.

Интеграция с другими DNS-серверами

В разделе «Понятие роли DNS Server» упоминалось, что существуют разные ме­
тоды для преобразования имен DNS, такие как переадресация, рекурсия, делегиро­
вание и итерация. Эти методы относятся к интеграции с другими DNS-серверами.
Прежде чем начать, вспомните, что итерация по существу управляется клиентом.
Если DNS-cepвep не имеет ответа, клиент перейдет на другой DNS-cepвep. Сервер
или клиент можно настроить только на итерацию, но это не делается по умолчанию
и редко реализуется. Другие три приема — переадресация, рекурсия и делеrирова­
ние — предусматривают взаимодействие запрашиваемого DNS-cepвepa с другими
D N S-серверами.
Рекурсия — это главный процесс, происходящий в Интернете. Запрашиваемый
DNS-cepвep начинает с самого верха и проходит вниз по ссылкам, получаемым от
каждого DNS-cepвepa, с которым он взаимодействует. На серверах Windows DNS
серверы верхнего уровня перечислены на вкладке Root Hiпts (Корневые подсказки)
диалогового окна свойств DNS-cepвepa (рис. 6.7). Это окно можно отобразить в
оснастке DNS Maпagemeпt (Управление DNS), щелкнув правой кнопкой мыши на
значке сервера и выбрав в контекстном меню пункт Properties (Свойства). По умол­
чанию список Name servers (Серверы имен) на вкладке Root Hiпts заполнен «дей­ствующими» DNS-серверами из Интернета.
Roo t hnts resofve queries for zones that do not exist оп the 1оса1 DNS
serve- . lhey are ony used tf furwarders l>.EDU
О. ROOT-SERVERS . NЕТ.
;
; f o rmerly NS. NASA.GOV
Е. ROOT-SERVERS. NЕТ.
3600000
3600000
360000 0
36000 00
360000 0
36000 00
36000 00
36000 00
3600000
3600000
IN NS А. ROOT-SERVERS . NET.
д 198.41.0.4
NS В. ROOT -SERVERS. NET.
д 192 . 228. 79. 201
NS С . ROOT-SERVERS .NЕТ.
д 192. ЗЗ.4.12
NS О. ROOT-SERVERS .NET.
д 126.8.10.90
NS Е . ROOT -SERVERS.NEТ.
А 192.203.230.10
Рис. 6.8. Список корневых подсказок в файле cache . dns

В единственной среде домена Active Directory это можно оставить в том виде, как
есть. DNS-cepвepы могут использовать эти ссылки для распознавания пространств
имен, основанных на Интернете, таких как Sybex . сот, когда клиент их запраши­
вает. В более крупных средах корневые подсказки на других серверах DNS можно
удалить и полагаться на поддержку одного сервера в преобразовании имен DNS из внешней среды. В сущности это мог бы быть кеширующий DNS-cepвep для внут­ренней структуры.
В то время как корневые подсказки управляют запросами, следующими вверх по
иерархической структуре DNS, делегирование управляет запросами, проходящими вниз. В рассматриваемом примере DNS-cepвepaм, которые управляют пространс­твом имен . сот, делегируется контроль над зарегистрированными поддоменами вроде Sybex . сот. Делегирование представляет собой просто список этих серверов.
Таким образом, сервер имен . сот отправляет список серверов имен DNS-cepвepy,
ищущему пространство имен Sybex . сот.
В среде Windows делегирование можно увидеть в действии с множеством доменов Active Directory. При наличии домена Active Directory по имени Bigfirт . сот вы имеете связанное с ним пространство имен DNS под названием Bigfirт. сот. Вы могли бы создать домен Active Directory по имени Ecoast . Bigfirт. сот. Вместо
того чтобы хранить все пространства имен DNS на DNS-cepвepe Bigfirт. сот, вы
можете делегировать пространство имен DNS под названием Ecoast . Bigfirт. сот другому DNS-cepвepy.
На рис. 6.9 такое делегирование демонстрируется в консоли управления
DNS. В DNS-cepвepe по имени осо 1 поддерживается зона прямого просмот­
ра Bigfirт. сот. Поддомен Ecoast, представленный значком с папкой серого
цвета с текстовым файлом поверх него, содержит только запись сервера имен для
ECl . Ecoast . Bigfirт. сот с его I Р-адресом.
Сервер пересылки — это еще один DNS-cepвep для обработки ответвленного за­
проса. Когда серверу не удается преобразовать имя DNS, он может переадресовать
запрос другому DNS-cepвepy, а не проходить по корневым подсказкам.
Во внуrренней среде DNS серверы пересылки могут применяться дЛЯ распознава­
ния других пространств имен. Например, DNS-cepвepy ECl . Ecoast . Bigfirm. com
необходимо распознавать серверы Bigfirm . com и другие пространстоа имен, по­
этому на вкладке Forwarders (Серверы пересылки) окна его свойств указан сервер
пересылки (рис. 6.10).
На рис. 6. 10 обратите внимание на флажок Use root hints if по forwarders are
availaЫe (Использовать корневые подсказки, если нет доступных серверов пересыл­ки). В более крупной среде его можно не отмечать, если необходимо централизовать DNS-запросы, основанные на Интернете. Кроме того, взгляните на текст, касаю­щийся серверов условной пересылки.
Серверы условной пересылки имеют собственный узел в дереве областей внутри
левой панели окна DNS Manager (Диспетчер DNS). Для управления распознава­
нием конкретного пространства имен сервер условной пересылки может направ­
лять запросы определенному серверу. На рис. 6. 1 1 видно, что сервер условной
пересылки был настроен для пространства имен Otherdomain . local. В резуль­
тате любые запросы к этому пространству имен будут передаваться DNS-cepвepy
OSOl . Otherdomain . local.
Серверы условной пересылки создаются путем щелчка правой кнопкой мыши
на папке Conditional Forwarder (Сервер условной пересылки) в консоли управления DNS и выбора в контекстном меню пункта New Conditional Forwarder (Новый сервер условной пересылки). Откроется диалоговое окно New Conditional Forwarder (Новыйсервер условной пересылки), которое предоставит вариант репликации настройки другим контроллерам домена в домене или лесе с использованием разделов каталога приложений Active Directory.
Переадресация также может применяться дЛЯ обработки запросов, основанных
на Интернете, вместо использования корневых подсказок.
Мы предпочитаем поступать так в небольших средах, обслуживаемых поставши­
ком Интернет-услуг посредством кабеля или цифровой абонентской линии (Digital
Subscriber Liпe — DSL). Эти поставщики Интернет-услуг имеют собственные DNS­
cepвepы, которые находятся в конфигурации маршрутизатора. Таким образом, ониуказаны как серверы пересылки во внутренних серверах DNS. Хотя корневые под­сказки и могут работать в такой среде, мы считаем прием с переадресацией более надежным. Вдобавок он ограничивает коммуникации внутреннего DNS-cepвepa за­данным внешним источником.
Интеграция с другими DNS-серверами может завершить конфигурирование
роли DNS. Один DNS-cepвep может получать запросы и затем отправлять их дру­
гим DNS-cepвepaм. После того, как DNS-cepвep получит ответ, он может кеширо­
вать информацию в течение определенного периода времени, который в Windows
Server 2012 R2 по умолчанию установлен равным одному часу. Такая конфигурация
называется сервером только для кеширования. Если сервер предназначен д.11я управле­ния пространством имен, вы должны добавить зоны.

Реализация зон для управления пространствами имен

Зона — это база данных д.11я пространства имен. В И нтернете имеется DNS­
cepвep, который управляет пространством имен Sybex . сот. Если вам необходим
1 Р-адрес для www . s уЬех . сот, то д.11я нахождения ответа этот DNS-cepвep будет
просматривать свою зону (базу данных). Таким образом, д.11 я управления пространс­
твами имен на серверах DNS можно создать зоны.
На серверах Wiпdows DNS существуют зоны четырех типов:
• стандартная основная зона;
• стандартная дополнительная зона;
• зона, интегрированная с Active Directory;
• зона-заглушка.

Зона-заглушка не управляет пространством имен и
больше похожа на сервер условной пересылки. Все типы
зон обсуждаются в последующих разделах.
стандартная основная зона
Серверы имен были спроектированы для централиза­
ции преобразования имен в сети. Первоначально DNS­
cepвep отвечал на запросы, основываясь на своем текс­
товом файле ноsтs. По существу это то, что в Microsoft
называют стандартной основной зоной. Стандартная ос­
новная зона представляет собой текстовый файл, в ко­
тором сервер поддерживает записи для заданного про­
странства имен. Это то, что характеризует реализацию
Windows DNS как стандартную. Характеристика основная
относится к репликации.
Во времена Windows NT существовал один ведущий
контроллер домена, называемый главным контроллером
домена (primary domain controller — РОС), который уп­
равлял всеми операциями записи в свою базу данных. Остальные операции управ­
лялись резервными контроллерами домена (backup domain controller — BDC), кото­рые представляли собой копии только для чтения. В терминах DNS основные зоны означают, что имеется только один хозяин, и им является данный сервер. Другие
DNS-cepвepы могут содержать лишь копии этой зоны, предназначенные только для
чтения; они являются дополнительными зонами.
Рис. б.12.
Создание НОВОЙ ЗОНЫ
Зона создается с помощью мастера новой зоны (New Zone Wizard), который
можно запустить, щелкнув правой кнопкой мыши на папке Forward Lookup Zones
(Зоны прямого просмотра) в диспетчере DNS и выбрав в контекстном меню пункт
New Zone (Новая зона), как показано на рис. 6.12.
Мастер новой зоны запросит перечисленную ниже информацию.
• Пространство имен или имя домена, такое как Primaryzone . local.
• Имя текстового файла, который по умолчанию имеет расширение . dns.
• Возможность динамического обновления DNS. Мы обсудим это в разделе
«Динамическое обновление DNS» далее в главе.
После создания зоны можно просмотреть содержимое текстового файла, кото­
рый хранится в папке c : windowssystem32dns (рис. 6.13). Созданные для при­
меров дополнительные записи CNAME и А находятся в конце файла.
Стандартная дополнительная зона
Стандартная дополнительная зона — это копия только для чтения стандартной
основной зоны или зоны, интегрированной с Active Directory. Репликация выполня­
ется посредством процесса переноса зоны, который конфигурируется через свойс­
тва зоны. На серверах Windows DNS стандартная настройка предусматривает раз­
решение переносов зоны только на зарегистрированные серверы имен этой зоны,
что можно видеть на вкладке Zone Transfers (Переносы зоны), представленной на
рис. 6.14.
Чтобы разрешить репликацию на сервер имен ECl . Ecoast . Bigfirm . com, его
необходимо добавить в список Name servers (Серверы имен) на вкладке Name Servers
(Серверы имен), как показано на рис. 6.15.
Теперь можно запустить мастер New Zone Wizard для создания стандартной до­
полнительной зоны на сервере ECl. Это потребует указания IР-адреса сервера-хо­зяина, у которого может запрашиваться перенос зоны. Он не обязательно должен
быть DNS-cepвepoм со стандартной основной зоной. Результатом будет успеш ный
перенос зоны на ECl (рис. 6.16).
Процесс переноса зоны не отличается особой сложностью. Сервер для основной
зоны отслеживает вносимые им изменения, назначая каждому из них серийный но­мер. Когда сервер для дополнительной зоны контактирует с сервером для основной
зоны, он проверяет этот серийный номер в записи Start of Authority (Начало зоны).
Если серийный номер на сервере для дополнительной зоны не совпадает, значит,
наступил момент для репликации изменений. Это просто текстовый способ заталки­вания информации в базу данных. Ранние версии DNS поддерживали репликацию
AXFR (все переносы зоны), которая означала, что на сервер для дополнительной
зоны реплицировалась вся зона целиком. В результате по линии передавался намно­го больший объем трафика. В Windows DNS поддерживается репликация IXFR (ин­крементные переносы зоны), при которой реплицируются только изменения. Кроме
того, в DNS поддерживается уведомление серверов для дополнительных зон, что со­кращает время ожидания для запуска репликации.

Зона, интегрированная с Active Directory
Зона, интегрированная с Active Directory, является преобладаюшей реализацией
серверов Windows DNS. Присугствие в ее названии Active Directory говорит о многом.
• Во-первых, записи DNS хранятся в базе данных Active Directory, а не в тексто­
вом файле.
• Во-вторых, зоны реплицируются всем другим контроллерам домена Active
Directory в домене, а не посредством процесса переноса зоны.
Поскольку в базе данных Active Directory применяется репликация с нескольки­
ми хозяевами, изменения могуг вноситься в зону DNS на любом контроллере доме­на, и они будуг реплицироваться на другие контроллеры домена. Благодаря интег­рации DNS с Active Directory, связка ролей DNS и контроллера домена становится
нормой. За дополнительными сведениями о процессе репликации обращайтесь в
главу 22.
Подобно стандартным зонам, зона, интегрированная с Active Directory, может
быть создана с помощью мастера New Zопе Wtzard. На экране Zone Туре (Тип зоны)мастера
На экране Active Directory Zone Replication Scope (Область действия репликации зоны Active Directory) мастера (рис. 6.1 8) на выбор предусмотрены четыре опции: науровне леса, на уровне домена, на уровне домена (совместимого с Windows 2000) и
хранение базы данных зоны в указанном специальном разделе каталога приложений
(последняя опция по умолчанию обычно недоступна, но в следующем абзаце мы
объясним, как сделать ее доступной). Первые две опции приводят к размешению
базы данных в автоматически созданном стандартном разделе каталога приложе­
ний: один для леса и один для домена, членом которого является контроллер доме­на. Местоположением, совместимым с Windows 2000, является раздел домена базыданных Active Directory, поэтому база данных зоны будет реплицироваться только контроллерам этого домена.
Если вы хотите создать специальные разделы каталога приложений, такие как
отображаемый в последней опции на рис. 6. 18, то вам придется воспользоваться
либо утилитой DNSCmd, либо командлетом Add-DNSServerDirectoryParti tion
в PowerShell. Оба средства встроены в Windows Server 201 2 R2 и предоставляют
возможность управления указанными типами специальных разделов. В сеансе
PowerShell с разрешениями администратора введите показанную ниже команду, что­бы создать новый раздел каталога приложений для упомянутой ранее зоны, интег­рированной с Active Directory. Имя раздела не обязательно должно совпадать с име­нем зоны; тем не менее, применение того же самого имени способствует лучшему пониманию конфигурации:
C : Usersadministrator . BIGFIRM>Add-DNSServerDirectoryPartition
-Name «adintegratedzone . local»
После того, как новый раздел создан, ему можно назначить зону, интегрирован­
ную с Active Directory (см. рис. 6.18).
Затем также с помощью PowerShell можно сконфигурировать другие контролле­
ры домена для поддержки зоны. Давайте предположим, что на сервере ECl, который является контроллером домена Ecoast . Bigfirm . com, необходимо добавить следу­ющие две зоны Active Directory:
+ зону adintegratedzone . local, которая помещена в собственный раздел ка­
талога приложений;
• зону обратного просмотра для подсети 192.168.0.0, которая помещена в общий
раздел леса.
Для начала добавьте сервер в список на вкладке Name Servers окна свойств жела­
емых зон подобно тому, как было показано на рис. 6.15 ранее в главе.
Затем запустите следующий командлет для вывода доступных разделов на серве­
ре ECl:
C : Usersadministrator . BIGFIRM>Get-DNSServerDirectoryPartition
В выводе можно заметить наличие четырех разделов каталога приложений.
Первый из них — это специальный раздел, созданный недавно, который сервер вовлек в совместное использование. Второй является разделом каталога приложенийдомена, который совместно используется всеми контроллерами домена, отличны­ми от Windows 2000, внутри домена Bigfirm. com. Третий раздел предназначен для домена Ecoast . Bigfirm. сот. Четвертый раздел ориентирован на все контроллеры доменов в рамках леса доменов. Сервер ECl уже вовлечен в совместное использова­ние этих двух разделов.
Использование зон-заглушек для интеграции с другими DNS-серверами
Зона-заглушка — это еще одно усовершенствование, впервые появившееся в
Windows Seiver 2003. В версии Windows Seiver 2012 R2 концепции и функциональ­ность зоны-заглушки не изменились, и по суmеству она представляет собой до­полнительный метод для интеграции с другими DNS-серверами. В зоне-заглушке перечислены только серверы имен для заданного пространства имен. Она не имеет никакого контроля над зоной, так что она указывает только на то, какой сервер мог бы поддерживать преобразование имен для пространства имен. Подобно серверам условной пересылки, зона-заглушка предоставляет ответвленное взаимодействие с авторитетным DNS-cepвepoм. Эти зоны также могут реплицироваться между конт­
роллерами домена.
Мастер New Zone Wiz.ard настраивает зону-заглушку со следующими параметрами:
• тип зоны Stub (Зона-заглушка);
• необязательное хранение в Active Directory с заданным разделом каталога при­ложений;
• пространство имен зоны, такое как Арех. сот;
• DNS-cepвep, который поддерживает это пространство имен.
После создания зоны-заглушки можно просмотреть ее содержимое (рис. 6. 19).
В нем присутствует запись Start of Authority для пространства имен, запись Nam
Seiver (Сервер имен) для пространства имен и запись Host (Хост) для сервера имен.
Использование зон обратного просмотра для увеличения безопасности
Вы можете заметить, что созданные зоны находятся в папке Forward Lookup Zones
(Зоны прямого просмотра) внутри консоли управления DNS. При прямом просмот­
ре клиент предоставляет полное имя домена (FQDN), а DNS-cepвep возвращает IР­
адрес. При обратном просмотре делается противоположное: клиент предоставляет
IР-адрес, а DNS-cepвep возвращает имя FQDN.

Вас может интересовать, мя чего это может потребоваться? Основные причины
связаны с безопасностью. Представьте себе взломшика, который настроил вредонос­
ную службу мя прослушивания DNS-запросов к именам FQDN, начинаюшимся с
www . , внутри сети. Когда эта служба получает запрос, она автоматически отправляет
клиенту поддельный ответ с 1 Р-адресом веб-сервера взлом шика, который загрузит
черви, вирусы, «троянские кони» еще до того, как пользователь узнает, что про­
изошло. Если веб-браузер можно было бы сконфигурировать на выполнение обрат­ного просмотра для предоставленного IР-адреса, то он мог бы сравнивать результат
с запрошенным именем и в случае несовпадения не подключаться к веб-серверу.
В качестве реального примера работы такого обратного просмотра при преобра­
зовании имен можно привести службу SMTP в Windows. Эта служба позволяет вы­
полнять обратный просмотр для подключений к серверу. Серверы SMTP предостав­
ляют при взаимодействии свои доменные имена, а при подключении указывается адрес TCP/IP. Затем может быть выполнен обратный просмотр для проверки, соот­ветствуют ли имена адресам, как должно быть.
Команда NsLookup иллюстрирует использование обратного просмотра. Как по­
казано ниже, эта команда запушена в интерактивном режиме для сервера, который
не имеет записи указателя (PTR) в зоне обратного просмотра. Обратите внимание,
что стандартный сервер обозначен как UnKnown. В этом случае запросы DNS могут быть ненадежными.
C : UsersAdministrator . BFl>Nslookup
De fault Server : UnKnown
Address : 1 92 . 1 6 8 . 0 . 1 0
Если в зоне обратного просмотра создана запись PTR, то вывод команды
NsLookup выглядит гораздо лучше. Легко заметить, что в выводе присутствует имя
сервера:
C : UsersAdministrator . BFl>Nslookup
Default Server: BFl . bigfi rm . com
Address : 1 92 . 1 6 8 . 0 . 1 0
Для корректного конфигурирования зон обратного просмотра внутри сети не­
обходимо понимать, как работает обратное преобразование. Адрес 1Pv4 представля­
ется в десятичной точечной нотаuии с помощью четырех октетов — x.y.w.z. Адрес
1 Pv6 похож, но в нем применяются шестнадuатеричные числа, и их намного боль­ше. В обоих случаях проuесс обратного преобразования один и тот же. DNS-cepвep,получающий запрос, изменяет порядок следования числе в IР-адресе. Таким об­разом, запрос имени FQDN мя IР-адреса x.y.w.z становится z.w.y.x, а в конuе до­бавляется . in-addr . arpa. Затем DNS-cepвep пытается преобразовать FQDN-имя z . w. у . х. in-addr . arpa подобно обычному имени FQDN. Преобразование начина­ется с домена верхнего уровня . arpa и проходит вниз к серверам имен in-addr . ,
при этом каждое десятичное значение становится поддоменом пространства имен справа от него. В небольших средах, которые включают только одну подсеть, эта подсеть мо­жет быть представлена единственной зоной. В рассматриваемом примере подсеть 192. 1 68.0.0 является одной зоной (рис. 6.20). При создании зоны обратного про­смотра мастер New Zone Wuard запрашивает имя подсети.
В более крупных средах, имеющих несколько подсетей, потребуется создать зону
для октета с наибольшим приоритетом, а октеты с меньшими приоритетами долж­ны быть представлены как поддомены или делегированные поддомены. Например,
если крупная организация использует схему частной I Р-адресации 10.0.0.0, то в ней можно создать зону обратного просмотра для доменного имени 1 О . in-addr . arpa.
Когда происходят динамические обновления, поддомены будут автоматичес­
ки создаваться для следующего октета от l до 254, а записи PTR будут заполняться
подпапками структуры. В определенный момент поддомены можно делегировать
другому множеству DNS-cepвepoв, вроде контроJUiеров домена, находящихся внутри сайта, который содержит эти подсети. Затем записи PTR можно зарегистрировать в
соответствующей зоне, представляющей подсеть.
На рис. 6.21 видно, что на сервере BFl была создана зона 10 . in-addr . arpa.
Если нужно, чтобы подсети 10. 1 1.0.0 управлялись другим сервером, понадобится де­легировать 1 1 поддоменов. Это было делегировано серверу ECl. Внутри него дейс­твительная подсеть 10. 1 1 .12.0 также представлена как делегированный поддомен.

На вкладJСе Advanced (Дополнительно) окна свойств DNS-cepвepa имеется несколь­
ко отмеченных флажком, два из которых приведены ниже:
• ЕnаЫе round roЬin (Включить циклический перебор)
• ЕnаЫе netmask ordering ( Включить упорядочение сетевых масок)
Циклический перебор (round rоЬiп). Это прием балансировки сетевой нагрузки (network
load balancing — N LB) «для бедняков». Если вы зарегистрировали несколько записей
хостов с одним и тем же именем, но разными I Р-адресами, то DNS-cepвep будет от­
вечать последовательно с отличающимся I Р-адресом для каждого запроса, начиная с самого меньшего IР-адреса. Хотя такой прием не распределяет клиентскую нагруз­ку равномерно или интеллектуально по доступным хостам, он все же предоставляет возможность некоторой балансировки между серверами.
Упорядочение сеrевых масок (пetmask ordering). Подобно циклическому перебору, при упорядочении сетевых масок используется множество записей хостов с одинаковым именем, но разными IР-адресами. Вместо выбора случайным образом выбирается за­пись, которая определена математически как более близкая. Это делается путем срав­нения подсетей. Такой прием хорош при наличии географически разделенных хостов и клиенту необходимо взаимодействовать с хостом, находящимся в его сети. Таким
образом, когда примен яютс я географически разнесенные серверы, вы должны решить, какой метод лучше избрать. Упорядочение сетевых масок сохранит время отклика на минимальном уровне из-за более короткого маршрута. Циклический перебор более равномерно распределит нагрузку, если клиенты сконцентрированы в одном месте.
Однако эти процессы доступны в случае применения Wmdows Server 20 l 2 R2 с
Windows 7 или Windows 8. Стек TCP/IP для I Pv6 и I Pv4, «когда возможно», будет
выполнять процесс похожий на упорядочение сетевых масок, который называется стандартным выбором адресов. Это значит, что он получает I Р-адреса от DNS-cepвepa и самостоятельно решает, какой из них лучше использовать.
Подобно большинству конфигураций, это можно переопределить с помощью объек­та групповой политики, указанного в следующем параметре реестра:
Hkey_Local_MachineSystemCurrentControlSet
ServicesTcpip ParametersOverrideDefaultAddressSelection
Значение 1 отключает стандартный выбор и разрешает произвольный выбор цикли­ческих серверов NLB.
Увидеть эффект от всего этого можно при использовании циклического перебора
географически ра:щеленных серверов. Например, среда с сайтом для восстановления после аварий может предлагать два сервера, которые выполняют одну и ту же службу,но расположены на разных сайтах. В таком случае для загрузки данных доступны два сервера FГР. DNS-cepвep сконфигурирован на предоставление двух I Р-адресов для одного имени ftp . Bigfirm. сот. Циклический перебор обеспечит последователь­ную обработку записей. Даже когда один из серверов FГР прекращает функциони­рование из-за аварийной ситуации, у клиентов по-прежнему сохранится подключае­мость к ftp. Bigf irm. сот. (Время от времени будет выбираться IР-адрес нерабочегосервера, но после повторного подключения поток данных возобновится.)Тем не менее, если включено упорядочение сетевых масок или стандартный выбор адресов, то клиенты могут никогда не получить IР-адрес функционирующего серве­ра FГР. Выбор будет делать либо DNS-cepвep, либо клиент. Таким образом, этот сце­нарий наталкивает на применение проверенного временем правила: «тестировать,тестировать, тестировать». Проверяйте, какие серверы используются в нормальном сценарии, и что происходит в аварийной ситуации.

Типы записей

Теперь, когда базы данных настроены для извлечения информаuии клиента­
ми, необходимо добавить в них записи. Как упоминалось ранее, Dynamic DNS
(DDNS) — это проuесс, который позволяет DNS-клиентам регистрировать свои
имена хостов в назначенном пространстве имен, таком как DHCP, и это приводит
к добавлению записей для компьютеров Windows внутри среды. Тем не менее, не­
которые записи по-прежнему придется добавлять вручную, равно как и проверять
корректность записей, созданных динамически. Для зоны DNS доступно свыше
25 типов записей. В этом разделе мы рассмотрим наиболее распространенные типы записей в рамках реализации Windows DNS.
Записи хостов и указателей
Записи хостов (А) и указателей (PTR) наиболее распространены в зонах прямого
просмотра и зонах обратного просмотра, соответственно. В записи А указывается
имя хоста компьютера и возвращается !Р-адрес. В записи PTR указывается !Р-адрес
и возвращается имя FQDN. Эти записи может потребоваться создать дnя компьюте­ров, не имеющих доступного протокола обномения DDNS.
записи псевдонимов
Записи псевдонимов (CNAME) создаются для определения второго имени ком­
пьютера. В записи CNAME указывается имя и возвращается имя FQDN, назначен­
ное компьютеру. Эти записи полезны в случае замены сервера с опубликованным
именем, которое клиенты применяют для доступа к приложениям или службам. Безнеобходимости в переконфигурировании после замены клиенты по-прежнему будут иметь доступ через псевдоним.
записи обмена почтой
Записи обмена почтой (mail exchanger — МХ) предназначены для коммуникаций
по протоколу SMTP. Почтовые серверы запрашивают записи МХ пля взаимодейс­
твия с получающим сервером SMTP в данном пространстве имен. Обычно записи
МХ настраиваются во внешней зоне DNS. Тем не менее, для специализированных
приложений они могут потребоваться и внутренне. Записи МХ нужно имя FQDN
сервера SMTP и значение приоритета.
Приоритет помогает определить, с какой записью МХ контактировать сначала,
а с какой впоследствии, если записей несколько. Чем меньше значение, тем выше
приоритет. Запомните это как «приоритет номер один».
Предположим, что у вас есть основной SМТР-сервер и SМТР-сервер типа смарт­
хост (smart host), предназначенный для поддержки получения электронной почты, когда основной сервер недоступен. Вам необходимо создать записи МХ для обоих серверов. Основной SМТР-сервер должен иметь меньшее значение приоритета, чем смарт-хост, например 10 и 20, соответственно. Когда основной SМТР-сервер недо­ступен, взаимодействие производится со смарт-хостом.
Записи служб
Записи служб (SRV) являются «знатным шаманом» для реализаuий Windows
DNS. Без записей SRV рабочие станции и серверы не смогли бы находить контрол­
леры доменов.

Сами по себе записи SRV имеют дело только с пятью значениями.
• Имя службы. Стандартное значение, обычно предваренное символом подчер­
кивания, такое как _gc или _ ladp. Оно является эквивалентом имени хоста и
будет присоединено к имени FQDN службы.
• Имя FQDN сервера. Сервер, который предоставляет службу.
• Порт. Порт ТСР или UDP, на котором доступна служба. Протокол обозначает­
ся своим зарегистрированным именем, например, _ ТСР.
• Приоритет. Работает точно так же, как в записях МХ — имеет «приоритет но­
мер один».
• Вес. Используется для разрешения конфликтов с приоритетами. Оставьте его
равным О, если вас это не заботит.
Вы обнаружите изобилие записей SRV в зоне Windows DNS, которая поддерживает
Active Directory. Они находятся в папках поддоменов, поскольку именам служб назна­чаются разные имена FQDN. Запрашиваемая служба описывается с помощью имени
FQDN наподобие _gс . tcp .Ьigfirrn. corn. Записи SRУ можно видеть на рис.
Записи начала зон
Запись начала зоны (Start of Authority — SOA) в единственном экземпляре при­
сутствует в каждой зоне. Она определяет информацию о том, какой DNS-cepвep уп­
равляет этой зоной, а также параметры, касающиеся того, каким образом трактовать
распознанные записи. Запись SOA содержит несколько значений, которые не долж­ны изменяться при редактировании записи. Редактирование производится на вклад­ке Start of Authority (SOA) (Запись начала зоны (SOA)) в окне свойств зоны (рис. 6.23).
Ниже описаны поля, находящиеся на вкладке Start of Authority (SOA).
• Serial Number (Серийный номер). Номер ревизии файла зоны. На самом деле
он имеет значение для стандартных основных зон, т.к. репликация Active
Directory поддерживает собственный серийный номер. Дополнительные зоны
могут сравнивать с ним свои номера, чтобы выяснять, актуальна ли информа­
ция в них. Если информация не актуальна, необходим перенос зоны.

• Primary Server (Основной сервер). Сервер, на котором зона была изначально
настроена. Если вы хотите изменить способ обновления зон в среде посредс­
твом репликации, можете переключать основной сервер на дополнительный
сервер и наоборот.
• ResponsiЫe Person (Ответственное лицо). Предположительно это должен быть
адрес электронной почты лица, администрирующего зону. Обратите внимание,
что символ @ заменяется точкой ( . ). Если хотите кого-то по-настоящему свес­
ти с ума, можете указать здесь его электронный адрес.
• Refresh lnterval (Интервал обновления). Период времени, в течение которого
дополнительный сервер может ожидать до того, как начнет попытки прове­
рить наличие изменений на основном сервере. В этот момент он сравнивает
серийный номер из записи SOA со своим номером. По умолчанию интервал
обновления составляет 1 5 минут. Внутри самой записи это значение указыва­
ется в секундах.
• Retry lnterval (Интервал повтора). Период времени, в течение которого допол­
нительный сервер ожидает до того, как повторить попытку после отказавшего
переноса зоны. По умолчанию интервал повтора составляет 10 минут и также
внутри самой записи указывается в секундах.
• Expires After (Истекает после). Период времени, в течение которого дополни­
тельный сервер может продолжать отвечать на запросы в этой зоне после того,
как перенос зоны был выполнен. По умолчанию составляет один день. Внутри
самой записи это значение также указывается в секундах и равно 86 400.
• Minimum (Detault) TTL (Минимальное (стандартное) время ТТL). Период време­
ни, в течение которого запись должна находиться в кеше или, другими слова­
ми, значение времени существования (Time То Live — ТТL). По умолчанию
составляет один час, или 3 600 секунд.

записи серверов имен
Записи серверов имен (NS) перечисляют серверы, которые могут отвечать на за­
просы для этой зоны. В зоне должна присутствовать, по меньшей мере, одна такаязапись. Подобно записи SOA, запись NS модифицируется на вкладке Name Servers(Серверы имен) окна свойств зоны, которая была показана ранее на рис. 6.15.Единственным обязательным значением в записи NS является имя FQDN сервера.В нижней части вкладке Name Servers вы заметите короткое примечание, указываю­щее на то, что 1 Р-адрес представляет собой извлеченное значение.

Управление клиентами DNS и преобразованием имен

Вы можете прийти к выводу, что каждый компьютер является клиентом DNS.
Служба DNS — это жизненно важный компонент сети, даже если Active Directory не входит в ее состав. Вдобавок он представляет собой единственный метод для пере­хода на ваши избранные веб-сайты в И нтернете, такие как www . Sybex . сот.
В операционных системах Windows есть две области, касающиеся клиентов DNS:
преобразование имен хостов и регистрация имен хостов и I Р-адресов через динами­
ческие обновления DNS.
Преобразование имен хостов
Процесс преобразования имен на компьютере Windows делится на две части.
Данный процесс настолько важен, что мы будет называть его «жизненным циклом».
Одной частью, которая близка к исчезновению, является NetBIOS, в друтой — DNS.
(Вы могли бы назвать ее процессом имени хоста, но большинство администраторов
называют его DNS.) Этот цикл состоит из набора шагов, которые компьютер дол­
жен предпринять для преобразования заданного имени (рис. 6.24).
Преобразование имен NetBios,__-+- —
Ретрансляция
Поиск в DNS
Поиск вWINS
Файл HOSTS
Файл LMHOSТS
Преобразование (имен хостов) DNS

Процесс NetBIOS предусматривает выполнение следующих шагов.
1 . Ретрансляция имени в сети и ожидание, ответит ли кто.
2. Поиск имени в WNS.
3. Поиск имени в файле LMHOSTS. Это еще один текстовый файл, аналогич­
ный файлу ноsтs, который находится в том же самом месте: с : windows
system32 drivers etc. Вместо имен хостов в нем перечислены имена
NetBIOS.
Порядок следования первых двух шагов можно изменять, особенно через сервер
DHCP. Шаг с ретрансляuией или шаг с поиском в WINS может быть опущен. По
умолчанию в Windows Server 2012 R2 сначала производится поиск имени посред­
ством WINS, а затем с помощью ретрансляции. Однако поиск в файле LMHOSTS
всегда выполняется последним.
Список шагов для процесса DNS короче.
1. Поиск имени в файле HOSTS.
2. Поиск имени в DNS.
Порядок следования шагов в процессе DNS настройке не поддается, но можно
изменить поведение просмотра DNS. С тем, что поиск имени сначала производится
в файле ноsтs, связаны как положительные, так и отрицательные моменты. Если
получить доступ к DNS-cepвepy невозможно или требуется переадресовать преобра­
зование имени в другое место, то редактирование файла ноsтs дает замечательные
результаты. Если же файл ноsтs содержит устаревшие или вредоносные записи, то
устранение неполадок DNS может оказаться затруднительным.
Процесс преобразования имен циркулирует по обеим частям до тех пор, пока не
будет получен IР-адрес. Кроме того, имеется выбор с чего начинать — NetBIOS или
DNS. В основном это зависит от приложения. Старые унаследованные приложения
Windows рассматривают имя как относящееся к NetBIOS. Приложения, основанные
на TCP/IP, считают его именем хоста. Это влияет на способ преобразования имен и является частью операционных систем Windows.
Примерами могут служить команды net view и ping.
Комама net view существует со времен LAN Manager, когда все полагалось uе­
ликом на NetBIOS. Если вы попытаетесь подключиться к серверу с применением
указанной команды, то увидите, что имя сервера заносится в кеш имен NetBIOS.
Содержимое этого кеша можно отобразить с помощью команды nЬtstat — с . Для
очистки кеша предназначена команда nbtstat -R.
rem Просмотр кеша имен NetBios
С: Users Adrnini strator . BFl >nhtstat -с
Local Area Connection :
Node IpAddress : [ 1 92 . 1 68 . 0 . 1 0 ] Scope Id: [ ]
No names in cache
rem Доступ к общим ресурсам на сервере Ьfscl
С: UsersAdrninistra�or . BFl>net view Ьfscl
Shared resources at \bfscl
Share name Туре Used as Comment
NETLOGON Disk Logon server share
SALES Disk
SYSVOL Disk Logon server share
Users Disk
The command completed success fully .
rem Повторный просмос>р кеша имен NetBios
С : UsersAdminis trator. BFl>nЬtstat -с
Local Area Connection :
Node IpAddress : ( 1 92 . 1 68 . 0 . 10 ] Scope I d : [ ]
NetBIOS Remote Cache Name ТаЫе
Name Туре
Host Address
BFSCl UNIQUE 1 92 . 1 68 . 0 . 1 1
ГЛАВА 6
Life [ sec]
6 0 0
При пинговании сервера используется проuесс DNS, т.к. команда ping являет­
ся утилитой ТСР /1 Р. Вы можете убедиться, что эта утилита распознает сервер че­
рез DNS, отобразив содержимое кеша DNS с применением команды ipconfig
/di splaydns. Кеш DNS очищается с помощью команды ipconfig / flushdns.
rem Очистка кеша DNS
С : Users Administrator . BFl>ipconfiq /flushdns
Windows I P Configuration
Success fully flushed the DNS Resolver Cache .
С : Users Administrator. BFl>pin9 BFSCl
Pinging BFSCl . bigfirm . com [ 1 92 . 1 68 . 0 . 1 1 ] with 32 bytes o f data :
Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 time Reply from 192 . 1 68 . 0 . 1 1 : bytes=32 time Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 time< lms TTL=128
Reply from 1 92 . 1 68 . 0 . 1 1 : bytes=32 timeipconfiq /displaydns
Nindows I P Con figuration
BFSCl
Record Name .
Record Туре .
Time То Live
Data Length .
Section . . .
А ( Host ) Record .
BFSCl . bigfirm . com
1
1 1 8 5
4
Answer
1 92 . 1 68 . 0 . 1 1
Такие сведения помогают решить, каким образом поддерживать проuесс преоб­
разования имен DNS для клиентов и устранить либо поддерживать (при необходи­
мости) имена NetBIOS. Проuесс NetBJOS потребляет излишние uиклы ЦП. В слу­
чае корректной конфигурации сервера и клиентов DNS поддержку преобразования
имен NetBIOS можно отключить или, по крайней мере, свести к минимуму.
Конфигурирование клиентов
Конфигураuии DNS и NetBIOS можно просмотреть в окне свойств протокола IP
для сетевого подключения. Конфигурация NetBIOS находится на вкладке WINS. На
рис. 6.25 показана вкладка WINS со стандартными настройками.

По умолчанию включен поиск в файле LMHOSTS и выбрано использование на­
строек NetBTOS из сервера DHCP. По умолчанию файл LMHOSTS пуст. Было бы не­
плохо отключить поиск в этом файле, поскольку вредоносное ПО могло в прошлом
занести в него данные.
Настройки NetBIOS получаются от сервера DHCP. Области видимости сервера
DHCP имеют опцию под названием NBT Node Туре (046) (Тип узла NBT (046)). Эта
настройка предписывает первые два шага проuесса NetBIOS в жизненном uикле.
Четыре опuии задаются десятичным значением:
• только ретрансляция: «Ь-узел», 1
• только обращение к WINS: «р-узел», 2
• сначала ретрансляция, а затем обращение к WINS: «m-узел», 4
• обращение к WINS, а затем ретрансляция: «h-узел», 8
Н-узел лучше всего подходит для сети, полагающейся на NetВIOS, т.к. он сокра­
щает объем обмена в среде, поддерживающей WINS. При отсутствии доступных сер­
веров WINS компьютер может, по крайней мере, получить какой-то ответ в подсети,
например, дома или в рабочей группе. Если сервер DHCP не сконфигурирован с этим значением, применяется стандартная конфигурация, установленная в ОС. В Windows Server 2012 R2 по умолчанию используется h-узел, т.е. rибридный (hybrid) режим.
Дrtя сред Active Directory лучше отключать NetBIOS, поскольку это сокращает объ­
ем дополнительного обмена и количество процессов. Кроме тоrо, это помогает снизить
угрозы безопасности со стороны ботов, которые ищут в сетях компьютеры с целью
атаки с применением данной системы имен. Однако прежде чем отключать NetBIOS,
удостоверьтесь в отсутствии слабых мест в системе преобразования имен DNS.
Конфигурация клиента DNS находится на вкладке DNS окна свойств сети, по­
казанной на рис. 6.26. Вполне очевидно, что обязательным является IР-адрес DNS­ cepвepa. Подключение должно осуществляться к ближайшему серверу, как правило,
на контроллере домена внутри локального сайта. Рекомендуется указать также до­полнительный DNS-cepвep.
Advanced TCP/IP Settings

Средняя часть вкладки DNS имеет отношение к неполным именам. Это имя хос­
та без его «второго имени», суффикса DNS (такого как BFSCl, используемого ра­
нее в примере команды ping). DNS-cepвepy необходимо имя FQDN, поэтому пе­
ред отправкой запроса клиент DNS добавляет суффиксы DNS, т.е. «второе имя».
Основной суффикс DNS отображается на странице System (Система) панели уп­
равления, в области Computer Name (Имя компьютера). Он управляется автомати­
чески ОС, когда компьютер присоединяется к домену, поэтому заботиться об этом
суффиксе не придется. Дополнительные суффиксы могут понадобиться в крупных
средах, но для сред с одним доменом стандартных настроек вполне достаточно.
Добавлять суффикс DNS подключения нужно только в редких случаях.
Все это становится спорным в случае регулярного применения имен FQDN.
Используйте имена FQDN серверов при конфигурировании приложений, папок
или переадресации папок, равно как при написании сценариев, которые подклю­
чают сетевые диски. Уловили смысл? Вдобавок применение имен FQDN обходит
процесс NetBIOS. Приложения могут определить разницу между именами NetBIOS
и FQDN и прибегнуть к DNS, когда они распознают FQDN.

динамическое обновление DNS

Чтобы сделать процесс преобразования имен DNS надежным, понадобится пе­
речислить все компьютеры в зонах DNS. В прошлом система DNS требовала от
системных администраторов работы в полную смену, т.к. нужно было вводить пос­тоянно растущее количество записей для их сети. Для сокращения объема работы системных администраторов в Microsoft при создании ОС Windows NT нашли ди­намическое решение через WINS и затем перешли на DNS, когда стал доступным протокол обновлений Dynamic DNS (DDNS). Сам процесс довольно прост.
1. Клиент запрашивает запись SOA мя пространства имен с основным суффик­
сом DNS. Это сообщит, может ли сервер принимать DDNS. То же самое дела­
ется для зоны обратного просмотра, с которой связан 1 Р-адрес сервера.
2. Клиент отправляет запрос DDNS этому серверу.
В записях Start of Authority стандартных зон указан основной сервер. В зонах,
интегрированных с Active Directory, контроллер домена, получающий запрос, моди­
фицирует запись SOA с таким именем. Поскольку он может изменять содержимое
базы данных Active Directory, нет нужды выискивать контроллер домена, находя­
шийся где-то в другом месте. Если процесс обновления терпит неудачу, производит­ся поиск других серверов имен для выполнения обновлений.
На вкладке DNS с протоколом обновлений DDNS связаны два флажка в самом
низу (см. рис. 6.26). Имеется возможность зарегистрировать имя с основным суффик­сом DNS или с суффиксом подключения. Второй флажок по умолчанию не отмечен.
Странно то, что служба клиента DNS не выполняет обновления DDNS. Это де­
лает служба клиента DHCP. Это напоминает нам богатый событиями день, когда
один из нас отключил службу клиента DHCP на контроллере домена. Он наивно
полагал, что эта служба не нужна, т.к. имеется статический IР-адрес. Как уже упо­миналось, �процесс DDNS используется контроллерами домена с целью предостав­ления записей SRV для Active Directory. В конечном итоге клиенты не смогли найти контроллер домена, т.к. для него не было никаких записей SRY. К счастью, все это происходило в испытательной среде.
Существуют еше два места, где производится управление процессом DDNS: зона
для пространства имен и сервер DHCP.
Зона DNS может быть включена для обновлений DDNS в мастере New Zone
Wizard или же путем изменения свойств зоны. На рис. 6.27 показаны опции для об­новлений DDNS — только безопасные, безопасные и небезопасные, а также пол­
ное отключение обновлений. Безопасные динамические обновления означают, что до их выполнения клиент DNS проходит аутентификацию на контроллере домена. Небезопасные динамические обновления означают, что они принимаются без аутен­тификации. Учитывая название, вы легко можете предположить, что злоумышлен­ники способны воспользоваться этой опцией. В случае отключения никакие обнов­
ления DDNS поступать не будут.
Сервер DHCP также может участвовать в процессе DDNS. В самых ранних вер­
сиях Windows Server было много клиентов Windows, которые не обладали возмож­
ностями DDNS. Для решения этой проблемы сервер DHCP идентифицирует такие
ОС и выполняет мя них обновления. Кроме того, сервер DHCP может выполнять
обновления по запросу. На рис. 6.28 приведена вкладка DNS окна свойств 1 Pv4 для сервера DHCP.
Здесь показаны стандартные настройки, которые редко изменяются. В сущности,
сервер DHCP не выполняет никаких обновлений, поскольку клиенты делают это
самостоятельно. Сервер DHCP производит очистку, когда истекает срок аренды.
Защита имен, включаемая за счет отметки флажка в окне, открывающемся по щелч­ку на кнопке Configure (Конфигурировать) в области Name Protectioп (Защита имен),предотврашает обновление сервером DHCP существуюшей записи DNS.

Система DNS в Active Directorv

В Microsoft настолько тесно интегрировали DNS и Active Directory, что обсуж­
дать их по отдельности довольно трудно. Во время создания среды Active Directory с Windows Server 2012 R2 проuесс установки Active Directory автоматически конфигу­рирует DNS при добавлении роли. Это освобождает спеuиалистов по 1Т от ручной настройки DNS.
В последующих разделах мы раскроем способ, которым Active Directory конфиrу­
рирует систему DNS и применяет ее для поддержки клиентов. За дополнительными
сведениями о терминах и конuепuиях Active Directory обращайтесь в главу 7.

Автоматическое конфигурирование DNS

ОС Windows Server 2012 R2 предлагает два способа установки службы DNS: до­
бавление роли DNS самой по себе (как было показано ранее для автономной кон­
фигурации, не присоединенной к домену) или добавление роли Active Directory
Domain Services (Службы домена Active Directory). В случае выбора второго спо­
соба вы должны запустить мастер установки служб домена Active Directory (Active
Diгectory Domain Services lnstalation Wizard), который проведет ряд настроек для
роли Active Directory Domain Services, включая автоматическое конфигурирование
и интеграцию с ролью DNS. В главе 7 процесс установки Active Directory будет рас­
смотрен во всех деталях, а здесь мы лишь посмотрим, что произоЙдет с ролью DNS.
Первым делом вы должны понять предварительные условия, которые должны
быть удовлетворены для проведения установки Active Directory. Будущему конт­
роллеру домена необходима возможность подключения к существующей структуре
Active Directory DNS. В противном случае нельзя будет подключиться к контрол­
лерам домена и получить нужную информацию. Таким образом, в настройках IР­
адресов должен быть указан DNS-cepвep внутри среды Active Directory, желательно
DNS-cepвep корня леса или DNS-cepвep в том же самом домене, к которому пла­
нируется присоединение. Единственным исключением является ситуация, когда со­здается самый первый контроJVIер домена в среде Active Directory. В этот момент нет
никакой структуры Active Directory DNS, на которую можно было бы указывать.
Во время выполнения мастера Active Directory Domain Services конфигурируется
новый контроллер домена. В зависимости от опций, выбранных в мастере, может
быть создан новый контроллер домена. В любом случае служба DNS и соответству­
ющие настройки конфигурируются автоматически. В среду вносятся описанные да­лее изменения.
Создание разделов каталога приложений
Разделы каталога приложений — это граниuы внутри базы дан ных Active
Directory, которые создаются для совместного использования зон DNS разными до­
менами при создании нового домена или леса.
Раздел Doma inDNSZones . doma in . name создается для контроллеров домена
внутри домена. Раздел ForestDNSZones . domain . name создается для совместного
использования контроллерами домена в рамках леса Active Directory.
Если вы снова взглянете на рис. 6.9, то заметите, что поддомен msdcs .
Ьigfirm . com делегирован подобно Ecoast. Он делегирован на тот же самый конт­
роллер домена, в рассматриваемом случае это DCOl . Bigfirm. com.
Зона _msdcs . Bigfirm . com создается в разделе ForestDNSZone . Bigfirm . com
каталога приложений. Это позволяет данной порции пространства имен реплициро­ваться на все домены внутри леса.
После создания дополнительных контроллеров доменов они автоматически по­
являются в этих разделах каталога приложений.
Добавление сервера пересылки
Сервер пересылки можно добавить, просмотреть и сконфигурировать на вкладке
Forwarders (Серверы пересылки) окна свойств DNS-cepвepa. Обычно это будет IР­
адрес исходного DNS-cepвepa, которым пользовался данный сервер.
Изменение /Р -адреса
Новый контроллер домена, созданный мастером Active Directory Domain Services
Wizard, также является новым DNS-cepвepoм. Адрес основного DNS-cepвepa кон­
фигурируется на I Р-адреса обратной связи ::1 (для 1Pv6) и 127.0.0. 1 (для 1Pv4).
делегирование поддомена
Дочерний домен имеет имя, являющееся поддоменом внутри существующе­
го пространства имен домена. Например, Ecoast . Bigfirrn . corn — это поддомен
в пространстве имен Bigfirrn . corn. В результате работы мастера Active Directory
Domain Services Wizard пространство имен нового домена будет поддерживаться в
новом контроллере домена в виде делегированного поддомена.
В родительском домене поддомен вроде Ecoast . Bigfirrn. corn делегируется но­
вому контроллеру домена. Делегирование свяжет родительский и дочерний домены дпя преобразования имен. Это иллюстрировалось ранее на рис. 6.9.
дополнительные рекомендации по конфигурированию
После создания контроллера домена мы рекомендуем внести в настройки DNS
перечисленные ниже изменения.
1 . В свойствах ТСР /1 Pv4 сетевого адаптера измените основной DNS-cepвep на 1 Р­
адрес основного сетевого подключения. Например, если IР-адресом сервера яв­
ляется 192.168.0. l, его понадобится указать в качестве основного DNS-cepвepa.
При поиске и устранении неполадок в DNS с помощью утилиты NsLookup ад­
рес обратной связи ( 1 27.0.0. 1) указывается как «неавторитетный». Мы нахо­
дим результаты применения адреса обратной связи несколько ненадежными,
поэтому лучше придерживаться основного I Р-адреса.
2. Создайте зоны обратного просмотра в разделе ForestDNSZones . dornain . name каталога приложений.Зону обратного просмотра для подсетей может потребоваться совместно ис­пользовать в контроллерах различных доменов.
3. Создайте зону-заглушку для новых деревьев доменов на корневом DNS­
cepвepe.
Дерево домена имеет имя, отличающееся от имени корневого DNS-cepвepa.
Поскольку запись об исходном DNS-cepвepe указана как сервер пересылки,
подобно поднятиям других контроллеров домена, этот DNS-cepвep может
взаимодействовать с остальной структурой Active Directory DNS. Тем не ме­
нее, для остальной структуры Active Directory DNS никакого автоматического
конфигурирования для преобразования имен в новом пространстве имен не
предусмотрено. Например, нам придется настроить сервер условной пересыл­
ки или зону-заглушку, чтобы нацелить DNS-cepвepы на новый контроллер до­
мена для Арех. сот. На рис. 6. 19 демонстрируется применение зоны-заглушки
для содействия преобразования имен FQDN домена Арех . com.

Записи SRV и клиенты

Глядя на зону DNS нового домена, вы заметите наличие в ней множества новых па­пок или поддоменов. Открывая эти папки, вы найдете множество записей расположе­ния служб, как было показано ранее на рис. 6.22. Как уже упоминалось, записи SRV и динамические обновления DNS необходимы для обеспечения работы Active Directory.
Они представляют собой результат совместного функuионирования двух технологий.
Служба netlogon выполняет запросы DDNS для создания записей SRV внутри
пространства имен Active Directory DNS. Единственная причина заключается в га­рантировании того, что компьютеры смогут найти контроллеры домена.
Внутри проuессов ОС Windows определенные службы находятся с исполhЗовани­
ем DNS. На рис. 6.22 присутствовало несколько служб:
• _gc (global catalog — глобальный каталог) — служба LDAP для поиска данных
в глобальном каталоге;
• kerberos — проuесс аутентификаuии;
• kpassword — еще одна часть процесса аутентификации;
• ldap — служба LDAP для поиска данных в домене.
Каждая из перечисленных служб выполняется контроллерами домена внут­
ри домена или леса. На рис. 6.22 было видно, что все эти роли выполнялись на
DCOl . Bigfirm. сот и прослушивался порт ТСР.
Таким образом, когда компьютеру Windows требуется какая-то служба контроллера домена, например, LDAP, он запросит запись SRV для ldap . tcp . Bigf i rrn . сот.
После этого он получит все, что необходимо мя взаимодействия с IР-адресом и
портом.
Если компьютеру Windows нужно найти контроллер домена внутри собственного
сайта, он может искать его в поддомене sites . Bigfirm . com. В этом поддомене будут отображаться все созданные сайты в консоли Active Diгectory Sites and Services(Сайты и службы Active Directory).
Вероятность того, что администраторы могли бы поддерживать все это множес­
тво записей DNS вручную, довольно низка. Для одного контроллера домена можно
ожидать регистрации, по меньшей мере, 16-20 разных записей SRV. Изучение их
всех — задача, безусловно, не из простых. Именно здесь в игру вступают инстру­менты, подобные DcDiag. Инструкции по работе с этими утилитами приведены в разделе «Использование NsLookup и DcDiag» далее в главе.

Дополнительные компоненты Windows Server 2012 R2

К этому моменту мы обсудили существенные компоненты и способы обраще­
ния с ними, что уже позволяет вам достаточно квалифицированно управлять средой Windows Server 2012 R2 DNS. В настоящем разделе будут рассматриваться дополни­тельные компоненты DNS в Windows Server 2012 R2, которые развертываются не так
часто, как основные компоненты, но о которых, тем не менее, полезно знать.
rлобальный список блокировки запросов
Существует несколько распространенных записей хостов, которые могут быть за­
регистрированы в DNS другими службами. Одной из таких служб является протокол
автоматического обнаружения веб-прокси (\еЬ Proxy Automatic Discovery Protocol —
WPAD). Он помогает веб-браузерам автоматически загружать конфигураuии прок­
си из сервера. Так как эта запись не относится к конкретному компьютеру, любой
компьютер, включая потенциально скомпрометированный злоумышленниками, мо­жет попытаться зарегистрировать свое имя. Другой распространенной записью хоста является протокол автоматической внутрисайтовой адресаuии туннелей (lntra-Site Automatic Tunneliпg Addressing Protocol — ISATAP). Как объяснялось в главе 4, прото­кол ISATAP предназначен для выполнения маршрутизации из сети 1Pv4 в сеть 1Pv6.
В глобальном списке блокировки запросов (global query Ыосk list) указаны имена, для которых регистраuия DDNS заблокирована. Таким образом, попытки компью­тера злоумышленника зарегистрировать имена WPAD или ISATAP отклоняются.
Показанные ниже команды иллюстрируют способы администрирования это­
го списка. Для просмотра списка служит командлет Get — DNSSe rverGl oba l
QueryBlocklist. Обратите внимание, что по умолчанию в списке находятся wpad
и isatap.
C : UsersAdministrator . BFl>Get-DNSServerGlobalQueryBlocklist
ЕnаЫе : True
List : { wpad, isatap }
Чтобы добавить в этот список имя вроде www, можно воспользоваться командле­
том Set-DNSServerGlobalQueryBlocklist. По умолчанию компонент глобально­
го списка блокировки запросов включен. Он отключается и повторно включается с применением опции -ЕnаЫе со значением $True или $False.
Преобразование глобальных имен и одиночных имен
Даже с учетом того, что использование WINS идет на убыль, возникает пот­
ребность в поддержке для некоторых приложений процесса преобразования имен
NetBIOS. Компонент GlobalNames (глобальные имена) — это специальная зона, со­зданная для преобразования имен NetBIOS (15 символов безо всяких точек). Клиент
DNS осуществляет запрос в зону GlobaName, когда поиски с основным и дополни­
тельным суффиксом DNS завершились неудачей.
Конфигурирование компонента GlobalNames выполняется несложно.
1. Создайте новую зону по имени GlobalNames.
Рекомендуется выбрать тип зоны, интегрированной с Active Directory, чтобы
обеспечить репликацию в другие контроллеры домена.
2. Включите поддержку зоны Gl oba lNames с помощью командлета Set­
DNSServerGlobalNameZone:
C : UsersAdmiпistrator . BFl>Set-DNSServerGlobalNameZoпe -ЕпаЫе $True
3. Проведите репликацию зоны в другие контроллеры домена.
Не забудьте добавить эти контроллеры домена в список серверов имен для зоны.
4. Добавьте в зону записи CNAME для переадресации на определенные хосты.
В данном примере www переадресуется на hostrecord . Pr imaryZone . local
(рис. 6.29).
5. Добавьте запись местоположения службы, если необходимо, чтобы эту зону
запрашивали другие леса Active Directory.
DNS И ПРЕОБРАЗОВАНИЕ ИМЕН В WINDOWS 5ERVER 201 2 R2
DNS Manager
———-�.— — ——
� � С a:ched Lookups
� ..::J Forwгrd loolcup Zont’S
1> ,Vf _msda.Bigfirm.com
1> :Р 1dint�nite:hone.loc1J
1> …; Bigfirm.com
.:,c_Gl_o_balNomt:’:
� Prim1ryZone.lcк.al
1> _. R�erse lookup Zon�
1> _.; Trust:Po1nts
1>
Cond» rtionlll Fo�rders
1> IDJ G l o bal log:.
! Name Туре Dat.• Тimm:.Jmp
{] (same 1Js p1tr.» SЬrt of Authonty(SOA) 111 dc01.bigfirm.com» hostm.itst.» static
� (same IS rur». N t!t m e Smrer (NS) dc01.Ьigfirm.com. stnic
{ijwww AJi1s (СNАМЕ) hostrecord.Prim1ryZone.loc1’i
< f . » Рис. 6.29. Зона GlobalNames 277 Протестировать преобразование глобальных имен можно посредством уrилиты NsLookup: C: UsersAdrninistrator . DCl>Nslookup
Default Server : DCOl .Ыgfirm. com
Address : 1 92 . 1 68 . 0 . 1
> www
Server :
Address :
Name :
Address :
Aliases :
DCOl .Ыgfirm. com
1 92 . 1 68 . 0 . 1
hostrecord.primaryzone . local
1 92 . 1 68 . 0 . 2 1
www . Ьigfirm. com
Как обсуждалось ранее, в большинстве сред, полагающихся на серверы Windows,
потребность в преобразовании одиночных имен (NetBIOS) сведена к минимуму.
Она также была минимизирована за счет подходящего развертывания приложений с
применением имен FQDN и привлечения DNS.
Фоновая загрузка зон
Некоторые старые среды имеют настолько большие зоны DNS, что перезапуск
службы DNS контроллерами доменов занимает более часа. Для решения этой про­
блемы предназначено средство фоновой загрузки зон. Чтобы такая проблема воз­
никла, зона DNS должна содержать огромное количество записей.
Во время запуска службы DNS она начинает реагировать на запросы к зонам,
которые уже загрузились. Запросы к пока еще не загруженным зонам будуr отсы­
латься другим DNS-cepвepaм.
DNSSEC
Подобно НТТР, система DNS является нешифрованной и неауrентифицируе­
мой. Как упоминалось при рассмотрении зон обратного просмотра, злоумышленни­
ки мoryr подделывать ответы DNS. Чтобы противостоять этому, были разработаны
стандарты DNSSEC (DNS Security Extensions — расширения безопасности DNS),
которые позволяют DNS-cepвepy добавлять цифровую подпись к записям ресурсов.
ОС Windows Server 2012 R2 обеспечивает поддержку дополнительных зон как зон
DNSSEC. Она реагирует только на запросы записей из зоны с цифровой подписью.
ОС также будет предостамять необходимые записи ресурсов для аутентификации
подписи.
Такими записями ямяются КЕУ, SIG и NXT Запись КЕУ — это открытый ключ
подписи DNS-cepвepa. Запись SIG представляет цифровую подпись записи ресурса.
В записи NXT перечислены все допустимые записи в пространстве имен.
В версии Windows Server 2012 R2 стандарты DNSSEC претерпели следующие
улучшения:
• интеграция с Active Directory и поддержка динамических обновлений DNS;
• обновленная поддержка стандартов DNSSEC (NSECЗ и RSA/SHA-2);
• проверка достоверности записей с использованием обноменных стандартов
DNSSEC;
• дополнительная поддержка DNSSEC в PowerShell.
Если вы хотите протестировать DNSSEC в испытательной среде, обратитесь к
пошаговому руководству от Microsoft, доступному по ссылке http : / /tinyurl . сот/
dnsseclab.
якори доверия
Якори доверия (trust anchors) — это открытые сертификаты серверов DNSSEC,
которым DNS-cepoep будет доверять при взаимодействии. Сертификаты якорей до­
верия будут применяться для проверки достоверности цифровых подписей ответов.
Они добавляются в снойства DNS-cepвepa в форме открытых ключей.
В якори доверия Windows Server 201 2 R2 внесены следующие усовершенствова-
ния:
• использование Active Directory для распространения якорей доверия;
• поддержка автоматического перебора;
• упрошенное извлечение корневого якоря доверия.
В Windows Server 2012 R2 якори доверия отображаются о консоли DNS Manager,
внутри расположенной в левой части папки Trust Points (Точки доверия).

Поддержка преобразования именDNS на основе Интернета

В рамках организации существует также потребность в управлении пространс­
твами имен Интернета. Пользователям локальной сети понадобится доступ к веб­
сайтам и другим основанным на Интернете службам. Внешним пользователям будет
нужен доступ к оеб-сайтам организации и, как минимум, постовым серверам. Таким образом, вы не должны упускать из виду и эти требования.
Чтобы разрешить внешним пользователям обращаться к веб-сайтам организа­
uии, должен существовать внешний домен DNS. Следовательно, вам придется об­
думать вопрос о необходимости развертывания внешнего DNS-cepвepa. Внутренние
компьютеры будут преобразовывать внешние имена с помощью внутренних DNS­
cepвepoo. По этой причине требуется интеграuия со структурой DNS из Интернета.

Поддержка внешних доменов DNS

Большинство компаний мя поддержки веб-сайта и электронной почты регист­
рируют какое-то пространство имен DNS. Мелкие и некоторые средние компании
поручают управлять пространством имен на внешних DNS-cepвepax поставщикам
Интернет-услуг. Преимущества такого подхода связаны с готовностью серверов
и устранению потребности в обслуживании дополнительных серверов в подсети,
открытой мя Интернета. Эти серверы управляются посредством неб-интерфейса
и позволяют работать только с небольшим набором типов записей, таких как А,
CNAME и МХ.
Допускается применение сервера Windows Server 2012 R2 мя внешних операций
DNS. Роль DNS можно установить на сервере, не являющемся членом домена (как
обсуждалось в разделе «Конфигурирование автономного DNS-cepвepa» ранее в гла­ве), и затем изменить запись сервера имен мя зарегистрированного пространства
имен DNS, указав публичный IР-адрес сервера. Конечно, открыть Интернету ав­
тономный DNS-cepnep можно и таким способом, но в реальности существует не­
сколько аргументов против такого подхода.
• ОС Windows Server 2012 R2 не является бесплатной, и ее использование в ка­
честве внешнего решения DNS нельзя считать экономически оправданным
подходом.
• Сервер Windows Server 2012 R2 нуждается в ограничении функциональных воз­
можностей и зашите, когда он открыт внешне.
• Сервер должен обладать высокой доступностью, поэтому вам придется класте­
ризировать его или настроить несколько DNS-cepвepoв.
• Если вы еще об этом не позаботились, вам также понадобится высокоскорост­
ное подключение к Интернету.
Общая цена, которую придется заплатить, двигаясь в таком направлении, вы­
сока, поэтому многие компании предпочитают тратить свои деньги по-другому.
Именно здесь преимущество следует отдать простой реализации DNS на базе Linux.
Тем не менее, мы рекомендуем наиболее распространенный подход — поручить уп­
равление внешним пространством имен поставщику Интернет-услуг.
Разделение
Когда дело доходит до DNS, многие компании также внедряют сценарий с раз­
делением (spit-brain), хотя и неумышленно. Это означает, что они имеют внутрен­нее пространство имен, совпадающее с внешним пространством имен. Например,компания регистрирует внешнее пространство имен Eigfirrrc. corn и затем решает строить среду Active Directory с тем же самым именем.
Управление данным сценарием на единственном сервере было бы идеальным.
Реализация разделенной DNS — хорошая идея, предназначенная для решения про­
блемы. Можно бьuю бы иметь один DNS-cepвep, поддерживающий внутреннюю и
внешнюю зону того же самого пространства имен. Тогда бы 1 Р-адреса мя внешней
зоны предоставлялись бы внешним запросам, а внутренние 1 Р-адреса — внутрен­
ним запросам.
ПРЕДОСТЕРЕЖЕНИЯ ОТНОСИТЕЛЬНО ПРИМЕНЕНИЯ РАЗДЕЛЕННОЙ DNS
Разные специалисты и различные технические документы тто DNS могут утверждать
о том, что использовать одно и то же доменное имя для внугреннего и внешнего
пространства имен DNS компании не рекомендуется. Взамен предлагается выбрать
другое имя, которое не встречается в Интернете, или зарегистрированное имя, кото­рым вы не пользовались.
Когда компании не следуют этой рекомендации, они вскоре обнаруживают кон­
фликт при распознавании внешних ресурсов, которыми владеют, таких как www .
Bigfirm . com. Внутренний DNS-cepвep не может найти это имя, и запрос терпит
неудачу. Администраторы пытаются исправить это путем ручного добавления име­ни с внешним 1Р-адресом, но добавление внешнего IР-адреса вызьшает проблемы с маршрутизацией. Кроме того, разработчики будут жаловаться на невозможность за­грузки нового содержимого по внешнему IР-адресу. Им нужен внугренний IР-адрес.
Такие дополнительные трудности администрирования становятся нормой при разде­лении DNS.
Идея неплоха, но Windows Server 201 2 R2 это не поддерживает. В первую очередь
не поддерживается организация, открывающая контроллер домена, на котором размещено внутреннее пространство имен DNS, даже на границе Интернета. Так сде­лано не только из соображений безопасности. База данных Active Directory слишком ценна, чтобы помещать ее в демилитаризованную зону (DMZ), где она станет лако­мым кусочком для злоумышленников. Поэтому придется прибегнуть к альтернативе.
Цель заключается в том, чтобы обеспечить предоставление внешним запросам
внешних IР-адресов, а внутренним запросам — внутренних IР-адресов. Для подде­
ржки такого сценария вы должны будете администрировать (минимум) два DNS­
cepвepa с помощью Microsoft DNS. Ниже перечислены базовые шаги.
1. Реализуйте внешний DNS-cepвep для поддержки Bigfirrn. corn. Обычно это
становится готовым после регистрации доменного имени с помощью постав­
щика Интернет-услуг.
2. Реализуйте внутреннюю структуру DNS. Это делается с применением мастера
Active Directory Domain Services lnstalation Wizard.
3. Добавьте любые внешние записи во внугреннюю зону для Bigfirrn. corn.
Помните, что DNS-cepвepы внутри сети будут авторитетными для домена
Bigfirm. corn. Если не удается найти сайт www . Bigfirrn. corn, то он не сущест­вует. Внешние записи должны быть продублированы во внутренней зоне, что­бы мог возвращаться положительный результат. Вам придется протестировать
маршрутизацию, удостоверившись в доступности указанного IР-адреса. В слу­
чае возникновения проблем с маршрутизацией может понадобиться использо­
вать внутренний адрес.
4. Сконфигурируйте преобразование внешних пространств имен с применени­
ем корневых подсказок или серверов пересылки. Данная тема раскрывается в
следующем разделе.

Преобразование внешних пространств имен

Мы обсуждали, каким образом интегрировать DNS-cepвep с другими. Основными
методами преобразования имен DNS в Интернете являются корневые подсказки
или серверы пересылки. Корневые подсказки содержат список DNS-cepвepoв, на­
ходящихся наверху структуры DNS Интернета. DNS-cepвep может взаимодейство­
вать с такими серверами дЛЯ выполнения рекурсивных запросов к внешним про­
странствам имен. Серверы пересылки производят ответвленные запросы к другому
DNS-cepвepy, чтобы посмотреть, не распознает ли он имя. Ранее мы упоминали,
что в небольших средах предпочитаем использовать серверы пересылки на внешний
DNS-cepвep, поддерживаемый поставщиком Интернет-услуг, но корневые подсказ­
ки в данном сценарии также работают.
Важно не смешивать эти два подхода. Не определяйте в корневых подсказках
серверы как серверы пересылки. Запрос к корневой подсказке — это направленный
запрос, который всегда возвращает сервер имен лля домена. Он не отвечает запися­ми хостов и не выполняет рекурсивную операцию, которую будет делать сервер пе­ресылки. Кроме того, серверы пересылки имеют приоритет перед корневыми под­сказками. На приведенном ранее рис. 6. 1 О вкладка Forwarders (Серверы пересылки)
содержала флажок Use root hints if по forwarders are availaЫe (Использонать корневые
подсказки, если нет доступных серверов пересылки). Вы можете сделать вывод, что если сервер пересылки указан, но получен отрицательный ответ, запрос завершится, а корневые подсказки вообще затрагиваться не будут.
В обширных внутренних средах DNS обдуманное применение серверов пере­
сылки и корневых подсказок является обязательным. Внутренние серверы имен
поддоменов должны распознавать запросы от корневого DNS-cepвepa. Они также
должны распознавать запросы, основанные на И нтернете. Получая преимущес­
тво возможности кеширования DNS, они могут полагаться на сервер в распозна­
вании и сохранять распространен ные запросы, чтобы сократить внешний трафик.
В Microsoft рекомендуют, чтобы кеширующий сервер не был корневым, что поз­
волит не перегружать корневой сервер дополнительной рабочей нагрузкой. Кроме того, в Microsoft предостерегают от прямого взаимодействия с Интернетом внутрен­них DNS-cepвepoв, на которых размещены зоны, чтобы уменьшить их видимость в
Интернете. На рис. 6.30 показано одно решение, которое могло бы работать с нашейвымышленной структурой DNS.
В этом примере серверы пересылки используются для отправки запросов корне­
вому DNS-cepвepy в Bigfirm . com. Корневые подсказки можно было бы задейство­
вать, уда,1ив корневые подсказки И нтернета и указав B F l . Bigfirm . com в качестве сервера корневых подсказок. Кеширующий сервер предотвращает отправку запросов
в Интернет DNS-серверами, на которых размещены зоны, интегрированные с Active
Directory. Он осуществляет преобразование имен посредством корневых подсказок.
Дr�я обработки запросов в домене Арех . сот применяется зона-заглушка или сервер
условной пересьшки.
Возможны другие решения, обеспечивающие преимущества по разным причи­
нам. Мы отдаем предпочтение простоте использования серверон пересылки дr1я уп­
равления интеграцией серверов.
Кеширующий
DNS-cepвep
Сервер пересылки

DNS-cepвep
Ecoast. Bigfirm.com
Зона-заглушка или
сервер условной пересылки
DNS-cepвep
Apex.com
Рис. 6.30. Внутренняя структура DNS

Администрирование и устранение неполадок с помощью инструментов DNS

В этом разделе мы обсудим доступные инструменты и приемы устранения непо­
ладок в преобразовании имен DNS. Учитывая важность DNS, вы должны хорошо
знать инструменты, которые предоставляют ценную информацию, позволяющую
выявить возможные проблемы с преобразованием имен. Вдобавок к конфигуриро­ванию стандартные инструменты администрирования, консоль управления DNS и PowerShell предлагают также и дополнительную информацию такого рода. Утилиты
NsLookup, DcDiag и DNSLint предоставляют удобные начальные признаки нали­
чия проблем, касающихся преобразования имен DNS.

Администрирование DNS-cepвepa с помощью консоли управления DNS и PowerShell

Для администрирования DNS-cepвepa придется иметь дело с двумя инструмен­
тами: консолью управления DNS, которая является оснасткой М МС, и PoweгShell,
представляющим собой инструмент командной строки. Подобно оснастке ММС,
инструмент PowerShell предлагает возможность администрирования всего сервера, а также немного дополнительной функциональности. Например, как вы уже знаете,консоль управления DNS не позволяет изменять глобальный список блокировки за­просов или создавать разделы каталога.
Повсюду в этой главе демонстрировалось применение консоли управления DNS
для создания зон и редактирования свойств серверов и зон, что является обыденны­ми задачами, с которыми приходится иметь дело.

Вы также можете воспользоваться внутри консоли несколькими диагностически­
ми конфигураuиями. Они настраиваются в свойствах DNS-cepвepa.
• Вкладка Event Logging (Ведение журнала событий). Для службы DNS создается
отдельный журнал, который можно открыть в программе просмотра событий
(Event Viewer). Он связан с консолью управления DNS. Вдобавок сервер по
умолчанию собирает все события, что настраивается на вкладке Event Logging.
+ Вкладка Debug Logging (Ведение журнала отладки). В целях анализа можно
собрать в журнале более детальные сведения о действительных коммуникаци­
ях, возникающих на DNS-cepвepe. Ведение журнала отладки по умолчанию
отключено, но может быть включено через свойства DNS-cepвepa; вкладка
Debug Logging представлена на рис. 6.3 1 . Эта возможность полезна при выяв­
лении причин ненадежной работы DNS-cepвepa. Хотя большинство проблем
с DNS решаются путем подходящей подключаемости IP, вы найдете данное
средство полезным, когда подключаемость IP не имеет отношения к пробле­
ме. В редких случаях мы должны проверять, попадают ли специфичные запро­
сы на сервер, и это средство предоставляет нужную информацию.
• Вкладка Monitoring (Мониторинг). Эта вкладка также доступна из окна свойств
DNS-cepвepa; она показана на рис. 6.32. Она позволяет проверить запросы
DNS из этого сервера или предназначенные другому серверу — обратите вни­
мание, не конкретному серверу, а любому произвольно выбранному серверу.
Можно задать частоту запуска этого теста.
В выводе указывается только о том, прошел тест или нет. По существу, если на
DNS-cepвepe имеются проблемы, тест не проходит. Нам не удалось обнаружить на
этой вкладке сколько-нибудь полезные данные при решении проблем с DNS и,
скорее всего, вы не найдете здесь ничего нового. Для мониторинга DNS-cepвepoв
рекомендуется применять инструменты вроде диспетчера операций системного цен­тра 2012 R2 (Microsoft System Center 2012 R2 Operations Manager), и эта тема обсуж­дается в главе 30 (том 2).
Инструмент PowerShell предлагает несколько диагностических командлетов, ко­
торые могут оказаться полезными при сборе и анализе данных.
• Get-DNSServer предоставляет конфигурационные настройки для DNS­
cepвepa.
• Get-DnsServer 1 Export-Clixml -Path «c: configDnsServerConfig.xml»
генерирует текстовый файл с конфигурацией и свойствами зон.
• Get-DNSServerDiagnostics предоставляет сведения о ведении журналов со­
бытий для специфических операций DNS на сервере.
• Clear-DNSServerCache опустошает кеш. Иногда устаревшие распознанные
записи должны быть удалены после решения проблемы. Данная задача также
доступна в консоли управления DNS.
Все эти инструменты предоставляют средства администрирования и мониторин­
га. Мы находим их полезными для проведения более глубоких исследований, когдапередовые инструменты, такие как NsLookup, DcDiag и DNSLint, не сразу указыва­ют на проблему.

Использование NsLookup и DcDiag

При устранении проблем с DNS чаще всего используются инструменты
NsLookup, DcDiag и DNSLint. Утилита NsLookup предоставляет немедленное ука­
зание на проблемы с преобразованием имен. Утилиты DcDiag и DNSLint обеспе­
чивают указание на наличие проблем, связанных с Active Directory, таких как ре­гистрация DDNS и записи SRV. Если с помощью этих инструментов не удается
идентифицировать проблему, можно положиться на средства консоли управления
DNS и PowerShell.

NsLookup
Утилита NsLookup является первым инструментом, который мы применяем при
поиске и устранении проблем с преобразованием имен. Она подключается к указан­
ному в конфигурации IР-адресов основному DNS-cepвepy и делает запросы DNS.
Обратите внимание, что данная утилита не выполняет полный процесс преоб­
разования имен, т.е. весь жизненный цикл. Она ограничивается одной частью это­го цикла. Во время обсуждения клиентов приводились примеры команд ping и
net view, демонстрирующие различные части процесса. Пример команды ping
показывал процесс DNS, включающий первый шаг поиска имени в файле ноsтs.
Если файл ноsтs содержит записи для того же имени хоста, вы заметите расхожде­ние между ping и NsLookup.
ВИРУС CONFICKER
Одним из примеров вредоносного ПОf использующего DNS мя нарушения нор­
мальной работы, является вирус Conficker. Он появился в 2008 году, и, верите вы или нет, его до сих пор можно обнаружить на компьютерах, где не применялись
исправления системы и обновления антивирусного ПО. В зараженных вирусом
Coпficker системах предотвращается доступ из браузеров к важным сайтам внутри
определенных пространств имен DNS, таких как Microsoft . сот, Symantec . сот
и Norton . сот.
В результате ПО становится непригодным для использования. Компьютер не может
загрузить обновления Wi11dows; он не может найти возможные решения проблемы.
Даже если на машине установлено ПО Norton AntiVirus, ему не удается получить до­
ступ к сайту обновлений Symantec для загрузки последних обновлений. Машина не может исправить сама себя!
Когда мы столкнулись с Co11ficker, утилита NsLookup была первым инструментом,
задействованным в процессе обнаружения проблемы. Запросы к Microsoft . сот и
Symantec . сот проходили нормально, но обращение к указанным сайтам из браузе­ра Inteшet Explorer или Firefox оказывалось невозможным. Это помогло сузить об­ласть поиска. Таким образом, браузеры были заражены.
Конечно, утилита NsLookup предоставляет I Р-адреса мя сайтов, к которым нам не­обходим доступ. Однако веб-сайты Мicrosoft не функционируют в случае указания в URL только I Р-адреса. В результате такой обходной путь не срабатьmает.
Мы нашли решение с применением инструмента удаления вредоносного ПО
(Microsoft Windows Malicio11s Software Removal Tool — MSRT). Этот инструмент дол­жен быть загружен на отдельном компьютере и затем физически перенесен на зара­женный компьютер. С помощью MSRT вирус удалось идентифицировать и удалить.
К счастью, в наши дни распространение вируса Conficker ограничивается старыми ОС с устаревшим или отсутствующим антивирусным ПО и обновлениями Windows.
Тем не менее, это хороший пример того, как за счет изменения в преобразовании
имен нарушается работа системы и каким образом с помощью инструментов, подоб­
ных NsLookup, найти и идентифицировать причину.
Если приложению не удается получить доступ к серверу, то после проверки
подключаемости ТСР /1 Р мы начинаем исследования с использованием команды
NsLookup.

Ниже перечислены вопросы, которые требуют прояснения.
• Отвечает ли DNS-cepвep? Команда в самом начале сообщит, можно ли под­
ключиться к DNS-cepвepy. При наличии задержки или тайм-аута нет необхо­
димости продолжать. Имеется проблема с подключаемостью.
• Является ли стандартный сервер неизвестным’? Это указывает на сбой обрат­
ного просмотра, инициируемого утилитой NsLookup. При таком состоянии
остальные проверки NsLookup становятся бессмысленными.
• Можно ли преобразовать локальное имя FQDN’? Это обходит часть обработки
со стороны клиента. Для поиска имен хостов клиент будет добавлять основ­
ные суффиксы DNS.
• Можно ли преобразовать имя хоста без суффикса DNS? Это то, что делает
клиент, и данный шаг можно проверить.
• Можно ли преобразовать внешние имена FQDN’? Это позволит проверить воз­
можность выхода в Интернет стандартного DNS-cepвepa.
С утилитой NsLookup можно работать двумя способами: с помощью командных
запросов и в интерактивном режиме. Интерактивный режим намного мощнее, по­
этому вначале используется именно он. Он предлагает возможность выполнять за­просы к разным типам записей ресурсов и позволяет переключаться на другой сер­вер. Ниже приведены примеры распространенных запросов (вместе с поясняющими комментариями):
C : Use r s Ad.rninis t r ator . BFl>Nslookup
De fault Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . 0 . 1 0
rem Запрос записи хоста
> BFl .bigfirm. com
Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . 0 . l J
Name :
Addres s :
BFl . Ьigfirm . com
1 92 . 1 68 . 0 . 1 0
rem Запрос обратной записи PTR
> set q=ptr
> 192 . 168 . 0 . 10
Server :
l’.ddres s :
BFl . Ьigfi rm . com
1 92 . 1 68 . 0 . 1 0
10 . 1 . 1 68 . 1 92 . in-addr . a rpa
rem Запрос записи SOA
> set q=soa
> Ьigfirm . com
Server : BFl . Ьigfi rm . com
Address : 1 9 2 . 1 68 . О . 1 0
Ыgfirm . com
name = BFl . Ьigfirm . com
primary name server BFl . Ьigfirm . com
DNS и ПРЕОБРАЗОВАНИЕ ИМЕН в WINDOWS SERVER 201 2 R2
responsiЫe rnail addr = hostrnaster . bigfirm . com
serial = 124
ref resh = 900 ( 1 5 mins )
retry = 600 ( 10 min s )
expire = 8 6400 ( 1 day)
default TTL = 3600 ( 1 hour )
BFl . Ьigfirrn . сот
rem Запрос записи NS
> set <i»‘ns > bigfirrn . corn
interпet address
Server : BFl . bigfirm . com
Address : 1 92 . 1 68 . О . 1 0
1 92 . 1 68 . 0 . 1 0
bigfirm . com
BFl . Ьigfirm . com
nameserver = BFl . Ьigfirm . com
iпternet address = 1 92 . 1 68 . 0 . 1 0
rem Запрос записи SRV
> set q,zsrv
> _1dap._tcp .biqf’irm. com
Server : BFl . Ыgfir�. com
Address : 1 92 . 1 68 . 0 . 10
ldap . tcp . Ьigfirm . com SRV service locatioп :
priority О
weight 100
port 389
svr hostпame BFl . Ыgfirm . com
BFl . Ьigfirm . com iпterпet address = 1 92 . 1 68 . 0 . 1 0
DcDiaq
287
Утилита DcDiag изначально была частью набора инструментов для поддержки
администрирования (которые нужно было устанавливать отдельно) в ранних верси­ях Windows Server, но теперь она по умолчанию является частью установки Windows Server 2012 R2. Это инструмент, который нужно применять первым для быстрой проверки работоспособности структуры DNS. Поскольку утилита DcDiag прово­дит диагностику контроллеров домена, она должна проверить корректность работы DNS. После выполнения стандартного набора тестов вы можете заметить ошибки при попытках подключения к контроллерам домена. После этого можно запустить дополнительные тесты DcDiag, ориентированные специально на DNS. В следующем примере осуществляется проверка, может ли контроллер домена выполнять DDNS для регистрации записей SRV:
dcdiaq /test:ReqisterrnDNS /DnsDomain:biqf’irm. com
/f : docшnentsdcdiaqRegisterinDNS . txt
Н иже показан вывод этой команды:
Startiпg tes t : Regis teriпDNS
DNS coпfiguratioп is suf f icieпt to allow this domaiп coпtroller to
dyпamicall y register the domaiп controller Locator records i n DNS .
The DNS coпfiguration is sufficient to allow this computer to dyпarnically
register the А record correspoпdiпg to its DNS паmе .
. . . . . . . . . . . . . . . . . . . . . . . . . BFl passed test RegisteriпDNS
288
Запуск теста : Regis terinDNS
Конфигурация DNS доста точна для того, чтобы позволить этому
контроллеру домена динамически регистрировать записи Loca tor
контроллеру домена в DNS .
Конфигурация DNS достаточна для того, чтобы позволить этому
контроллеру домена динамически регистрировать запись А,
соответствующую его имени DNS .
. . . . . . . . . . . . . . . . . . . . . . . . . Brl прошел тест RegisterinDNS
Утилита DcDiag выполняет множество тестов, относящихся к контроллеру доме­
на, включая несколько тестов DNS. Выше был упомянут один из таких тестов —
RegisterinDNS. Эти тесты в первую очередь сосредоточены на интеграции между
DNS-серверами внутри среды Active Directol)’. Тесты могут быть выполнены в отно­
шении делегирования, серверов пересылки, обновлений и преобразовании внешних
имен DNS.
Ниже приведена часть справочной информации по утилите DcDiag. В ней при­
сутствует список тестов, доступных для DNS. При тестировании преобразования
внешних имен мы обычно полагаемся на NsLookup, поэтому никогда не пользуемся
тестами /DnsForwarders и /DnsResolveExtName, но для полноты они здесь пока­
заны.
DNS
Этот тест проверяет работоспособность настроек DNS для целого
предприятия . Подтесты могут запускаться по отдельности с применением
перечисленных далее ключей . По умолчанию запускаются все тесты кроме
тех , кото�:;ые проверяют преобразование внешних имен .
/DnsBas ic
/Dпs Forwarders
/DnsDelegation
/DnsDynamicUpda te
/DnsRecordRegistrat ion
/DnsResolveExtName
/DnsAll
/Dns internetName :
( базовые тесты, не могут быть пропущены)
(тесты для серверов пересылки и корневых подсказок)
( тесты для делегирования )
( тесты для динамических обновлений )
( тесты для регистрацv.и записей )
(тесты для преобразования вl-!ешних имен)
includes all tests above )
<Интер!-!ет-имя> (для теста /DnsResolveExtName )
( по умолчанию www .microsof t . com)
Как обсуждалось ранее при рассмотрении записей SRV, количество та­
ких записей, зарегистрированных контроллером домена, настолько велико,
что определить на глаз, корректно ли они работают, достаточно трудно. В до­
полнение к тесту / regi sterinDNS прогоняются тесты /DnsDynamicUpdate и
/DnsRecordRegistration, проверяющие регистрацию записей SRV контроллерами
доменов. В отличие от /registerinDNS, они не обязательно должны запускаться
локально на контроллере домена. Представленная ниже команда будет верифици­
ровать записи SRV мя контроллера домена. Опция /v означает «verЬose» («подроб­
но»). Вывод получаетсs� минным, поскольку в нем перечислены все записи SRV мя контроллера домена.
С : Jsers Administrator . БFl >dcdiag /s :BFl .Ьigfirm. com
/test : dns /dnsrecordregistration /v
DNS И ПРЕОБРАЗОВАНИЕ ИМЕН В WINDOWS 5ERVER 201 2 R2 289
Следующая команда будет проверять работоспособность обновлений DDNS мя
зоны. Она зарегистрирует хост и удалит его из зоны DNS сервера. В данном случае сервером является Ecoast . Bigfirm. сот.
C : UsersAdministrator . BFl>dcdiag /s :ecl . Ecoast . Bigfirm. com
/test:dns /dnsdynamicupdate /v
ИНСТРУМЕНТ DIG МОЩНЕЕ, ЧЕМ NsLookup
Существует инструмент для устранения неполадок в DNS, который эксплуатиру­
ется в мире Unix на протяжении продолжительного времени и называется Domain
Wormation Groper (Прощупывание доменной информации), или DJG. Если вы спро­
сите у пользователей DJG их мнение о том, насколько сравнима утилита NsLookup с DIG как инструмент для устранения неполадок в DNS, то не удивляйтесь, если они сначала рассмеются, после чего вежливо скажут, что они вообще несравнимы!
Однако хорошая новость в том, что DIG можно загрузить совершенно бесплатно
(http: //www . isc . org/software/Ьind) и установить в среде Windows Server 2012 R2, тем самым серьезно усилив уровень устранения неполадок в DNS. Инструмент DIG можно запускать в обычном формате командной строки, но он располагает так­же пакетным режимом, который поддерживает чтение запросов просмотра из файла.
Сведения по установке DIG в системе Windows Server доступны по ссылке http : / /tinyurl . com/DIGinstall. Можете также просмотреть онлайновое руководство поработе с DIG, воспользовавшись ссылкой http : //tinyurl . com/DIGusage.

Полезные ссылки по устранению неполадок в DNS

Все рассмотренные до сих пор инструменты основаны на том, что доступно в
готовом виде в ОС Windows Serveг 2012 R2. Именно с этих инструментов вы должны начинать поиск и устранение проблем в сети. В настоящем разделе мы поделимся с вами адресами нескольких веб-сайтов, имеющих отношение к DNS, которые ока­жут содействие в решении проблем с внешними именами DNS.
• www . IntoDNS . com. Это простой, но эффективный веб-сайт, который вы долж­ны добавить в свой арсенал инструментов для поиска и устранения неполадок
в DNS. Когда вы достигаете домашней страницы, понадобится лишь ввести
DNS-имя домена, о котором нужно получить информацию, и щелкнуть на
кнопке Report (Отчет). В результате возвратится все доступные сведения по за­писям А (родительской), NS, SOA, МХ и WWW мя домена. Располагая этой
информацией, вы можете быстро идентифицировать некорректно сконфигу­
рированные записи или же просто использовать ее при перекрестном контро­
ле предоставленных вам сведений.
• www . мхтоо lЬо х . com. Этот сайт делает намного больше того, что заявлено на
его начальной странице. Он предназначен для содействия в поиске и устра­
нении проблем с записями МХ и может оказаться полезным при попытках
выяснить, почему почтовый поток для отдельного домена электронной почты
не работает. В отношении любого домена можно запускать несколько разных
тестов, таких как просмотр МХ, проверка черного списка (Blacklist), просмотр
Whois и верификация SMTP. Если вы не пользовались этим сайтом ранее, то
самое время добавить его в список закладок.
290 ГЛАВА 6
• http://www.DNSStuff . com. Это еще один популярный сайт, который можно приме­
нять мя формирования отчетов по DNS, просмотров Whois и информаuии об
1 Р-адресах. Здесь вы можете также получить доступ к большому количеству
дополнительных инструментов дЛЯ поиска и устранения проблем с DNS, если
приобретете учетную запись на нем, но сначала имеет смысл оценить обещан­
ные преимущества, воспользовавшись пробным периодом.

dc1_domain_controller

В данной заметке, подробно рассмотрим процесс внедрения первого контроллера домена на предприятии. А всего их будет три:

1) Основной контроллер домена, ОС — Windows Server 2012 R2 with GUI, сетевое имя: dc1.

2) Дополнительный контроллер домена (на случай выхода из строя основного), ОС — Windows Server 2012 R2 Core, сетевое имя: dc2.

3) Контроллер домена только для чтения (RODC), находящийся в филиале компании за vpn-каналом, ОС — Windows Server 2012 R2 Core, сетевое имя: dc3.

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

Шаг 1: Установка первого контроллера домена. Подготовка.

Перед запуском мастера ролей, серверу необходимо задать сетевое имя и настроить ip-адрес. Сетевое имя — dc1. Настройки TCP/IP укажем как на скриншоте ниже.

2012r2-tcp-settings

Запускаем диспетчер сервера — Server Manager -> Dashboard -> Configure this local server -> Add Role and Features Wizard. На первом экране мастер нам сообщает, что перед тем как продолжить, должен быть установлен сложный пароль администратора, в настройках сети указан статический ip-адрес, установлены  последние обновления. Если все это сделано, то нажимаем Next.

dd_role_and_features_wizard

На следующем экране, выбираем первый пункт Role-based or feature-based installation (Базовая установка ролей и компонентов). Второй пункт Remote Desktop Service installtion предназначен исключительно для установки роли удаленных рабочих столов.

server_manager_select_installtion_type

На экране Select Destination server диспетчер предлагает нам, выбрать сервер из пула или расположенный на VHD-диске. Поскольку у нас пока только один локальный сервер, то нажимаем Next.

server_manager_select_destination_server

Выбираем Active Directory Domain Services (Доменные службы Active Directory), после чего появится окно с предложением добавить роли и компоненты, необходимые для установки роли AD. Нажимаем кнопку Add Features и затем Next.

server_manager_add_roles_and_features_wizard

Обычно, на серверах с AD DS имеет смысл, параллельно разворачивать DHCP Server, поэтому отмечаем его для установки так же. Соглашаемся с установкой компонент. Нажимаем Next.

server_manager_add_role_dhcp_server

На экране Features предлагается выбрать дополнительные компоненты. На контроллере домена ничего экстраординарного обычно не требуется, поэтому нажимаем Next.

server_manager_add_role_and_features_wizard2

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

Службы Active Directory Domain Services требуют установленного в сети DNS-сервера. В случае если он не установлен, то роль DNS Server будет предложена для установки.

Так же, службы Active Directory Domain Services требуют установки дополнительных служб пространства имен, файловой и DFS репликации (DFS Namespace, DFS Replication, File Replication). Нажимаем Next.

server_manager_AD_DS

На последнем экране Confirm installation selection (Подтверждение устанавливаемых компонентов), можно экспортировать конфигурацию в xml-фаил, который поможет быстро установить еще один сервер с идентичными настройками. Для этого потребуется на новом сервере, используя PowerShell, ввести следующую команду:

Install-WindowsFeature –ConfigurationFilePath
D:ConfigurationFilesDeploymentConfigTemplate.xml

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

Install-WindowsFeature –ConfigurationFilePath
D:ConfigurationFilesADCSConfigFile.xml -ComputerName $servername

В конце нажимаем Install. Дожидаемся окончания процесса установки.

server_manager_confirm_installation_selection

Шаг 2: Установка первого контроллера домена. Настройка служб Active Directory, DNS, DHCP.

Теперь нажимаем на значок треугольника с восклицательным знаком и выбираем сначала Promote this server to domain controller (Повысить этот сервер до контроллера домена). Позже запустим процесс развертывания DHCP-сервера.

server_manager_promote_to_domain_controller

Запустится мастер Active Directory Domain Services Configuration Wizard (Мастер конфигурации доменных служб Active Directory). Доступно, три варианта развертывания, если:

Add New Forest — создать новый корневой домен в новом лесу. Используется для новой «чистой» установки Active Directory; (например ‘test.ru’)

Add a new domain to an existing forest — добавить новый домен в существующем лесу, возможные варианты: Tree Domain —  корневой домен нового дерева в существующем лесу (например ‘test2.ru’ параллельно с ‘test.ru’) или Child Domain — дочерний домен в существующем лесу (например ‘corp.test.ru’)

Add a domain controller to an existing domain — добавить дополнительный контроллер домена в существующем домене, используется для резервного или филиального домена.

Выбираем вариант Add New Forest, задаем корневое имя домена, нажимаем Next.

server_manager_add_new_forest

На следующей вкладке можно задать функциональный уровень домена и леса (по умолчанию 2012R2), снять или отметить для установки DNS Server, и задать пароль для режима восстановления службы каталогов (DSRM). Укажем только пароль для DSRM и нажмем Далее.

server_manager_domain_controller_option

На следующем шаге DNS Options мастер ругнется, на то, что делегирование для этого DNS-сервера создано не было, потому что не найдена дочерняя зона или запущенный DNS-сервер. Что не удивительно, т.к. роль DNS Server у нас создается в процессе. Нажимаем Next.

server_manager_dns_options

Далее в Addional Optional соглашаемся с NetBIOS именем, которое предлагает нам система, жмем Next.

server_manager_verify_netbios

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

server_manager_paths

На следующем этапе Review Options отображается сводная информация по настройке. Кнопка View Script, позволяет посмотреть Powershell скрипт, при помощи которого, в будущем можно будет произвести настройку доменных служб Active Directory. Нажимаем Next.

server_manager_ad_ds_review_options

И наконец, на последнем этапе предварительных проверок, если видим надпись: «All prerequisite checks are passed successfully. Click «install» to begin installation.» (Все предварительные проверки пройдены успешно. Нажмите кнопку «установить», чтобы начать установку.), то нажимаем Install, дожидаемся окончания процесса установки.

server_manager_ad-ds_install_prerequisites_check

После перезагрузки, снова заходим в Server Manager -> Dashboard и запускаем пиктограмму треугольника с восклицательным знаком и выбираем там Complete DHCP Configuration (Завершение конфигурации DHCP).

server_manager_dhcp_configurel

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

server_manager_dhcp_post_install_wizard

На следующем экране нажимаем Commit что бы завершить процесс авторизации в Active Directory.

server_manager_authorize_dhcp_server

Если видим, что Create Security Group — Done и Authorizing DHCP Server — Done, то процесс завершился успешно, нажимаем Close.

Теперь создадим обратную зону в DNS. Обратная зона, позволяет выполнить разрешение FQDN-имен хостов по их IP-адресам. В процессе добавления ролей AD и DNS по умолчанию не создаются, поскольку предполагается, что в сети может существовать другой DNS-сервер, контролирующий обратную зону. Поэтому создадим ее сами, для этого переходим в диспетчер DNS (DNS Manager), на вкладку Reverse Lookup Zones, кликаем правой кнопкой и выбираем  New Zone.

dns_manager

Запустится мастер DNS-зоны. Соглашаемся с параметрами по умолчанию, а именно нам предлагается создать основную зону которая будет хранится на этом сервере (Primary Zone) и будет интегрирована в Active Directory (Store the zone in Active Directory..). Нажимаем Next.

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

Для всех DNS-серверов расположенных на контроллере домена в этом лесу (То all DNS servers running on domain controllers in this forest). Репликации во всем лесу Active Directory включая все деревья доменов.

Для всех DNS-серверов расположенных на контроллере домена в этом домене (То all DNS servers running on domain controllers in this domain). Репликация внутри текущего домена и его дочерних доменов.

Для всех контроллеров домена в этом домене (То all domain controllers in this domain). Репликация на все контроллеры домена внутри текущего домена и его дочерних доменов.

На все контроллеры домена в указанном разделе каталога приложений (To all domain controllers specified in the scope of this directory partition). Репликация на все контроллеры домена, но DNS-зона располагается в специальном каталоге приложений. Поле будет доступно для выбора, после создания каталога. Подробнее.

dns_zone_replication_scope

Выбираем вариант по умолчанию, нажимаем Next. Затем выбираем протокол по умолчанию IPv4 и снова жмем Next.

На следующем экране зададим идентификатор сети (Network ID). В нашем случае 192.168.0. В поле Reverse Lookup Zone Name увидим как автоматически подставится адрес зоны обратного просмотра. Нажимаем Next.

dns_network_ID

На экране Dynamic Update (динамические обновления), выберем один из трех возможных вариантов динамического обновления.

Разрешить только безопасные динамические обновления (Allow Only Secure Dynamic Updates). Это опция доступна, только если зона интегрирована в Active Directory.

Разрешить любые, безопасные и не безопасные динамические обновления (Allow Both Nonsecure And Secure Dynamic Updates). Данный переключатель, позволяет любому клиенту обновлять его записи ресурса в DNS при наличии изменений.

Запретить динамические обновления (Do Not Allow Dynamic Updates). Это опция отключает динамические обновления DNS. Ее следует использовать только при отсутствии интеграции зоны с Active Directory.

dns_dynamic_updates

Выбираем первый вариант, нажимаем Next и завершаем настройку нажатием Finish.

Еще одна полезная опция, которая обычно настраивается в DNS — это серверы пересылки или Forwarders, основное предназначение которых кэшировать и перенаправлять DNS-запросы с локального DNS-сервера на внешний DNS-сервер в сети интернет, например тот что находится у провайдера. Например мы хотим, что бы локальные компьютеры в нашей доменной сети, в сетевых настройках у которых прописан DNS-сервер (192.168.0.3) смогли получить доступ в интернет, необходимо что бы наш локальный dns-сервер был настроен на разрешение dns-запросов вышестоящего сервера. Для настройки серверов пересылки (Forwarders) переходим в консоль менеджера DNS. Затем в свойствах сервера переходим на вкладку Forwarders и нажимаем там Edit.

dns_forwarders_properties

Укажем как минимум один IP-адрес. Желательно несколько. Нажимаем ОК.

dns_edit_forwarders

Теперь настроим службу DHCP. Запускаем оснастку.

dhcp_manager1

Сперва зададим полный рабочий диапазон адресов из которого будут браться адреса для выдачи клиентам. Выбираем ActionNew Scope. Запустится мастер добавления области. Зададим имя области.

dhcp_manager_scope_name

Далее укажем начальный и конечный адрес диапазона сети.

dhcp_manager_range_of_the_scope

Далее добавим адреса которые мы хотим исключить из выдачи клиентам. Жмем Далее.

dhcp_manager_exclusions_delay

На экране Lease Duration укажем отличное от по умолчанию время аренды, если требуется. Жмем Далее.

dhcp_manager_lease_duration

Затем согласимся, что хотим настроить опции DHCP: Yes, I want to configure these option now.

Последовательно укажем шлюз, доменное имя, адреса DNS, WINS пропускаем и в конце соглашаемся с активацией области нажатием: Yes, I want to activate this scope now. Finish.

dhcp_manager_add_gateway

dhcp_manager_domain_and_dns

dhcp_manager_activate_scope

Для безопасной работы службы DHCP, требуется настроить специальную учетную запись для динамического обновления записей DNS. Это необходимо сделать, с одной стороны для того что бы предотвратить динамическую регистрацию клиентов в DNS при помощи административной учетной записи домена и возможного злоупотребления ею, с другой стороны в случае резервирования службы DHCP и сбоя основного сервера, можно будет перенести резервную копию зоны на второй сервер, а для этого потребуется учетная запись первого сервера. Для выполнения этих условий, в оснастке Active Directory Users and Computers создадим учетную запись с именем dhcp и назначим бессрочный пароль, выбрав параметр: Password Never Expires.

dhcp_ad_account

Назначим пользователю надежный пароль и добавим в группу DnsUpdateProxy. Затем удалим пользователя из группы Domain Users, предварительно назначив пользователю primary группу «DnsUpdateProxy». Данная учетная запись будет отвечать исключительно за динамическое обновление записей и не иметь доступа не каким другим ресурсам где достаточно базовых доменных прав.

DNSUpdateProxy-account

Нажимаем Apply и затем ОК. Открываем снова консоль DHCP. Переходим в свойства протокола IPv4 на вкладку Advanced.

dhcp_ipv4_advanced

Нажимаем Credentials и указываем там нашего пользователя DHCP.

DNSUpdateProxy-credentials

Нажимаем ОК, перезапускаем службу.

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

В данном руководстве подробно описан и продемонстрирован процесс настройки DNS-сервера на Windows Server 2012 R2.

Для настройки DNS-сервера на Windows Server 2012 R2 потребуются:

1. Компьютер, под управлением Windows Server 2012 R2 (О том как установить Windows Server 2012 R2 можно прочитать в данной статье: «Установка и активация Windows Server 2012 R2 с USB флешки» );

2. Установленная и настроенная роль Active Directory Domain Services (контроллер домена) на Windows Server 2012 R2 (О том как установить Active Directory Domain Services можно прочитать в данной статье: «Установка контроллера домена Active Directory в Windows Server 2012 R2» ).

Порядок настройки DNS-сервера на Windows Server 2012 R2

1. Откройте окно диспетчера сервера, затем нажмите Средства и выберите из списка пункт DNS (Рис.1).

Рис.1

.

2. В меню Действие выберите пункт Настроить DNS-сервер… (Рис.2).

Рис.2

.

3. На странице приветствия мастера настройки DNS-сервера щелкните на кнопке Далее (Рис.3).

Рис.3

.

4. Выберите пункт Создать зоны прямого и обратного просмотра (рекомендуется для больших сетей) и щелкните на кнопке Далее (Рис.4).

Рис.4

.

5. Выберите пункт Да, создать зону прямого просмотра сейчас (рекомендуется), затем нажмите Далее (Рис.5).

Рис.5

.

6. Выберите тип зоны Основная зона, установите галочку напротив Сохранять зону в Active Directory, затем нажмите Далее (Рис.6).

Рис.6

.

7. Выберите пункт Для всех DNS-серверов, работающих на контроллерах домена в этом домене (прим. в данном руководстве используется домен с названием example.local), затем нажмите Далее (Рис.7).

Рис.7

.

8. Введите имя зоны (прим. в данном руководстве используется имя example.local), затем нажмите Далее (Рис.8).

Рис.8

.

9. Выберите нужный тип динамического обновления Разрешить только безопасные динамические обновления, либо Запретить динамические обновления, затем нажмите Далее (Рис.9).

Рис.9

.

10. Выберите пункт Да, создать зону обратного просмотра сейчас и нажмите Далее (Рис.10).

Рис.10

.

11. Выберите тип зоны Основная зона, установите галочку напротив Сохранять зону в Active Directory, затем нажмите Далее (Рис.11).

Рис.11

.

12. Выберите пункт Для всех DNS-серверов, работающих на контроллерах домена в этом домене (прим. в данном руководстве используется домен с названием example.local), затем нажмите Далее (Рис.12).

Рис.12

.

13. Выберите пункт Зона обратного просмотра IPv4, затем нажмите Далее (Рис.13).

Рис.13

.

14. Введите идентификатор сети для зоны обратного просмотра и нажмите Далее (прим. как правило, в качестве сетевого идентификатора вводится первый набор октетов из IP-адреса зоны. Например, если в сети используется диапазон IP-адресов класса С 192.168.0.0/24, то в качестве сетевого идентификатора могут быть введено значение 192.168.0.) (Рис.14).

Рис.14

.

15. Выберите Запретить динамические обновления, затем нажмите Далее (Рис.15).

Рис.15

.

16. В настройках пересылки выберите пункт Нет, не пересылать запросы, затем нажмите Далее (Рис.16).

Рис.16

.

17. Для сохранения выбранных параметров настройки нажмите Готово (Рис.17).

Рис.17

.

Настройка DNS-сервера в Windows Server 2012 R2 завершена!

.

Internet and especially the web are based on the DNS system and the very large number of domain names that exist at the moment.
If you have already bought a domain name on the Internet or consulted the whois of a domain, you will have surely noticed that the domain is always managed by at least 2 DNS servers (created by the host where the user bought his domain name).

Since only one DNS server can be authoritative for each zone, it was necessary to find a technique to obtain a certain fault tolerance.
This technique consists in creating at least 2 DNS servers :

  1. the 1st DNS server will act as the primary DNS server for the desired DNS zone (the domain name) and will therefore be authoritative for this zone.
  2. your other DNS servers may act as secondary DNS servers for the desired DNS zone (the domain name) if your primary DNS server allows it to retrieve a copy of its DNS zone

Note that Google’s public DNS servers and those created by ISPs are not secondary DNS servers, but only DNS servers that keep information cached when their clients send them DNS queries.
These DNS servers are therefore not authoritative for the relevant DNS zones and don’t contain all the relevant DNS zone information.

  1. Create a DNS zone on a secondary DNS server
  2. Allow the transfer of the DNS zone
  3. Update the DNS zone

To begin, create your primary (primary) DNS server by following our tutorial : Windows Server 2012 / 2012 R2 — Create and configure a DNS server, as well as delegate subdomains
Then, install the «DNS Server» role on your 2nd server.

Open the DNS Manager and create a new forward lookup zone.

The new zone wizard appears.

Select : Secondary zone.

Specify the name of the zone that you manage on your primary DNS server and that you want to replicate to your secondary DNS server.

Specify the IP address of your master (primary) DNS server where you are currently managing this zone.

If all goes well, the validation will succeed.

The secondary zone has been created.

After the secondary zone is created, the «Zone Not Loaded by DNS Server» message may be displayed.
In order for the DNS server to obtain a copy of the zone from your primary DNS server, you must first authorize the transfer of the zone to your secondary DNS server.

2. Allow the transfer of the DNS zone

To allow the transfer of the DNS zone from the master (primary) server to the secondary server, go to your primary DNS server and create a new host (A or AAAA).

Type «ns2» (which means : name server 2 or DNS server 2 if you prefer).

Then, go to the properties of your main DNS zone and add a name server.

Add the name or IP address of your secondary DNS server and click : Resolve.

The secondary server is obviously not authoritative for this zone.

Now, your 2 DNS servers are referenced as name servers for this zone.

Finally, authorize the transfer of the zone to the servers listed in the Name Servers tab.

Note : selecting the «Only to the following servers» option by specifying the IP address of the secondary DNS server would also work.
However, since you must also add the IP address of the secondary server as a name server for the concerned zone, it’s preferable to use the «Only to servers listed on the Name Servers tab» option.

As you can see, our secondary DNS server (ns2) is well referenced as a name server for this zone.

If we try to get the IP address corresponding to the «ns1.informatiweb.lan» domain using the nslookup command on our main DNS server, we get the same IP address from our 2 DNS servers.

3. Update the DNS zone

As explained in our previous tutorial, for each change, Windows Server automatically increment the serial number of the zone.
This serial number allows secondary DNS servers to know if the zone has been modified since the last time they received a copy of this DNS zone.

Currently, the serial number of our DNS zone is : 19.

We create a new record on our primary DNS server.

And Windows Server automatically increments the serial number of our DNS zone.

Then, go to your secondary DNS server and right-click «Load again» on your fordward lookup zone to force the update of the zone.
As expected, the new «web-server» record created on the primary DNS server also appears on the secondary DNS server.

Сейчас мы установим роль сервера DNS-сервер на операционной системе Microsoft Windows Server 2012 R2 Datacenter, затем создадим зону прямого просмотра, а также вспомним, что такое вообще DNS и для чего он нужен.

И прежде чем устанавливать и настраивать DNS сервер, давайте вспомним, что такое DNS и DNS сервер. Так как подобной информации в Интернете полно мы рассмотрим это кратко и перейдем сразу к делу. Напомню, что в прошлых статьях мы рассматривали установку Windows Server 2012 R2 и установка и настройку DHCP сервера на этой же операционной системе, теперь продолжаем и на очереди у нас DNS сервер.

Содержание

  1. Что такое DNS и DNS сервер?
  2. Установка DNS сервера на Windows Server 2012 R2
  3. Шаг 1
  4. Шаг 2
  5. Шаг 3
  6. Шаг 4
  7. Шаг 5
  8. Шаг 6
  9. Шаг 7
  10. Шаг 8
  11. Создание зоны прямого просмотра на DNS сервере 2012 R2

DNS (Domain Name System) – это система доменных имён, которая позволяет по доменному имени узнать IP адрес хоста и наоборот. Так как у каждого компьютера или сетевого устройства есть свой IP адрес и для того чтобы обратиться к тому или иному компьютеру или устройству соответственно нужно знать этот IP адрес, но так как запоминать определенную последовательность цифр не удобно, да и как если, например Вы обращаетесь ко многим компьютерам (запомнить просто не реально) поэтому чтобы  не запоминать эти цифры, и существует система доменных имен, например, что лучше для восприятия 192.168.1.1 или mycomp.  Вот такое простое определение, но так как материал для начинающих администраторов, этого вполне достаточно.

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

Хватит теории, и так как материал посвящен именно установки роли DNS сервер, давайте переходить непосредственно к этому.

Примечание! Как видно из названия, DNS сервер мы будем устанавливать на ОС Windows Server 2012 R2 Datacenter, только мы будем использовать, как и в прошлых статьях, ознакомительную версию.

Установка DNS сервера на Windows Server 2012 R2

Шаг 1

Открываем диспетчер серверов и выбираем «Добавить роли и компоненты»

Скриншот 1

Шаг 2

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

Скриншот 2

Шаг 3

На этом шаге, также ничего не нужно делать, все по умолчанию выбрано правильно именно так как нам и нужно, жмем «Далее»

Скриншот 3

Шаг 4

Затем предстоит выбрать сервер, на который будет производиться установка роли DNS сервера, так как у меня сервер один я его и выбираю, жму «Далее»

Скриншот 4

Шаг 5

Вот как раз на этом шаге и нужно выбрать, какие роли мы будем устанавливать, а мы соответственно будем устанавливать роль DNS сервер, поэтому выбираем его

Скриншот 5

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

Скриншот 6

Затем жмем «Далее»

Скриншот 7

Шаг 6

И так как компоненты мы уже добавили нам искать их здесь не нужно, но для примера я покажу, где они находятся и что они уже выбраны, жмем «Далее»

Скриншот 8

Шаг 7

На следующем окне нам говорят, на что обратить внимание при установке роли DNS сервер, жмем «Далее»

Скриншот 9

Шаг 8

Все подтверждаем установку нажатием кнопку «Установить», ставить галочку «Автоматический перезапуск сервера» в данном случае не нужно.

Скриншот 10

Вот и все началась установка

Скриншот 11

Продлится она не долго минуты 3, и появится следующее сообщение, жмем «Закрыть»

Скриншот 12

Курс по SQL для начинающих

Все, роль сервера DNS-сервер установлена. Для запуска средств управления DNS сервером используйте Диспетчер серверов->Средства ->DNS

Скриншот 13

Или через меню Пуск

Скриншот 14

Само средство управления выглядит следующим образом

Скриншот 15

Создание зоны прямого просмотра на DNS сервере 2012 R2

На группе «Зоны прямого просмотра» щелкаем правой кнопкой мыши и выбираем «Создать новую зону»

Скриншот 16

После у нас запустится мастер создания новой зоны, жмем «Далее»

Скриншот 17

В следующем окне выбираем тип наше зоны, описание можете посмотреть непосредственно под каждым типов, я выбираю «Основную» жму «Далее»

Скриншот 18

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

Скриншот 19

Далее я выбираю «Создать новый файл», так как у меня другого DNS сервера нет, жму «Далее»

Скриншот 20

Затем предстоит выбрать «Тип динамического обновления» я пока такой функционал запрещу, но в последствии я всегда могу его включить, а Вы можете включить его, если, например, у Вас DNS сервер только для Вашей локальной сети, жму «Далее»

Скриншот 21

Заключительное окно, которое говорит нам, что все готово, мы соответственно и жмем «Готово»

Скриншот 22

Вот и все зона создана, давайте создадим запись типа A, например для нашего же сервера. Для этого по зоне щелкаем правой кнопкой мыши и жмем «Создать узел A или AAAA»

Скриншот 23

Затем вводим имя нашего узла, которое мы хотим, чтобы у него было, и соответственно какой у него IP адрес, это уже по факту. Жмем «Добавить узел»

Скриншот 24

Появится сообщение о том, что узел создан

Скриншот 25

И появится соответствующая запись

Скриншот 26

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

Скриншот 27

Как видите, система распознала по доменному имени его IP адрес. И на этом предлагаю заканчивать. Удачи!

Понравилась статья? Поделить с друзьями:
  • Делаем установочную флешку windows 10 ultraiso
  • Делаем установочную флешку windows 10 rufus
  • Делаем точку доступа wi fi в windows 10
  • Делаем точку восстановления системы windows 10
  • Делаем рабочий стол красивым windows 10