Настройки dns в реестре windows

Статья давно не обновлялась, поэтому информация могла устареть.

Чтобы установить DNS-сервер

Откройте диспетчер сервера. Чтобы открыть диспетчер сервера, щелкните Пуск, затем выберите Диспетчер сервера.

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

В области результатов, в разделе Сводка по ролям щелкните элемент Добавить роли.

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

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

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

Прочитайте сведения на странице DNS-сервер, затем нажмите кнопку Далее.
На странице Подтверждение параметров установки убедитесь, что будет установлена роль DNS-сервера, затем нажмите кнопку Установить.

Настройка

Чтобы настроить параметры DNS-сервера, щелкните правой кнопкой мыши имя нужного сервера и в контекстном меню выберите Свойства.

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

На вкладке Интерфейсы вы можете указать IP-адреса интерфейсов, которые будет «прослушивать» DNS-сервер и отвечать на DNS-запросы. Изменять этот параметр имеет смысл только при использовании нескольких сетевых адаптеров или при настройке нескольких IP-адресов для сетевых интерфейсов.

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

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

На вкладке Пересылка вы можете настроить IP-адреса серверов, использующихся для пересылки DNS-запросов. Ваш DNS-сервер будет переадресовывать все запросы, не относящиеся к его зоне ответственности, на указанные серверы. В этом случае по отношению к вышестоящим серверам он ведет себя как DNS-клиент. Метод пересылки запросов удобен при использовании межсетевых экранов (firewall) для защиты внутренней сети: все запросы на разрешение имен внутренние DNS-серверы пересылают на внешние. Также этот метод может использоваться для уменьшения трафика по каналам с малой пропускной способностью — в этом случае все запросы перенаправляются на DNS-сервер провайдера, который, в свою очередь, осуществляет разрешение имени.

Используя поле IP-адрес и кнопки Добавить и Удалить, вы можете указать список серверов, на которые будут пересылаться запросы. Кнопки Вверх и Вниз служат для изменения порядка опроса DNS-серверов. Если первый сервер не пришлет ответ в течение времени, указанного в поле Время ожидания пересылки, запрос будет отправлен на следующий сервер из списка, и т. д. Если ни один из перечисленных серверов не смог ответить на DNS-запрос за отведенное время, настраиваемый DNS-сервер пытается выполнить рекурсивный запрос для разрешения имени самостоятельно. Установка флажка Не использовать рекурсию запрещает серверу выполнять рекурсивные запросы, и он возвращает сообщение об ошибке.

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

На вкладке Дополнительно вы можете настроить дополнительные параметры DNS-сервера. Они загружаются при запуске службы DNS-сервера из информационного загрузочного файла, системного реестра или Active Directory. В большинстве случаев значения параметров, установленные по умолчанию, не требуют модификации.

В поле Номер версии сервера вы можете узнать номер версии службы DNS-сервера. Это бывает необходимо для выяснения совместимости службы DNS-сервера Windows с другими DNS-серверами.

Раскрывающийся список Проверка имен позволяет выбрать метод проверки имен при изменении записей средствами Консоли управления. Возможны следующие значения:

Строгое следование (Strict) RFC (ANSI) — все вводимые имена должны полностью соответствовать требованиям стандарта RFC 1123;

• Не (Non) RFC (ANSI) — допускается ввод нестандартных имен, недопустимых стандартом RFC 1123;
• Многобайтовый (UTF8) — допускается ввод имен, содержащих не ASCII-символы, включая символы в кодировке Unicode, которые обычно требуют для своего хранения более одного байта. Этот режим проверки выбран по умолчанию.

Раскрывающийся список Загружать зону при старте позволяет указать, откуда будут загружаться параметры службы DNS-сервера при ее запуске. Возможны следующие значения:

Из реестра — параметры службы DNS-сервера загружаются из системного реестра. Для хранения параметров службы используется ветвь реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\ Parameters. Из файла — параметры службы загружаются из специального файла по аналогии с серверами BIND (Berkeley Internet Name Domain). Для использования этого режима необходим загрузочный файл (обычно с именем Named.boot) с другого DNS-сервера, использующего BIND. В Windows Server 2003 этот файл должен иметь имя boot и располагаться в папке %systemroot%\system32\dns. Файл должен иметь более ранний формат BIND 4, а не BIND 8. Для всех параметров, не настраиваемых через загрузочный файл, будут использоваться значения из системного реестра. Из Active Directory и реестра — параметры службы DNS-сервера загружаются из Active Directory и системного реестра. Этот режим загрузки используется по умолчанию.

Установив флажок Разрешить автоматическое удаление устаревших записей, вы включаете автоматическое удаление устаревших записей зон DNS-сервера. Чтобы механизм автоматического обновления работал, он должен быть включен для сервера в целом. В поле Период очистки введите период времени, по прошествии которого производится анализ и удаление устаревших записей. Из соображений производительности сервера не рекомендуется устанавливать период автоматического удаления менее 1 часа.

Щелкнув кнопку Восстановить умолчания, вы восстановите значения параметров по умолчанию.

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

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

