Настройка зоны обратного просмотра dns windows server 2016

Microsoft Windows Server 2016 — это обновленная версия и мощная операционная система, способная выполнять множество различных настраиваемых ролей и функций. Однако для предотвращения перегрузки оборудования и серьезного снижения производительности оборудования Windows Server 2016 по-прежнему предоставляет модульный подход к задачам и ролям в административной среде сервера с помощью функции добавления ролей и компонентов.

В дополнение к текущим мощным возможностям, предлагаемым ролью DNS Windows Server 2012, Windows Server 2016 включает в себя обновленные и улучшенные функции.Назвать несколько:

• Настройки GP для NRPT позволяют клиенту DNS больше не связываться с определенным интерфейсом.
• Добавлены политики DNS
• Добавлено ограничение RRP / Response Rate.
• Аутентификация именованных объектов на основе DNS (DANE)
• Поддержка неизвестной записи
• Корневые подсказки IPv6
• Улучшена поддержка Windows Powershell

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

Как установить роль DNS-сервера в Windows Server 2016

1. Откройте окно диспетчера сервера и перейдите к локальному серверу.

2. Нажмите Управление и «Добавить роли и функции».

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

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

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

6. Выберите роль DNS-сервера.

7. Затем окно просит вас подтвердить зависимости (обычно только инструменты администрирования, необходимые для роли DNS), также для установки. Нажмите Добавить функции, как это обычно требуется

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

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

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

11. Окончательное подтверждение установки. Он предоставляет возможность перезапустить целевой сервер (рекомендуется для массовых установок) и возвращает вас в окно диспетчера серверов.

Запуск / настройка роли DNS

1. Выберите параметр DNS на боковой панели диспетчера сервера.
2. Выберите сервер, который вы хотите управлять, щелкните правой кнопкой мыши его и нажмите «DNS Manager» (альтернативный метод, щелкните меню «Пуск», выберите «Административные инструменты», и нажмите DNS).
3. Щелкните «Действие».
4. Щелкните Настроить DNS-сервер…
5. Появится приглашение к мастеру настройки DNS-сервера, нажмите «Далее».
6. Выберите один из 3 вариантов, который вы хотите использовать, который может удовлетворить ваши потребности.

Зона прямого просмотра

1. Как только будет выбран любой из вариантов, он перейдет к запросу имени зоны. Введите название зоны.
2. Если выбран параметр DNS, поддерживаемый поставщиком Интернет-услуг, он будет запрашивать информацию для DNS поставщика услуг Интернета. Если Сервер обслуживает зону, он запросит имя зоны. Подойдет любое имя.
3. После нажатия следующего на сервере придерживается зона, она будет спросить, хотите ли вы создать новый файл или использовать существующий файл, вводит информацию или файл, который вы хотите использовать, а затем нажмите «Далее»
4. Далее он представит вам 3 варианта, 2, если Active Directory не установлен. Сделал предпринимаемые предупреждения, выберите вариант, который вы хотите использовать, и нажмите Далее.
5. Этот раздел спросит вас, должен ли он переадресовывать запросы на DNS-серверы с определенным IP или если это не должно.Выберите опцию, которую вы хотите использовать, введите любую необходимую информацию и нажмите Далее.
6. Наконец, подтвердите детали с вами, и «Готово» завершит процесс.

Зона прямого и обратного просмотра

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

1. Выберите, хотите ли вы создать зону обратного просмотра сейчас.
2. Нажмите Далее. Если вы выбрали, чтобы создать один сейчас, он перейдет на аналогичный экран к зоне переднего поиска, выбирая, какой вариант желательна. Однако, если вы решите не устанавливать зону обратного поиска, она закончит процесс.
3. Зона обратного просмотра использует тот же процесс, что и зона прямого просмотра, но требует информации rDNS.

Расширенный вид отображает зоны обратного поиска на 0, 127.0.0.1 и 255 трансляций. Это дополнительно отображает кэшированные поиски. Включите только продвинутый вид, если требуется диктует его, так как редактирование их может вызвать проблемы.

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

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

Если вы нажали Root Hint, он отправит вас в конец и завершит задачу. Если вы выберете параметры зоны прямого или прямого и обратного просмотра, он будет продолжен.

Опубликовано
⏰ 29.06.2019

Приветствую Вас, уважаемые читатели. Сегодня у нас тема: «DNS-сервер в Windows Server 2012-2016». И опять две ОС в одной статье. Статья о добавлении роли DNS-сервера, и создании зон просмотра.

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

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

Подготовительные действия

Так же как и в статье о Windows Server 2008, убеждаемся, что сетевой адаптер у Вас настроен должным образом. (Ip адресс, маска подсети, основной шлюз, DNS-сервера)

• В свойствах системы, заходим в «Изменить параметры», и в открывшемся окне жмём на «Изменить».

• В следующем окне, даём имя серверу (на Ваше усмотрение), и жмём на «Дополнительно».

Открывается следующее окно.

