Команда nslookup: синтаксис, MX, TXT и обратный запрос

Коротко: nslookup NAME спрашивает у вашего DNS-сервера адреса указанного имени; nslookup -type=mx NAME запрашивает другой тип записи, а второй аргумент, как в nslookup NAME 1.1.1.1, отправляет вопрос указанному серверу. Команда встроена в Windows и macOS. В Linux она входит в пакет утилит BIND, который в минимальных образах не ставится. Выводы ниже получены в nslookup 9.18 на Debian 12 и там, где отмечено, сокращены; Windows печатает те же ответы в немного другом формате.

Ключи пишутся перед именем и начинаются с дефиса. Замените example.com на проверяемый домен, а 203.0.113.10 — на IP-адрес, для которого нужно имя.

Как читать вывод nslookup

nslookup example.com

Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   example.com
Address: 104.20.23.154
Name:   example.com
Address: 172.66.147.243
Name:   example.com
Address: 2606:4700:10::ac42:93f3
Name:   example.com
Address: 2606:4700:10::6814:179a

• Server / Address: DNS-сервер, который ответил, и его порт, #53. Без второго аргумента это первый сервер из /etc/resolv.conf в Linux и macOS или DNS-сервер сетевого адаптера в Windows. В Ubuntu здесь будет 127.0.0.53: это локальная заглушка systemd-resolved, которая пересылает запросы настоящим серверам из вывода resolvectl status.
• Non-authoritative answer: ответ пришёл от резолвера, который нашёл имя или взял его из кеша, а не от сервера, на котором лежит зона. Для повседневных запросов это норма, и сомневаться в ответе из-за этой строки не нужно.
• Пары Name / Address: по одной на запись. Без -type BIND 9.11 и новее (то есть любой современный Linux) запрашивает A, а затем AAAA, поэтому выводятся и IPv4, и IPv6. nslookup в macOS — это BIND 9.10, он спрашивает только A, так что там добавляйте -type=aaaa.

В Windows первые две строки показывают имя резолвера, найденное обратным запросом по его адресу. Server: UnKnown значит лишь, что у этого адреса нет записи PTR, на ответ это не влияет. В русской Windows часть строк переведена: Сервер:, Имя: и Не заслуживающий доверия ответ: — так звучит Non-authoritative answer. Несмотря на пугающий перевод, это не ошибка и чинить ничего не нужно. Строка Address: и названия ошибок остаются английскими.

Чтобы получить авторитетный ответ, спросите один из DNS-серверов самой зоны. Строка «Non-authoritative» тогда исчезает:

nslookup example.com elliott.ns.cloudflare.com

Server:         elliott.ns.cloudflare.com
Address:        108.162.195.228#53

Name:   example.com
Address: 172.66.147.243
Name:   example.com
Address: 104.20.23.154

Так проверяют изменение в DNS раньше, чем обновятся кеши: на сервере зоны новое значение появляется сразу, а резолвер может отдавать старое, пока не истечёт TTL.

Как посмотреть записи MX, TXT, NS и другие

Добавьте -type= (или синоним -query=) с типом записи. Регистр не важен.

MX: какие серверы принимают почту

nslookup -type=mx google.com

Non-authoritative answer:
google.com      mail exchanger = 10 smtp.google.com.

Число — это приоритет: отправители сначала пробуют наименьший. example.com отвечает mail exchanger = 0 ., это «null MX» (RFC 7505): домен вообще не принимает почту. Если записи MX нет совсем, отправители берут адресную запись домена. После таких ответов версия для Linux и macOS часто печатает пустой заголовок Authoritative answers can be found from:; перечислять ей нечего, его можно не замечать.

TXT: SPF, DMARC, DKIM и строки подтверждения

nslookup -type=txt example.com
nslookup -type=txt _dmarc.google.com

example.com     text = "v=spf1 -all"
example.com     text = "_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"

_dmarc.google.com       text = "v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

SPF лежит на самом домене, DMARC — под _dmarc., а ключ DKIM — под SELECTOR._domainkey., где SELECTOR — имя, которое выдал ваш почтовый провайдер. Длинная запись вроде ключа DKIM часто разбита на несколько строк в кавычках; получатели склеивают их без пробелов. Проверить, что записи ещё и корректно разбираются, помогут DMARC Checker (англ.) и его соседи для SPF и DKIM: они идут дальше простого запроса.

NS и SOA: кто обслуживает зону

nslookup -type=ns vmheaven.io
nslookup -type=soa vmheaven.io

vmheaven.io     nameserver = aisha.ns.cloudflare.com.
vmheaven.io     nameserver = dimitris.ns.cloudflare.com.

vmheaven.io
        origin = aisha.ns.cloudflare.com
        mail addr = dns.cloudflare.com
        serial = 2415933946
        refresh = 10000
        retry = 2400
        expire = 604800
        minimum = 1800