На вкладке Корневые ссылки вы можете отредактировать список корневых DNS-серверов, ответственных за обслуживание корневой зоны, именуемой «.» (точка). Эта информация используется DNS-сервером при выполнении рекурсивных запросов на разрешение имени.

Сведения о корневых серверах хранятся в файле %systemroot%\system32\DNS\ Cache.dns. Вы можете редактировать его вручную в текстовом редакторе, либо воспользоваться вкладкой Корневые ссылки окна свойств DNS-сервера. Файл корневых ссылок Cache.dns автоматически создается и заполняется при первом запуске службы DNS-сервера Windows Server 2003.

Вы можете обновить или модифицировать файл корневых ссылок в зависимости от используемой конфигурации DNS-серверов.

Если ваша сеть подключена к Интернету, при необходимости можно обновить файл cache.dns, загрузив новую версию файла корневых ссылок Named.root по адресу ftp://rs.internic.net/domain/named.root. Переименуйте полученный файл в cache.dns. Если ваша сеть не подключена к Интернету, можно сохранить файл cache.dns в надежном месте, очистить его и добавить адреса серверов, ответственных за обслуживание корневого домена. На серверах, обслуживающих корневой домен, этот файл может быть вообще удален, т. к. для нормальной работы корневых серверов он не нужен.

Чтобы добавить новый корневой сервер, щелкните кнопку Добавить. В появившемся окне введите DNS-имя сервера (или, если оно определено в одной из зон, обслуживаемых локальным сервером, найдите его, щелкнув кнопку Обзор). Если соответствующий хост уже имеет доменное имя DNS, щелкните кнопку Сопоставить, чтобы получить IP-адрес хоста. Если же у него еще нет доменного имени DNS, самостоятельно укажите один или более IP-адресов сервера, последовательно вводя их в поле IP-адрес и щелкая кнопку Добавить. Для добавления DNS-сервера должно быть указано и его имя, и как минимум один его IP-адрес. Заполнив все необходимые поля, щелкните кнопку ОК.

Чтобы изменить информацию о корневом сервере, щелкните кнопку Изменить.

При добавлении корневого сервера в файл cache.dns заносятся две записи: запись NS сервера и запись A соответствующего хоста. Запись A добавляется независимо от того, определена она в какой-либо зоне или нет. Такая запись называется glue record и предназначена для того, чтобы соответствующее имя хоста можно было использовать даже в случае неработоспособности зоны, в которой он определен. DNS-сервер Windows Server 2003 добавляет glue-записи для всех серверов, указываемых в записях NS.

Ниже приводится содержимое стандартного файла cache.dns:

cache.dns — DNS CACHE FILE

 

Initial cache data for root domain servers.

 

YOU SHOULD CHANGE

 

-> Nothing if connected to the Internet. Edit this file only when

updated root name server list is released.

OR

-> If NOT connected to the Internet, remove these records and replace

with NS and A records for the DNS server authoritative for the

root domain at your site.

 

Note, if you are a root domain server, for your own private intranet,

no cache is required, and you may edit your boot file to remove

it.

 

This file holds the information on root name servers needed to

initialize cache of Internet domain name servers

(e.g. reference this file in the «cache . «

configuration file of BIND domain name servers).

 

This file is made available by InterNIC

under anonymous FTP as

file /domain/named.root

on server FTP.INTERNIC.NET

 

last update

Nov 5, 2002

related version of root zone

2002110501

 

 

formerly NS.INTERNIC.NET

 

. 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4

 

formerly NS1.ISI.EDU

 

. 3600000 NS B.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107

 

formerly C.PSI.NET

 

. 3600000 NS C.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12

 

formerly TERP.UMD.EDU

 

. 3600000 NS D.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90

 

formerly NS.NASA.GOV

 

. 3600000 NS E.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10

 

formerly NS.ISC.ORG

 

. 3600000 NS F.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241

 

formerly NS.NIC.DDN.MIL

 

. 3600000 NS G.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4

 

formerly AOS.ARL.ARMY.MIL

 

. 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53

 

formerly NIC.NORDU.NET

 

. 3600000 NS I.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17

 

operated by VeriSign, Inc.

 

. 3600000 NS J.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 3600000 A 192.58.128.30

 

housed in LINX, operated by RIPE NCC

 

. 3600000 NS K.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 3600000 A 193.0.14.129

 

operated by IANA

 

. 3600000 NS L.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12

 

housed in Japan, operated by WIDE

 

. 3600000 NS M.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33

End of File

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

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

На вкладке Ведение журнала отладки вы можете настроить список параметров, фиксируемых в журнале DNS-сервера. Журнал располагается в файле %systemroot%\ system32\dns\dns.log. Чтобы начать ведение журнала, включите как минимум один параметр журнала и щелкните кнопку ОК.

Чтобы включить параметр, установите соответствующий флажок.

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

Запросы и передачи — фиксируются все запросы клиентов на разрешение имен; Уведомление — фиксируются уведомления, посылаемые серверу другими DNS-серверами; Обновление — фиксируются все динамические обновления; Запрос — фиксируются основные параметры запроса на разрешение имени; Отклик — фиксируются основные параметры ответа на запрос на разрешение имени; Исходящие — фиксируется количество запросов, отправленных DNS-сервером; Входящие — фиксируется количество запросов, полученных DNS-сервером; UDP — фиксируется количество запросов, полученных DNS-сервером через UDP-порт; TCP — фиксируется количество запросов, полученных DNS-сервером через TCP-порт;

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

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

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

