Порядок разрешения имён в Windows — hosts, кэш DNS, LLMNR/mDNS и DoH

«Настройки одинаковые, а внутренний сервер недоступен только на этом ПК.» «В браузере открывается, а бизнес-приложение сбоит на разрешении имён.» «Положил в hosts — не действует.»

Когда расследуете такие проблемы, первое, что установить, — какой механизм отвечает за это имя. У Windows несколько путей: кэш, hosts, DNS-сервер, LLMNR, NetBIOS и mDNS, а некоторые приложения используют свой путь, отдельный от Windows.

Статья сначала даёт общую картину, разбирает форму имени и различия путей, затем переходит к фактической процедуре изоляции. Если нужно расследовать прямо сейчас, переходите к нужному разделу из следующей таблицы.

Предпосылки этой статьи

Статья о захвате пакетов покрывает пакеты, которые идут по проводу, а статья о прокси — «чьи настройки прокси читаются». Эта статья покрывает шаг до них: «откуда взялся IP-адрес назначения», организованный на основе первичных источников Microsoft.

1. Сначала вывод

Запомнить нужно три вещи.

• Разрешение имён Windows не всегда идёт вниз по одной очереди по порядку. Кэш и hosts идут первыми, но для однометки DNS и LLMNR/NetBT по умолчанию работают параллельно.³⁴
• Одно имя даёт разные результаты, когда настройки ПК и путь приложения различаются. Суффиксы, VPN, NRPT и встроенный резолвер браузера думайте отдельно.⁵⁶⁷
• В расследовании ограничивайте используемый путь и сравнивайте результаты. Отделяйте кэш, DNS и link-local переключателями Resolve-DnsName, затем подтверждайте сравнением настроек с рабочим ПК и захватом.⁸

Следующую схему используйте как общую карту.

flowchart TB
    accTitle: Разрешение имён — стопка слоёв
    accDescr: Запрос разрешения имён идёт от API приложения к службе DNS-клиент; сначала проверяются кэш и hosts, затем DNS-сервер, и только для однометок пробуются LLMNR и NetBIOS (по умолчанию параллельно с DNS). Для имён .local mDNS — дополнительный путь рядом с настроенным DNS. У браузера свой резолвер вне этой очереди
    app["Приложение (getaddrinfo)"] --> svc["Служба DNS-клиент"]
    svc --> cache["Кэш (включая hosts)"]
    cache -->|если нет| dns["Запросить DNS-сервер"]
    cache -->|"если нет, однометка (по умолчанию параллельно с DNS)"| ll["LLMNR / NetBIOS"]
    svc -->|"имя .local (дополнительный путь)"| mdns["mDNS"]
    browser["Браузер"] -.->|свой резолвер, DoH| ext["Отдельный путь"]

Кэш проверяется первым; за ним DNS и, для однометок, LLMNR и NetBIOS работают параллельно. У браузера отдельный путь.

Ниже «какой слой отвечает» покрыто в главах 3–5, «как отправляется запрос» — в главе 6, «как проверять» — в главах 7 и 8. DoH — функция, которая переключает транспорт к DNS-серверу на HTTPS; она не заменяет порядок hosts, кэша и NRPT.⁹

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 48, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. «Разрешение имён» — не одна операция

Приложение получает обратно только адрес или ошибку

Когда приложение подключается по имени вроде www.example.com, вызывается getaddrinfo Winsock (Unicode-версия — GetAddrInfoW). Для пространства имён NS_DNS эта функция превращает имя в адрес через DNS, локальный файл hosts и другие механизмы. Если отвечают несколько поставщиков пространства имён, она агрегирует их ответы и возвращает их.¹⁰

Иными словами, по результату, который получает приложение, нельзя сказать, какой слой ответил.

Dns.GetHostAddresses в .NET на Windows тоже использует getaddrinfo. Для хоста, перечисленного в hosts, он возвращает этот адрес, не запрашивая DNS-сервер. HttpClient работает поверх этого класса Dns, поэтому приложение .NET, которое подключается к назначению напрямую, наследует порядок разрешения имён Windows.¹¹

Через HTTP-прокси меняется имя, которое разрешается. Локально разрешается имя прокси; имя назначения разрешается на стороне прокси. В этом случае локальные hosts, кэш, суффиксы и NRPT в разрешении назначения не участвуют. Какие настройки прокси используются, покрыто в статье о прокси.

2.1 Порядок решает служба DNS-клиент

Под getaddrinfo работает служба DNS-клиент (имя службы Dnscache). Документация Microsoft описывает базовый порядок так.³

1. Проверить кэш.
2. Проверить файл hosts.
3. Запросить DNS-сервер.

Поскольку содержимое hosts загружается в кэш при запуске службы, статья рассматривает первые два вместе как слой 1, «кэш и hosts».⁵

Дальше путь ветвится в зависимости от имени и политик.

«Интеллектуальное разрешение имён при нескольких подключениях» по умолчанию отправляет запросы DNS, LLMNR и NetBT во все сети параллельно. Какой ответ принимается, решают правила разделов 4.3 и 5.2.⁴

Поэтому «когда запрос отправлен» и «приоритет, данный ответам, которые пришли» — разные вещи. Увидеть LLMNR или NetBT в захвате само по себе не значит «DNS не удался». «Три слоя» в этой статье — деление для объяснения; они не значат, что слои всегда идут последовательно по времени.

2.2 То, что вне очереди

Два, которые особенно легко спутать, — эти.

Использование встроенного клиента Edge само по себе не значит, что DNS-сервер меняется. Раздел 6.2 рассматривает его отдельно от настройки Secure DNS, которая выбирает другого провайдера.

3. Слой 1 — кэш и hosts

На этом слое нужно знать какие ответы остаются внутри ПК. Кэш держит не только верные ответы, но и устаревшие и ответы «имя не существует».

3.1 hosts загружается в кэш

Файл hosts находится в C:\Windows\System32\drivers\etc\hosts. Когда служба DNS-клиент запускается, её соответствия имён IP-адресам загружаются в кэш резолвера. Записи, полученные из запросов DNS, держатся в том же кэше на свой TTL (time to live).⁵

ipconfig /displaydns показывает и записи, загруженные из hosts, и записи, полученные недавними запросами DNS.¹³ В собственном примере Microsoft, если положить contoso.com в hosts, Resolve-DnsName contoso.com возвращает этот адрес и трафик DNS не идёт.³

