DNS-сервер Windows Server 2012 (часть 2)

Опубликовано: 19 Марта, 2023

на информационный бюллетень WindowsNetworking.com, посвященный обновлению статей в режиме реального времени

Служба DNS-сервера не установлена в Windows Server 2012 по умолчанию. Его необходимо добавить в качестве роли сервера одним из следующих способов:

  • Менеджер сервера
  • Windows PowerShell
  • Мастер установки доменных служб Active Directory (при повышении роли сервера до контроллера домена Active Directory)

После завершения установки консоль управления Microsoft с оснасткой «Диспетчер DNS» автоматически становится доступной из меню « Инструменты», и вы можете отслеживать один или несколько DNS-серверов из консоли «Диспетчер серверов». Введите dnsmgmt.msc в командной строке или в поле поиска, чтобы открыть диспетчер DNS.

Давайте рассмотрим шаги по установке DNS с помощью диспетчера серверов:

1. В консоли диспетчера серверов щелкните Добавить роли и компоненты.

Изображение 4808
фигура 1

2. На странице «Перед началом» нажмите «Далее».

3. На странице Выбор типа установки убедитесь, что выбран вариант Установка на основе ролей или компонентов, и нажмите Далее.

Изображение 4809
фигура 2

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

Изображение 4810
Рисунок 3

5. На странице Выбор ролей сервера выберите DNS-сервер.

Изображение 4811
Рисунок 4

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

Изображение 4812
Рисунок 5

7. На странице «Выбрать компоненты» нажмите «Далее».

Изображение 4813
Рисунок 6

8. На странице «DNS-сервер» нажмите «Далее».

Изображение 4814
Рисунок 7

9. На странице Подтверждение выбора установки щелкните Установить.

Изображение 4815
Рисунок 8

10. Когда на странице «Ход установки» появится сообщение «Установка прошла успешно», нажмите «Закрыть».

Изображение 4816
Рисунок 9

Давайте теперь рассмотрим процесс установки DNS с помощью Windows PowerShell. Мы можем проверить роли и функции, установленные на сервере Windows 2012, введя следующее в командной строке PowerShell:

Get-WindowsFeature| ? {$_.установлено}.

Изображение 4817
Рисунок 10

На предыдущем рисунке показаны компоненты, установленные в Windows Server 2012 по умолчанию. Чтобы добавить роль DNS-сервера с помощью Windows PowerShell, сначала импортируйте модуль PowerShell ServerManager, а затем запустите командлет Install-WindowsFeature, как показано ниже:

Изображение 4818
Рисунок 11

Снова используя PowerShell, мы можем убедиться, что роль DNS теперь установлена:

Изображение 4819
Рисунок 12

DNS-сервер только для кэширования

Независимо от того, используете ли вы диспетчер серверов или Windows PowerShell, DNS-сервер не имеет зоны, настроенной сразу после установки. Без зон вы все равно можете использовать этот сервер в качестве кэширующего DNS.

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

Чтобы проверить корневые ссылки на DNS-сервере Windows Server 2012, используйте следующий командлет PowerShell:

Изображение 4820
Рисунок 13

Типы DNS-зон

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

Первичная зона. DNS-сервер может читать и записывать данные в основной зоне. Это возможно, поскольку DNS-сервер хранит основную копию данных зоны либо в текстовом файле, либо в базе данных Active Directory, если DNS установлен на контроллере домена. Если используется локальный файл, файлу присваивается то же имя, что и зоне, с использованием расширения.dns, например zone_name.dns. Файл зоны по умолчанию сохраняется в каталоге %windir%system32dns.

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

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

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

Зона заглушки. Зона-заглушка — это ограниченная копия зоны, состоящая из следующих записей: записей ресурсов начала полномочий (SOA), записей сервера имен (NS) и записей имени хоста (A). Эти записи используются для идентификации авторитетных DNS-серверов зоны. DNS-сервер, на котором находится зона-заглушка, не является полномочным для этой зоны. Когда этот DNS-сервер получает запрос на разрешение имени, ему необходимо обратиться к одному из авторитетных DNS-серверов из зоны-заглушки.

Интегрированная зона Active Directory. Интегрированные зоны Active Directory можно настроить только на контроллерах домена, которые также являются DNS-серверами. Это основная зона, данные которой хранятся в базе данных Active Directory. См. рисунок ниже.

Изображение 4821
Рисунок 14

Существует несколько преимуществ использования интегрированных зон Active Directory, среди которых:

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

Безопасная топология репликации. Нет необходимости настраивать передачу зон в интегрированных зонах Active Directory так, как это необходимо делать для стандартных первичных и вторичных зон. В зонах, интегрированных с Active Directory, данные DNS передаются автоматически как часть репликации Active Directory. Вся репликация AD зашифрована по умолчанию.

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

Разрешения безопасности. Как и любой другой объект Active Directory, вы можете делегировать администрирование и применять индивидуальные разрешения к зонам и записям ресурсов, изменяя список управления доступом (ACL) для зоны. См. ниже вкладку безопасности в свойствах интегрированной зоны Active Directory:

Изображение 4822
Рисунок 15

Расширенные параметры конфигурации DNS Windows Server 2012

Windows Server 2012 предлагает некоторые расширенные параметры конфигурации, которые позволяют повысить безопасность и производительность вашей инфраструктуры DNS. Давайте рассмотрим некоторые из них:

