Сервер условной пересылки dns windows server 2003 - Доктор Windows

Новые функции для работы с многодоменными лесами

В статье «Устраняем проблемы DNS», опубликованной в этом же номере, речь идет о том, как построить инфраструктуру DNS для двухдоменного леса Active Directory (AD). В ней отмечается, что, хотя DNS-серверы на базе Windows 2000 успешно работают в многодоменных лесах, некоторых функций в них все же недостает. Этот пробел можно восполнить с помощью DNS-серверов на базе Windows 2003.

В качестве простого примера в статье рассматривается лес с двумя доменами — один из них назван bigfirm.biz, а другой — bigfirm.com. В обоих доменах используется разделенная (split-brain) DNS; они должны взаимно разрешать имена и SRV-записи для поиска контроллеров домена (DC), чтобы системы и пользователи каждого домена могли быть идентифицированы в любом из них. Компания Bigfirm может выбрать один из двух подходов. Можно построить динамические зоны для каждого домена и не интегрировать их с AD. В этом случае администраторы должны проверить все DNS-серверы корпоративной сети и убедиться, что каждый из них является первичным или вторичным сервером как для зоны bigfirm.biz, так и для bigfirm.com.

Альтернативный подход — преобразовать bigfirm.biz и bigfirm.com в зоны, интегрированные с AD. Как правило, интегрированные с AD зоны — более подходящее решение для AD-зон, чем разделенная DNS. Но, к сожалению, DNS-серверы на базе Windows 2000 обмениваются DNS-информацией о зоне только с DC данной зоны. Например, если DNS-зона bigfirm.biz интегрирована с AD, то только DNS-серверы, которые одновременно являются контроллерами домена bigfirm.biz, смогут получить DNS-информацию о bigfirm.biz. Даже если изменить DNS-зону bigfirm.com, интегрировав ее с AD, DNS-серверы bigfirm.com получат информацию только о bigfirm.com, но не о bigfirm.biz, даже если оба домена находятся в одной сети. Чтобы устранить невосприимчивость DNS-серверов на базе Windows 2000 к любой AD-интегрированной информации вне своего домена, следует сделать эти DNS-серверы обычными вторичными серверами для других серверов в лесу.

Предположим, что у компании Bigfirm имеется несколько тысяч хост-машин и несколько десятков DNS-серверов. Каждый из этих DNS-серверов играет роль вторичного сервера по крайней мере в одной зоне. Поэтому каждый раз, когда в зоне происходят изменения, эту информацию приходится пересылать на все вторичные серверы компании, что создает большую нагрузку на каналы связи и процессор. Microsoft DNS не требует пересылки всей зоны при любом незначительном изменении (в отличие от некоторых старых программных решений DNS), но все же процедура пересылки данных зоны способом, описанным в документе RFC (Request for Comments), неэффективна. В случае интеграции с AD пересылка выполняется более эффективным механизмом репликации AD со сжатием трафика репликации между сайтами. В DNS-серверах Windows 2003 появились три усовершенствования по сравнению с Windows 2000: зоны-заглушки (stub zones), условная ретрансляция (conditional forwarding) и зоны, интегрированные с AD в масштабах всего леса.

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

Благодаря зонам-заглушкам программы DNS-серверов Windows 2003 формируют зоны, которые отличаются от размещаемых на стандартных первичных и вторичных DNS-серверах. В зонах на стандартных первичных и вторичных DNS-серверах содержится полный экземпляр файла зоны, а в зоне-заглушке хранится лишь минимальный файл зоны. Зона-заглушка вместо всех записей зоны хранит лишь записи Start of Authority (SOA) и Name Server (NS). Другими словами, единственная информация, которую можно получить от DNS-сервера с зоной-заглушкой для данной зоны, — это имена DNS-серверов и сведения о том, какой из них является первичным DNS-сервером зоны. IP-адрес определенной хост-машины в зоне из зоны-заглушки получить нельзя.