• Прописываем основной DNS-суффикс компьютера.(Имя домена Вашей сети)
• Жмём «ОК».

• В окне, изменения имени компьютера, так же жмём «ОК».

Выходит сообщение, о необходимости перезагрузить компьютер.

• Перезагружаем компьютер.

Добавление роли DNS-сервера

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

• Жмём «Далее», в окне памятке мастера.

• В окне, типа установки, нас интересует «Установка ролей и компонентов».
• Жмём «Далее».

В следующем окне нам нужно выбрать целевой сервер.

• Выбираем нужный сервер или виртуальный диск.
• Жмём «Далее».

Следующий шаг, это выбор ролей сервера.

• Выбираем DNS-сервер.

• Появляется окно с компонентами, необходимыми для функционала данной роли.
• Жмём «Добавить компоненты».

• И в окне, выбора ролей, жмём «Далее».

В следующем окне, можно выбрать дополнительные компоненты.

• Если что то нужно, выбираем.
• Жмём «Далее».

Окно с информацией о DNS-сервере.

• Жмём «Далее».

• Выходит сводка, устанавливаемых компонентов.
• Если ничего не забыли, то жмём «Установить».

• Ждём окончания установки.
• По окончании, жмём «Закрыть».

Настройка DNS-сервера

• Заходим в диспетчер сервера, в списке выбираем «DNS».
• В панели мониторинга появляется наш сервер, кликаем по нему правой кнопкой мышки, и выбираем «Диспетчер DNS».

• Открывается оснастка, выбираем наш сервер, кликаем правой кнопкой мышки, и выбираем «Настроить DNS-сервер».

• Открывается мастер.
• Жмём «Далее».

Открывается окно выбора действия.

• Выбираем «Создание зон прямого и обратного просмотра».
• Жмём «Далее».

• В следующем окне, выбираем «Да, создать зону прямого просмотра».
• Жмём «Далее».

Следующее окно, это выбор типа зоны.

• Выбираем «Основная».
• Жмём «Далее».

• Теперь нужно задать имя зоны.
• Задаём имя, и жмём «Далее».

Следующий шаг, это создание файла зоны.

• Выбираем «Создать новый», и жмём «Далее».

• В следующем окне, запрещаем динамические обновления. Мы будем сами обновлять информацию на сервере.
• Жмём «Далее».

• Далее нам предлагают создать зону обратного просмотра, ведь мы выбрали это в предыдущих шагах.
• Выбираем «Да, создать зону обратного просмотра сейчас».
• Жмём «Далее».

• В выборе типа зоны, выбираем «Основная».
• Жмём «Далее».

Далее окно выбора версии протокола, для зоны.

• Выбираем «Зона обратного просмотра IPv4».

• В открывшемся окне, указываем идентификатор зоны, и жмём «Далее».

Окно создания файла зоны.

• Выбираем «Создать новый файл», и жмём «Далее».

• Так же, как и при создании зоны прямого просмотра, запрещаем динамические обновления.
• Жмём «Далее».

• Сервер у нас в сети будет один, так что в следующем окне, выбираем вариант «Нет, не пересылать запросы».
• Жмём «Далее».

• Система начинает поиск корневых ссылок.

У нас нет подключения к интернету, поэтому результата не будет.

• Появляется окно, завершения настройки, жмём «Готово».

• Выходит сообщение, о неудаче в поиске корневых ссылок.
• Жмём «ОК».

Проверяем созданные зоны

• В диспетчере DNS, открываем вкладку «Зоны прямого просмотра», и видим созданную нами зону.

• Открываем вкладку «Зоны обратного просмотра», и так же видим зону, которую мы создали.

Сегодня мы рассмотрели тему: «DNS-сервер в Windows Server 2012-2016». Добавили роль DNS-сервера, и создали зону прямого, и зону обратного просмотра.

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

✍

С уважением, Андрей Бондаренко.

---

Видео на тему «DNS-сервер в Windows Server 2012»:

Видео на тему «DNS-сервер в Windows Server 2016»:

✧✧✧

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

WMZ-кошелёк = Z667041230317

---

✧ Рубрика «Windows server»

✧ Комментарии: нет

Похожие записи

Установка и настройка DNS-сервера и Active Directory в Windows Server 2016 практически не отличается от предыдущих выпусков серверов компании Microsoft, таких как Windows Server 2012, 2008. Пройдя несколько шагов устанавливается роль DNS и Доменные службы Active Directory, также для сервера имён потребуется небольшая настройка. 

Установка и настройка роли DNS-сервера и Доменные службы Active Directory

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

1. Нажимаем правой клавишей мыши на «Этот компьютер» и выбираем «Свойства». В открывшемся окне — «Изменить параметры» — «Изменить». Задаём имя компьютера и нажимаем «ОК». Для того, чтобы изменения вступили в силу, перезагружаем компьютер.

2. Для того, чтобы открыть сетевые соединения, в поле «Поиск» набираем команду ncpa.cpl. Выбираем нужный сетевой интерфейс, правой клавишей мыши — «Свойства». IP версии 6(TCP/IPv6) выключаем, если не используем. Затем выбираем IP версии(TCP/IPv4). Заполняем поля:

IP-адрес: адрес сервера (например, 192.168.100.5)

Маска подсети: маска сети (например, 255.255.255.0)

Основной шлюз: шлюз, если имеется (например, 192.168.100.1)

Предпочитаемый DNS-сервер: (например, 192.168.100.5)

3. Теперь можно начать установку ролей сервера. Для этого выбираем «Диспетчер серверов».

4. В следующем окне — «Добавить роли и компоненты».

5. Читаем «Перед началом работы» и нажимаем «Далее». Затем оставляем по умолчанию чекбокс «Установка ролей или компонентов» и снова «Далее». В следующем окне выбираем сервер, на который будем устанавливать роли и «Далее».

6. Выбора ролей сервера — ставим галочки напротив «DNS-сервера» и «Доменные службы Active Directory». При появлении запроса о добавлении компонентов — «Добавить компоненты». Затем «Далее».

7. В следующих окнах нажимаем «Далее», а в окне «Подтверждение установки компонентов» выбираем «Установить». Этот мастер можно закрывать, по окончании установки появится предупреждение в диспетчере серверов.

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

9. В следующем окне — «Добавить новый лес». Имя корневого домена — уникальное имя вашего домена.

10. В «Параметрах контроллера домена» оставляем по умолчанию режим работы леса и домена — «Windows Server 2016». Вводим пароль для режима восстановления служб каталогов (DSRM).Этот пароль может пригодиться, его обязательно надо запомнить или записать в надежное место.

11. В окне «Параметры DNS» — нажимаем «Далее».

12. В «Дополнительные параметры» — «Далее».

13. Расположение базы данных AD DS, файлов журналов и попок SYSVOL оставляем по умолчанию, нажимаем «Далее».

14. Проверяем параметры, затем «Далее».

15. После того, как сервер проверит соответствие предварительных требований, можно нажимать «Установить».

16. После настройки контроллера домена, можно перейти к настройке обратной зоны DNS-сервера. Для этого в «Диспетчер серверов» выбираем «Средства», далее «DNS».

17. В открывшемся окне выбираем наш сервер, затем «Зона обратного просмотра». Правой клавишей мыши — «Создать новую зону…».

18. В мастере создания новой зоны оставляем тип зоны — «Основная зона», затем «Далее».

19. Оставляем по умолчанию чекбокс на «Для всех DNS-серверов, работающих на контроллерах домена в этом домене, снова «Далее».

20. В следующем окне — «Зона обратного просмотра IPv4», затем «Далее».

21. Для настройки зоны обратного просмотра задаем «Идентификатор сети» (например 192.168.100). После этого появится автоматически зона обратного просмотра. Нажимаем «Далее».

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

23. Для завершения настройки создания новой зоны проверяем настройки и нажимаем «Готово».

24. Появится зона обратного просмотра для домена.

25. В «Диспетчере серверов» выбираем «Пользователи и компьютеры Active Directory». Проверяем работу Active Directory.

На этом установка и настройка выбранных ролей сервера заканчивается.

Посмотреть, что и как делать, можно здесь:

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

Установка и настройка DHCP — Windows Server 2016

Второй контроллер домена — Windows Server 2016

Создание и удаление пользователя, восстановление из корзины — Windows Server 2016

Ввод компьютера в домен — Windows Server 2016

Переименование учётной записи администратора домена — Windows Server 2016

Windows server 2019 — установка и настройка Active Directory, DNS, DHCP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверка

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

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

Из вывода команды видно, что по умолчанию используется 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-сервер – пожалуй, та инфраструктурная единица, функционал которой точно надо знать до мелочей. Ведь если с DNS будут проблемы – они же сразу появятся у всех зависимых сервисов – у той же Active Directory, например.

Встроенный в Windows Server компонент DNS прошёл долгий путь развития – но его функциональность, безусловно, ещё далека от совершенства. Шаги в нужном направлении делаются, и сегодня мы поговорим про нововведение в Windows Server 2016 (он же Windows 10 Server, он же Windows Server Threshold, он же CloudOS) – возможность фильтрации и управления обработкой запросов (как на разрешение имён, так и на трансфер зон) на уровне DNS-сервера. Ранее управлять можно было на уровне клиента (см. мою статью про NRPT) – ну а аналога bind’овых view не было.

Я предполагаю, что вы знакомы с работой DNS-сервера на уровне хотя бы MCSA : Windows Server и обладаете углублённым знанием вопросов безопасности на уровне материала статьи про защиту DNS Server.

Начнём.

Фильтрация запросов и трансфера зон в Windows Server 2016

• Зачем фильтровать запросы к DNS-серверу
• Подготовка к фильтрации запросов – размечаем подсети с клиентами
• Подготовка к фильтрации запросов – добавляем zone scope
• Добавляем в зону A-запись, видимую только для определённого zone scope
• Добавляем к зоне политику обработки запросов
• Различные варианты применения политик запросов
• Политики обработки рекурсии
• Политики передачи DNS-зон
• Общие правила применения политик

