Когда вы вводите \\fileserver или ping srv01, Windows должна превратить имя в IP-адрес. Основной механизм - DNS, но рядом с ним до сих пор живут старые и вспомогательные способы: LLMNR, NetBIOS и служба WINS. Именно они объясняют многие странности: имя, которого нет в DNS, иногда всё равно находится, а иногда находится «не тот» компьютер.

Инструкция подходит для Windows Server 2016, 2019, 2022 и 2025 и клиентов Windows 10 и 11.

Порядок разрешения имени

Вертикальная цепочка блоков: кэш, файл hosts, DNS, широковещательные запросы

Упрощённо клиент Windows действует так:

  1. Проверяет, не своё ли это имя.
  2. Ищет в кэше DNS-клиента. Записи из файла hosts тоже попадают в этот кэш.
  3. Спрашивает DNS-серверы, указанные в настройках сетевого адаптера. Если имя короткое, без точки, к нему по очереди добавляются DNS-суффиксы (подробнее ниже).
  4. Если DNS не ответил, отправляет в локальную сеть многоадресный запрос LLMNR, а в современных версиях Windows ещё и mDNS.
  5. Если имя подходит под формат NetBIOS (до 15 символов), проверяет кэш NetBIOS, спрашивает сервер WINS, если он настроен, отправляет широковещательный запрос и читает файл LMHOSTS.

Шаги 4 и 5 - запасные. В хорошо настроенной сети имя должно находиться на шаге 3, а всё остальное лучше отключить. Почему - в разделе про безопасность.

Посмотреть, через что нашлось имя, помогают команды:

powershell
rem кэш DNS-клиента
ipconfig /displaydns
# запрос с подробностями (PowerShell)
Resolve-DnsName srv01
rem кэш имён NetBIOS
nbtstat -c
rem NetBIOS-имена этого компьютера
nbtstat -n
rem запросить NetBIOS-таблицу удалённого компьютера
nbtstat -a srv01
rem очистить кэш NetBIOS и перечитать LMHOSTS
nbtstat -R

DNS-суффиксы на клиенте

Короткое имя srv01 DNS-сервер не знает: ему нужен полный вариант вроде srv01.corp.example. Достраивает его клиент, перебирая суффиксы:

  • основной DNS-суффикс компьютера - для членов домена это имя домена;
  • DNS-суффикс подключения - задаётся в свойствах адаптера или приходит по DHCP;
  • список суффиксов поиска - если он задан, используется вместо двух предыдущих.

Список задают вручную в свойствах протокола IPv4: «Дополнительно» → вкладка «DNS» → «Добавлять следующие DNS-суффиксы (по порядку)». Для многих компьютеров удобнее групповая политика: «Конфигурация компьютера» → «Административные шаблоны» → «Сеть» → «DNS-клиент» → «Список DNS-суффиксов поиска». В PowerShell:

powershell
Set-DnsClientGlobalSetting -SuffixSearchList @("corp.example", "branch.corp.example")

На той же вкладке «DNS» настраивается, регистрирует ли компьютер свой адрес в DNS. Для членов домена флажок «Зарегистрировать адреса этого подключения в DNS» должен быть включён, иначе другие компьютеры не найдут его по имени.

Если имя не находится, первым делом проверьте ipconfig /all: правильные ли DNS-серверы (для членов домена - контроллеры домена или DNS-серверы, которые знают зону домена, а не публичные серверы провайдера) и какие суффиксы в списке поиска.

NetBIOS и WINS

NetBIOS - механизм имён из эпохи, когда сети Windows работали без DNS. Имя NetBIOS плоское, до 15 символов, без доменной иерархии. В маленькой сети компьютеры находят друг друга широковещательными запросами, но широковещание не проходит через маршрутизаторы. Чтобы разрешать NetBIOS-имена между подсетями, придумали WINS - сервер, где компьютеры регистрируют свои имена и куда отправляют запросы.

Режим работы клиента определяет тип узла (node type): B - только широковещание, P - только WINS, M - сначала широковещание, потом WINS, H - сначала WINS, потом широковещание. Текущий тип показывает ipconfig /all в строке «Тип узла». Если WINS-сервер задан, клиент работает в режиме H.

Нужен ли WINS сегодня

В большинстве сетей - нет. Active Directory, общие папки, принтеры и удалённый рабочий стол работают через DNS. WINS остаётся оправданным, только если в сети есть старые приложения или устройства, которые умеют искать ресурсы исключительно по NetBIOS-именам между подсетями. Microsoft официально объявила WINS устаревшим: в Windows Server 2025 компонент ещё есть и поддерживается до конца её жизненного цикла (ноябрь 2034 года), но в следующих версиях Windows Server его не будет. Если WINS у вас ещё работает, планируйте переход на DNS.