Чем может быть полезна зона, которая лишь сообщает, какие серверы являются серверами имен зоны? Предположим, что bigfirm.biz располагает большой зоной, содержащей тысячи записей, и разработчикам домена требуется множество DNS-серверов. Они создали первичный DNS-сервер и группу вторичных DNS-серверов. Но сетевые трассировки показывают, что DNS-серверы тратят больше времени на получение последней информации о зоне от первичного DNS-сервера (и тем самым замедляют работу первичного сервера и нагружают каналы связи), чем на рассылку ответов на запросы. Разработчики сетей должны разместить зону какого-нибудь типа для bigfirm.biz на каждом DNS-сервере сети Bigfirm, но обмен данными между первичными и вторичными серверами приводит к дополнительной трате ресурсов. Выход — в преобразовании некоторых вторичных DNS-серверов в DNS-серверы зоны-заглушки. Если эти DNS-серверы получают запрос относительно bigfirm.biz, то они не дадут ответа, но им известно, на какой сервер нужно направить запрос. Для этого не требуется проходить по всей иерархии DNS-серверов в поисках источника информации о bigfirm.biz. Затем запрашивающий DNS-сервер задает DNS-серверу зоны-заглушки вопрос относительно bigfirm.biz, и сервер зоны-заглушки передает ответ. Кроме того, серверы зоны-заглушки играют роль серверов кэширования (как практически все DNS-серверы), поэтому следующий компьютер, запросивший информацию о bigfirm.biz, получит ответ немедленно, так как сервер с зоной-заглушкой может предоставить ответ на запрос из своего кэша.

Маленькая зона-заглушка быстро обновляется, поэтому не создает серьезной нагрузки на оперативную память и процессор DNS-сервера. Часто простые серверы кэширования (DNS-серверы без зон) размещаются в сети для преобразования имен клиентов, но разделенная DNS требует, чтобы все DNS-серверы содержали экземпляр каждой AD-зоны леса. Применение зон-заглушек — самый простой способ выполнить это требование.

Условная ретрансляция

Как быть, если администраторы Bigfirm не хотят использовать DNS-серверы с зоной-заглушкой? Существует ли способ разместить в сети группу DNS-серверов, не назначая их вторичными серверами для bigfirm.biz и bigfirm.com? Да, поскольку DNS-служба Windows 2003 обеспечивает метод, называемый условной ретрансляцией.

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

Для условной ретрансляции DNS-сервер настраивается таким образом, что при поступлении запроса о конкретном домене (например, bigfirm.biz), на который у сервера нет ответа, он просит другой DNS-сервер (ретранслятор) найти ответ. Следует обратить внимание на различие: стандартная ретрансляция — это передача безответных запросов о любом домене конкретному DNS-серверу, а условная ретрансляция заставляет передавать ретранслятору только запросы о конкретном домене.

Служба DNS Windows 2003 позволяет указать сервер или серверы, которые будут отвечать на запросы о конкретном домене. Поэтому если компания Bigfirm намерена развернуть 10 вторичных DNS-серверов для bigfirm.biz и bigfirm.com и еще 100 DNS-серверов для разрешения внутренних запросов разделенной DNS bigfirm.biz и bigfirm.com, то нужно просто настроить 100 этих серверов на условную ретрансляцию всех запросов bigfirm.biz на 10 вторичных серверов.

Конечно, различия между зонами-заглушками и условной ретрансляцией весьма тонки, но ими нельзя пренебрегать. Например, какой из этих методов автоматически обновляет информацию о зоне? Предположим, что в зону добавлен DNS-сервер. Как информировать сервер зоны-заглушки или сервер с условной ретрансляцией об этом событии? В случае с сервером зоны-заглушки делать ничего не потребуется — новый сервер появится в зоне-заглушке после репликации. Но если используется условная ретрансляция, то необходимо посетить каждый DNS-сервер и изменить список серверов, к которым следует обращаться в поисках записи bigfirm.com. Насколько я понимаю, составить сценарий для такой процедуры нельзя.

