По IP соединение есть, по имени нет: как разбирать DNS в Windows

Доступ по IP ещё не доказывает неисправность DNS

Общая папка открывается по адресу, но не по имени; сайт по имени зависает, а IP отвечает на ping. Эти ситуации требуют разных проверок. Ping проверяет ICMP, общая папка — SMB, сайт — HTTP поверх TLS. Успех одного протокола не гарантирует успех другого.

Открывать HTTPS-сайт как https://IP-адрес для сравнения некорректно: меняются имя в запросе, выбор виртуального сайта и проверка сертификата. Сначала нужно узнать, во что Windows разрешает имя, затем проверить тот же сервис. При работе через прокси конечное имя может разрешать сам посредник.

Ниже — диагностика клиента Windows 11. Имена server.example и files.corp.example учебные: заменяйте их реальными именами из своей сети.

Посмотрите ответ системы для A и AAAA

Откройте PowerShell:

Resolve-DnsName -Name server.example -Type A
Resolve-DnsName -Name server.example -Type AAAA

A — IPv4, AAAA — IPv6. Ответ может содержать CNAME и несколько адресов; не выбирайте автоматически первую строку как единственный сервер. Сохраните типы записей и ошибку целиком. Команда умеет отдельно ограничивать запрос DNS, исключать Hosts и обращаться к заданному серверу. ^[1]

Установите, какие серверы и суффиксы настроены

Снимите конфигурацию:

Get-DnsClientServerAddress |
  Format-Table InterfaceAlias, AddressFamily, ServerAddresses -Auto
Get-DnsClient |
  Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientGlobalSetting |
  Format-List SuffixSearchList, UseDevolution
Get-DnsClientNrptPolicy -Effective

Последняя команда показывает действующие правила NRPT, если они есть. VPN может отправлять запросы корпоративной зоны особым DNS-серверам. Общий список адаптеров и одно значение «предпочитаемый DNS» не всегда описывают фактическую обработку каждого имени. ^{[2], [3], [4], [5]}

Для краткого имени files Windows может пробовать суффиксы сети. Сравните его с полным files.corp.example.: завершающая точка явно обозначает полное DNS-имя. Если полное имя работает, а краткое нет, исправление находится в суффиксах или правилах поиска, а не в сбросе всех сетевых настроек. ^[6]

Спросите конкретный DNS-сервер

Чтобы сравнить ответ с настройкой адаптера, укажите фактический сервер вашей сети:

Resolve-DnsName -Name files.corp.example. -Type A -Server 192.0.2.53 -DnsOnly -NoHostsFile

192.0.2.53 — учебный адрес. Подставьте разрешённый DNS-сервер организации или домашнего маршрутизатора. Этот тест проверяет ответ указанного резолвера с заданными опциями; он не воспроизводит весь путь браузера. ^[1]

Если два сервера дают разные ответы, сначала уточните назначение зоны. Внутреннее имя может намеренно существовать только внутри сети. Запрос такого имени публичному серверу не обязан работать. Для общедоступного имени разница также бывает связана с TTL и распределённой инфраструктурой; нужны повторение и сравнение времени.

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

Отделите Hosts и кэш от удалённого ответа

Сначала прочитайте текущее состояние:

Get-Content "$env:windir\System32\drivers\etc\hosts"
Get-DnsClientCache |
  Where-Object Entry -Like '*server.example*' |
  Format-List *

Сравните обычный Resolve-DnsName с запросом к нужному серверу через -DnsOnly -NoHostsFile. Статическая строка в Hosts может направлять на старый адрес без обращения к DNS. Кэш хранит и отрицательные результаты, поэтому недавнее исправление записи не всегда сразу видно приложению. ^{[1], [6], [7]}

После сохранения наблюдений кэш системного DNS можно очистить в повышенной командной строке:

ipconfig /flushdns

Команда не переписывает Hosts, записи на DNS-сервере и настройки браузерного защищённого DNS. Если проблема повторилась после первого запроса, нужно искать источник неправильного ответа. Вручную стирать весь Hosts ради проверки не требуется. ^[8]

Проверьте транспорт DNS и транспорт приложения

Обычные DNS-запросы могут идти по UDP и TCP 53. Успешный TCP-тест порта 53 не доказывает, что UDP-запросы проходят. При подозрении на разницу повторите тот же запрос с -TcpOnly:

Resolve-DnsName -Name server.example -Type A -Server 192.0.2.53 -DnsOnly -NoHostsFile -TcpOnly
Test-NetConnection -ComputerName server.example -Port 443 -InformationLevel Detailed

Первый результат сравнивают с запросом без TcpOnly. Второй относится уже к TCP-порту приложения. Точные адрес и порт из вывода важнее общего сообщения «сеть работает». При управляемом DNS over HTTPS транспорт и политика другие; ориентируйтесь на применённую конфигурацию. ^{[1], [9]}

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

Для проверки того же HTTPS-имени с конкретным подтверждённым адресом curl умеет сохранять имя в URL и подставлять только адрес соединения:

curl.exe --resolve "site.example:443:192.0.2.10" --connect-timeout 10 --max-time 30 --output NUL "https://site.example/"

Здесь имя и IP учебные; используйте только адрес, который действительно принадлежит нужному сервису. В отличие от URL с голым IP, сохраняется имя сайта для HTTPS. Тест относится к curl, а при прокси может не подменять DNS так, как при прямом соединении. Он помогает отделить разрешение имени, но не заменяет настройку DNS всей Windows. ^[10]

Исправьте найденную причину и подтвердите результат

Опечатку исправляют в адресе приложения; неправильный суффикс — в настройке нужного соединения; ошибочную Hosts-строку — точечно после сохранения копии; отсутствующую запись внутреннего ресурса — у владельца DNS-зоны. Недоступный сервер организации нельзя автоматически заменять публичным: внутренние службы могут зависеть от него.

В отчёт об ошибке включите точное имя с точкой или без неё, A/AAAA, время, используемый интерфейс, ответы штатного и явно заданного резолвера, наличие VPN и результат соединения с нужным портом. Это позволяет разделить клиентскую настройку и проблему за пределами компьютера.

Повторная проверка состоит из двух действий: Windows получает ожидаемый ответ, а исходная программа открывает нужный ресурс. Один удачный nslookup или очищенный кэш ещё не завершают диагностику.