Расширения безопасности DNS (DNSSEC). Протокол DNS не имеет встроенных возможностей для обеспечения аутентификации или проверки целостности информации DNS, которой обмениваются DNS-серверы или доставляются DNS-клиентам. Эта известная уязвимость может быть использована злоумышленниками, которые могут перехватить действия по разрешению имен, когда пользователи пытаются получить доступ к веб-сайту в Интернете. Одной из целей злоумышленника может быть получение контроля над процессом и перенаправление браузера пользователя на фальшивый мошеннический веб-сайт, где пользователя просят ввести личную информацию, такую как имя пользователя, пароль, номер кредитной карты, банковский счет или номера социального страхования. DNSSEC использует сертификаты инфраструктуры открытых ключей (PKI) с протоколом DNS, чтобы позволить DNS-серверам проверять ответы DNS. С помощью DNSSEC администратор может подписать зону DNS цифровой подписью, что является способом цифровой подписи всех записей в этой зоне.

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

Ресурсные записи DNSSEC

Новые типы записей ресурсов связаны с DNSSEC. Подписи, созданные после реализации DNSSEC, содержатся в зоне DNS как подпись записи ресурса (RRSIG). Когда DNS-сервер отвечает на запрос разрешения имен, в ответ возвращается одна или несколько записей RRSIG. Открытый криптографический ключ, хранящийся в записи ресурса DNSKEY, используется для проверки подписи. Запись DNSKEY извлекается DNS-сервером в процессе проверки. Если соответствующая запись ресурса не найдена, это означает, что записи RRSIG нет, однако ответ DNS-сервера все равно должен быть проверен, поскольку в этих случаях используются записи Next Secure (NSEC). Валидатор может использовать запись NSEC в качестве доказательства того, что имя не существует. NSEC3 — лучшая альтернатива записи NSEC; оба поддерживаются Windows Server 2012.

Точки доверия и таблица политик разрешения имен

Двумя важными компонентами реализации DNSSEC являются точки доверия и таблица политик разрешения имен.

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

Таблица политики разрешения имен (NRPT). В нем перечислены зоны или пространства имен, которые выполняют запросы DNSSEC, и те, которые этого не делают. Можно использовать либо групповую политику, либо Windows PowerShell, чтобы настроить NRPT так, чтобы проверка DNSSEC выполнялась для ответов DNS в выбранных пространствах имен.

Используя Windows PowerShell, мы можем убедиться, что зона DNS в настоящее время не подписана. В командной строке PowerShell введите: Resolve-Dnsname FQDN –server DNS_Server_name –dnssecok. См. следующий вывод:

Изображение 4823
Рисунок 16

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

1. Откройте диспетчер DNS, щелкните правой кнопкой мыши зону DNS и выберите DNSSEC — Подписать зону.

Изображение 4824
Рисунок 17

2. На странице Расширения безопасности DNS (DNSSEC) нажмите Далее.

Изображение 4825
Рисунок 18

3. На странице «Параметры подписи» выберите «Использовать параметры по умолчанию для подписи зоны » и нажмите «Далее».

Изображение 4826
Рисунок 19

4. На странице Расширения безопасности DNS (DNSSEC) щелкните Далее.

Изображение 4827
Рисунок 20

5. На странице «Подписание зоны» нажмите «Готово».

Изображение 4828
Рисунок 21

Теперь мы можем видеть записи ресурсов RRSIG, DNSKEY и NSEC3, содержащиеся в подписанной зоне.

Изображение 4829
Рисунок 22

Снова запустив Windows PowerShell, вы убедитесь, что зона имеет цифровую подпись. Вы можете сравнить этот результат с предыдущими выводами до того, как мы применили DNSSEC.

Изображение 4830
Рисунок 23

Пул сокетов DNS и блокировка кеша

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

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

На рисунке ниже показано, как использовать инструмент dnscmd для проверки и настройки размера пула сокетов DNS.

Изображение 4831
Рисунок 24

Блокировка кэша. Если блокировка кеша включена, DNS-сервер не позволит перезаписывать кэшированные записи в течение времени жизни (TTL) в записи DNS. Эта функция защищает записи кэша DNS от возможных атак с отравлением кэша DNS злонамеренными пользователями в Интернете.

Блокировка кэша настраивается как процентное значение. Предположим, что вы установили значение блокировки кеша на 75, DNS-сервер не будет перезаписывать кэшированную запись в течение 75% от продолжительности TTL. По умолчанию значение процента блокировки кэша равно 100, что означает, что кэшированные записи не будут перезаписываться в течение всего срока жизни.

Вы можете использовать инструмент dnscmd для настройки блокировки кэша на DNS-сервере Windows Server 2012. См. рисунок ниже.

Изображение 4832
Рисунок 25

В этой статье мы рассмотрели процесс установки роли DNS с использованием Windows Server 2012 Server Manager и Windows PowerShell. Мы использовали консоль диспетчера DNS, PowerShell и dnscmd для выполнения административных задач и рассмотрели некоторые расширенные функции безопасности, включая интегрированные зоны Active Directory, DNSSEC, пул сокетов и просмотр кэша.

Intense School

на информационный бюллетень WindowsNetworking.com, посвященный обновлению статей в режиме реального времени