Как читать отсутствие пакетов DNS

Если разрешаете FQDN без DoH или DoT, разрешение имён удаётся и на порту 53 нет запроса, предположительно отвечают кэш или hosts. Сначала, однако, исключите следующие другие пути.

Не заключайте «кэш» только потому, что «на порту 53 ничего нет»; смотрите и пути, которые могут быть в использовании. Одна строка тестового hosts, оставленная на машине разработки, может увести расследование в сторону.

Правка hosts требует прав администратора, и продукты безопасности могут обнаружить смену. Проекта, который заставляет операции бизнес-приложения зависеть от hosts, следует избегать.

3.2 Отрицательные ответы тоже кэшируются

«Не найдено» — тоже один из ответов, которые кэшируются. DNS-клиент хранит и отрицательные ответы, и положительные.⁵

Если ipconfig /displaydns показывает «Name does not exist» для целевого имени, отрицательный ответ DNS-сервера остаётся на клиенте. Процедура Microsoft указывает сбросить его через ipconfig /flushdns.¹⁴¹³

Время хранения отрицательного кэша — MaxNegativeCacheTtl в HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters, по умолчанию 5 секунд.¹⁵ Поэтому ПК может несколько секунд продолжать возвращать сбои даже сразу после того, как запись добавили в DNS.

3.3 TTL и «только часть ПК устарела»

Положительные ответы тоже остаются на свой TTL. ПК, который разрешил имя до смены IP-адреса сервера, продолжает использовать старый ответ, а ПК, который разрешает его впервые после смены, получает новый. Даже с одним DNS-сервером результат различается, когда различается время запроса.⁵

Clear-DnsClientCache ведёт себя так же, как ipconfig /flushdns, и удаляет всё содержимое кэша, включая отрицательные ответы.¹⁶ Через Get-DnsClientCache можно получить кэш как объекты и проверить тип записи и оставшийся TTL.¹⁷

# Есть ли конкретное имя в кэше и сколько секунд TTL осталось
Get-DnsClientCache -Entry 'app01.corp.example.com' |
    Select-Object Entry, Type, Status, TimeToLive, Data

# Проверить содержимое hosts и кэша вместе
ipconfig /displaydns | Select-String -Pattern 'app01' -Context 0,6

# Сбросить кэш (включая отрицательные ответы)
Clear-DnsClientCache

Если ответ найден на слое 1, этот запрос решается до того, как дойдёт до DNS-сервера. Однако остаётся возможность, что неверный ответ изначально узнали от DNS-сервера. Не останавливайтесь на очистке; также проверьте ответ, полученный заново, на шаге 3 главы 8.

4. Слой 2 — запрос DNS-сервера

Если на слое 1 ответа нет, разрешение переходит к DNS. Здесь отдельно думайте о том, какое имя отправляется, какому серверу и в какой момент.

4.1 Однометки и суффиксы

Сначала проверьте форму имени, которое передало приложение.⁵

Суффикс — часть домена, добавляемая после короткого имени. Добавление corp.example.com к app01 делает запрашиваемое имя app01.corp.example.com.

Когда есть список поиска

Суффиксы из списка поиска DNS-суффиксов добавляются по порядку сверху, и имя отправляется с завершающей точкой. Как только список поиска настроен, используется только он. Основной суффикс, суффиксы, специфичные для подключения, и devolving имени не используются.¹⁸

Когда списка поиска нет

Добавляется основной DNS-суффикс. Если devolving имени включён, после каждого сбоя отбрасывается самая левая метка и имя пробуется снова; например, от www.test.contoso.com к www.contoso.com. Если у адаптера есть DNS-суффикс, специфичный для подключения, он тоже добавляется и отправляется.⁵

Поэтому один и тот же server01 раскрывается по-разному в среде, где групповая политика раздаёт список поиска, и в среде, где членство в домене даёт основной суффикс.

Длинный список тоже увеличивает ожидание

Если верный суффикс ближе к концу списка, время запроса накапливается, пока до него не дойдут. Microsoft тоже объясняет эту задержку примером, который пробует шесть суффиксов. Чтобы попробовать только одно конкретное раскрытие, добавьте завершающую точку, как в internal.contoso.com..³

# Глобальные настройки: список поиска и devolution
Get-DnsClientGlobalSetting

# По интерфейсу: суффикс, специфичный для подключения, и настройки регистрации
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering

# DNS-серверы по интерфейсу (и IPv4, и IPv6)
Get-DnsClientServerAddress | Where-Object ServerAddresses | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

Get-DnsClientGlobalSetting возвращает глобальные настройки вроде списка поиска и того, включён ли devolving и до какого уровня; Get-DnsClient возвращает настройки на интерфейс.¹⁹²⁰

4.2 Порядок нескольких DNS-серверов и тайм-ауты

Когда «не сбоит, но есть ожидание в несколько секунд», подозревайте повторные передачи к неотвечающему DNS-серверу. Для DNS-серверов, настроенных на одном NIC, время повторной передачи по умолчанию выстраивается так.²¹

Это таблица для случая, когда ответа нет. В особенности не путайте следующие два.

Когда «остановили один из них, а переключения нет», если сервер, держащий старую зону, продолжает работать и возвращает отрицательные ответы, разрешение не переходит к следующему серверу.²¹

До четвёртого и последующих серверов не доходят раньше чем через 4 секунды

Если сервер, который может ответить, четвёртый или позже в списке, после первого запроса проходит минимум 4 секунды. Если крайний срок приложения короче, оно сбоит на этапе разрешения имён. Чтобы запрос ушёл раньше, пришлось бы переместить этот сервер в первые три, но корневое исправление — починить недостижимые серверы впереди него или убрать их из настроек. Пересмотрите и тайм-аут на стороне приложения.²¹

В примере Microsoft тоже конфигурация, в которой из четырёх серверов достижим только один, занимает около 4 секунд до завершения. Время можно измерить через Measure-Command, и тот же документ считает приемлемым меньше 1 секунды.³

# Спросить конкретный сервер напрямую, только DNS, и получить затраченное время в миллисекундах
(Measure-Command {
    Resolve-DnsName -Name 'app01.corp.example.com' -Server 10.0.1.2 -DnsOnly
}).TotalMilliseconds