Зачем фильтровать запросы к DNS-серверу

Фильтрация запросов к DNS-серверу нужна для решения ряда базовых задач безопасности и производительности. Например, если ваш DNS-сервер стоит в регионе строго как кэширующий, то ему нет никакого смысла пытаться обрабатывать что запросы не из местных сетей, что из внешней. Равно как и внешний DNS-сервер на площадке провайдера, который нужен для ускорения обработки запросов ваших клиентов, которые находятся вне сети предприятия – ему тоже неплохо бы заниматься только тем, чем надо, а не быть открытым DNS-прокси.
 
Безусловно, есть базовые задачи фильтрации – например, привязать DNS-сервер только к определённым IP-адресам на определённых интерфейсах, чтобы входящие запросы с других сторон его не интересовали – равно как и можно просто закрыть встроенным Windows Advanced Firewall’ом доступ к портам DNS-сервера. Всё это – также меры фильтрации запросов, но предполагается, что вы их уже используете и нужна более тонкая обработка.
 
Это мы и сделаем.

Подготовка к фильтрации запросов – размечаем подсети с клиентами

Обычно администратор Active Directory прописывает привязку сетей и подсетей к сайтам Active Directory – для оптимизации скорости логина с рабочих станций и member-серверов. В нашем случае механизм будет не привязан к Active Directory, т.к. фильтровать запросы каждый DNS-сервер в организации может по индивидуальной логике – да и необязательно для этого быть членом домена.
 
Для того, чтобы определить подмножество адресов, запросы из-под которого будут обрабатываться специфичным образом, нам надо будет сделать следующее – придумать ему название (удобное для нас, чтобы идентифицировать проще) и добавить данную именованную связку имя+сеть в локальный DNS-сервер. Это делается следующим командлетом:
 
Add-DnsServerClientSubnet -Name "MSK_VLAN_201" -IPv4Subnet 10.1.201.0/24
 
Синтаксис вполне тривиален – создан объект-“сеть” с именем MSK_VLAN_201 и к нему привязана IPv4-сеть 10.1.201/24. Если хочется привязать IPv6-сеть – используйте -IPv6Subnet.
 
Эти данные DNS-сервер записал в свою локальную конфигурацию – в частности, в ветку HKEY_LOCAL_MACHINE SOFTWARE Microsoft Windows NT CurrentVersion DNS Server ClientSubnets:
 

 
ОК, теперь надо добавить к DNS-серверу именованные объекты, нужные для применения политик – “zone scope”.

Подготовка к фильтрации запросов – добавляем zone scope

Механизмы фильтрации и управления политиками обработки запросов – новые и реализуются через дополнительные объекты, “привязываемые” к конкретному DNS-серверу или зоне на нём. Нам надо будет создать такой объект – мы выберем вариант привязки к зоне и это несложно сделаем:
 
Add-DnsServerZoneScope -ZoneName "atraining.test" -Name "ScopeMSK_1"
 
Синтаксис опять же тривиален – создан именованный объект ScopeMSK_1, привязанный к DNS-зоне atraining.test. Замечу, что пока что привязывать такие объекты можно только к зонам, не интегрированным в Active Directory – что намекает на использование в провайдерских и кэширующих сценариях. Можно создать и для другого DNS-сервера – тогда его надо указать в параметре -ComputerName.
 
Вот что в результате создаст DNS-сервер в реестре:
 

 
И в каталоге %WINDIR% system32 dns :
 

 
ОК, теперь добавим запись, которая будет существовать только для тех, кто подпадёт под данный zone scope (замечу, что мы ещё не привязали клиентский диапазон к scope – это предстоит сделать).

Добавляем в зону A-запись, видимую только для определённого zone scope

Для добавления записи, видимой только в определённом zone scope, нам опять-таки нужен PowerShell – графического интерфейса нет (надеюсь, что пока нет, а к Windows Server 2016 RTM всё ж добавится). Командлет
 
Add-DnsServerResourceRecord -ZoneName "atraining.lab" -A -Name "server1" -IPv4Address "192.168.0.1" -ZoneScope "ScopeMSK_1"
 
выполнит эту задачу – запись появится в файле zone scope, который мы только что создали (кстати, её можно туда вписать руками безо всякого командлета, эффект будет такой же).
 
Теперь соединим вместе всё вышесозданное политикой, говорящей что наконец-то со всем этим делать.

Добавляем к зоне политику обработки запросов

Политика обработки запросов будет уже сложнее, чем первоначальные операции по именованию отдельных сущностей. Что нам надо будет указать в командлете Add-DnsServerQueryResolutionPolicy, помимо очевидного параметра -Name, указывающего имя политики?
 

Параметр -ClientSubnet

В данном параметре вы указываете логическое выражение, описывающее то, к кому из клиентов (тех, кто запрашивает) применима данная политика. Логическое выражение содержит две части – EQ и NE. В части eq можно указать одну или более клиентских сетей, притом, если указать несколько, то логика объединения будет “или”. Например:
 