Еще одна проблема, возникающая при сравнении зон-заглушек с условной ретрансляцией, связана с полномочиями. Мы предполагаем, что bigfirm.biz и bigfirm.com — единая дружная компания, но что если между подразделениями существует соперничество? В этом случае размещать зоны-заглушки для серверов bigfirm.com на серверах bigfirm.biz можно лишь с разрешения администраторов bigfirm.com. Для того чтобы серверы bigfirm.biz получали при репликации DNS информацию от серверов bigfirm.com, серверы bigfirm.com должны дать согласие на передачу этой информации при пересылке зоны. По умолчанию DNS-серверы Windows 2000 передают данные любому запросившему их серверу. Но находящиеся в зоне DNS-серверы на базе Windows 2003 по умолчанию выполняют пересылки зоны только на серверы, имеющие в этой зоне NS-записи. Поэтому, прежде чем DNS-сервер bigfirm.biz с зоной-заглушкой bigfirm.com сможет обновить информацию о зоне с DNS-сервера bigfirm.com, этот сервер bigfirm.biz должен получить NS-запись в зоне bigfirm.com. Если кто-то захочет настроить свои DNS-серверы на пересылку всех запросов для сайтов microsoft.com на мой DNS-сервер, я не смогу этому помешать. Но вряд ли кто-нибудь сделает это, так как в результате существенно замедлится процесс разрешения имен для данного лица.

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

Зоны, интегрированные с AD в масштабах всего леса

Третий метод, с использованием зон, интегрированных с AD в масштабах всего леса, расширяет возможности DNS-зон, интегрированных с AD, по сравнению с Windows 2000. DNS-зоны, интегрированные с AD, тиражируют информацию DNS между DNS-серверами, которые также должны быть контроллерами домена (DC). Но на серверах Windows 2000 интегрированная с AD информация перемещается только внутри домена; DNS-серверы bigfirm.biz не могут видеть интегрированную с AD зону bigfirm.com, а DNS-серверы bigfirm.com не видят интегрированную с AD зону bigfirm.biz.

В Windows 2003 можно создать интегрированные с AD DNS-зоны, которые выполняют репликацию не только во всем домене, но и во всем лесу. Поэтому можно сначала сформировать bigfirm.biz и bigfirm.com, как описано в статье «Устраняем проблемы DNS», со стандартными первичным и вторичным серверами. Затем, после того как будут сформированы домены и лес AD, можно просто изменить несколько параметров и настроить все DNS-серверы bigfirm.biz и bigfirm.com на хранение информации в лесу. Впоследствии процесс репликации AD обеспечит синхронизацию всех DNS-серверов. Естественно, все DC должны работать на Windows 2003 — по крайней мере, на это указывают проведенные мною эксперименты.

Марк Минаси — редактоp Windows NT Magazine MCSE и автор книги «Mastering Windows NT Server 4.0» (издательство Sybex). С ним можно связаться по адресу: mark@minasi.com

Источник

Во многих организациях используется два и более сервера DNS — один для внутренних пользователей, а другой, доступный через Интернет, для всех остальных. Для облегчения управления серверами используются интегрированные в Active Directory зоны DNS. Иногда бывает необходимо обрабатывать запросы, направляемые к этим серверам DNS, по-разному, в зависимости от расположения запрашивающего. Это называется расщепление DNS. Запросы к внутреннему серверу DNS обрабатываются иначе, чем к внешнему, а управление этим процессом осуществляется с помощью Windows Server 2003.

Давайте посмотрим, как осуществляется расщепление DNS в интегрированных с Active Directory зонах в Windows 2003.

В каких ситуациях происходит расщепление DNS?