Вы можете использовать два вида тестов.

Простой запрос к этому DNS-серверу — для теста используется локальный DNS-клиент, при помощи которого DNS-серверу отправляется итеративный запрос (с запретом использования рекурсии); Рекурсивный запрос к другим DNS-серверам — для теста используется локальный DNS-клиент, при помощи которого DNS-серверу отправляется рекурсивный запрос.

После того как вы выберете хотя бы один тест, станет доступна кнопка Тест. Кроме того, установив флажок Автоматическое тестирование и желаемый интервал выполнения проверки в поле Интервал теста, вы можете включить автоматическую многократную проверку сервера через определенные интервалы времени. Одиночный или многократный тест запускается щелчком кнопки Тест.

Результаты тестов выводятся в таблице в нижней части окна. В ней отображается дата и время исполнения каждого теста, а также результат (ПРОШЕЛ или ОШИБКА ) простого и рекурсивного запросов.

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

Вкладка Безопасность позволяет устанавливать права доступа к объектам службы DNS определенным пользователям и группам пользователей, устанавливая тем самым уровень безопасности и защищенности службы.

Записи системного реестра, относящиеся к серверу DNS, содержатся в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters в записи NameServer. Записи разделены пробелами. Утилита REG.EXE из пакета Resource Kit позволяет изменять записи сервера DNS с помощью следующей команды:

Here, in this article, we will show you all possible ways to enable or disable DNS Client Service in Windows 11 or 10. Main work of this service is to cache Domain Name System names and register the full computer name. If you disable the same, it will continue to resolve the DNS names. At the same time, dnscache service will stop catching the queries of DNS and will not register the computer’s name anymore. Moreover, any services depending on DNS Client Service will become unable to run correctly.

dnscache service is a pre-installed program of Microsoft that helps on DNS resolution when you browse the internet. It also works to translate domain names to IP addresses. Furthermore, it caches the results to provide quicker DNS resolution for frequently visited servers. To do so, it links directly to the DNS servers. When you start this service on your PC, DNS runs as a service on the computer.

Ways to Enable or Disable DNS Client Service in Windows 11 and 10

Here is How to Enable or Disable DNS Client Service in Windows 11 or 10 –

Way-1: Take the help of System Configuration

Step-1: Press Windows and R on the keyboard simultaneously to invoke Run dialog box.

Step-2: Once appears, type msconfig in the text box located next to Open and hit Enter.

Step-3: System Configuration wizard will show up now. Here, click on Services tab.

Step-4: Locate DNS Client from the available services. If you wish to Disable DNS Client Service, untick the checkbox of the same.

Step-5: To keep the service enabled, simply click on the checkbox to keep the tick mark.

Step-6: Subsequently, Click Apply and then OK button.

Step-7: Reboot the device otherwise the changes will not take place.

Way-2: Enable or Disable DNS Client Service using Services Console

• Press Win+Q to bring up the Windows search bar.
• Type services.msc in the text field and hit Enter when the result rolls out.
• On the console, find out DNS Client located under Name column.
• Make double-click on the same to open its Properties.
• Go to Startup type segment and use the drop-down menu to choose Automatic.
• Now, click on the Start button to enable DNS Client Service in Windows 11 or 10.
• To disable the same service, simply hit the Stop button.
• Finally, click Apply followed by pressing the OK button to make the changes effective.

Way-3: Use Registry Editor

You can Enable or Disable DNS Client Service in Windows 11 or 10 by changing the value of registry entries. But, keep in mind that if you do it incorrectly, your PC may get affected by a serious issue.

• Click on Start menu icon and type regedit.
• When the result comes up, hit Registry Editor option.
• A UAC will prompt up, click on Yes for positive consent.
• Once Registry Editor page comes into the view, navigate the following path from the left pane –

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dnscache

• Once you reach there, shift to the adjacent right side. Double click on the Start DWORD to modify its value.
• In the Value data box, put preferred value followed by clicking OK button.

Automatic – 2

Manual – 3

Disabled – 4

Automatic (Delayed Start) – 2

Way-4: Via Command Prompt

The procedure to Enable or Disable DNS Client Service in Windows 10 or 11 using the Command Prompt is given below  –

Step#1: Open Run dialog box.

Step#2: Type cmd.exe in the empty text bar and hit Ctrl+shift+Enter shortcut at the same time.

Step#3: If a UAC turns up, click Yes to run Command Prompt as admin.

Step#4: To disable DNS Client Service in Windows 11 or 10, run the below command in elevated Command Prompt –

net stop dnscache

Step#5: To enable the same, type the following and hit Enter to execute –

net start dnscache

This will Enable DNS Client Service instantly unless otherwise, the Startup type of this service is Disabled.

Step#6: To change the Startup type, execute the preferred command listed below –

Automatic –

REG add “HKLM\SYSTEM\CurrentControlSet\services\dnscache” /v Start /t REG_DWORD /d 2 /f

Manual –