-ClientSubnet "EQ,MSK_VLAN_201"
 
укажет, что создаваемая нами политика будет срабатывать в случае поступления запроса из-под адресов, подпадающих под ранее определённый client subnet object с именем MSK_VLAN_201, а вариант
 
-ClientSubnet "EQ,MSK_VLAN_201,MSK_VLAN_202"
 
скажет, что срабатывать надо и в случае подпадания под MSK_VLAN_201, и под MSK_VLAN_202. Т.е. вы можете сделать одну политику обработки, привязав к ней пачку разных именованных сетей – это удобно.
 
Часть NE будет действовать обратно – исключать из множества EQ подмножество. То есть в варианте:
 
-ClientSubnet "EQ,MSK_VLAN_201,MSK_VLAN_202,NE,SPECIAL_SUBNET_VLAN_201"
 
запрос будет обработан DNS query-политикой в случае, если он подпадёт под любой из двух указанных диапазонов, но не будет подпадать под SPECIAL_SUBNET_VLAN_201. Можно указать несколько диапазонов после NE – тогда они будут объединяться по логике “если подпадёт под хотя бы один, не обрабатывается”.
 
Вариантов применения множество – вы можете создать, например, клиентский диапазон из частных сетей, используемых в вашей организации, и запретить ему обрабатываться политикой для разрешения внешних имён в организации – это поможет при split-brain в случае одноимённо названного домена Active Directory и интернет-домена.

Параметр -InternetProtocol

Этот параметр в схожем с предыдущим синтаксисе позволит указать, для запросов, пришедших по каким IP-протоколам будет работать наша политика. Примеры синтаксиса просты:
 
-InternetProtocol "EQ,IPv4,IPv6"
 
В этом варианте – для всех.
 
-InternetProtocol "EQ,IPv4,NE,IPv6"
 
А тут только для IPv4-запросов. Обратите внимание – речь не про то, какие адреса запрашиваются – т.е. не про A / AAAA записи, например – а про то, каким протоколом пользуется клиент для доставки запроса DNS-серверу. Может возникнуть вопрос – зачем это надо, ведь мы и так в Client Subnet указывали сеть, из неё явно следует, какой протокол будет использоваться? Да, указывали, но Client Subnet – самостоятельный объект, который может включать в себя и IPv4-сеть и IPv6-сеть – а политики могут, используя этот объект (и не плодя дополнительные), различно обрабатывать запросы, пришедшие по разным сетевым протоколам. Следующий параметр будет примерно про это же:

Параметр -TransportProtocol

То же, но не для сетевого, а для транспортного уровня. Запросы на ваш DNS-сервер могут приходить разными способами (про тонкости в части UDP / TCP можно посмотреть в статье про настройку ENDS0 на Windows Server), и можно адресно сказать политике, про какой протокол идёт речь. Синтаксис тот же:
 
-TransportProtocol "EQ,UDP"
 
или, если по всем –
 
-TransportProtocol "EQ,UDP,TCP"

Параметр -ServerInterfaceIP

Ранее можно было просто привязать службу DNS Server к явно указанным интерфейсам и отдельным адресам на них. Теперь можно ещё лучше – привязать политику к конкретному адресу, на котором слушает запросы DNS Server. Простой пример – например, если у вас развёрнуто шлюзовое решение или просто есть сервер с интерфейсами в несколько L2-сред, вы можете явно указать, что, допустим, при входящем запросе с внешнего адреса не надо ресолвить имена вида “*.ourdomain.local”. Синтаксис прост:
 
-ServerInterfaceIP "EQ,1.2.3.4"
 
где 1.2.3.4 – IP-адрес на одном из интерфейсов. Если добавить тот адрес, на котором DNS-сервер не слушает – просто ничего не произойдёт, т.е. этот IP не появится на интерфейсе и не начнёт принимать от всех DNS-запросы.

Параметр -Fqdn

Здесь ситуация ещё интереснее – это фильтр по тому, какое имя разрешает клиент (тип записи здесь не играет роли). При этом, можно использовать wildcard:
 
-Fqdn "EQ,*.atraining.lab,NE,*.test.atraining.lab"
 
В данном примере политика обработает запрос, если он про что-то внутри atraining.lab, но что не подпадает под *.test.atraining.lab.

Параметр -QType

Этот параметр поможет дополнительно отфильтровать входящие запросы по типу запрашиваемых записей. То есть можно сделать, допустим, две политики, которая будет реагировать только на запросы MX и выдавать одни адреса почтовых серверов, когда запрос из внутренней сети (например, какому-нибудь серверу надо отправить служебное сообщение на адрес администратора), и другие – когда снаружи (обычный приём почты из внешнего мира). Синтаксис -QType будет уже знаком:
 
-QType "EQ,A,AAAA"
 
или
 
-QType "EQ,A,AAAA,NE,PTR"

Параметр -TimeOfDay

