Автор статьи — Андрей Каптелин, участник ИТ-сообщества

С выходом Windows Server Technical Preview 2 многие службы получили обновления. Не обошли обновления стороной и заслуженный сервер имен DNS. Помимо поддержки управления DNS-сервером из PowerShell, появилась новая возможность – DNS policy.

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


Принцип работы


Политики применяются к трем категориям запросов:
  • Запрос на разрешение записи. Все обычные запросы на разрешение имени в IP-адрес, или получение значений TXT-, MX- и SRV-записей.
  • Запрос на передачу зон. Запросы от ваших вторичных серверов на обновление информации о зоне. Если такой запрос будет выполнен для чужого сервера, он получит всё содержимое вашей зоны.
  • Запрос, для выполнения которого нужно выполнить рекурсивный запрос. Например, клиент запросил имя, находящееся не в ваших зонах. Сервер должен переспросить вышестоящий сервер для получения результата. Для внешних клиентов обрабатывать такие запросы нужно не всегда.

Область применения политики может быть, как на весь сервер, так и на конкретную зону, если эта зона не интегрирована в Active Directory.

Политики DNS-сервера позволяют реализовать следующие действия:
  • Создавать зону с различным набором записей.
  • Классифицировать клиента по его IP-адресу и использовать это в правилах применения политик.
  • Применять политики на весь сервер и на зоны, не интегрированные в АД.
  • Применять различные политики в зависимости от интерфейса, получившего запрос.
  • Применять политики в зависимости от времени суток.
  • Применять политики по типу запрашиваемых записей.
  • Отвечать на запросы данными из различных версий зоны в заданных пропорциях, похоже на управляемый Round Robin.
  • Применять политики для пересылки зон.
  • Применять нужную политику по фильтру, если для завершения запроса нужно выполнить рекурсию.
  • Располагать политики в нужном порядке обработки.

Все созданные политики сохраняются в реестре в следующих разделах:

Заданные подсети, используемые в правилах применения политик, хранятся в разделе реестра
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\ClientSubnets

Политики, применяемые на сервер, хранятся в разделе реестра
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Policies

Политики, применяемые к конкретной зоне, хранятся в разделе реестра
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones\{имя зоны}\Policies

Зоны, используемые в правилах рекурсивных запросов, хранятся в разделе реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters\ServerScopes

Значение о состоянии рекурсии для всего сервера (используется зона ".") хранится в разделе
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

Ключ NoRecursion равен «0» — рекурсия включена, «1» — выключена. Переключение из включенного в выключенное состояние, требует перезапуска службы DNS-сервера.

Если для зоны создается альтернативное содержание (Add-DnsServerZoneScope), оно помещается в файле, размещенном в
C:\Windows\System32\dns\{имя зоны}
А конфигурация записывается в реестр
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DNS Server\Zones\{имя_зоны}\ZoneScopes\

При удалении альтернативной версии зоны, запись в реестре удаляется, а файл альтернативного содержания остаётся на месте.

Несмотря на обилие мест расположения настроек, для их изменений достаточно несколько команд PowerShell.

Для работы с политиками запросов разрешения записи и рекурсивных запросов:
Add-DnsServerQueryResolutionPolicy
Get-DnsServerQueryResolutionPolicy
Set-DnsServerQueryResolutionPolicy
Remove-DnsServerQueryResolutionPolicy

Для работы с запросами по передаче зон:
Add-DnsServerZoneTransferPolicy
Get-DnsServerZoneTransferPolicy
Set-DnsServerZoneTransferPolicy
Remove-DnsServerZoneTransferPolicy

Действия выполнения политик могут быть следующие:
-Action ALLOW – запрос выполняется сервером DNS
-Action DENY – сервер DNS отвечает отказом
-Action IGNORE – запрос не обрабатывается сервером DNS

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

Схема обработки запросов разрешения записи и рекурсивных запросов:



Схема обработки запросов на передачу зон:



Примеры


Настройка ограничения выполнения рекурсивных запросов


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

# Запрещаем рекурсию на область «.» - т.е. на уровне сервера
Set-DnsServerRecursionScope -Name . -EnableRecursion $False
# Добавляем область для внутренних клиентов с разрешением выполнения рекурсивных запросов
Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True
# Создаём правило, разрешающее рекурсивные запросы
Add-DnsServerQueryResolutionPolicy -Name "SplitBrainRecursionPolicy" -Action ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP "EQ,10.0.0.39" 

Разберём команду создания политики подробнее.
Add-DnsServerQueryResolutionPolicy – командлет создания политики обработки запросов на разрешение записей и рекурсивных запросов.
-Name «SplitBrainRecursionPolicy» – имя политики
-Action ALLOW – действие политики – выполнить запрос
-ApplyOnRecursion – политика обрабатывает только запросы, для которых нужно выполнить рекурсивный запрос
-RecursionScope «InternalClients – получает значение разрешения или запрета рекурсии заданной ранее области
-ServerInterfaceIP „EQ,10.0.0.39“ – правило применения политики – только запрос, пришедший на интерфейс сервера с IPv4-адресом равным 10.0.0.39.

Модификация ответа на запрос разрешения имени


В компании есть отказоустойчивый веб-сервер, размещенный на двух площадках – в Европе и в Австралии. Скорость работы обоих площадок всегда одинакова, но в ночные часы стоимость аренды меньше. Компания решила задействовать площадки в зависимости от времени суток. Для этого принято решение распределять запросы клиентов в процентном отношении 80/20 на ночной и дневной датацентр.

