Windows dns 2016 and 1709 server query overload

This topic describes Response Rate Limiting which is the Domain Name System (DNS) server functionality in Windows Server 2016 and 2019. It prevents the possibility of malicious systems using your DNS servers to initiate a denial of service attack on a DNS client.

By configuring RRL settings it can be controlled how to respond to requests to a DNS client when your server receives several requests targeting the same client. This will prevent someone from sending a Denial of Service (DoS) attack on your DNS servers. For instance, a botnet can send requests to your DNS server using the IP address of a third computer as the requestor. Without RRL, your DNS servers might respond to all the requests, flooding the third computer. Using RRL, you can configure the following settings:

·        Responses per second. This is the maximum number of times the same response will be given to a client within one second.

·        Errors per second. This is the maximum number of times an error response will be sent to the same client within one second.

·        Window. This is the number of seconds for which responses to a client will be suspended if too many requests are made.

·        Leak rate. Determines how often the DNS server responds to queries if a client is in the suspension window. The leak rate is the number of queries it takes before a response is sent. A leak rate of 42 means that the DNS server only responds to one query out of every 42 when a client is in the suspension window period.

·        TC rate. Tells the client to try connecting with TCP when the client is in the suspension window. The TC rate should be below the leak rate to give the client the option of attempting a TCP connection before a leak response is sent. This is used to tell the client to try connecting with TCP when responses to the client are suspended. For instance, if the TC rate is 3, and the server suspends responses to a given client, the server will issue a request for TCP connection for every 3 queries received. Make sure the value for TC rate is lower than the leak rate, to give the client the option to connect via TCP before leaking responses.

·        Maximum responses. This is the maximum number of responses the server will issue to a client while responses are suspended.

·        White list domains. This is a list of domains to be excluded from RRL settings.

·        White list subnets. This is a list of subnets to be excluded from RRL settings.

·        White list server interfaces. This is a list of DNS server interfaces to be excluded from RRL settings.

Examples:

The Get-DnsServerResponseRateLimiting cmdlet displays response rate limiting (RRL) settings on a DNS server.

Command to display RRL settings on a DNS server

Get-DnsServerResponseRateLimiting or Get-DnsServerRRL

This command displays the RRL settings on the DNS server.

Command to set RRL Mode Enabled on a DNS serverSet-DnsServerResponseRateLimiting -Mode Enable

Command to set RRL parameters on a DNS server

Set-DnsServerResponseRateLimiting -WindowInSec 7 -LeakRate 4 -TruncateRate 3 -ErrorsPerSec 8 -ResponsesPerSec 8

Command to reset RRL settings to default values

Set-DnsServerResponseRateLimiting -ResetToDefault

Command to set RRL to LogOnly mode

Set-DnsServerRRL -Mode LogOnly

Add DNS Server Response Rate Limiting Exceptionlist:

The Add-DnsServerResponseRateLimiting cmdlet adds a Response Rate Limiting (RRL) exception list on the DNS server. The RRL exception list indicates that responses to queries for specified Fully Qualified Domain Names (FQDNs), queries originating from specified client subnets, queries received on specified server interfaces, or any combination of these values, are exempt from RRL.

Example: Add a domain to an RRL exception list

Add-DnsServerResponseRateLimitingExceptionlist -Name “SafeList1” -Fqdn “EQ,*.contoso.com”

This command adds an RRL exception for the domain contoso.com

Set-DnsServerResponseRateLimitingExceptionlist:

The Set-DnsServerResponseRateLimitingExceptionlist cmdlet updates the settings of a Response Rate Limiting (RRL) exception list.

Example: Set a RRL exception list

Set-DnsServerResponseRateLimitingExceptionlist -Name “SafeList1” -ServerInterfaceIP “EQ,10.0.0.1”

This command sets the ServerInterfaceIP value of the RRL exception list named SafeList1 to EQ,10.0.0.1.

Get RRL settings from a DNS server to set on a second server:

Get-DnsServerRRL -ComputerName “server1” | Set-DnsServerRRL -ComputerName “server2” -force

This command gets the RRL settings on server1 and sets the same settings on server2.

В этой статье мы рассмотрим два способа организации условного разрешения имен в DNS сервере на Windows Server 2016: DNS conditional forwarding и DNS policy. Эти технологии позволяют настроить условное разрешение DNS имен в зависимости от запрошенного имени, IP адреса и местоположения клиента, времени суток и т.д.

Условная пересылка DNS (Conditional Forwarding) позволяет перенаправить DNS запросы об определенном домене на определенные DNS-сервера. Обычно Conditional Forwarders используется, когда нужно настроить быстрое разрешение имен между несколькими внутренними приватными доменами, или вы не хотите, чтобы DNS запросы с вашего сервера пересылались через публичную сеть Интернет. В этом случае вы можете создать на DNS сервере правило DNS пересылки DNS запросов для определенной доменной зоны (только !!!) на определенный DNS сервер.

Настройка DNS Conditional Forwarder в Windows Server

Попробуем настроить условное перенаправление DNS запросов для определенной доменной зоны на Windows Server 2016. Например, я хочу, чтобы все DNS запросы к зоне corp.winitpro.ru пересылались на DNS сервер 10.1.10.11.

1. Запустите консоль управления DNS (
   dnsmgmt.msc
   );
2. Разверните ваш DNS сервер, щелкните правой кнопкой по разделу Conditional Forwarders и выберите New Conditional Forwarder;
3. В поле DNS domain укажите FQDN имя домена, для которого нужно включить условную пересылку;
4. В поле IP addresses of the master servers укажите IP адрес DNS сервера, на который нужно пересылать все запросы для указанного пространства имен;
   

   Картинка с сайта: winitpro.ru