REG add “HKLM\SYSTEM\CurrentControlSet\services\dnscache” /v Start /t REG_DWORD /d 3 /f

Disabled –

REG add “HKLM\SYSTEM\CurrentControlSet\services\dnscache” /v Start /t REG_DWORD /d 4 /f

Automatic (Delayed Start) –

REG add “HKLM\SYSTEM\CurrentControlSet\services\dnscache” /v Start /t REG_DWORD /d 2 /f

That’s all!!

Современные версии Windows поддерживают протокол DNS over HTTPS (DoH), который позволяет выполнять разрешение имен (DNS запросы) через шифрованное HTTPS соединение. В этой статье мы рассмотрим, для чего нужен протокол DNS over HTTPS, как его включить и использовать в Windows.

По умолчанию DNS трафик не шифруется. Это означает, что все запросы с вашего компьютера на разрешение имен к DNS-серверу передаются по сети в открытом виде. Сторонние лица могут подслушать ваш DNS трафик, определить какие ресурсы вы посещали, или манипулировать DNS трафиком по типу main-in-the-middle. Протокол DoH позволяет инкапсулировать DNS запросы в шифрованное HTTPS соединение и отправить их DNS серверу (нужен специальный DNS сервер с поддержкой DoH).

Как включить DNS over HTTPS из графического интерфейса Windows?

Встроенная поддержка протокола DNS-over-HTTPS (DoH) в DNS клиенте доступна в Windows 11 и Windows Server 2022. Чтобы ваш клиент использовал DoH для шифрования DNS трафика, нужно в настройках сетевого подключения указать IP адрес сервера с поддержкой DoH.

Список IP адресов публичных DNS серверов с поддержкой DoH можно вывести PowerShell командой:

Get-DNSClientDohServerAddress

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

Нужно указать IPv4 и IPv6 адрес одного из этих DNS сервера (или адрес любого альтернативного DNS сервера с поддержкой DoH, предварительно добавив его, о чем ниже) в настройках сетевого интерфейса.

1. Перейдите в Settings -> Network & Internet -> Ethernet (или Wi-Fi)
2. В данном случае видно, что DNS трафик не зашифрован.
   

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

3. Нажмите кнопку Edit
4. Укажите IP адрес DNS сервера, и для параметра DNS over HTTPS выберите -> On (automatic template)
5. Сохраните изменения. Теперь DNS запросы будут отправляться в шифрованном виде.
   

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

В DNS клиенте Windows Server 2022 также поддерживается DoH (но служба DNS Server в этой версии Windows Server пока не поддерживает DoH).

Укажите IP адрес DNS сервера в настройках сетевого интерфейса и включите режим обязательного использования шифрования: Encrypted only (DNS over HTTPS).

Ни один из релизов Windows 10 сейчас не поддерживает протокол DoH. В одной из инсайдерской версии (Insider Preview OS Build 19628) этот протокол можно было включить через реестр. Для включения поддержки DoH, нужно было создайть параметр реестра с помощью командлета New-ItemProperty:

$AutoDohPath = 'HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters'
$AutoDohKey = 'EnableAutoDoh'
New-ItemProperty -Path $AutoDohPath -Name $AutoDohKey -Value 2 -PropertyType DWord -Force

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

Но в финальный релиз Windows 10 этот функционал не внедрен!

Настройка DNS over HTTPS в Windows 11 из командной строки

В Windows можно включить и настроить использование DNS over HTTPS из командной строки.

Сначала нужно добавить IP адрес сервера DoH в список известных серверов. Например, чтобы добавить альтернативные DNS сервера Cloudflare Family
1.1.1.3
и
1.0.0.3
(фильтруют вредоносный и взрослый контент), выполните PowerShell команду:

$DNSServer="1.1.1.3"
Add-DnsClientDohServerAddress -ServerAddress $DNSServer -DohTemplate "https://family.cloudflare-dns.com/dns-query" -AllowFallbackToUdp $False -AutoUpgrade $True

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

После того, как вы зарегистрировали шаблон для DNS сервера DoH нужно назначить этот IP в качестве предпочтительного DNS сервера в настройках сетевого интерфейса с помощью PowerShell команды:

Set-DnsClientServerAddress Ethernet0 -ServerAddresses ($DNSServer)

Затем включить обязательное использование DNS over HTTPS для сетевого интерфейса:
$i = Get-NetAdapter -Physical -Name Ethernet0


$s1 = "HKLM:System\CurrentControlSet\Services\Dnscache\InterfaceSpecificParameters\" + $i.InterfaceGuid + "\DohInterfaceSettings\Doh\$DNSServer"
New-Item -Path $s1 -Force | New-ItemProperty -Name "DohFlags" -Value 1 -PropertyType QWORD
Clear-DnsClientCache

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

С помощью отдельного параметра GPO можно включить обязательное использование DoH:

1. Запустите редактор локальной GPO (
   gpedit.msc
   )
2. Перейдите в Computer Configuration -> Policies -> Administrative Templates -> Network -> DNS Client section
3. Включите политику «Configure DNS over HTTPS (DoH) name resolution» и задайте значение Require DoH.
   

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

Как убедиться, что для разрешения имен в Windows используется DNS over HTTPS?

