Знакомство с Name Resolution Policy Table (NRPT – таблица имен) в Windows Server 2008 R2

Были ли бы вы против метода, который позволил бы вам контролировать, какой DNS-сервер используется DNS-клиентом на основании FQDN или по какому-нибудь другому критерию, который можно установить в групповых политиках? Такая функция позволила бы вам расширить круг ваших возможностей по распознаванию имен с клиентской стороны, при этом клиент может использовать DNS-серверы, настроенные на сетевых картах системы или использовать различные DNS-серверы на основании FQDN, DNS-суффикса, DNS-префикса, сетевого ID в виде IPv4, сетевого ID в виде IPv6 и т.п.! Существует набор сценариев, который позволит вам воспользоваться преимуществами таблицы имен, включенной в Windows Server 2008 R2.

NRPT определяет поведение DNS-клиента на основании запросов, сделанных DNS-клиентом. Если клиент делает запрос на один FQDN, этот запрос будет отправлен на DNS-сервер, настроенный на клиентской сетевой карте. Если клиент делает запрос на другой FQDN, этот запрос будет отправлен на другой DNS-сервер, не настроенный на клиентской сетевой карте, на основании записи в NRPT. На самом деле, Windows 7 и Windows Server 2008 R2 пользуются подобной возможностью для контролирования, какие DNS-серверы используются, и каким должно быть поведение DNS-клиента на основании темы запроса при реализациях DNSSEC и DirectAccess.

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

Чтобы лучше понять, что можно делать с NRPT, давайте посмотрим на настройки NRPT в Active Directory Group Policy. Найти их можно, открыв редактор групповых политик, и перейдя к Computer Configuration\Policies\Windows Settings\Name Resolution Policy, как показано на рисунке ниже.

В правой панели консоли вы увидите интерфейс настройки NRPT, как показано на рисунке ниже.

Теперь давайте изучим эти опции и увидим, как они используются для настройки записей в NRPT.

В разделе To which part of the namespace does this rule apply? вы определяете, хотите ли вы применять правило к Suffix(Суффикс), к Prefix(Префикс), к FQDN, к Subnet (IPv4)(Подсеть), к Subnet (IPv6) или Any(Любой части). Если вы выберете 'Any', все запросы будут контролироваться политикой, устанавливаемой для данной записи NRPT. В нашем примере мы выбрали опцию Suffix и ввели DNS-суффикс ipadsux.org.

Следующая опция - настройка Certification Authority(Optional)(Центр сертификации). Она применяется, когда вы используете NRPT для установки DNSSEC. DNSSEC представляет собой метод, который можно использовать для подтверждения, что DNS-запросы и отклики происходят в защищенном режиме, а также что DNS-клиенты могут аутентифицировать DNS-серверы для запросов, которые делаются для хостов в конкретных доменах. Вы можете щелкнуть кнопку Browse, чтобы обнаружить сертификат ЦС, которому будет доверять DNS-клиент при аутентификации DNS-сервера при установке DNSSEC.

Есть две вкладки, которые используются для создания правила для NRPT: вкладки DNSSEC и DNS Settings for DirectAccess. При создании правила используйте только одну из этих вкладок за раз. В общем, лучше разделить правила, отделив правила для DNSSEC от правил для DirectAccess; что упрощает отслеживание и независимое удаление при необходимости.

На вкладке DNSSEC, как показано на рисунке ниже, у вас есть следующие опции:

• Enable DNSSEC in this rule: При включении этой опции все запросы для указанного выше FQDN потребуют использования DNSSEC.
• Require DNS clients to check that name and address data has been validated by the DNS Server: Установка этого значения контролирует, как DNS-клиент обрабатывает DNS-запросы; при этом она не контролирует поведение DNS-сервера или настройку 'trust anchor' (используемую DNSSEC для обеспечения безопасных зон) на DNS-сервере. Ее задача – сообщать DNS-клиентам о проверке бита 'Authenticated Data' в DNS-отклике, полученным DNS-сервером для DNS-запроса, сделанного клиентом. Если бит 'Authenticated Data' не установлен (подтверждая тем самым, что возвращаемые данные не проверяются), DNS-клиент не примет отклик и будет считать запрос неудавшимся.
• Use IPsec in communication between the DNS client and DNS server: Эта опция сообщает клиенту, должен ли он устанавливать IPsec-соединение между собой и DNS-сервером до того, как отправлять DNS-запрос и получать отклик на него. Если вы решите выбрать включение IPsec для обеспечения взаимодействия между DNS-клиентом и сервером, у вас появляется несколько опции для настройки способов обеспечения безопасности: No encryption (integrity only)(без шифрования – только проверка целостности), Low: 3DES, AES (128, 192, 256)(Низкий уровень шифрования), Medium: AES (128, 192,256)(средний уровень шифрования) или High: AES (192,256)(Высокий уровень). Опция 'no encryption' приводит к обеспечению только машинной аутентификации, и трафик DNS-запросов будет свободно перемещаться. Если вы выберете одну из опций для шифрования, IPsec-связь будет подвергнута как аутентификации, так и шифрованию с использованием уровня шифрования, выбранного вами и поддерживаемого клиентом и сервером.

Сделав свой выбор конфигурации DNSSEC, вы можете щелкнуть на кнопку Update, после чего вы увидите запись NRPT в таблице Name Resolution Policy Table, как показано на рисунке ниже. Обратите внимание на две кнопки под таблицей: Delete Rule(Удалить правило) и Edit Rule(Редактировать правило). Эти кнопки появляются, когда вы щелкаете на строку в таблице с интересующим вас правилом. Если вы хотите отредактировать правило, щелкните на кнопку Edit Rule. Если вы хотите удалить правило, щелкните на кнопку Delete Rule. Все просто.