Расщепление DNS может представлять определенные трудности для организаций, использующих несколько внутренних доменных имен, например, sales.company.com и research.company.com. В таких условиях необходимо, чтобы в каждом домене DNS корректно работал с Active Directory. Когда пользователь из домена research.company.com пытается получить доступ к веб-странице или компьютеру в домене sales.company.com, могут возникнуть сложности при обработке этого запроса локальным сервером DNS. Запрос направляется на сервер DNS данного домена, а тот передает его публичному серверу DNS компании. В такой ситуации ресурс, к которому направлен запрос, должен быть доступен из Интернета, чтобы сервер мог его найти. Однако на практике этот ресурс находится в другом внутреннем домене, поэтому внешний сервер DNS не сможет его найти по стандартному сценарию.

Windows Server 2003 позволяет решить эту проблему с помощью условных пересылкок. Условные пересылки направляют запросы определенного характера не на публичные серверы, а непосредственно на нужный внутренний сервер. Таким образом, при попытке обратиться к ресурсу в домене sales.company.com из домена research.company.com, полученный локальным сервером запрос направляется сразу на сервер DNS другого домена. Все это происходит незаметно для пользователей и обеспечивает быстрый доступ к нужным ресурсам.

Как настроить условные пересылки?

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

1. Откройте консоль DNS на контроллере домена Windows Server 2003.
2. Нажмите правой кнопкой на сервере DNS, который хотите настроить, и выберите пункт «Свойства» (Properties).
3. Откройте вкладку «Пересылка» (Forwarders) в окне свойств выбранного сервера.
4. Нажмите кнопку «Создать» (New) справа от списка доменов DNS.
5. Введите имя домена, для которого хотите использовать условные пересылки (к примеру, sales.company.com), и нажмите «OK».
6. Нажмите на новой пересылке домена, которую только что добавили в список доменов DNS, и введите IP-адрес основного сервера DNS для данного домена в поле «Список IP-адресов пересылки для выбранного домена» (Selected Domains Forwarder IP Address List).
7. Нажмите кнопку «Добавить» (Add).
8. Нажмите «OK», чтобы закрыть окно свойств DNS.

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

Обратите внимание: для успешного использования условных пересылок необходимо, чтобы на всех серверах DNS в среде Active Directory, была установлена Windows Server 2003.

Эта простая конфигурация позволяет использовать множественные субдомены в среде Active Directory.

Автор: Derek Schauland
Перевод: SVET

Оцените статью: Голосов

Источник

December 3, 2003, 12:00 AM PST

Step-By-Step: Standard and conditional forwarding in Windows 2003 DNS

Make your DNS servers more efficient by forwarding unresolved DNS queries. This Step-By-Step walks you through setting up standard forwarding as well as the new Windows 2003 conditional forwarding process.

Forwarding is used to resolve queries that cannot be resolved on the local DNS server. The process involves having a DNS server communicate directly with other DNS servers. When you have your local DNS server directly communicate with outside DNS servers, you reduce the amount of nonlocal site information that is stored in the DNS cache. This allows your local DNS servers to be more efficient with resolving local queries.

Prior to Windows 2003, you could identify multiple servers to which all unresolved queries could be forwarded. If one server was unavailable, the requests would be sent to the next server on the list. This is called standard forwarding in Windows 2003.

Conditional forwarding defines where DNS queries on specific domains are forwarded. This is a new feature available in Windows 2003 DNS. It is designed to work with multiple DNS zone environments in which systems in one namespace (e.g., prep.com) need to communicate with systems in another namespace (e.g., test.com). Also, it can be used for resolution for an intranet (two companies that have merged) or Internet (sharing data with a business partner) scenario.

Setting up standard forwarding

Go to the Start Menu | Administration Tools | DNS to access the DNS service. The DNS Management Tool main appears.
Select the name of your DNS server on the tree hierarchy in the left panel.
Click the right mouse button, and then choose Properties. The DNS properties dialog box appears as shown in Figure A.

Figure A

Notice “All other DNS domains” in the DNS domain field is selected. Any servers added as forwarders while this is selected will be used for standard forwarding (or for any queries involving domains that do not have conditional forwarding defined).

