Что вообще такое Name Resolution Policy и почему админы ее редко включают
В мире Windows есть иллюзия порядка:
“DNS? Да что там сложного — сервер есть, IP есть, работает.”
И тут в домене появляется:
- VPN
- split DNS
- DirectAccess
- Always On VPN
- корпорат + интернет + SaaS
- и один особо талантливый пользователь с Wi-Fi из “KFC_Free”
И Windows такая:
“Окей, у меня 3 DNS-сервера, 2 интерфейса, один туннель и чувство тревоги. КУДА МНЕ ИДТИ?”
Вот тут и выходит на сцену Name Resolution Policy —
мозг, совесть и родительский контроль DNS-резолвинга в Windows.
NRP говорит системе:
“Вот эти имена — ТОЛЬКО через ЭТИ DNS.
А вот туда — НИ НОГОЙ.
А если попробуешь — я тебя зафильтрую, залогирую и расскажу администратору.”
Зачем вообще NRP придумали
Без NRP Windows действует по принципу:
“Кто первый ответил — того и тапки.”
Есть публичный DNS? Отлично.
Есть DNS от VPN? Тоже норм.
Есть DHCP, который подсунул что-то подозрительное? Ну ладно, попробуем.
А теперь представь:
- Адрес контроллера домена dc.mlhost.ru, само доменное имя mlhost.ru, например, не принадлежит компании (что не редкость).
- у пользователя VPN отключился
- Windows пошла резолвить через публичный DNS
- DNS такой:
“Не знаю, но вот тебе IP. Честное слово — контроллер домена.”
И всё.
Занавес.
Kerberos плачет.
NTLM начинает молиться.
NRP придумали, чтобы Windows перестала быть доверчивым ребёнком.
Что именно делает Name Resolution Policy
NRP — это правила, которые говорят:
- какие DNS-суффиксы
- через какие интерфейсы
- к каким DNS-серверам
- можно или нельзя резолвить
Проще говоря:
“mlhost.ru — только через доменные DNS, только по защищённому каналу, и вообще без шуток.”
Windows при резолвинге:
- смотрит на имя
- сравнивает с политиками
- отбрасывает лишние DNS-серверы, даже если они есть
- идёт строго туда, куда разрешили
Это не рекомендация.
Это приказ уровня GPO.
Что чаще всего реально используют (а не просто знают)
На практике 99% админов из тех кто знает про NRP используют три сценария, и они золотые.
1️⃣ DNS Namespace Rule для домена
Самый популярный кейс:
- corp.local
- ad.company.ru
- internal.company.com
Правило говорит:
“Эти зоны — ТОЛЬКО через корпоративные DNS.
Никаких Google, никаких 1.1.1.1, никаких ‘я тут быстрее отвечу’.”
Это must-have, если есть:
- VPN
- split DNS
- удалённые пользователи
2️⃣ Require DNS over VPN / DirectAccess
Когда используется DirectAccess или Always On VPN, NRP умеет:
“Если имя корпоративное — резолвить ТОЛЬКО через защищённый туннель.”
Если туннеля нет - резолвинга нет вообще.
Не “попробуем публичный DNS”.
Не “ну может прокатит”.
А просто:
❌ “Имя не найдено. Подключай VPN, дружок.”
3️⃣ Block Public Resolution for Internal Names
Это уже уровень паранойи, но правильной.
NRP может сказать:
“Если имя похоже на внутреннее -
даже не смей спрашивать его у публичного DNS.”
Это защищает от:
- DNS spoofing
- утечек имён внутренней инфраструктуры
- “ой, мы случайно светанули все наши хосты наружу”
Почему NRP реально повышает безопасность
А вот тут самое вкусное.
1. Защита от DNS spoofing
Без NRP:
- любой DNS, доступный интерфейсу, может ответить
С NRP:
- строго определённые серверы
- строго для определённых имён
Злоумышленник может хоть обмазаться fake DNS - Windows его просто не спросит.
2. Предотвращение утечек внутренних имён
Без NRP:
- dc01.contoso.com улетает на публичный DNS
- логируется
- анализируется
- используется для атаки
С NRP:
“Внешний DNS вообще не узнает, что такое contoso.com.”
3. Чёткое поведение системы
NRP убирает магию и случайность.
Windows перестаёт действовать по принципу:
“Ну… посмотрим, что получится.”
И начинает:
“Вот правило. Вот маршрут. Вот DNS. Других вариантов нет.”
Для безопасности это золото.
Почему NRP не любят (и зря)
NRP не любят, потому что:
- оно не настраивается за 5 минут
- оно ломает плохо настроенный DNS
- оно сразу показывает, где у тебя бардак
NRP — как честный лог:
“Если что-то не работает — значит, оно и не должно было работать.”
И это бесит. Но это правильно.
Так что если в твоём домене есть:
- VPN
- удалёнка
- безопасность
- или хотя бы желание спать спокойно - Name Resolution Policy должна быть включена и продумана.