Теперь давайте исследуем опции для DNS Settings for DirectAccess. Обратите внимание на небольшую синтаксическую ошибку на этой странице конфигурации объекта групповой политики. DirectAccess пишется в одно слово, а в списке он указан как словосочетание из двух слов, и так несколько раз в этом интерфейсе. Я уже рассказал об этом Тому, и теперь это его проблема :)

Обратите внимание, что если вы хотите создать новое правило, вы должны щелкнуть на кнопку Clear и запустить настройку из раздела To which part of the namespace does this rule apply и раздела Certification Authority. Затем вы можете щелкнуть на кнопку Create для создания нового правила и воспользоваться кнопкой Edit Rule для внесения изменений в дальнейшем при необходимости.

Опции здесь такие:

• Enable DNS settings for Direct Access [sic] in this rule: Эта опция включает настройки DNS, сделанные здесь для клиентов DirectAccess.
• Web proxy (optional): Это интересная опция, у нее несколько возможных значений. Однако, документация по этому поводу отсутствует, поэтому я бы порекомендовал избегать этой опции, пока такая документация не появится.
• IPsec: Use IPsec in communication between the DNS client and DNS server: Эта опция включает те же варианты, что и опция IPsec, которую мы уже видели. У вас появляются те же опции, включая: No encryption, Low, Medium и High.

Есть еще одно интересное диалоговое окно при установке решения Windows DirectAccess. Щелкните на кнопку Advanced Global Policy Settings, чтобы увидеть это диалоговое окно (см. рисунок ниже).

В этом диалоговом окне три раздела:

• Network Location Dependency
• Query Failure
• Query Resolution

Опция Network Location Dependency позволяет вам настраивать опции роуминга. По умолчанию предлагается Let Network ID (NID) determine when Direct Access [sic] settings are to be used (Разрешить сети определять, когда нужно использовать настройки DirectAccess). Это недокументированная опция, но мне кажется, что она связана с тем, может ли клиент подключаться к определенному ресурсу в корпоративной сети для определения используемых DNS-настроек, когда клиент действует в качестве клиента DirectAccess. Если клиент видит, что он в сети, он воспользуется DNS-настройками этой сети. Если клиент DirectAccess не может подключиться к ресурсу, располагающемуся в корпоративной сети, тогда клиент DirectAccess предполагает, что он находится вне зоны действия, и начинает пользоваться настройками DirectAccess для определения имен. Однако это эмпирическая догадка, поскольку на данный момент эти опции незадокументированы.

Опция Query Failure определяет, как проводить распознавание имен при наличии ошибки в DNS-запросе имени. Если вы выберете вариант Configure query failure options, настройкой по умолчанию является Always fall back to Link-Local Multicast Name Resolution (LLMNR) and NetBIOS if the name does not exist in DNS or if the DNS servers are unreachable when on a private network (moderately secure). Эта опция позволяет воспользоваться локальным определением имени в частной сети, когда корпоративные DNS-серверы недоступны клиенту DirectAccess.

Раздел Query Resolution тоже интересен. Опять же, все это диалоговое окно недокументировано, но я думаю, что мы можем сделать некоторые предположения. Когда вы выбираете Configure query resolution options, у вас появляется два варианта: Resolve only IPv6 address for names (recommended) и Resolve both IPv4 and IPv6 addresses for names. Это интересно, потому что когда клиент DirectAccess подключается к ресурсам корпоративной сети через соединение DirectAccess, он использует только IPv6-адреса, так как все взаимодействия между клиентом DirectAccess и корпоративной сетью являются IPv6-соединениями; IPv4 никогда не используется при подключении клиента DirectAccess к корпоративной сети. Вероятно, именно по этой причине рекомендуются такие настройки.

Раздел Resolve both IPv4 and IPv6 addresses for names не кажется осмысленным в контексте работы клиента DirectAccess при вышеупомянутых обстоятельствах. Однако может, это означает, что вы имеете возможность использовать IPv4 для локального определения имен или тех имен, которые не обрабатываются NRPT? Думаю, нам придется подождать, пока Microsoft не предъявит какую-нибудь документацию по этой странице настроек.

Хотя все это может оказаться далеким от практики: Том говорит мне, что при использовании UAG для решения DirectAccess, UAG управляет настройкой NRPT и передает правильные настройки клиентам DirectAccess с помощью GPO, которые применяются только к тем клиентским компьютерам, которые являются членами группы безопасности, к которой применяется GPO. Поэтому при работе с UAG DirectAccess, вас не будет интересовать это диалоговое окно. Но все равно было бы неплохо почитать документацию по поводу этих настроек.

Заключение

В этой статье вам была представлена таблица Name Resolution Policy Table (NRPT) и некоторые конфигурационные опции, доступные в NRPT. NRPT позволяет вам настроить поведение при распознавании имен для DNS-клиентов в зависимости от настроек в таблице. Два основные сценария при применении NRPT включают среды, настроенные на поддержку DNSSEC и DirectAccess. DNSSEC представляет собой метод, используемый для обеспечения безопасности инфраструктуры распознавания имен, а DirectAccess - новая технологию удаленного доступа, позволяющую компьютерам подключаться к корпоративной сети отовсюду без необходимости в VPN-соединении. В продолжение этой статье мы подробнее рассмотрим DNSSEC и способы использования и настройки DNSSEC для проверки инфраструктуры распознавания имен в корпоративной сети в последующей статье.