Resolve-DnsName в PowerShell: как выполнять DNS-запросы и читать ответ

Resolve-DnsName появился в Windows 8 и Windows Server 2012 и стал штатной заменой nslookup для PowerShell. Главное отличие в форме результата: nslookup выдаёт текст, а Resolve-DnsName возвращает объекты с полями Name, Type, TTL, Section и данными записи. Их легко фильтровать, сортировать и передавать по конвейеру.

Второе отличие — источник ответа. По умолчанию командлет использует механизм разрешения имён Windows и потому учитывает файл hosts, кэш DNS-клиента, а также такие механизмы, как LLMNR и NetBIOS для коротких имён. Чтобы получить чистый DNS-ответ без всего этого, добавьте параметр -DnsOnly. Для точной диагностики удобнее именно он.

Командлет доступен в Windows PowerShell 5.1 и в PowerShell 7 на Windows. В macOS и Linux его нет: там пользуются dig, host или nslookup. На системах с systemd-resolved диагностику дополняет resolvectl.

Базовый вызов: Resolve-DnsName example.com. Без указания типа запрашиваются адреса A и AAAA, а также цепочка CNAME, если она есть.

Типичные запросы: Resolve-DnsName example.com -Type MX покажет почтовые серверы с приоритетами, -Type NS — серверы имён домена, -Type TXT — текстовые записи, где размещают, например, политику отправки почты. Запрос -Type SOA выведет служебные сведения о зоне, включая серийный номер, что удобно при проверке распространения изменений.

Обратный запрос выполняется по адресу: Resolve-DnsName 203.0.113.10 вернёт PTR-запись, если она настроена. Тип PTR указывать не нужно, командлет определит его сам.

Если сайт открывается у одних пользователей и не у других, полезно сравнить ответы разных серверов. Параметр -Server позволяет опросить резолвер напрямую: Resolve-DnsName example.com -Server 203.0.113.53 -DnsOnly. Подставьте адрес нужного DNS-сервера, например резолвера вашего провайдера или домашнего роутера.

1. Выполните запрос с DNS-сервером по умолчанию и запишите адреса и TTL.
2. Повторите с адресом роутера, затем с публичным резолвером.
3. Сравните: одинаковые адреса — DNS в порядке, а причина в другом месте.
4. Различаются адреса — вы видите разницу кэшей или записей, например изменение записи ещё не дошло до всех серверов.
5. Один из серверов не отвечает — проблема в нём, и его стоит убрать из настроек адаптера.

Проверить авторитетный сервер можно, если узнать его имя запросом NS и затем выполнить запрос к нему напрямую. Ответ авторитетного сервера показывает «истину» о зоне, а остальные отдают то, что у них в кэше.

Пример вывода (пример) для запроса MX: строки с Name example.com, Type MX, TTL 3600, Section Answer, а также поля NameExchange и Preference. Число Preference задаёт порядок обращения: меньшее значение соответствует более высокому приоритету. Колонка TTL показывает, сколько секунд запись может храниться в кэше. Если запросить одно имя дважды, второй ответ придёт из кэша с уменьшившимся TTL.

Так как результат — объекты, работать с ним удобно: Resolve-DnsName example.com -Type A | Select-Object -ExpandProperty IPAddress выведет только адреса. Команда Resolve-DnsName example.com -Type TXT | Select-Object -ExpandProperty Strings покажет текст записей. Чтобы пройти по списку доменов, используйте цикл с Get-Content и сохраните результат в файл через Export-Csv.

Раздел Section различает Answer, Authority и Additional. В Answer лежит прямой ответ на вопрос, а в Authority — сведения об ответственных серверах, они появляются, когда прямого ответа нет.

Если Resolve-DnsName возвращает не то, что в интернете, проверьте три вещи. Первая — запись в файле hosts: командлет учитывает её без параметра -DnsOnly. Вторая — кэш DNS-клиента: посмотреть его можно командой Get-DnsClientCache, очистить — Clear-DnsClientCache. Третья — настройки адаптера: Get-DnsClientServerAddress покажет, какие DNS-серверы использует каждый интерфейс.

Ошибка DNS name does not exist означает, что имя не существует, то есть код NXDOMAIN. Сообщение об истекшем времени ожидания говорит о недоступности сервера или фильтрации порта 53. Пустой результат для типа записи без ошибки означает, что имя существует, но записей этого типа нет.

В смешанной среде помните о соответствии: Resolve-DnsName -Type MX это dig MX, Resolve-DnsName -Server это указание сервера через знак «@» в dig, -DnsOnly примерно соответствует прямому DNS-запросу без учёта системных механизмов. Запрашивайте сведения только о тех доменах и серверах, к которым имеете отношение и законный интерес: массовые запросы к чужим DNS-серверам могут восприниматься как злоупотребление.

Несколько готовых приёмов. Проверка почтовой инфраструктуры своего домена: запросите MX и убедитесь, что приоритеты и имена серверов совпадают с документацией почтового сервиса; затем TXT, чтобы увидеть политику отправки и записи подтверждения владения. Если вы только что изменили запись, а результат прежний, посмотрите TTL: пока не прошло это время, кэши могут отдавать старое значение. Перед плановым изменением адреса заранее уменьшите TTL, чтобы переключение прошло быстрее.

Проверка «сайт открывается не у всех»: сравните ответы двух резолверов, как описано выше, и посмотрите, одинаковые ли адреса. Проверка цепочки CNAME: запрос без типа покажет промежуточные имена, а итоговый адрес окажется в конце. Для отладки локальной сети выполните запрос по имени устройства и сравните с результатом при -DnsOnly: если различие есть, имя разрешается через hosts или локальные механизмы, а не через DNS.

Для отчёта в техподдержку сохраните результат: Resolve-DnsName example.com -Type A | Format-List | Out-File dns.txt. Приложите время проверки и адрес используемого DNS-сервера, полученный через Get-DnsClientServerAddress.