Это, что исключительно логично, про время суток. Вы можете задать диапазоны (считаться будет во времени сервера, в 24х часовом формате), во время которых запросы данной политикой (если ещё не ошалели от перечня параметров – вот мы всё это время допиливаем политику, которая будет говорить когда, какие запросы, из-под каких сетей и их совокупностей, в какой именно scope у какой именно зоны будут попадать) будут обрабатываться. Формат прост – диапазоны через дефис:
 
-TimeOfDay "EQ,8:00-21:00"
 
В этом случае данная политика будет работать только если запрос пришёл на сервер, и на локальных системных часах время от 8:00 до 21:00.

Параметры -ZoneScope и -ZoneName

Тут всё просто – -ZoneName будет указывать имя DNS-зоны, с которой идёт работа, а вот -ZoneScope будет указывать тот zone scope (удобно, кстати, сокращать до звучного zope), для которого это будет применяться. Притом можно задать и несколько – главное, правильно распределить веса для используемых zone scope. Пример:
 
-ZoneScope "ScopeMSK_1,100"
 
В этом случае всё просто – данные для ответа политика будет доставать из ScopeMSK_1. Или так:
 
-ZoneScope "ScopeMSK_1,50,ScopeMSKRes_1,100"

Параметр -ProcessingOrder

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

Параметр -Action

Ключевой параметр – что делать-то, если запрос пробрался сквозь дебри условий. Вариантов будет три. Первый – ALLOW – разрешить обработку запроса. Второй – тихо проигнорировать – IGNORE. И явно ответить, что сервер не хочет обрабатывать запрос – т.е. отправить SERV_FAIL – третий вариант, DENY.
 
Теперь наконец-то включим нашу политику:
 
Add-DnsServerQueryResolutionPolicy -Name "MSKUsers" -Action ALLOW -InternetProtocol "EQ,IPv4" -ClientSubnet "EQ,MSK_VLAN_201" -ZoneScope "ScopeMSK_1,100" -ZoneName "atraining.test"
 
Смотрим, как она выглядит локально:
 

 
Вполне прилично – да и править, если что, всё понятно где и как. Увидеть факт, что она привязалась к конкретной зоне и работает (да и вообще все политики, которые есть на этой зоне) можно так:
 
Get-DnsServerQueryResolutionPolicy -ZoneName "atraining.test"
 
Теперь, когда к нам придёт запрос с IP-адресом из диапазона 10.1.201.0/24, мы обработаем его исходя из содержимого ScopeMSK_1.
 
Если после хочется отключить или заново включить политику (не удаляя её и не вводя заново) – есть удобная пара командлетов:
 
Enable-DnsServerPolicy -Level Zone -ZoneName "atraining.test" -Name "MSKUsers"
 
и Disable-DnsServerPolicy с достаточно очевидным синтаксисом.
 
Обратите внимание, сейчас мы разбираем работу и привязку политики к конкретной DNS-зоне. Можно применять политики и на уровне сервера.

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

Например:

Имитируем управляемый netmask ordering

Механизм netmask ordering есть в DNS server с незапамятных времён. И работает вроде просто – но вот привязан к классовым сетям и не даёт возможность детально описать структуру современной сети. Поправим это, например, так:
 
Предполагаем, что есть организация, где несколько регионов, и надо выдавать всем клиентам правильный IP-адрес локального DFS-хранилища файлов (например, DP для SCCM 2012):
 
Add-DnsServerClientSubnet -Name "MSK_VLAN_Users1" -IPv4Subnet 10.1.201.0/24
 
Add-DnsServerClientSubnet -Name "SPB_VLAN_Users1" -IPv4Subnet 10.2.11.0/24
 
Add-DnsServerClientSubnet -Name "NSK_VLAN_Users1" -IPv4Subnet 10.3.1.0/24
 
Теперь на сервере заведём zone scope’ы для всех регионов:
 
Add-DnsServerZoneScope -ZoneName "firma.local" -Name "ScopeMSKUsers1"
 
Add-DnsServerZoneScope -ZoneName "firma.local" -Name "ScopeSPBUsers1"
 
Add-DnsServerZoneScope -ZoneName "firma.local" -Name "ScopeNSKUsers1"
 
Добавим варианты адреса сервера для каждого региона:
 
Add-DnsServerResourceRecord -ZoneName "firma.local" -A -Name "filesrv" -IPv4Address "10.1.201.252" -ZoneScope "ScopeMSKUsers1"
 
Add-DnsServerResourceRecord -ZoneName "firma.local" -A -Name "filesrv" -IPv4Address "10.2.11.100" -ZoneScope "ScopeSPBUsers1"
 
Add-DnsServerResourceRecord -ZoneName "firma.local" -A -Name "filesrv" -IPv4Address "10.3.1.2" -ZoneScope "ScopeNSKUsers1"
 
И теперь политики обработки запросов:
 