Поскольку эта команда фиксирует сервер, она измеряет время ответа только этого сервера. Задержку, пока не дойдут до четвёртой записи в списке, проверяют запросом без -Server или захватом этого запроса.

Заметьте, что DNS-клиент поднимает быстрее отвечающие серверы, запоминает неотвечающие и периодически повторяет их. Начальный тайм-аут также подстраивается в диапазоне от 25 до 1000 миллисекунд на основе прошлой производительности. Таблица выше — скелет по умолчанию, поэтому фактические измерения от неё отклоняются.⁵

4.3 Несколько NIC и «интеллектуальное разрешение имён при нескольких подключениях»

На ПК с проводным и Wi-Fi или ПК, к которому добавлен адаптер VPN, проверяйте не только список DNS-серверов, но и запросы по сетям и выбор ответа.

Повторная передача к нескольким адаптерам

В процедуре запроса Microsoft запрос идёт к первому DNS-серверу предпочитаемого адаптера с ожиданием 1 секунды. Если ответа нет, он идёт к первому серверу каждого адаптера, ещё оставшегося в наборе кандидатов, с ожиданием 2 секунд, а затем ко всем серверам всех адаптеров с ожиданиями 2, 4 и 8 секунд. Когда сервер на одном адаптере возвращает отрицательный ответ, остальные серверы этого адаптера убираются из кандидатов.⁵

Политика, которая управляет параллельными запросами

Групповая политика «Отключить интеллектуальное разрешение имён при нескольких подключениях» управляет следующим поведением.⁴

Поскольку политика названа «Отключить», заметьте, что включение политики отключает оптимизацию.

Пример, где VPN меняет результат

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

При двух положительных ответах принятие решает порядок привязки. В нынешнем Windows этот приоритет определяется метрикой интерфейса; чем меньше InterfaceMetric, который показывает Get-NetIPInterface, тем выше приоритет. Различия этого порядка от ПК к ПК становятся различиями результата.²²

Если, с другой стороны, домашняя сторона возвращает отрицательный ответ, этот адаптер убирается из кандидатов и используется ответ стороны VPN.⁵ Продукты VPN раздают NRPT или «Отключить интеллектуальное разрешение имён при нескольких подключениях» именно чтобы управлять этими различиями.

4.4 NRPT — смена того, куда идут запросы, по пространству имён

NRPT (Name Resolution Policy Table) — таблица, которая задаёт для пространства имён вроде .corp.contoso.com, какие DNS-серверы использовать и настройки DirectAccess и DNSSEC. Профили DirectAccess и Always On VPN пишут в неё правила, чтобы получить поведение вроде «отправлять только внутренние имена во внутренний DNS».²³⁶

Get-DnsClientNrptPolicy -Effective показывает правила, которые фактически действуют.

# Правила NRPT, которые фактически действуют
Get-DnsClientNrptPolicy -Effective

# Показать только правила конкретного пространства имён. -Namespace фильтрует только по атрибуту Namespace; сопоставление с именем не делает.
# Передача 'app01.corp.example.com' не возвращает суффиксное правило для '.corp.example.com'.
# Чтобы найти, какое правило применяется к имени, перечислите правила и сопоставьте сами, как на шаге 4 главы 8
Get-DnsClientNrptPolicy -Effective -Namespace '.corp.example.com'

NRPT применяется только к приложениям, которые используют Windows DNS API. Приложения с собственной реализацией DNS обходят этот путь. Документация VPNv2 CSP приводит nslookup как пример и требует Resolve-DnsName для проверки NRPT. Встроенный резолвер браузера и DoH тоже вне Windows DNS API.⁶

5. Слой 3 — запасные пути для однометок: LLMNR, NetBIOS, затем mDNS

5.1 Чем три протокола различаются

LLMNR и NetBIOS over TCP/IP (NetBT) — альтернативные средства разрешения однометки вроде app01. По умолчанию они работают параллельно с DNS, и link-local ответ может быть принят даже когда DNS возвращает положительный ответ. Последовательно после сбоя DNS они становятся, только когда интеллектуальное разрешение имён при нескольких подключениях отключено.⁴

mDNS отдельно от них; это дополнительный путь для имён .local. Это не универсальный запасной путь, который включается после сбоя разрешения однометки через DNS.²⁴

Даже для .local не пропускайте проверку DNS

.local не становится только mDNS. Если домен Active Directory что-то вроде corp.local, это имя продолжает разрешаться и настроенными DNS-серверами, и NRPT. RFC 6762 также допускает сосуществование с unicast DNS. Когда расследуете имена .local, проверяйте и политики DNS и VPN.²⁴

NetBT зависит от того, есть ли WINS, и от типа узла

Без настроенного WINS по умолчанию B-node; при хотя бы одном настроенном сервере WINS по умолчанию H-node.²⁹ Широковещания LLMNR и NetBT не пересекают подсети, но запросы к WINS — unicast и поэтому могут.

nbtstat -c показывает кэш имён NetBIOS, а nbtstat -R очищает кэш и перезагружает LMHOSTS.³¹

5.2 Что имеет приоритет

Какой ответ имеет приоритет после параллельных запросов, тоже управляется политикой.⁴

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

5.3 Курс Microsoft: выравнивание по mDNS

В апреле 2022 года Microsoft объявила курс на выравнивание по mDNS и постепенное сворачивание разрешения имён NetBIOS и LLMNR.²⁷ Старые и небезопасные протоколы обнаружения устройств вроде Computer Browser тоже объявлены deprecated.³² Проекты, которые дополняют однометки multicast или широковещанием, уходят.

Сведения Microsoft об уязвимости LLMNR перечисляют как обходы блокировку TCP/UDP 5355 и включение групповой политики «Отключить разрешение многоадресных имён». Также указано, что как следствие компьютер может стать невидимым для других компьютеров.²⁵ Включение этой политики отключает LLMNR на всех адаптерах DNS-клиента.⁴

Само решение отключить — правильное, но замену пути, который исчезает, нужно предоставить в DNS. Для устройств, не зарегистрированных в DNS, зарегистрируйте их A-записи или включите динамическую регистрацию через DHCP и смените назначения на FQDN. Устройства, которые поддерживают mDNS, могут использовать имена .local, но досягаемость ограничена тем, куда проходит multicast.

5.4 Типичный случай «только часть ПК не подключается»: однометки

Когда в файле конфигурации или ярлыке стоит \\fileserver01 или http://app01/, одно имя даёт следующие различия.