# Создаём версии зоны для Европы и Австралии 
Add-DnsServerZoneScope -ZoneName "testzone.z" -Name "EuropeDC"
Add-DnsServerZoneScope -ZoneName "testzone.z" -Name "AustralianDC"

# Создаём запись для веб-сервера в новых зонах с указанием на разные датацентры 
Add-DnsServerResourceRecord -ZoneName "testzone.z" -A -Name "www" -IPv4Address "1.1.1.1" -ZoneScope "EuropeDC"
Add-DnsServerResourceRecord -ZoneName "testzne.oz" -A -Name "www" -IPv4Address "2.2.2.2" -ZoneScope "AustralianDC"

# Создаём политики обработки запросов по наших условиям
Add-DnsServerQueryResolutionPolicy -Name "www-6-18" -Action ALLOW -ZoneScope "AustralianDC,4;EuropeDC,1" –TimeOfDay “EQ,06:00-18:00” -ZoneName "testzone.z" –ProcessingOrder 1
Add-DnsServerQueryResolutionPolicy -Name "www-0-6" -Action ALLOW -ZoneScope "AustralianDC,1;EuropeDC,4" –TimeOfDay “EQ,00:00-06:00” -ZoneName "testzone.z" –ProcessingOrder 2
Add-DnsServerQueryResolutionPolicy -Name "www-18-24" -Action ALLOW -ZoneScope "AustralianDC,1;EuropeDC,4" –TimeOfDay “EQ,18:00-23:59” -ZoneName "testzone.z" –ProcessingOrder 3

Разберём команду создания политики подробнее.
Add-DnsServerQueryResolutionPolicy – командлет создания политики
-Name „www-6-18“ – имя политики
-Action ALLOW – действие политики – выполнить запрос
-ZoneScope „AustralianDC,4;EuropeDC,1“ – указывает политике, использовать две версии зоны в пропорциях 4 к 1, получая требуемое соотношение 80% к 20% в выдаче данных из версии зоны для Европы и Австралии
–TimeOfDay “EQ,06:00-18:00” – Время действия политики
-ZoneName „testzone.z“ – имя зоны, для которой действует политика
–ProcessingOrder 1 – очередность применения политики, для политик этой зоны

Ограничение запросов на передачу зон


В компания имеется основной DNS-сервер для внешних зон и два вторичных DNS-сервера, размещенных у разных провайдеров. Запретить сетевым экраном обращение к основному серверу по протоколу TCP на 53-й порт не представляется возможным, т.к. зоны имеют записи, превышающие размер пакета UDP. Решено использовать для этих целей DNS policy.

# Создаём диапазоны адресов наших вторичных DNS-серверов
Add-DnsServerClientSubnet -Name "DNSsecondary1" -IPv4Subnet 4.4.4.4/32
Add-DnsServerClientSubnet -Name "DNSsecondary2" -IPv4Subnet 5.5.5.5/32
# Создаём политику обработки запросов на перенос зон
Add-DnsServerZoneTransferPolicy -Name "Allow secondary DNS" -ZoneName "testzone.z" -Action IGNORE -ClientSubnet "ne,DNSsecondary1,DNSsecondary2"

Разберём команду создания политики подробнее.
Add-DnsServerZoneTransferPolicy – командлет создания политики обработки запросов на перенос зон
-Name „Allow secondary DNS“ – название политики
-ZoneName „testzone.z“ – название зоны, для которой будет действовать политика
-Action IGNORE – действие политики
-ClientSubnet „ne,DNSsecondary1,DNSsecondary2“ – условие применения для всех кроме наших серверов

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

Ссылки по теме


DNS Policies Overview
Статьи в блоге Windows Networking Team [MSFT]

Комментарии (9)


  1. alex_www
    17.07.2015 18:36

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


    1. navion
      19.07.2015 03:02
      -1

      1. alex_www
        19.07.2015 19:20
        -1

        Вы сами ссылку смотрели? Там ни слова прo то что я спросил.


        1. navion
          19.07.2015 20:28
          +2

          Я ошибочно предположил, что вы сможете разобраться в навигации и потому дал ссылку на корневую страницу про DNSSEC.
          Специально для вас:
          1. Общие данные по DNSSEC в Windows Server 2012:
          technet.microsoft.com/en-us/library/dn593674.aspx#support
          2. Немного про параметры KSK:
          technet.microsoft.com/en-us/library/dn593642.aspx#ksk_config


          1. alex_www
            20.07.2015 03:54

            Вторая ссылка то что надо. Да навигация ужасная.


  1. Vinchi
    18.07.2015 09:27

    А можно пример использования при отказе одного из датацентров, чтобы записи шли на доступные сервера?


    1. ashapo Автор
      21.07.2015 10:08

      Сформулируйте, пожалуйста, вопрос более развернуто. О каких записях идет речь и чего хочется достичь?


  1. Ivan_83
    18.07.2015 14:59
    +1

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

    За время потраченное на выдумывание и вбивание этих политик можно поставить bind/nds, разобраться в их конфиге и спокойно в текстовом редакторе сочинить и написать всё что нужно.
    И потом скопировать файлы с настройками на 100500 серверов и в бэкап за считанные секунды.

    И сам пример тоже оторван от жизни.
    Гораздо чаще этот ДНС нужен только для АД, притом что домен реальный и где то у хостера находится почта и сайт.
    В итоге нужно выкручиваться чтобы сайт хотя бы по www открывался и почта через pop/imap+smtp бегала, тут бы по хорошему эти записи искать не в своей базе а в инете. А так приходится ручками заводить и следить за актуальностью.


    1. ashapo Автор
      20.07.2015 09:46

      Дело вкуса