Type the IP address for the server to which queries will be forwarded in the Selected Domain’s Forwarder IP_Address List field, and then click Add. The servers used as forwarders will be listed in the order in which they were added (Figure B).

Figure B

You can change the order by selecting an IP address in the list and clicking UP or DOWN appropriately.

Click OK at the bottom of the DNS Properties dialog box once you have finished.

Setting up conditional forwarding
In this scenario, two companies–each with its own network–have merged. They want to keep the network configurations as they are; however, each of the domains used are only resolved internally. Several applications and activities require each of the networks to be able to resolve the domain on the other network. This is a perfect scenario for conditional forwarding.

Access the Forwarders tab in Properties for the DNS server (steps 1 through 3 in the above section).
Click New next to the DNS domain list to add a domain. The New Forwarder dialog box appears as shown in Figure C.

Figure C

Type the domain for which queries will be forwarded in the DNS Domain field, and then click OK. The domain is added to the DNS Domain list on the Forwarders tab (Figure D).

Figure D

Add the IP address for the internal DNS server which maintains the domain locally. As with standard forwarding, you can add more than one forwarder for the domain.
Click OK at the bottom of the DNS Properties dialog box once you have finished.

Additional hints and tips for conditional forwarding

Conditional forwarding can only be used for domains for which the DNS server does not hold a primary or secondary zone. This means conditional forwarding can be set for any domain that is at the same level or higher than zones maintained locally. For example, you can set up conditional forwarding to test.com, corp.test.com, or prep.com where example.test.com is a zone maintained locally on the DNS server. However, you cannot conditionally forward for one.example.test.com nor example.test.com.
For fault tolerance, it is recommended that you define more than one server as a forwarder for each conditional forward set up. If one server is not available, another one can be queried.
Conditional forwarding can replace secondary zones that were used to resolve queries in other namespaces in previous versions of the Windows DNS service.

Microsoft

Источник

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

Содержание:

Настройка DNS Conditional Forwarder в Windows Server
Настройка DNS Conditional Forwarding с помощью PowerShell
Фильтрация запросов DNS, политики разрешения имен в Windows Server 2016

Условная пересылка 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.

Запустите консоль управления DNS (
dnsmgmt.msc
);
Разверните ваш DNS сервер, щелкните правой кнопкой по разделу Conditional Forwarders и выберите New Conditional Forwarder;
В поле DNS domain укажите FQDN имя домена, для которого нужно включить условную пересылку;
В поле IP addresses of the master servers укажите IP адрес DNS сервера, на который нужно пересылать все запросы для указанного пространства имен;
Если вы хотите хранить правило условной переадресации не только на этом DNS сервере, вы можете интегрировать его в AD. Выберите опцию “Store this conditional forwarder in Active Directory”;
Выберите правило репликации записи conditional forwarding (All DNS servers in this forest, All DNS servers in this domain или All domain controllers in this domain).

Настройка 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 "rootMicrosoftDNS" -Class "MicrosoftDNS_Zone" $Zones | Select-Object Name,MasterServers,DsIntegrated,ZoneType | where {$_.ZoneType -eq "4"} | ft -AutoSize

Фильтрация запросов 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

Теперь нужно для каждого офиса создать отдельную 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

Теперь нужно создать 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 политиках доступны следующие действия:

-Action ALLOW
-Action DENY
-Action IGNORE

Можно использовать следующие параметры в фильтре DNS:

-InternetProtocol "EQ,IPv4,NE,IPv6" -TransportProtocol "EQ,UDP,TCP" -ServerInterfaceIP "EQ,192.168.1.21" -QType "EQ,A,AAAA,NE,PTR" -TimeOfDay "EQ,9:00-18:00"

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

Get-DnsServerQueryResolutionPolicy -ZoneName winitpro.ru

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

nslookup proxy.winitpro.ru

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

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

Источник