Что говорит Resolve-DnsName app01 -LlmnrOnly — «можно ли разрешить через LLMNR». Это не говорит, откуда пришёл ответ, принятый в повседневных запросах. Сравнение с результатом без переключателей и захваты делают на шаге 5 главы 8.⁸

Корневое исправление — FQDN и регистрация в DNS

Смените назначения, которые зависят от однометок, на FQDN и сведите разрешение имён к DNS.

SMB2 и новее подключаются напрямую по TCP 445 и не используют сеансы NetBIOS.³³ Это, однако, вопрос транспорта. На этапе разрешения имени в назначении вроде \\fileserver01\share могут использоваться LLMNR или NetBT. Укажите FQDN, как в \\fileserver01.corp.example.com\share, чтобы убрать зависимость от пути однометки.

Некоторые оговорки остаются даже с FQDN. FQDN без завершающей точки тоже пробуется с суффиксами, если включена политика, которая добавляет суффиксы к многометкам. Имя, оканчивающееся на .local, может использовать mDNS рядом с DNS. Форма, которая безусловно фиксирует имя, — абсолютное имя с завершающей точкой. Предпосылка считать на практике «FQDN зафиксирован на DNS» истинным — что политика выше отключена и что внутреннее доменное имя не использует .local.

6. Транспорт к DNS-серверу — DoH не меняет порядок

6.1 DoH в Windows 11 / Windows Server 2022

DoH Windows — функция, которая отправляет запросы к DNS-серверу по HTTPS. Она интегрирована с существующими hosts, кэшем и NRPT и с настройками резолвера на адаптер и профиль; она не заменяет порядок, описанный в главах 3 и 4.⁹

DNS-клиент Windows 11 поддерживает DoH, а более новые версии также поддерживают DoT (DNS over TLS). Описание Microsoft, однако, не указывает, какие версии поддерживают DoT, поэтому доступность не гарантирована в каждой среде, которую предполагает статья. Дальше покрывается DoH.⁹

Сначала проверьте список известных DoH-серверов

Если DDR не включён, можно использовать только серверы из списка известных DoH-серверов. Список по умолчанию содержит Cloudflare, Google и Quad9, и его можно проверить через Get-DnsClientDohServerAddress. Для внутреннего DNS-сервера и подобного зарегистрируйте шаблон DoH вместе с настройками отката и автообновления.¹³⁴

# Список известных DoH-серверов
Get-DnsClientDohServerAddress

# Зарегистрировать внутренний DNS-сервер как DoH-сервер (без отката к открытому тексту, с автообновлением)
Add-DnsClientDohServerAddress -ServerAddress '10.0.1.2' `
    -DohTemplate 'https://dns.corp.example.com/dns-query' `
    -AllowFallbackToUdp $false -AutoUpgrade $true

Регистрация также возможна через netsh dnsclient add encryption. Глобальный netsh dnsclient set global doh=yes|no|auto — настройка, отдельная от autoupgrade на сервер.³⁵

Одного auto недостаточно, чтобы запретить откат к открытому тексту. Откатываться ли к UDP при сбое решает отдельно udpfallback на сервер или -AllowFallbackToUdp в PowerShell. Чтобы ограничить разрешение только зашифрованным транспортом, отключите и откат.³⁵

При включённом DDR есть и путь динамического обнаружения

На версиях, которые поддерживают DDR (Discovery of Designated Resolvers), резолвер, настроенный в открытом тексте, может объявить свои конечные точки зашифрованного DNS. Поскольку соединение можно обновить до шифрования без регистрации в статическом списке, нельзя сказать «его нет в списке, значит это не DoH».³⁵

Чтобы DDR работал, нужны оба: глобальный netsh dnsclient set global ddr=yes и на адаптер set interface <name> ddr=yes. Откатываться ли к открытому тексту, когда зашифрованное разрешение, полученное через DDR, не удаётся, решает ddrfallback, который по умолчанию отключён.

В расследовании кроме известного списка проверьте netsh dnsclient show global и netsh dnsclient show state и значения, заданные через set interface на адаптерах, у которых есть DNS-серверы. Подкоманды show, определённые в документации, — encryption, global и state; отдельной подкоманды show на адаптер нет.³⁵

Разделяйте «Разрешить», «Требовать» и откат к открытому тексту

В приложении «Параметры» задайте настройки DNS вручную; «Предпочитаемое шифрование DNS» можно выбрать, только когда предпочитаемый DNS-сервер в известном списке. Есть три варианта.¹

Групповая политика «Настройка разрешения имён DNS over HTTPS (DoH)» имеет Разрешить, Запретить и Требовать. При Разрешить DoH используется, когда помимо регистрации в известном списке выполнены условия вроде автообновления, настройки шифрования адаптера или глобального doh=auto. При «Требовать» само разрешение имён сбоит против серверов, которые не поддерживают DoH.¹³⁵

Не применяйте «Требовать DoH» к ПК, присоединённым к домену. Microsoft предупреждает об этом явно. Службы домена Active Directory сильно зависят от DNS, а служба DNS-сервера, поставляемая с Windows Server, не поддерживает запросы DoH.¹

В захвате читайте настройки и фактический трафик отдельно

Запросы, фактически отправленные по DoH, идут внутри TLS на порту 443, а не UDP 53. Даже при «Разрешить DoH», однако, запросы к серверам не из известного списка и откаты после сбоя шифрования идут открытым текстом. Настроенный DoH не заставляет трафик порта 53 исчезнуть.

Если запросов DNS не видно, проверяйте DoH и DoT (порт 853) в дополнение к hosts и кэшу. Как захватывать, см. статью о захвате пакетов.

6.2 DoH в браузере отдельно от ОС

Встроенный DNS-клиент Edge и смена назначения запроса через Secure DNS понятнее, когда разделить на два этапа.

Встроенный клиент управляется BuiltInDnsClientEnabled, и запросы DoH всегда делает встроенный резолвер.⁷ Secure DNS по умолчанию отключён на ПК, управляемых организацией, и настраивается через DnsOverHttpsMode (off / automatic / secure) и DnsOverHttpsTemplates.³⁶³⁷

Edge, у которого выбран другой провайдер, может разрешать внешние сайты, но не разрешать имена, известные только внутреннему DNS. Обратно, один Edge может всё ещё открывать страницы, когда DNS ОС нездоров. Если остаётся с текущим провайдером, назначение запроса не меняется.