origin — первичный DNS-сервер, mail addr — контакт зоны, где первая точка означает @, а serial меняется при каждой правке. Последнее поле, minimum, вместе с TTL самой записи SOA ограничивает, сколько резолверы могут кешировать ответ «такого имени нет». Поэтому только что созданная запись какое-то время может оставаться невидимой; расчёт есть в статье DNS_PROBE_FINISHED_NXDOMAIN.

AAAA и CNAME

nslookup -type=aaaa one.one.one.one
nslookup www.github.com

Name:   one.one.one.one
Address: 2606:4700:4700::1111
Name:   one.one.one.one
Address: 2606:4700:4700::1001

www.github.com  canonical name = github.com.
Name:   github.com
Address: 140.82.121.4

Обычный запрос проходит по CNAME и печатает оба шага. -type=cname показывает только псевдоним. Остальные типы работают так же: -type=srv _service._tcp.example.com, -type=caa или -type=ptr.

Почему -type=any показывает не все записи

Во многих инструкциях написано, что -type=any выводит все записи имени. После RFC 8482 и резолверы, и собственные DNS-серверы домена могут отвечать на запрос ANY минимально, так что результат зависит от того, кого вы спрашиваете:

nslookup -type=any example.com 1.1.1.1
** server can't find example.com: NOTIMP

nslookup -type=any example.com 8.8.8.8
example.com     hinfo = "RFC8482" ""

nslookup -type=any google.com 8.8.8.8
(35 records: A, AAAA, MX, NS, SOA, TXT, CAA, HTTPS)

Резолвер Cloudflare отказывает в ANY сразу. example.com обслуживают DNS-серверы Cloudflare, которые на любой ANY отвечают такой записью-заглушкой HINFO, а резолвер Google просто передаёт её дальше. Собственные серверы google.com по-прежнему отдают полный набор. Другие резолверы могут отвечать тем, что у них есть в кеше: Quad9 вернул набор google.com без записи CAA. Запрашивайте каждый тип отдельно или воспользуйтесь DNS Lookup (англ.): его вариант «All» отправляет отдельные запросы A, AAAA, CNAME, MX, NS, TXT, SOA и CAA и показывает каждую запись с её TTL.

Как указать в nslookup конкретный DNS-сервер

Напишите сервер после имени, IP-адресом или именем хоста:

nslookup example.com 1.1.1.1
nslookup example.com 9.9.9.9
nslookup -port=5335 example.com 127.0.0.1
nslookup -vc example.com 1.1.1.1

Сравнение двух публичных резолверов показывает, дошло ли до них изменение. Если ваш резолвер не отвечает, а 1.1.1.1 отвечает, проблема в вашей настройке DNS, а не в домене; в Linux в такой ситуации вы увидите ошибку «Temporary failure in name resolution». -port= позволяет обратиться к резолверу на нестандартном порту, например к локальному unbound за Pi-hole (порт 5335 в руководстве самого Pi-hole), а -vc отправляет запрос по TCP вместо UDP. Это помогает в сетях, которые блокируют или подменяют UDP-порт 53. Чтобы увидеть все резолверы разом, а не по одному, DNS Propagation Checker (англ.) параллельно опрашивает двенадцать публичных резолверов и DNS-сервер самого домена.

Как сделать обратный DNS-запрос через nslookup

Укажите вместо имени IP-адрес. nslookup превратит его в запрос PTR в зоне in-addr.arpa (IPv4) или ip6.arpa (IPv6):

nslookup 1.1.1.1
nslookup 2606:4700:4700::1111
nslookup -type=ptr 1.1.1.1.in-addr.arpa

1.1.1.1.in-addr.arpa    name = one.one.one.one.

1.1.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.4.0.0.7.4.6.0.6.2.ip6.arpa        name = one.one.one.one.

Третья форма запрашивает PTR по полному имени и возвращает тот же ответ; её набирают, когда хотят сами проверить «перевёрнутую» запись адреса. PTR-запись задаёт тот, кому принадлежит блок адресов, а не владелец домена, поэтому отсутствующее или безликое имя ничего не говорит о домене. Для почтового сервера это важно: получатели проверяют, что PTR называет хост, чья запись A указывает обратно на тот же адрес. На VPS от VMHeaven PTR вы задаёте сами в личном кабинете, в разделе «Обратный DNS (rDNS)». Изменения вступают в силу примерно за 30 минут, и запись должна указывать на имя хоста, которое разрешается обратно в этот IP-адрес, иначе почтовые провайдеры её проигнорируют. Указывайте там полное доменное имя (FQDN) (англ.), а не короткое имя хоста. Полная настройка вместе с проверкой FCrDNS (прямая запись имени из PTR должна вести обратно на тот же IP) — в статье Reverse DNS and PTR records (англ.).

Как работает интерактивный режим

Запустите nslookup без аргументов или nslookup - 9.9.9.9, чтобы сразу выбрать сервер. Приглашение сменится на >, и каждая строка будет либо именем для запроса, либо настройкой:

> server 9.9.9.9
Default server: 9.9.9.9
Address: 9.9.9.9#53
> set type=mx
> vmheaven.io
Server:         9.9.9.9
Address:        9.9.9.9#53