Add-DnsServerQueryResolutionPolicy -Name "MSKUsers1" -Action ALLOW -InternetProtocol "EQ,IPv4" -ClientSubnet "EQ,MSK_VLAN_Users1" -ZoneScope "ScopeMSKUsers1,100" -ZoneName "firma.local"
 
Add-DnsServerQueryResolutionPolicy -Name "SPBUsers1" -Action ALLOW -InternetProtocol "EQ,IPv4" -ClientSubnet "EQ,SPB_VLAN_Users1" -ZoneScope "ScopeSPBUsers1,100" -ZoneName "firma.local"
 
Add-DnsServerQueryResolutionPolicy -Name "NSKUsers1" -Action ALLOW -InternetProtocol "EQ,IPv4" -ClientSubnet "EQ,NSK_VLAN_Users1" -ZoneScope "ScopeNSKUsers1,100" -ZoneName "firma.local"
 
Enable-DnsServerPolicy -Level Zone -ZoneName "firma.local" -Name "MSKUsers1"
 
Enable-DnsServerPolicy -Level Zone -ZoneName "firma.local" -Name "SPBUsers1"
 
Enable-DnsServerPolicy -Level Zone -ZoneName "firma.local" -Name "NSKUsers1"
 
Теперь у нас для запроса из каждого региона (в который мы можем добавить сколько хочется каких нужно сетей) будет отдаваться свой адрес сервера filesrv.firma.local – и всё в явном виде прописано и под контролем.
 
Можно придумать и схему с усилением безопасности (DNS-сервер отвечает верно только для известных ему сетей – если где-то в организации будет новая сеть, из которой начнут приходить запросы, он не ответит, пока явно её не пропишут в ClientSubnet), и с шлюзом с несколькими интерфесами (запросы из-под внешнего интерфейса разрешают atraining.ru в адрес внешнего сайта, а из-под других интерфейсов – в адрес ближайшего к спрашивающему DC), и много другого. Но мы продолжим изучать другие варианты политик – запросами клиентов всё не ограничивается.

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

Ещё одним нововведением будут политики обработки рекурсивных запросов. Суть проста – в случае, если приходящий запрос имеет бит “хочу рекурсию” (т.е. клиенту нужен финальный ответ, а не любая помощь в нахождении оного), теперь можно повлиять на то, и будет ли рекурсивный запрос для нужного подмножества query вообще обрабатываться (т.е. разрешат ли рекурсию или пришлют отбой клиенту), и на какие форвардеры уйдёт запрос. Т.е. это более гибкий вариант conditional forwarders плюс новая фильтрация. Такие политики будет применимы только на уровне сервера.
 
Посмотрим, как это делается.
 
Вначале надо создать именованную группу forwarder’ов – к ней мы будем привязывать политику обработки запросов.
 
Add-DnsServerRecursionScope -Name "PartnerADForest1" -Forwarder 178.159.49.228 -EnableRecursion $true
 
Эта политика будет указывать, что когда запрос будет удовлетворять всем запросам, то он будет перенаправлен на заданный IPv4-адрес. Адресов может быть и несколько – через запятую. Параметр -EnableRecursion будет указывать на то, будет ли запрашиваться рекурсия для отправленного запроса. Если этот параметр скинуть в $false – то запрос уйдёт на адрес, но ответ будет приниматься только если отвечающий сервер является держателем зоны, из которой выдаётся ответ – т.е. дальнейшая передача запроса кому-нибудь ещё отменяется.
 
Теперь можно сделать политику, которая скажет, что запросы от определённой группы клиентов (как указать тучу других параметров – см.выше) могут, если уже прописан форвардинг (это важно – политики именно указывают как обрабатывать запросы), уходить по указанному адресу.
 
Add-DnsServerQueryResolutionPolicy -Name "MSKUsersPartnerTrust1" -ApplyOnRecursion -Action ALLOW -ClientSubnet "EQ,MSK_VLAN_Users1" -RecursionScope "ScopeMSKUsers"
 
Особенностей, как видно, всего две – добавление параметра -ApplyOnRecursion, который укажет, что речь про политику, связанную с рекурсией, и параметр -RecursionScope (вместо -ZoneScope), который привязывает к политике конкретную группу форвардеров.
 
Можно, кстати, также повлиять на то, как обрабатывается стандартный список форвардеров в DNS-сервере – он выступает под именем точки:
 
Set-DnsServerRecursionScope -Name . -EnableRecursion $true
 
Т.е. например выключить рекурсию на нём, лично. В стандартном интерфейсе этого нет:
 

 
Впрочем, больше настроек форвардинга и раньше реализовалось через PowerShell (см. статью про безопасную настройку DNS Server, пункт про настройку форвардеров).
 
