tanaka.host dig и nslookup: проверка DNS-записей домена
Как узнать A, AAAA, MX, TXT, NS и PTR-записи, спросить конкретный резолвер или NS-сервер напрямую и пройти цепочку dig +trace. Linux, macOS, Windows.
Поменяли запись у регистратора, а сайт открывается со старого сервера. Почта на домен не приходит. Сервис просит подтвердить домен TXT-записью и уверяет, что не видит её. Во всех случаях нужно спросить у DNS напрямую, что он отвечает прямо сейчас — для этого есть dig и nslookup.
Если нужен сервер, с которого удобно смотреть сеть «со стороны», подойдёт любой VPS на tanaka.host: Ubuntu или Debian ставятся при заказе, оплата по дням.
Почему DNS отвечает по-разному
Ответ на вопрос «какой IP у домена» почти никогда не приходит от сервера, который за домен отвечает. Компьютер спрашивает свой резолвер (провайдера, 1.1.1.1, 8.8.8.8), а тот либо отдаёт ответ из кэша, либо идёт по цепочке: корневой сервер → серверы зоны .com → NS-серверы домена, где и лежат записи. Подробнее цепочка разобрана в статье про привязку домена к VPS.
Поэтому в один момент разные резолверы могут отвечать по-разному: один уже получил новую запись, другой держит старую, пока не истечёт её TTL. При проверке полезно сравнить несколько резолверов, а для полной уверенности спросить NS-сервер домена напрямую.
Разница между командами — в удобстве. nslookup есть почти везде, включая Windows, и выводит ответ просто. dig показывает подробнее (TTL, служебные секции), умеет +trace и удобнее в скриптах. На Ubuntu и Debian обе ставятся одним пакетом:
sudo apt install -y dnsutils
# RHEL: sudo dnf install -y bind-utilsНа macOS обе команды уже есть.
1. IP-адрес домена
# Только секция ответа
dig example.com +noall +answer
# Только адреса
dig example.com +short
# То же через nslookup, работает и в Windows
nslookup example.comЧисло во второй колонке ответа dig — оставшийся TTL в секундах: столько резолвер ещё будет помнить этот ответ. IPv6 — тип AAAA: dig example.com AAAA +short.
2. Записи других типов
Тип указывается после имени в dig или через -type= в nslookup.
# Почтовые серверы, число перед именем — приоритет
dig gmail.com MX +short
# TXT: SPF, DKIM, коды подтверждения сервисов
dig example.com TXT +short
# NS-серверы, обслуживающие домен
dig example.com NS +short
# Обратная запись PTR: какое имя у IP
dig -x 1.1.1.1 +shortВ nslookup:
nslookup -type=mx gmail.com
nslookup -type=txt example.com
nslookup -type=ns example.com
nslookup 1.1.1.1| Тип | Что хранит | Когда проверять |
|---|---|---|
| A / AAAA | IPv4 / IPv6 адрес | Сайт открывается не с того сервера |
| MX | Почтовые серверы | Не приходит почта |
| TXT | SPF, DKIM, DMARC, подтверждения | Сервис «не видит» запись, письма в спаме |
| NS | Кто обслуживает домен | Записи «не применяются» |
| PTR | Имя по IP | Исходящая почта с сервера |
3. Спросить конкретный сервер
Адрес сервера указывается после @ в dig или последним параметром в nslookup:
# Публичные резолверы Google и Cloudflare
dig @8.8.8.8 example.com +short
dig @1.1.1.1 example.com +short
# NS-сервер самого домена — ответ без кэша
dig @elliott.ns.cloudflare.com example.com +short
# То же через nslookup
nslookup example.com 8.8.8.8Если NS-сервер домена уже отдаёт новую запись, а публичные резолверы ещё нет — вы всё сделали правильно, осталось дождаться истечения TTL.
4. Вся цепочка: dig +trace
+trace заставляет dig не обращаться к резолверу, а пройти путь самостоятельно от корневых серверов:
dig +trace example.comВывод длинный. Смотрите строки Received … from — какой сервер ответил на каждом шаге: корневой направил к серверам .com, те сообщили NS-серверы домена, NS-сервер выдал адрес. Если цепочка обрывается — видно, где именно. Типичный случай: у регистратора указаны NS-серверы, которые ничего не знают о домене.
Полезные команды
| Команда | Что делает |
|---|---|
dig example.com +short |
Только значения |
dig example.com +noall +answer |
Ответ с TTL, без шапки |
dig example.com ANY |
Все типы (многие серверы больше не отвечают на ANY) |
dig @ns1.example.net example.com SOA |
Серийник зоны — обновилась ли она на этом NS |
dig example.com +trace |
Путь от корня |
dig -x IP +short |
PTR |
dig example.com +tcp |
Запрос по TCP, если UDP режется |
Частые ошибки
dig: command not found — поставьте dnsutils (Debian/Ubuntu) или bind-utils (RHEL).
status: NXDOMAIN — такого имени нет. Проверьте написание и что запись создана для нужного имени: для www нужна отдельная. Если домен только что зарегистрирован — проверьте dig example.com NS +short: есть ли вообще делегирование.
Ответ пустой, ошибки нет — домен существует, но записи этого типа нет. Например, есть A, нет MX.
Запись видна на одном резолвере и не видна на другом — второй ещё держит старый ответ. TTL в dig +noall +answer покажет, сколько ждать. Кэш на своём компьютере: Windows — ipconfig /flushdns, macOS — sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder, Linux с systemd-resolved — sudo resolvectl flush-caches.
Если DNS отвечает правильно, а подключения всё равно нет — проверьте порт через netcat и путь через mtr.