Чтобы проверить, что клиент DNS использует для разрешения имен протокол HTTPS по порту 443 вместо обычного 53 порта, используете встроенную утилита захвата сетевого трафика PktMon.exe (о которой мы говорили ранее).

Удалите все текущие фильтры Packet Monitor:

pktmon filter remove

Создайте новый фильтр для стандартного DNS порта 53:

pktmon filter add -p 53

Запустите мониторинг трафика в реальном времени (трафик выводится в консоль):

pktmon start --etw -m real-time

Если вы правильно настроили DNS over HTTPS, то трафик по порту 53 должен отсутствовать. Это ожначает, что все DNS запросы отправляются в шифрованной HTTPS сессии (на скриншоте ниже показан вывод в консоль при отключённом DoH и при включенном).

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

DNS over HTTPS реализован во всех популярных браузерах (Google Chrome, Mozilla Firefox, Microsoft Edge, Opera). В каждом из этих браузеров вы можете включить поддержку DoH. Таком образом все DNS запросы от браузера будут шифроваться (DNS трафик других приложений по-прежнему будет идти в открытом текстовом виде).

Больше все проблем технологии DNS over HTTPS и DNS over TLS создадут администраторам корпоративных сетей, которым станет сложнее блокировать доступ к внешним ресурсам из внутренних сетей. Также не понятно, что планирует делать Роскомнадзор, чья методика глубокой проверки и управления сетевым трафиком Deep Packet Inspection (DPI) перестанет работать при переходе протокола DNS на рельсы шифрованного https.

Привет.

Введение

Эта статья – про отдельную, но достаточно важную функцию по управлению DNS-подсистемой на стороне клиента. В частности, NRPT будет помогать и при использовании DNSSEC, и про работе с DirectAccess, в общем знание работы NRPT необходимо, чтобы обладать пониманием всей системы DNS на предприятии. Без NRPT Вы можете хорошо представлять, как взаимодействуют сервера друг меж другом и с внешними источниками, но безопасная ‘последняя миля’ без NRPT не настраивается. Я вообще хотел это сделать частью статьи про DNSSEC, но и эта тема заслуживает отдельного описания, и та статья уже достаточно масштабна и имеет тенденцию к росту. Поэтому заранее делаем отдельно.

Технология NRPT реализована в Windows 7, поэтому разговор будет именно про эту ОС. Я предполагаю, что Вы ознакомились со статьями про безопасность DNS в Windows Server 2008 R2 и про DNSSEC в Windows Server 2008 R2.

Многие предполагают, что NRPT – исключительно “внутридоменная” технология. Это не так, и NRPT настраиваема и для отдельных хостов. Далее – подробнее.

Оглавление

• Что такое NRPT – Name Resolution Policy Table
• Про Windows 7 DNS Client
• Глобальные настройки NRPT
  • Network Location Dependency
  • Query Failure
  • Query Resolution
  • Просмотр текущего значения глобальных настроек NRPT
• Правила NRPT и DNSSEC / DirectAccess
• Настройка NRPT в домене
• Настройка NRPT на отдельном хосте
• Как изменится алгоритм работы DNS Resolver с NRPT
• Проверяем работу NRPT

Что такое NRPT – Name Resolution Policy Table

NRPT – массив служебной информации, которая детализирует поведение сервиса DNS Client в плане безопасности. Говоря проще, это возможность установить специфику поведения DNS-клиента в зависимости от FQDN запроса или ответа со стороны сервера. Состоит NRPT из отдельных правил, которые указывают, для каких запросов как надо себя вести (например, добавлять ли флаги о поддержке DNSSEC в отправляемые на сервер запросы, как проверять и проверять ли ответы от DNS-сервера, что делать в случае работы DirectAccess). Хранится это всё в реестре, управляется через групповую политику либо напрямую, правкой реестра.

Данная функциональность появляется только в Windows 7.

Про Windows 7 DNS Client

Никогда не задумывались, что будет, если выключить сервис DNS Client? А почти ничего не будет. Этот сервис, по сути – мини-DNS-сервер, который при старте забирает в кэш содержимое файла hosts и форвардит запросы от ОС и ПО на указанные в настройках сервера, запрашивая рекурсию. Про DNS client в Windows 7 пишут страшную фразу: “Non-validating security-aware stub resolver”. Разберемся, что это обозначает:

• Non-validating – это обозначает, что клиентский сервис в Windows 7 не проверяет целостность записей, которые ему возвращает сервер. То есть, если в ответе сервера есть, допустим, RRSIG, клиент Windows 7 его не проверит, даже если будет иметь технологическую возможность. Почему? Потому что сценарий DNSSEC в связке Win2008R2+Win7 – это “дотащить через инфраструктуру DNS-серверов безопасный ответ от других серверов, обеспечивая его целостность и аутентичность”. В этом сценарии клиент верит, что раз он что-то берёт от своего DNS-сервера, то раз оно “доползло” до сервера, то оно правильное-целостное-хорошее. Поэтому Microsoft, к примеру, предлагает защищать трафик от DNS-сервера до клиента IPSec’ом. “Как же так, ну вот зашифруете вы этот кусочек трассы, и что?” – удивляются люди. А ничего удивительного – если взять предположение, что DNSSEC-инфраструктура настроена правильно, то она просто “плохие” ответы не допустит до последнего в цепочке DNS-сервера, к которому, в свою очередь, будут подключаться клиенты.
• Security-aware – это обозначает, что клиентский сервис умеет ставить в запросах бит, показывающий, что ему нужно возвращать DNSSEC-ответы. Т.е. наличие этого бита важно – тогда сервер начинает понимать, что это вообще нужно делать. Заметьте, что для этого обязательно должен быть включен и настроен EDNS0 (как это сделать, есть в статье про безопасность DNS в Windows Server 2008 R2). И ещё, если клиент поставит такой бит, а сервер не-DNSSEC совместимый (как большинство публичных DNS-серверов, допустим, использующихся в домашних сетях и у провайдеров доступа в Интернет), то сервер, скорее всего, пришлёт “отбой” – что он не может отработать запрос клиента.
• Stub resolver – это обозначает, что клиентский сервис всегда запрашивает рекурсивный запрос, просто перебирая указанные ему DNS-сервера.

Соответственно, эффективная настройка клиента возможна только с учётом всего вышеуказанного (и EDNS0, и NRPT, и всё остальное).

Теперь начнём настраивать NRPT. Начнём, что и логично, с глобальных настроек.

Глобальные настройки NRPT

Глобальные настройки NRPT проще всего редактировать через групповую политику (соответственно, на локальной системе – через вызов gpedit.msc). Откройте объект групповой политики, там выберите Computer -> Windows Settings -> Name Resolution Policy. В этом разделе, в общем-то, и собраны все настройки NRPT. Делятся они на две части:

• Линейный массив правил
• Глобальные настройки хоста

Посмотрим, какие нам доступны глобальные настройки. Это можно сделать, нажав кнопку Advanced Global Policy Settings.

Настройка Query Resolution в NRPT

Данная настройка поможет Вам выбрать поведение клиента, в случае, если ему в ответ на запрос будет возвращены и записи типа A, и AAAA. Зачем может понадобиться такая странная настройка, тем более, не учитывающая наличие IPv6 на узле вообще и на интерфейсах в частности? Это нужно в случае, когда Вы подключаетесь по DirectAccess. В этом случае, подключаясь к корпоративной сети, все узлы (в силу природы Direct Access) должны быть доступны по IPv6, и их имена должны разрешаться в AAAA. Обсуждаемая настройка будет закреплять эту ситуацию тем, что даже если для узла будет доступна/разрешаема/в локальном кэше позитивная запись и A и AAAA вида, будет обрабатываться только AAAA. Соответственно, включайте режим Resolve only IPv6 adresses for names только для описанного случая. Просто так не надо.

Настройка Query Failure в NRPT

Данная настройка – единственная, адресно относящаяся к DNSSEC. Она помогает настроить поведение клиента в случае, когда самый оптимальный и безопасный вариант разрешения имени (через DNSSEC) не сработал. Если эта опция не включена, то по умолчанию DNS-клиент будет пробовать другие способы разрешения имени (LLMNR и NBNS) только если получит чёткий ответ от сервера, что такой записи нет. Вы можете, управляя этой настройкой, управлять тем, как и после каких ошибок разрешения имени DNS-клиент будет действовать дальше. Варианты будут состоять из:

• 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) – этот вариант используется по-умолчанию и подразумевает, что если сервер, у которого мы запрашивали DNSSEC-ответ, вернул нам сообщение, что имя не найдено, то мы попробуем другие способы разрешения имени.
• Only use LLMNR and NetBIOS ... (в конце помечен как most secure) – если не нашли по DNSSEC, то считаем, что имени нет и не пробуем LLMNR и NetBIOS.
• Always fall back ... (в конце - least secure) – самый небезопасный вариант. Логика проста – если по любой причине не удалось разрешить имя узла через DNSSEC-сервер, пробовать разрешить его через LLMNR и NetBIOS. Данный вариант является самым небезопасным, потому что даже в случае, допустим, если Ваш хост начнёт искать www.atraining.ru, а DNSSEC-сервер скажет, что “ну нет записи www в зоне atraining.ru.“, Ваш хост попробует найти среди соседей того, кто откликнется на броадкаст “Кто тут www?”.

Настройка Network Location Dependency в NRPT

Настройка пригодится в случае работы через UAG с Direct Access. В этом варианте Вам должен быть доступен NLS-сервер (точнее даже, NLS-сайт на нём). Соответственно, можно тюнинговать поведение клиента в виде трёх различных вариантов, выбираемых в этой настройке:

• Клиент, у которого есть подключение по DirectAccess, сам “осознаёт”, подключён он к intranet или нет – вариант Let Network ID (NID) determine when Direct Access setting are to be user (это нормальная логика поведения клиента).
• Клиент всегда предполагает, что раз в системе есть подключение по DirectAccess, то он “в intranet’е” – вариант Always use Direct Access settings in th NRPT. Соответственно, все правила NRPT, где есть настройки DirectAccess, обрабатываются и принимаются во внимание.
• Клиент всегда предполагает, что он отключен от intranet’а и должен вести себя (с точки зрения обработки правил NRPT, заметьте!) так, будто канал DirectAccess сконфигурирован, но не подключен – вариант Never use Direct Access settings in th NRPT.