Вывод: не считайте успех браузера и успех бизнес-приложения свидетельствами об одном пути. Проверяйте путь ОС через Resolve-DnsName или ping.

7. Какой путь берёт приложение?

Прежде чем выбирать инструменты расследования, выровняйте путь, на который смотрите.

Основные переключатели Resolve-DnsName, организованные по цели расследования, следующие.⁸

7.1 A и AAAA: IPv6 возвращается первым

Даже когда разрешение имён удаётся, выбор адреса, который следует, может сделать соединение медленным.

DNS-клиент запрашивает и A (IPv4), и AAAA (IPv6). В захвате тоже оба запроса появляются парой.³ После того как ответы пришли, getaddrinfo и стек подключения выбирают адрес для использования. Windows Vista и новее используют таблицу префиксов RFC 3484 и по умолчанию предпочитают глобальный unicast IPv6 IPv4.³⁸

Однако одного ответа AAAA недостаточно, чтобы всегда пытались соединение IPv6. Выбор назначения сначала отбрасывает непригодные назначения, например без исходного адреса IPv6 или маршрута, затем упорядочивает кандидатов.³⁹

Проблема возникает в средах, где исходный адрес IPv6 и маршрут как будто есть, но на самом деле не работают. Разрешение имён удаётся, но время теряется на соединении. Пытались ли IPv6 на самом деле, подтверждают не из одного ответа DNS, а из журналов соединения или захвата.

Microsoft не рекомендует отключать IPv6 как средство, потому что некоторые компоненты Windows перестают работать. Вместо этого описывает задание DisabledComponents в 0x20, чтобы предпочитать IPv4 в политике префиксов.³⁸ Случай, когда localhost разрешается в ::1 и конфликтует с расследованием, которое предполагало 127.0.0.1, также покрыт в статье о захвате пакетов.

8. Процедура изоляции — снимайте слои сверху

На нерабочем ПК выполняйте следующее по порядку. Каждая команда существует, чтобы ограничить путь, и одного её успеха недостаточно, чтобы доказать путь, взятый в повседневном разрешении. Сочетайте сравнение результатов с захватом в конце.

Шаг 1: проверьте форму имени

Проверьте в журнале или файле конфигурации имя, которое приложение фактически передаёт. Путь меняется в зависимости от того, однометка ли это, оканчивается ли на .local или есть ли завершающая точка. Для короткого имени вроде http://app01/ начните с дополнения в разделе 4.1 и различий по ПК в разделе 5.4.

Шаг 2: можно ли разрешить из одного кэша и hosts?

Resolve-DnsName -Name 'app01.corp.example.com' -CacheOnly
Get-DnsClientCache -Entry 'app01.corp.example.com'
Get-Content "$env:SystemRoot\System32\drivers\etc\hosts" | Select-String -Pattern 'app01'

-CacheOnly только ограничивает этот запрос локальным кэшем. Если неверный ответ узнали от DNS-сервера, после очистки приходит то же значение. То, что оно было в кэше, не доказательство, что DNS-сервер ни при чём.⁸

Шаг 3: можно ли разрешить через один DNS?

# Исключить hosts, не отправлять LLMNR/NetBIOS и запрашивать только настроенные DNS-серверы
Resolve-DnsName -Name 'app01.corp.example.com' -NoHostsFile -DnsOnly

Если на шаге 2 ответа не было, а этот шаг просто удаётся, обычно это обычный промах кэша. Назвать это проблемой кэша или hosts можно только когда шаг 2 показал устаревший ответ, неверный ответ или запись отрицательного кэша.

Если этот шаг тоже не удаётся, расследуйте маршрут к DNS-серверу, сторону сервера и политики на стороне клиента. Прежде чем переходить к шагу 4, проверьте следующее.

• Get-DnsClientNrptPolicy -Effective: есть ли правило, которое направляет имя к другому DNS-серверу?
• Get-DnsClientDohServerAddress и групповая политика DoH: задано ли «Требовать DoH» против сервера, который его не поддерживает?

Если есть NRPT, целевые серверы на шаге 4 меняются. Если причина — «Требовать DoH», сбоит только разрешение имён, тогда как маршрут и сервер оба здоровы. Сначала закончите проверки в разделах 4.4 и 6.1.

Шаг 4: спросите каждый сервер напрямую

Соберите DNS-серверы подключённых адаптеров и, если к целевому имени применяется правило NRPT, замените их серверами этого правила. Включите и DNS-серверы, настроенные только для IPv6.

$name = 'app01.corp.example.com'
# Собрать DNS-серверы подключённых интерфейсов и из IPv4, и из IPv6.
# Серверы, оставшиеся в настройках отключённого VPN или виртуального коммутатора, не относятся к текущему пути разрешения, поэтому исключите их (не пропустите серверы, настроенные только для IPv6)
$connected = @((Get-NetIPInterface -ConnectionState Connected).ifIndex | Select-Object -Unique)
$servers = @((Get-DnsClientServerAddress |
    Where-Object { $_.ServerAddresses -and ($connected -contains $_.InterfaceIndex) }).ServerAddresses)