Если всё же нужно, WINS ставится как компонент Windows Server:

powershell
Install-WindowsFeature WINS -IncludeManagementTools

Управление - в оснастке winsmgmt.msc. Если серверов несколько, между ними настраивают репликацию: на каждом сервере добавляют другой как партнёра по репликации (push, pull или оба направления), иначе каждый будет знать только свои записи.

Клиентам адрес WINS-сервера проще всего раздать по DHCP: параметр 044 «Серверы WINS/NBNS» и параметр 046 «Тип узла WINS/NBT» со значением 0x8 (режим H). Вручную это делается в свойствах IPv4: «Дополнительно» → вкладка «WINS».

Зона GlobalNames вместо WINS

Самая частая причина держать WINS - привычка пользователей к коротким именам вроде \\files или http://portal, причём из разных доменов и филиалов, где суффиксы поиска не помогают. Для этого в DNS-сервере Windows есть зона GlobalNames: в ней хранятся короткие имена, которые разрешаются во всём лесу Active Directory.

Настройка:

  1. Включите поддержку на DNS-серверах. Команда применяется к одному серверу, поэтому её нужно выполнить на каждом:

    powershell
    Set-DnsServerGlobalNameZone -Enable $true

    Старый вариант той же настройки: dnscmd /config /enableglobalnamessupport 1.

  2. Создайте интегрированную в Active Directory основную зону с именем GlobalNames и репликацией на все DNS-серверы леса:

    powershell
    Add-DnsServerPrimaryZone -Name "GlobalNames" -ReplicationScope "Forest"

  3. Добавьте в неё записи CNAME, указывающие на полные имена:

    powershell
    Add-DnsServerResourceRecordCName -ZoneName "GlobalNames" -Name "files" -HostNameAlias "fs01.corp.example"

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

LLMNR

LLMNR (Link-Local Multicast Name Resolution) позволяет компьютерам в одном сегменте сети находить друг друга без DNS-сервера. Запрос уходит на многоадресный адрес 224.0.0.252 (для IPv6 - FF02::1:3), UDP-порт 5355, и отвечает тот, кто узнал своё имя. Это удобно в домашней сети или на изолированном стенде, но в корпоративной сети LLMNR скорее вредит.

Почему LLMNR и NetBIOS лучше отключить

Круги широковещательного запроса, щит и предупреждение у подозрительного узла

У широковещательных и многоадресных запросов нет проверки подлинности: ответить на них может любой компьютер в сегменте. Злоумышленник в локальной сети может отвечать на все запросы, которые не разрешил DNS (а это опечатки в именах, старые ярлыки, исчезнувшие серверы), и выдавать себя за нужный сервер. Клиент после этого пытается к нему подключиться и часто отправляет хеш пароля пользователя. Атака известна давно и широко автоматизирована, поэтому отключение LLMNR и NetBIOS входит практически во все рекомендации по защите сетей Windows.

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

Отключение LLMNR

Групповой политикой: «Конфигурация компьютера» → «Административные шаблоны» → «Сеть» → «DNS-клиент» → «Отключить многоадресное разрешение имён» (Turn off multicast name resolution) → «Включено».

На отдельном компьютере то же самое делает параметр реестра:

batch
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast /t REG_DWORD /d 0 /f

Отключение NetBIOS через TCP/IP

Вручную: свойства IPv4 → «Дополнительно» → вкладка «WINS» → «Отключить NetBIOS через TCP/IP». Настройка задаётся для каждого адаптера отдельно.

Для компьютеров, получающих адрес по DHCP, удобнее параметр DHCP-сервера. В DHCP Windows Server это параметр 001 «Microsoft Disable Netbios Option» из класса поставщика «Параметры Microsoft Windows 2000» со значением 0x2. На клиенте при этом остаётся значение по умолчанию «Использовать параметр NetBIOS, предоставляемый DHCP-сервером».

На всех адаптерах сразу через PowerShell:

powershell
Get-CimInstance Win32_NetworkAdapterConfiguration -Filter "IPEnabled = True" |
    Invoke-CimMethod -MethodName SetTcpipNetbios -Arguments @{TcpipNetbiosOptions = 2}

Значение 2 - отключить, 1 - включить, 0 - брать настройку от DHCP.

После этого nbtstat -n должен показывать, что для адаптеров нет зарегистрированных имён, а короткие имена в сети продолжат работать через DNS-суффиксы и зону GlobalNames.