Вы поменяли запись у регистратора, а сайт по-прежнему открывается со старого сервера. Почта на домен не приходит, или сервис просит подтвердить домен TXT-записью и уверяет, что не видит её. Во всех этих случаях нужно спросить у DNS напрямую, что он отвечает прямо сейчас. Для этого есть две команды, nslookup и dig. В этой статье разберём, чем они отличаются, научимся смотреть записи разных типов, спрашивать конкретный DNS-сервер и проходить всю цепочку от корневых серверов до ответа. Все примеры выполнены на тестовом сервере с Debian 12.
Почему ответы DNS бывают разными
Когда вы спрашиваете у DNS адрес домена, ответ почти никогда не приходит напрямую от сервера, который за этот домен отвечает. Компьютер обращается к своему резолверу, например к серверу провайдера или к публичному 1.1.1.1, а резолвер либо отдаёт ответ из своей памяти, либо проходит по цепочке. Сначала он спрашивает корневой сервер, тот направляет его к серверам зоны, например .com, а они к NS-серверам самого домена, у которых и хранятся записи. Подробно эта цепочка разобрана в статье про привязку домена к VPS.
Из такого устройства следует, что разные резолверы в один и тот же момент могут отвечать по-разному. Один уже получил новую запись, а другой ещё отдаёт старую из памяти, пока у неё не истечёт срок хранения TTL. Поэтому при проверке полезно сравнивать ответы нескольких резолверов и, если нужна полная уверенность, спрашивать NS-сервер домена напрямую. Обе команды это умеют, а dig вдобавок может пройти всю цепочку сам и показать, какой сервер что ответил.
Разница между командами в основном в удобстве. nslookup есть почти везде, включая Windows, и выводит ответ в простом виде. dig входит в Linux и macOS, показывает ответ подробнее, с TTL и служебными полями, и удобнее для скриптов. На Debian и Ubuntu обе команды ставятся одним пакетом.
apt install -y dnsutils1. Узнайте IP-адрес домена
# Подробный ответ dig, только раздел с ответом
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 и коды подтверждения сервисов
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 показывает те же MX-записи в другом виде
3. Спросите конкретный DNS-сервер
Чтобы узнать, что отвечает определённый резолвер или сам NS-сервер домена, укажите его после @ в 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Полный вывод длинный, поэтому для скриншота мы оставили только строки со шагами и найденными записями.
Корневой сервер, сервер зоны .com и NS-сервер домена по очереди
Строки Received … from показывают, какой сервер ответил на каждом шаге. Здесь корневой сервер e.root-servers.net направил запрос к серверам зоны .com, сервер c.gtld-servers.net сообщил, что домен обслуживает Cloudflare, а NS-сервер elliott.ns.cloudflare.com выдал адреса. Если цепочка обрывается, видно, на каком шаге. Например, если у регистратора указаны NS-серверы, которые ничего не знают о домене.
Частые вопросы
dig: command not found
Команда входит в пакет dnsutils. Установите его командой apt install -y dnsutils. В нашем образе Debian 12 этот пакет уже установлен.
Ответ status: NXDOMAIN
Такого имени в DNS нет. Проверьте написание домена и что запись создана для нужного имени, например для www отдельно. Если домен только что зарегистрирован, проверьте NS-серверы командой dig example.com NS +short.
Ответ пустой, но ошибки нет
Домен существует, но записи нужного типа у него нет. Например, у домена есть запись A, но нет записи MX. Проверьте, что запись создана с нужным типом.
Свежая запись видна на одном резолвере и не видна на другом
Второй резолвер ещё хранит старый ответ. Посмотрите на TTL в выводе dig +noall +answer, это время в секундах до обновления. На своём компьютере кэш DNS можно очистить. В Windows это команда ipconfig /flushdns.
Наши ресурсы
Telegram-канал: https://t.me/f3cloud_news
Официальный сайт: https://f3cloud.com