Лучше, пока сильно не надо, эту настройку не трогать. Выиграть в обычной ситуации, когда Direct Access нет, Вы этим ничего не выиграете.

Если что, настроить URL, по которому будет проверяться наличие NLS-сайта, можно здесь:

HKLM\software\policies\microsoft\windows\NetworkConnectivityStatusIndicator\
CorporateConnectivity\DomainLocationDeterminationUrl

Как посмотреть текущие глобальные настройки NRPT?

Достаточно несложно – есть команда

netsh dns show state

которая их покажет.

Теперь поговорим про создание и управление правилами NRPT.

NRPT в домене и правила DNSSEC / DirectAccess

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

В каждом NRPT-правиле будут следующие компоненты:

Компонент Namespace

Варианты:

• FQDN – явно указанный FQDN отдельного узла. Не подойдут варианты вида *.atraining.ru, т.е. именно явно указанный узел.
• Suffix – все запросы, которые будут заканчиваться на указанный суффикс, будут считаться подпадающими под это правило.
• Prefix – все запросы, FQDN которых будут начинаться с этого компонента. Внимание – в случае с суффиксом длина суффикса не ограничена – он может быть как из 2, так и из 3 или 4 компонентов. В префиксе же допустимо только одно имя: точку использовать нельзя.
• Subnet (IPv4) – все запросы для PTR-записей из указанной IPv4-подсети (указывается в формате ip-адрес/длина маски).
• Subnet (IPv6) – все запросы для PTR-записей из указанной IPv6-подсети.

Компонент Certification Authority

Это поле задавать не нужно. Причина в следующем. Правило лишь покажет клиенту, когда надо ставить бит “требую DNSSEC-ответ”. Сама связь с DNS-сервером будет защищаться уже IPSec-политикой, в которой будут настройки аутентификации. Т.е. тут проверять CA не имеет смысла – это правило перенаправления, а не проверки серверов.

Если Вы всё же зададите это правило, то надо будет выбрать один из сертификатов корневых CA, и сервер будет проверяться на выданность именно этим CA. Со стороны организации это приведёт к тому, что надо будет сделать специальный CA, который будет выдавать только специальный вид сертификатов DNSSEC, которые делаются из специального шаблона (т.е. этот пункт мало того, что проверяет сертификат на действительность и выданность указанным CA, так ещё и проверяет EKU, поэтому, допустим, обычный компьютерный сертификат не подойдёт). Про это я подробнее писал в DNSSEC в Windows Server 2008 R2, а так как эта статья про настройки клиентов, то здесь про это подробнее не особо надо.

Компонент DNSSEC : Validation

Если запросы, подпадающие под данное правило, нуждаются в защите посредством DNSSEC, выберите вкладку DNSSEC и включите её – Enable DNSSEC in this rule. Как понятно, на вкладке про Direct Access будет аналогичный “выключатель” – ведь технологии DNSSEC и Direct Access не противоречат друг другу.

Теперь включим обязательный запрос DNSSEC-ответа. По сути, мы скажем – если наш запрос подпадает под правило, надо ставить бит DO (DO – это хардкорное обозначание ои DNSSEC OK) в EDNS0-запросе. Включим установкой отметки около Require DNS clients to check that name and address data has been validated by the DNS server.

Компонент DNSSEC : Encryption

Это – про шифрование запросов. Да, это, по сути, не DNSSEC. Но это то, что ожидают от термина “защита DNS-трафика”, поэтому, несмотря на то, что эта настройка, по сути, “инициирует” требование защиты IPSec’ом, она здесь есть.

Включите параметр Use IPsec in communication between the DNS client and DNS server и выберите нужную степень защиты. Обратите внимание, что это уже FIPS140-1 – Вам даже не предложат RC4, DES, и самым минимальным будет 3DES/AES. Доступные варианты будут:

• Не требовать шифрование; достаточно подтверждения подлинности.
• 3DES и любой AES.
• Только AES.
• Только AES с ключом более 128 бит (т.е. 192 или 256).

Я бы рекомендовал в этой настройке всегда выбирать максимум. Причина – DNS-трафик крайне мал, поэтому рост вычислительной сложности алгоритма шифрования никак не повлияет на скорость работы клиента.

Будьте внимательны, есть различие между вообще не включённой этой настройкой и включением и выбором пункта “Не требовать шифрование”. Если настройку не включать, то для общения с сервером не обязателен будет IPSec (т.е. живая IKE’шная SA). Если включать и выбрать “не требовать шифрования”, то IPSec будет согласован, но не обязательно ESP, а AH. Авторами настроек предполагается, что у Вас в политике IPSec, действующей на связку клиент-сервер, будет список согласовываемых алгоритмов и методов, который будет начинаться с ESP и заканчиваться AH.

Если Вы сделали всё это, то с настройками, касающимися DNSSEC, уже всё ОК. Остался только Direct Access, про него будет отдельно.

Настройка NRPT на отдельном хосте

Ну тут как обычно. Те, кто читает уже не первую статью на этом ресурсе, знает, что сейчас начнётся.