5. Если вы хотите хранить правило условной переадресации не только на этом DNS сервере, вы можете интегрировать его в AD. Выберите опцию “Store this conditional forwarder in Active Directory”;
6. Выберите правило репликации записи conditional forwarding (All DNS servers in this forest, All DNS servers in this domain или All domain controllers in this domain).
   

   Картинка с сайта: winitpro.ru

Настройка DNS Conditional Forwarding с помощью PowerShell

Вы можете создать правило Conditional Forward для определенной DNS зоны с помощью PowerShell. Воспользуйтесь командлетом Add-DnsServerConditionalForwarderZone:

Add-DnsServerConditionalForwarderZone -Name dmz.winitpro.ru -MasterServers 192.168.1.11,192.168.101.11 -ReplicationScope Forest

Чтобы вывести список DNS Conditional Forwarders на определенном сервере, выполните следующий PowerShell скрипт:

$DNSServer = "DC01"
$Zones = Get-WMIObject -Computer $DNSServer -Namespace "root\MicrosoftDNS" -Class "MicrosoftDNS_Zone"
$Zones | Select-Object Name,MasterServers,DsIntegrated,ZoneType | where {$_.ZoneType -eq "4"} | ft -AutoSize

Картинка с сайта: winitpro.ru

Фильтрация запросов DNS, политики разрешения имен в Windows Server 2016

В Windows Server 2016 появилась новая фича в службе DNS сервера – DNS политики. DNS политики позволяют настроить DNS сервер так, чтобы он возвращал различные ответы на DNS запросы в зависимости от местоположения клиента (с какого IP адреса или подсети пришел запрос), интерфейса DNS сервера, времени суток, типа запрошенной записи (A, CNAME, PTR, MX) и т.д. DNS политики в Windows Server 2016 позволяют реализовать сценарии балансировки нагрузки, фильтрации DNS трафика, возврата DNS записей в зависимости от геолокации (IP адреса клиента) и многие другие сложные сценарии.

Вы можете создать политику как на уровне DNS сервера, так и на уровне всей зоны. Настройка DNS политик в Windows Server 2016 возможна только из командной строки PowerShell.

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

Я создал 3 подсети для разных офисов компании:

Add-DnsServerClientSubnet -Name "MSK_DNS_Subnet" -IPv4Subnet "192.168.1.0/24"
Add-DnsServerClientSubnet -Name "EKB_DNS_Subnet" -IPv4Subnet "192.168.11.0/24"
Add-DnsServerClientSubnet -Name "SPB_DNS_Subnet" -IPv4Subnet "192.168.21.0/24"

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

Чтобы вывести список всех IP подсетей клиентов, выполните:

Get-DnsServerClientSubnet

Картинка с сайта: winitpro.ru

Теперь нужно для каждого офиса создать отдельную DNS область:

Add-DnsServerZoneScope -ZoneName “winitpro.ru” -Name “MSKZoneScope”
Add-DnsServerZoneScope -ZoneName “winitpro.ru” -Name “EKBZoneScope”
Add-DnsServerZoneScope -ZoneName “winitpro.ru” -Name “SPBZoneScope”

Следующие команды добавят 3 DNS записи с одним именем, но указывающие на разные IP адреса в разных областях DNS:

Add-DnsServerResourceRecord -ZoneName “winitpro.ru” -A -Name “proxy” -IPv4Address “192.168.1.10” -ZoneScope “MSKZoneScope”
Add-DnsServerResourceRecord -ZoneName “winitpro.ru” -A -Name “proxy” -IPv4Address “192.168.11.10” -ZoneScope “EKBZoneScope”
Add-DnsServerResourceRecord -ZoneName “winitpro.ru” -A -Name “proxy” -IPv4Address “192.168.21.10” -ZoneScope “SPBZoneScope”

Вы можете вывести все ресурсные DNS записи для области с помощью команды:

Get-DnsServerResourceRecord -ZoneName “winitpro.ru” -ZoneScope SPBZoneScope

Картинка с сайта: winitpro.ru

Теперь нужно создать DNS политики, которые свяжут IP подсети, DNS области и A записи.

Add-DnsServerQueryResolutionPolicy -Name “MSKResolutionPolicy” -Action ALLOW -ClientSubnet “eq,MSK_DNS_Subnet” -ZoneScope “MSKZoneScope,1” -ZoneName “winitpro.ru” –PassThru
Add-DnsServerQueryResolutionPolicy -Name “EKBResolutionPolicy” -Action ALLOW -ClientSubnet “eq,EKB_DNS_Subnet” -ZoneScope “EKBZoneScope,1” -ZoneName “winitpro.ru” -PassThru
Add-DnsServerQueryResolutionPolicy -Name “SPBResolutionPolicy” -Action ALLOW -ClientSubnet “eq,SPB_DNS_Subnet” -ZoneScope “SPBZoneScope,1” -ZoneName “winitpro.ru” –PassThru

Вывести список всех DNS политик для DNS зоны на сервере можно так:

Get-DnsServerQueryResolutionPolicy -ZoneName winitpro.ru

Картинка с сайта: winitpro.ru

Теперь с устройств из различных офисов проверьте, что DNS сервер на один и тот же запрос возвращает различные IP адреса прокси:

nslookup proxy.winitpro.ru

Можно запретить DNS серверу возвращать DNS адреса для определенного пространства имен (домена):

Add-DnsServerQueryResolutionPolicy -Name 'BlockFidhingPolicy' -Action IGNORE -FQDN "EQ,*.cberbank.ru"

Привет.

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 и применяем.
 
Удач!