# Серверы правила NRPT, действующего для этого имени (их пишут Always On VPN или DirectAccess), не появляются в настройках адаптера, поэтому берите их из действующей политики.
# Параметр -Namespace у Get-DnsClientNrptPolicy фильтрует только по атрибуту Namespace правила; сопоставление с именем не делает.
# Поэтому самостоятельно сопоставьте правило Any (.), суффиксные правила (ведущая точка; действуют на само пространство имён и дочерние домены), правила FQDN и префиксные правила (часть имени хоста; допускаются подстановочные знаки вроде web*),
# и примите более конкретное (более длинное) правило. Правило Any самое короткое, поэтому выбирается только когда другие правила не совпали
# Namespace — набор строк (отображается как Namespace : {.corp.example.com}), поэтому разверните элементы каждого правила для сопоставления и упорядочьте по длине совпавшего пространства имён
# Для абсолютного имени с завершающей точкой (app01.corp.example.com.) снимайте точку только при сопоставлении. В Resolve-DnsName передавайте исходный $name
$matchName = $name.TrimEnd('.')
$label = $matchName.Split('.')[0]
$matched = foreach ($policy in @(Get-DnsClientNrptPolicy -Effective)) {
    foreach ($ns in @($policy.Namespace)) {
        if (-not $ns) { continue }
        $hit = if ($ns -eq '.') { $true }
               elseif ($ns.StartsWith('.')) { $matchName.Equals($ns.TrimStart('.'), [System.StringComparison]::OrdinalIgnoreCase) -or $matchName.EndsWith($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               elseif ($ns.Contains('.')) { $matchName.Equals($ns, [System.StringComparison]::OrdinalIgnoreCase) }
               else { $label -like $ns }
        if ($hit) { [pscustomobject]@{ Namespace = $ns; Policy = $policy } }
    }
}
$rule = $matched | Sort-Object { $_.Namespace.Length } -Descending | Select-Object -First 1
$policyServers = @()
if ($rule) { $policyServers = @(@($rule.Policy.NameServers) + @($rule.Policy.DirectAccessDnsServers) | Where-Object { $_ }) }
if ($policyServers.Count -gt 0) {
    # Если NRPT задаёт серверы для этого пространства имён, запрос шага 3 идёт к этим серверам. Серверы адаптера вне пути, поэтому замените их
    $servers = $policyServers
}
$servers = $servers | Where-Object { $_ } | Select-Object -Unique
foreach ($server in $servers) {
    $sw = [System.Diagnostics.Stopwatch]::StartNew()
    try {
        $r = Resolve-DnsName -Name $name -Server $server -DnsOnly -ErrorAction Stop
        $status = 'OK'
        # Несколько записей могут приходить в разном порядке в каждом ответе, поэтому перед сравнением отсортируйте
        $answer = ($r.IPAddress | Sort-Object) -join ','
    } catch {
        # Сюда попадают отрицательные ответы (имени нет), SERVFAIL и тайм-ауты. Сохраните причину, не отбрасывайте её
        $status = $_.Exception.Message
        $answer = ''
    }
    [pscustomobject]@{ Server = $server; Status = $status; Answer = $answer; Milliseconds = [int]$sw.ElapsedMilliseconds }
}

Сначала выстройте серверы для сравнения

NameServers и DirectAccessDnsServers NRPT могут не появляться в настройках DNS адаптера. Если шаг 3 спрашивал серверы NRPT, а шаг 4 смотрит только серверы адаптера, вы сравниваете разные пути.

У NRPT есть типы правил вроде суффикса, FQDN, префикса и Any (.), и более специфичные правила имеют приоритет.⁴⁰ -Namespace только фильтрует по атрибуту правила; он не сопоставляет с именем хоста. Поэтому код выше раскрывает пространства имён правил и сопоставляет их с целевым именем.²³

На VPN со split-DNS нормально, что резолвер домашней стороны возвращает отрицательный ответ для внутреннего имени, а положительный возвращает только сторона NRPT. Если сравниваете и серверы вне пути, записывайте их отдельно как «контроль» и не смешивайте в суждение о расхождении зон. Тайм-ауты против серверов, оставленных на отключённых адаптерах, также отдельно от задержек на текущем пути разрешения.

Затем читайте результаты раздельно

Если они различаются и как наборы, проверьте содержимое зоны и серийные номера. Также это измерение с назначением, зафиксированным -Server. Задержку из-за положения в списке, «4 секунды, пока не дойдут до четвёртого и последующих серверов» из раздела 4.2, проверяют на шаге 3 или в его захвате.

Шаг 5: проверьте слой link-local

Resolve-DnsName -Name 'app01' -LlmnrOnly          # только LLMNR
Resolve-DnsName -Name 'app01' -LlmnrNetbiosOnly   # только LLMNR или NetBIOS (DNS не используется)
nbtstat -c                                        # кэш имён NetBIOS

Эта проверка нацелена на однометки. -NetbiosFallback откатывается к NetBIOS, только когда DNS не удаётся, поэтому для имени, которое DNS может разрешить, это не проверка NetBIOS.⁸

Читайте результаты так.

Какой протокол ответил, отличают в захвате по UDP 5355 (LLMNR) против UDP 137 (NetBT). Чтобы подтвердить повседневный путь разрешения, также сравните с адресом, который возвращает Resolve-DnsName без переключателей, и если они расходятся, проверьте принятый ответ в захвате, потому что по умолчанию DNS тоже запрашивается параллельно.

Шаг 6: сравните дампы настроек

В расследовании «только часть ПК» выполняйте тот же скрипт на рабочем и нерабочем ПК и сравнивайте.

# name-resolution-dump.ps1 -- запускайте с правами администратора и сравнивайте выходные файлы двух машин рядом
$out = "$env:COMPUTERNAME-name-resolution.txt"
$sections = [ordered]@{
    'Get-DnsClientServerAddress' = { Get-DnsClientServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'Get-DnsClientGlobalSetting' = { Get-DnsClientGlobalSetting | Format-List | Out-String }
    'Get-DnsClient'              = { Get-DnsClient | Format-Table InterfaceAlias, ConnectionSpecificSuffix, UseSuffixWhenRegistering -AutoSize | Out-String -Width 200 }
    'Get-DnsClientNrptPolicy'    = { Get-DnsClientNrptPolicy -Effective | Format-List | Out-String }
    'Get-DnsClientDohServerAddress' = { Get-DnsClientDohServerAddress | Format-Table -AutoSize | Out-String -Width 200 }
    'netsh dnsclient show state' = { netsh dnsclient show state 2>&1 | Out-String }
    'Get-NetIPInterface'         = { Get-NetIPInterface | Sort-Object AddressFamily, InterfaceMetric | Format-Table InterfaceAlias, AddressFamily, InterfaceMetric, ConnectionState, Dhcp -AutoSize | Out-String -Width 200 }
    'DNSClient policy registry'  = { Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient' -ErrorAction SilentlyContinue | Format-List | Out-String }
    'ipconfig /all'              = { ipconfig /all | Out-String }
}
$sections.GetEnumerator() | ForEach-Object {
    "===== $($_.Key) ====="
    try { & $_.Value } catch { "ERROR: $($_.Exception.Message)" }  # Отсутствующие пункты (например DoH в Windows 10) оставляйте записанными как ошибки
} | Set-Content -Path $out -Encoding UTF8
Write-Host "wrote $out"

Сравнивать нужно порядок DNS-серверов, список поиска, суффиксы, специфичные для подключения, NRPT, DoH, метрики интерфейсов и значения политик.

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient держит EnableMulticast для «Отключить разрешение многоадресных имён», DisableSmartNameResolution для «Отключить интеллектуальное разрешение имён при нескольких подключениях», список поиска, основной суффикс и так далее.⁴ Сверяйте разницу с работой каждого слоя, организованной до сих пор.

Шаг 7: подкрепите захватом пакетов

Процедура сбора данных Microsoft запускает netsh trace start capture=yes и на клиенте, и на сервере, сбрасывает кэш через ipconfig /flushdns, воспроизводит проблему и останавливает через netsh trace stop.⁴¹

В Wireshark фильтруйте dns.qry.name == "app01.corp.example.com" или dns.qry.name contains "app01", чтобы увидеть, какой сервер спросили о чём и что пришло обратно.

Если брандмауэр стороны отправки блокирует UDP 53, Resolve-DnsName истекает по тайм-ауту и в захвате тоже нет запроса DNS. Изолируйте не только случай, когда разрешение имён удаётся и трафик не уходит, но и случай, когда оно не удаётся и трафик не уходит.³

Кроме DNS проверяйте 5355 для LLMNR, UDP 5353 для mDNS и UDP 137 для службы имён NetBT. DoH — 443, DoT — 853. Как захватывать и читать захваты, собрано в статье о захвате пакетов.

9. Проектирование на стороне бизнес-приложения — устойчивость к разрешению имён

Чтобы расследования были легче, важно, чтобы сторона приложения могла записать «какое имя, во что разрешилось и где сбой». Сопоставление журнала приложения с дампами настроек и захватами, которые собирают ИТ-сотрудники, облегчает решение, с какого места главы 8 начинать.

Держите назначения как FQDN и не зависьте от hosts

Сделайте значения по умолчанию в файлах конфигурации, ярлыках и UNC-путях FQDN. Это убирает зависимость от дополнения однометок суффиксом и от LLMNR и NetBT. Оговорки из раздела 5.4, однако, остаются: mDNS рядом с DNS для имён .local и политика, которая добавляет суффиксы к именам без завершающей точки.

hosts удобен для временного переопределения при разработке, но требует прав администратора и ручной работы. Распространение и история изменений трудно управлять, и некоторые резолверы его вовсе не смотрят (nslookup не смотрит¹²). Переключайте назначения через файлы конфигурации.

Записывайте результат, время и причину сбоя разрешения имён

При запуске и подобных точках записывайте адреса IPv4 и IPv6 и затраченное время для основных назначений. Поскольку Dns.GetHostAddresses возвращает тот же результат, что getaddrinfo, можно проследить «на каком ПК, с какого момента, во что разрешилось».¹¹

// Записать результаты разрешения имён основных назначений при запуске (.NET 6 и новее)
static async Task LogNameResolutionAsync(ILogger logger, string host)
{
    var sw = System.Diagnostics.Stopwatch.StartNew();
    try
    {
        var addresses = await System.Net.Dns.GetHostAddressesAsync(host);
        logger.LogInformation("Разрешение имени {Host} -> {Addresses} ({Elapsed} ms)",
            host, string.Join(",", addresses.Select(a => a.ToString())), sw.ElapsedMilliseconds);
    }
    catch (System.Net.Sockets.SocketException ex)
    {
        logger.LogError(ex, "Сбой разрешения имени {Host} ошибка {Code} ({Elapsed} ms)",
            host, ex.SocketErrorCode, sw.ElapsedMilliseconds);
        throw;
    }
}

Журналируйте сбои и пробрасывайте дальше. Молчаливое переключение на другое имя или фиксированный IP делает фактический путь при расследовании непознаваемым. С кодом ошибки и затраченным временем ИТ-сотрудники могут решить, с какого из шагов 2–4 начинать.

Закладывайте тайм-ауты и ответы IPv6

DNS-клиент тратит до 10 секунд на кандидата, запрошенного против неотвечающих серверов.²¹ Если поиск суффиксов даёт несколько кандидатов, сумма может превысить 10 секунд.

Если тайм-аут соединения сжат до 2 или 3 секунд, разрешение имён не успевает до крайнего срока в конфигурациях вроде той, где отвечающий сервер четвёртый или позже. Второй сервер, однако, запрашивается через 1 секунду, а третий через 2 секунды, поэтому один сбойный сервер не обязательно значит сбой. Проектируйте с учётом времени повторной передачи из раздела 4.2.

Также, когда приходит ответ AAAA и есть исходный адрес IPv6 и маршрут, Windows по умолчанию предпочитает IPv6.³⁸ Код соединения, который предполагает только IPv4, может не подключиться, хотя разрешение имён удалось. Отделяйте успех разрешения имён от успеха соединения и обрабатывайте оба вида адресов.

10. Итог

Первое, что разделить в разрешении имён Windows, — форма имени, слой, который возвращает ответ, и путь, который берёт приложение.

Кэш и hosts отвечают первыми, а для однометок DNS и LLMNR/NetBT по умолчанию работают параллельно. Для .local присоединяется mDNS. Когда разрешение переходит к DNS, суффиксы, время повторной передачи, несколько NIC и NRPT меняют результат. DoH — функция, которая переключает этот транспорт, и её рассматривают отдельно от встроенного резолвера браузера.

Расследование ограничивает путь в порядке -CacheOnly, затем -NoHostsFile -DnsOnly, затем -Server, затем -LlmnrOnly и подтверждает сравнением настроек и захватом. Важно не упустить отрицательный кэш, разницу между отсутствием ответа и отрицательным ответом и политики на стороне клиента.

Когда «не подключается только этот ПК», сначала проверьте эти две вещи.

В какой форме передаётся имя? На этом ПК какой путь отвечает?

Когда эти два установлены, можно сузить, куда смотреть.

Похожие статьи

• Захват пакетов в Windows на практике — pktmon, netsh trace и Wireshark
• Корпоративный прокси и приложения Windows — как WinINET, WinHTTP и .NET выбирают прокси
• Не создавайте HttpClient в using на каждый запрос — создание, тайм-ауты и повторные попытки в C#
• Брандмауэр Windows и бизнес-приложения — входящие правила регистрирует установщик
• Сетевые диски и UNC-пути: типичные ловушки ── как бизнес-приложению работать с файловым сервером (общей папкой)
• NTLM и Kerberos с схемами — почему проверка подлинности откатывается на NTLM
• Практические команды PowerShell — мелкие приёмы для повседневной работы

Смежные области консультирования

KomuraSoft LLC занимается расследованием первопричин связанных с разрешением имён сбоев связи вроде «бизнес-приложение не достучится до внутреннего сервера только на части ПК» и «в браузере открывается, а приложение сбоит на разрешении имён», ревью проектирования того, выдержит ли бизнес-приложение смены среды вроде отключения LLMNR, DoH и VPN, и реализацией слоя связи, который записывает результаты разрешения имён и тайм-ауты. Если при обращении приложите дампы настроек рабочего и нерабочего ПК, отправная точка расследования устанавливается быстро.

• Расследование причин сбоев
• Техническая консультация и ревью проектирования
• Разработка приложений для Windows
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

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

Правил файл hosts, но изменение не вступает в силу. Почему?

В Windows содержимое файла hosts загружается в кэш при запуске службы DNS-клиент, и разрешение имён идёт в порядке кэш, hosts, DNS-сервер. Когда изменение не вступает в силу, сначала проверьте запись для этого имени через ipconfig /displaydns и, если старый ответ ещё там, сбросьте его через ipconfig /flushdns. Затем спросите, проходит ли инструмент, которым проверяете, через резолвер Windows вообще. nslookup не использует резолвер ОС; он обходит кэш, hosts и NRPT и запрашивает DNS-сервер напрямую, поэтому содержимое hosts в его выводе не отражается. Чтобы увидеть фактический результат разрешения, включая hosts, используйте Resolve-DnsName или ping. Если всё равно не вступает в силу, проверьте, нет ли у приложения, как у браузера, собственного резолвера или DoH.

Сайт открывается в браузере, а бизнес-приложение только на разрешении имён сбоит.

Скорее всего браузер и приложение разрешают имя разными путями. По умолчанию Microsoft Edge говорит с DNS-сервером встроенным DNS-клиентом, а не DNS-клиентом ОС, и если в Secure DNS (DoH) выбран другой провайдер, он запрашивает внешний резолвер. С другой стороны, Dns.GetHostAddresses в .NET и HttpClient, который подключается к назначению напрямую, идут через getaddrinfo ОС, поэтому на них действуют hosts, кэш DNS, NRPT и список поиска DNS-суффиксов (для запросов через HTTP-прокси имя назначения разрешается на стороне прокси). Когда они возвращают разные ответы, самый быстрый путь — сопоставить, какой путь спросил какой DNS-сервер о чём, через Resolve-DnsName и захват пакетов.

Настройки вроде одинаковые, а внутренний сервер недоступен только на части ПК. Что сравнивать?

Сравните форму имени и слой, на котором каждый ПК получает ответ. Однометка (имя без точки, например server01) дополняется списком поиска DNS-суффиксов ПК или суффиксом, специфичным для подключения, и отправляется в DNS, а по умолчанию параллельно также отправляется средствам только той же подсети, таким как LLMNR и широковещание NetBIOS (их пробуют последовательно после сбоя DNS, только если оптимизацию отключили; если настроен WINS, NetBIOS использует unicast и может пересекать подсети). ПК, присоединённый к домену, может разрешить имя, потому что суффикс дополняет его до FQDN, тогда как ПК на VPN или в другой подсети, или ПК с отключёнными LLMNR и NetBIOS, то же имя разрешить не может. Надёжный метод — собрать вывод Get-DnsClientServerAddress, Get-DnsClientGlobalSetting, Get-DnsClient и Get-DnsClientNrptPolicy -Effective на рабочем и нерабочем ПК и сравнить. Корневое исправление — сделать назначения в файлах конфигурации и ярлыках FQDN.

Разрешение имён не сбоит; просто несколько секунд ждёшь, пока соединение наконец проходит. Что вызывает это?

Это проявляется механизм тайм-аута и повторов DNS-клиента. Против DNS-сервера, который не отвечает, Windows повторяет запросы через 1, 2, 4 и 8 секунд от начала и сдаётся на 10-й секунде. Даже с несколькими настроенными DNS-серверами, если отвечающий стоит четвёртым или позже в списке, Windows ждёт минимум 4 секунды, прежде чем запросить этот сервер. Длинный список поиска DNS-суффиксов тоже накапливает задержку, потому что однометка пробуется с каждым суффиксом по очереди. Измерьте, сколько занимает Resolve-DnsName, через Measure-Command и примените фильтр dns.qry.name в Wireshark, чтобы увидеть, запросы к какому серверу остаются без ответа.

Отключили LLMNR и NetBIOS как меру безопасности, и теперь до части устройств нельзя достучаться по имени.

Это ожидаемый побочный эффект. LLMNR и NetBIOS over TCP/IP — вторичные средства разрешения однометок устройств, не зарегистрированных в DNS, в пределах той же подсети, и их отключение убирает этот путь. Сама Microsoft в 2022 году объявила курс на выравнивание по mDNS и постепенное сворачивание разрешения имён NetBIOS и LLMNR, поэтому само решение отключить — правильное. Средство — свести разрешение имён к DNS: зарегистрировать A-записи устройств во внутреннем DNS или включить динамическую регистрацию через DHCP и переписать назначения приложений и общих папок на FQDN. Устройства, которые поддерживают mDNS, можно разрешать по именам .local, но и этот путь ограничен диапазоном, куда доходит multicast.

Что происходит с внутренним разрешением имён, когда включаю DoH (DNS over HTTPS) в Windows 11?

DoH — функция, которая переключает транспорт на HTTPS, когда DNS-клиент запрашивает настроенные DNS-серверы; существующий порядок hosts, кэша и NRPT остаётся как есть. Если DDR (Discovery of Designated Resolvers) не включён, DoH можно использовать только когда сервер в списке известных DoH-серверов, поэтому чтобы использовать внутренний DNS-сервер, администратор должен зарегистрировать его через Add-DnsClientDohServerAddress. Если групповая политика «Настройка разрешения имён DNS over HTTPS (DoH)» задана в «Требовать DoH», само разрешение имён сбоит против серверов, которые не поддерживают DoH. Microsoft явно говорит не включать эту настройку на ПК, присоединённых к домену, потому что служба DNS-сервера, поставляемая с Windows Server, от которой зависит Active Directory, не поддерживает запросы DoH.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.