Надо создать ключ реестра с названием

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig

В нём – для каждого правила свой подключ вида Rule1, Rule2, и далее, до RuleX. Каждый из этих подключей, что логично, будет задавать отдельное правило NRPT и иметь свой одинаковый комплект значений. Их будет чуть больше, чем в графическом интерфейсе. Разберемся.

Значение Version в NRPT

Тип – DWORD32. Обозначает версию NRPT. На данный момент только единица.

Значение ConfigOptions в NRPT

Тип – DWORD32. Обозначает, на каких из двух вкладок Вы поставили “включить”. Если равно 2 – то на DNSSEC. Если 4 – то на DirectAccess. Если 6 – то на обоих.

Значение Name в NRPT

Тип – MULTI_SZ. Тут уже интереснее. Будьте аккуратнее.
Система не делает два отдельных поля “Тип имени” и “Имя”, поэтому отличает типы по признакам. Смотрите:

• Если Вы задаёте FQDN – например, www.atraining.ru – система узнает его по тому, что это строка, разделенная точками, и не имеющая точек в начале и конце
• Если Вы задаёте суффикс – например, .atraining.net – система узнает его по стартовой точке.
• Если Вы задаёте подсеть IPv4/IPv6 – например, .0.168.192.in-addr.arpa или .1.0.0.0.0.0.0.4.3.2.1.0.2.0.0.2.ip6.arpa – система узнает это по предсказуемому суффиксу и стартовой точке.
• Если Вы задаёте префикс – hostname1 – система узнает это по отсутствию точек.
• Если под правило должно подпадать всё – просто укажите точку.

Значение IPSECCARestriction в NRPT

Тип – SZ. Это – DN CA, который должен подтверждать подлинность DNS-сервера. То есть, это строка, имеющая вид типа “CN=ca1,DC=domain,DC=local”.

Значение DNSSECValidationRequired в NRPT

Тип – DWORD32. Аналог того, что выше обсуждалось как Validation. Значения – единица или нуль.

Значение DNSSECQueryIPSECRequired в NRPT

Тип – DWORD32. Флаг, надо ли требовать IPSec. Значения – единица или нуль.

Значение DNSSECQueryIPSECEncryption в NRPT

Тип – DWORD32. Выбор варианта защиты IPSec’ом; 0 – если шифрование необязательно, 1 – подойдёт любое, 2 – только AES, 3 – только AES выше 128 бит. Тоже выше обсуждали.

В общем-то, всё. Как понимаете, благодаря этим настройкам Вы сможете даже с домашней машины сделать вполне разумную политику – от запросов к каким доменам (допустим, корпоративным) требовать подтверждения, а с какими – и шифрования, и как вести себя системе, если DNSSEC-запрос не срабатывает.

Если подозреваете, что эти параметры не работают, поставьте требовать от Any (которое точка) и DNSSEC и шифрование, удивитесь, с какой скоростью перестанут разрешаться имена. На локальном хосте это применяется крайне шустро.

Теперь давайте, вооруженные знаниями по возможностям и настройкам, разберемся, как наличие NRPT дополняет стандартную логику DNS Client’а.

Как выглядит алгоритм работы DNS Resolver, который с NRPT

• Приложение запрашивает какое-либо имя. Если это имя не кончается на точку, система дополняет его суффиксом.
• Получившееся имя смотрят в локальном кэше. Если результат есть (что негативный, что позитивный) – он возвращается клиенту. Если нет – далее.
• Проверяется, подпадает ли этот FQDN под одно из правил NRPT. Если не подпадает, или подпадает под правило-исключение, в котором стоит “не запрашивать DNSSEC и/или DirectAccess”, то запрос обрабатывается нормально – DNS Client вспоминает, что он тупой стаб и делает рекурсию по списку известных ему DNS-серверов.
• Если запрос подпал только под одно NRPT-правило, то он обрабатывается согласно ему. Если под несколько – то правила выстраиваются в порядке приоритета. По порядку:
  • Первым идёт FQDN-правило, потому что 100% подпадение.
  • Потом правила на совпадение префиксов – выбирается то, у которого совпал максимум символов (т.е. если мы запрашивали, например, host1.atraining.ru, то если такого FQDN нет, нам подойдёт префиксовое правило про host1, после – и про hos)
  • Потом правила на суффиксы – тоже выиграет самое длинное совпадение, т.к. полного-то уже не будет точно.
  • Ну а потом, что логично – точка.
• И запрос обрабатывается самым лучшим по приоритету правилом. Одним.

Как понятно, в случае приёма ситуация проще – всё принятое “прогоняется” через таблицу, если подпало – проверяется на совпадение деталей (шифрование, целостность, имя CA – что настроите).

В общем-то, всё.

Проверяем работу NRPT

Как проверить на локальном хосте, как у него сейчас работает NRPT?

Есть команда:

netsh namespace show policy

которая выведет все текущие настройки NRPR.

Заключение

Я искренне надеюсь, что “тёмных углов” в хороших и нужных современных сетевых технологиях у Вас стало на один меньше. Если нет – пишите в комментарии; как обычно, я допишу те моменты, которых не хватает, либо те, которые расписаны недостаточно подробно.