Теперь вы можете достаточно тонко настроить работу, связанную с ситуацией “пришёл запрос, а локально наш DNS-сервер на него ответить не может” – опять же, указывая IP-сети, время, входящие интерфейсы, и многое другое. Да и безопасность сделать повыше – например, у вас есть партнёр со своим лесом Active Directory, с которым у вас forest trust. Раньше вы могли прописать conditional forwarder на все его DNS, доступные снаружи, да и всё. Теперь вы можете детально прописать – запросы из каких подсетей должны иметь возможность туда уходить (например, есть принтерная подсеть или management vlan, где строго интерфейсы сетевых устройств – им-то зачем?), плюс добавить отключение рекурсии – ведь если вы спрашиваете у DNS-сервера соседа, у которого зона partnerdomain.local, про хост dc1.partnerdomain.local – какой смысл в рекурсии? У кого он переспросит, если он авторитативен за эту зону?
 
Так что штука безусловно полезная. Продолжим, впереди – трансфер зон.

Политики передачи DNS-зон

Внутри организации, когда есть Active Directory, этот вопрос решён уже давно – DNS-записи будут отдельными объектами AD, и будут реплицироваться так же, как все остальные. Но в случае наличия других DNS-серверов – которые вне Active Directory, например в DMZ или на площадке у провайдера, вопрос поднимается вновь. Раньше можно было поработать с тайм-аутами и AXFR/IXFR передачей зон, ну и со всякими уведомлениями и прочим (см. про безопасную настройку трансфера зон в DNS Server), но теперь можно и просто зафильтровать именно запросы на трансфер.
 
Многие спросят – но ведь это можно и на обычном Windows Advanced Firewall, просто 53 TCP закрыть для неправильных адресов, да и всё. Это ошибка – DNS-сервер по 53 TCP обрабатывает не только трансферы, но и запросы на разрешение имён, да и закрыть только по критерию принадлежности к IPv4-сети – не очень. Политики позволят закрыть именно трансферы и с доп.параметрами для тонкой настройки условий.
 
Add-DnsServerZoneTransferPolicy -Name "AllowOnlyDCTransfer" -Action IGNORE -ClientSubnet "NE,OurDCNetwork"
 
Этот командлет будет тихо игнорировать все запросы, которые придут и не подпадут под объект OurDCNetwork (это, допустим, наша внешняя сетка в датацентре, из-под которой наши сервера оттуда общаются с серверами в организации). Можно и явно отправлять SERV_FAIL – для этого IGNORE надо заменить на DENY. Можно добавить -ServerInterfaceIP, -TransportProtocol, и многие другие параметры – выбирайте.
 
Не забывайте только, что политика добавляется сразу включённой – этого можно избежать, добавив ключ -Disabled, ну а после включить тем же командлетом Enable-DnsServerPolicy.

Общие правила применения политик

Политики обработки рекурсии будут срабатывать только если пришёл запрос с битом “хочу рекурсию”, и только если не получилось ответить на него локально.
 
Политики обработки запросов будут уровня сервера и уровня зоны. Политики уровня сервера будут применяться первыми и ограничены только запретительными действиями – а на уровне зоны уже можно будет работать с логикой “разрешить только указанным”. Последними будут срабатывать политики обработки рекурсии.
 
Приоритет обработки задаётся параметром -ProcessingOrder – самой главной, в случае если несколько политик подпали под критерии, будет политика с минимальным числовым приоритетом.
 
Не путайте приоритет с весом – в варианте -ZoneScope "ScopeMSK_1,50,ScopeMSKRes_1,100" запросы будут распределяться между zone scope согласно соотношению весов (в примере – 1/3 в ScopeMSK_1, 2/3 запросов – в ScopeMSKRes_1).
 
А в остальном – в общем, всё логично и несложно.

Напоследок

Новый функционал – очень гибкий и полезный. Он и даёт новые возможности, и улучшает уровень безопасности. Так что ждём релиза Windows Server 2016 и применяем.
 
Удач!
 

В этой статье рассмотрим основные команды, которые можно использовать для управления DNS сервером в Windows Server 2016 с помощью утилиты PowerShell, без использования графической консоли DNS.

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

Модуль Windows DNS впервые был представлен в Windows Server 2008 R2. При помощи данного модуля можно было выполнять около 40% задач управления сервером DNS. В Windows Server 2016 функционал модуля был существенно расширен, и теперь наверно все 100% задач администрирования DNS сервера можно выполнять из CLI без использования графической консоли.

Для того, чтобы начать работу и вывести все доступные команды модуля DNSServer, необходимо открыть PowerShell и выполнить команду:

Get-Command -Module dnsserver

Как видите, в модуле имеется 134 команды.

Создадим новую первичную DNS зону с именем devtest.local:

Add-DnsServerPrimaryZone -Name devtest.local -ZoneFile devtest.dns

Чтобы вывести все зоны, доступные на этом сервере, выполните команду:

Get-DnsServerZone

Чтобы создать DNS зону обратного просмотра (Lockup Zone), воспользуемся командой:

Add-DnsServerPrimaryZone -NetworkId "172.23.106.0/24" -ReplicationScope Domain

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

add-DnsServerResourceRecordA -Name host1.devtest.local -IPv4Address 192.168.100.30 -ZoneName devtest.local

Для того, чтобы синхронизировать вашу DNS эону с другим DNS-сервером:

Sync-DnsServerZone –PassThru

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