Non-authoritative answer:
vmheaven.io     mail exchanger = 10 mail.vmheaven.io.

Authoritative answers can be found from:
> set type=a
> one.one.one.one
Server:         9.9.9.9
Address:        9.9.9.9#53

Non-authoritative answer:
Name:   one.one.one.one
Address: 1.1.1.1
Name:   one.one.one.one
Address: 1.0.0.1
> exit

set all показывает текущие настройки, set debug и set nodebug включают и выключают вывод пакетов, а exit завершает сеанс. В nslookup для Windows есть ещё команда ls, которая запрашивает полную передачу зоны. Почти все публичные серверы в этом отказывают; в nslookup из BIND команды ls нет вовсе, а для своих серверов есть dig axfr example.com @NAMESERVER.

Как увидеть TTL: ключ -debug

nslookup -debug -type=a example.com 1.1.1.1

------------
    QUESTIONS:
        example.com, type = A, class = IN
    ANSWERS:
    ->  example.com
        internet address = 172.66.147.243
        ttl = 126
    ->  example.com
        internet address = 104.20.23.154
        ttl = 126
    AUTHORITY RECORDS:
    ADDITIONAL RECORDS:
------------

ttl — сколько ещё секунд этот резолвер будет отдавать ответ из кеша. Спросите дважды, и число уменьшится; спросите авторитетный сервер, и увидите полное значение из зоны. В Windows ключ -d2 печатает все поля каждого пакета; версия из BIND вместо этого выводит собственную внутреннюю трассировку, от которой мало толку.

Что значат сообщения об ошибках nslookup

На «No answer» спотыкаются чаще всего: nslookup -type=aaaa github.com выводит его потому, что у GitHub нет записей IPv6, а не потому, что что-то сломано. Если в Windows строка DNS request timed out. (она и в русской Windows английская) стоит в самом начале, ещё до Server: (в русской Windows — Сервер:), значит, по таймауту не ответил обратный запрос, которым nslookup при запуске узнаёт имя самого DNS-сервера; тогда сервер в выводе называется UnKnown. Если ниже пришёл ответ на ваш запрос, ему можно верить. Для скриптов учтите, что nslookup из BIND завершается с кодом 1 при NXDOMAIN, SERVFAIL, REFUSED и таймаутах, но с кодом 0 при «No answer». Windows по умолчанию ждёт две секунды на попытку; с -timeout=2 -retry=1 версия для Linux сдаётся после одной двухсекундной попытки, а не примерно через пятнадцать секунд. Домен, который в браузере падает со страницей NXDOMAIN, разобран в статье DNS_PROBE_FINISHED_NXDOMAIN — с проверками и для посетителей, и для владельцев сайтов.

nslookup, dig, host и Resolve-DnsName: что выбрать

Переходите на dig, когда нужны флаги ответа (aa — авторитетный ответ, ad — проверен DNSSEC), коды Extended DNS Errors, которые присылают новые резолверы, +trace, чтобы увидеть, где рвётся делегирование, или +short для скриптов. nslookup, dig и host никогда не читают /etc/hosts: они спрашивают DNS-сервер напрямую. Чтобы увидеть, что на самом деле получают ваши программы, вместе с записями из hosts, используйте в Linux getent hosts example.com. Как устроены резолверы, кеши и авторитетные серверы, объясняет статья What is DNS (англ.).

Чем заменить nslookup в PowerShell

Resolve-DnsName входит в Windows и возвращает объекты, которые можно фильтровать. Без -Type он запрашивает A и AAAA вместе:

Resolve-DnsName example.com
Resolve-DnsName example.com -Type MX -Server 1.1.1.1
Resolve-DnsName _dmarc.google.com -Type TXT
Resolve-DnsName 1.1.1.1 -Type PTR
Resolve-DnsName example.com -DnsOnly -NoHostsFile -TcpOnly

-DnsOnly пропускает LLMNR и NetBIOS, -NoHostsFile игнорирует файл hosts, -TcpOnly работает по TCP, а -DnssecOk запрашивает записи DNSSEC. В отличие от nslookup, эта команда может ответить из файла hosts и из DNS-кеша Windows, то есть ближе к тому, что получают программы в Windows.

Как исправить nslookup: command not found

nslookup, dig и host поставляются вместе, в клиентских утилитах BIND, а минимальные образы серверов и контейнеров их не содержат. В Debian с русской локалью ошибка выглядит как bash: nslookup: команда не найдена. Лечится установкой пакета:

sudo apt update && sudo apt install -y bind9-dnsutils

sudo dnf install -y bind-utils

apk add --no-cache bind-tools

Старое имя пакета dnsutils по-прежнему работает: в Debian 12 и Ubuntu это переходный пакет, который подтягивает bind9-dnsutils, а в Debian 13 — виртуальное имя, которое предоставляет bind9-dnsutils. В Alpine уже есть небольшой nslookup из BusyBox, без дополнительного пакета. В Arch Linux утилиты входят в пакет bind. То же исправление для dig, со случаями Docker и WSL, — в статье dig: command not found (англ.).

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