Проверка DNS-записей домена: как убедиться, что всё настроено правильно

DNS — та часть сайта, которую настраивают один раз и забывают. Ровно до момента, когда «сайт не открывается», «почта не доходит» или «после переезда всё сломалось». Практический разбор: как проверить каждую DNS-запись домена своими руками, какие ошибки встречаются чаще всего и как поймать изменение записей раньше, чем его заметят посетители.

Инструмент один — dig (и nslookup для Windows)

Теорию — какие бывают записи и за что отвечают — мы разбирали в статье про DNS-записи. Здесь — практика. Всё проверяется двумя командами: dig (macOS/Linux, самый удобный) или nslookup (есть и в Windows). Полный аудит домена руками занимает три минуты:

# Куда указывает сайт
dig example.ru +short              # A-запись (IPv4)
dig AAAA example.ru +short         # IPv6, если есть
dig www.example.ru +short          # не забыть www!

# Кто принимает почту
dig MX example.ru +short

# Служебные записи
dig TXT example.ru +short          # SPF и подтверждения сервисов
dig TXT _dmarc.example.ru +short   # DMARC
dig NS example.ru +short           # NS-серверы домена

# Спросить конкретный DNS-сервер (минуя кэш провайдера)
dig example.ru @77.88.8.8 +short

Последний приём — самый недооценённый: один и тот же вопрос, заданный разным DNS-серверам, показывает, разошлись ли ответы. Это главный инструмент диагностики «у меня работает, у клиента нет» после любых изменений в зоне.

Чек-лист: что проверять и какие ошибки искать

Аудит зоны за десять минут: готовый сценарий

Если проверять домен приходится регулярно (после работ подрядчика, перед переездом, при приёмке нового проекта), удобно прогонять весь список одной командой. Скрипт для macOS/Linux, который выводит все ключевые записи разом:

D=example.ru
for T in A AAAA MX NS TXT SOA; do
  echo "== $T =="; dig $T $D +short
done
echo "== www =="; dig www.$D +short
echo "== DMARC =="; dig TXT _dmarc.$D +short

Сохраните вывод в файл — это и есть эталонный снимок зоны. После любых работ прогоните скрипт снова и сравните два файла: любое расхождение, которое вы не планировали, — предмет для разбирательства. По сути это ручная версия того, что мониторинг DNS делает автоматически каждый день.

Отдельного взгляда заслуживает запись SOA (её выводит скрипт): в ней зашит серийный номер зоны, который должен увеличиваться при каждом изменении. Если вы что-то поменяли, а серийник на авторитетных серверах не вырос, — изменение не применилось. И проверьте, что NS-серверов у домена минимум два и они в разных сетях: единственный NS — единая точка отказа для всего домена сразу, включая почту.

«Я поменял запись, но ничего не изменилось»

Самый частый вопрос про DNS. Ответ почти всегда один: кэш. Изменение записи не рассылается миру мгновенно — мир сам приходит за ней, когда истечёт TTL предыдущего ответа. Если TTL был сутки, то в течение суток разные провайдеры будут отдавать разные ответы, и это не поломка, а штатная работа системы. Проверить фактическое состояние можно, спросив напрямую авторитетный сервер зоны (dig example.ru @ns1.вашdns.ru) — он отдаёт свежее значение без кэша. Если там запись новая, остаётся ждать истечения TTL; если старая — изменение вообще не применилось, и вопрос уже к панели DNS-хостинга. Подробно про эту механику — в статье про TTL.

Приёмка проекта: DNS-вопросы подрядчику

Отдельный сценарий, где проверка DNS обязательна, — приём сайта у студии или уходящего администратора. Три вопроса, которые сэкономят месяцы разбирательств. Первый: у кого доступ к панели DNS и к аккаунту регистратора — это два разных доступа, и оба должны быть у вас, а не «у Миши, который уволился». Второй: почему записи такие — по каждой непонятной строке зоны должен быть ответ; забытые записи старых сервисов удаляются сразу (это готовые лазейки для перехвата поддоменов). Третий: где почта — MX и SPF должны указывать на сервис, которым вы реально пользуетесь, а не на хостинг студии, с которого вы съезжаете. Снимите эталонный снимок зоны скриптом выше до расставания с подрядчиком: потом сравнивать будет не с чем.

Почему разовая проверка не решает проблему

Проверить зону один раз — полезно, но DNS ломается не в день аудита. Записи меняются при переездах, смене почтового сервиса, подключении CDN, работе подрядчиков с доступом к панели — и каждая такая операция может незаметно снести или переписать что-то соседнее. А ещё DNS — первая цель при угоне домена: злоумышленнику не нужен ваш сервер, достаточно переписать A-запись, и трафик уходит на подставную площадку.

Общая черта всех этих сценариев: сломанную DNS-запись не видно снаружи, пока не начнут жаловаться люди. Сайт у вас открывается (кэш!), письма вроде уходят — а часть мира уже живёт с другой версией вашей зоны. Поэтому зрелый подход — сравнение: зафиксировать эталонное состояние записей и автоматически сверять с ним текущее, поднимая тревогу при любом расхождении.

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

Как проверить DNS-записи без терминала? Любым онлайн-DNS-чекером: вводите домен и тип записи, получаете ответ, часто сразу с нескольких серверов мира. Для разовой проверки этого достаточно; терминал выигрывает, когда нужно спросить конкретный сервер или сравнить ответы.

Сколько ждать обновления DNS «по всему миру»? Ровно столько, каким был TTL старой записи, плюс небольшой хвост: провайдерские кэши в основном уважают TTL. Мифические «72 часа» из старых инструкций — перестраховка; при TTL 300 обновление расходится за минуты.

Что проверить первым, если перестала ходить почта? MX-записи (не пропали ли), затем SPF (одна ли запись, все ли отправители в ней) и не попал ли IP почтового сервера в чёрные списки. Полный разбор почтовых записей — в статье про SPF, DKIM и DMARC.

Опасно ли, что кто-то может посмотреть все мои DNS-записи? Записи, нужные для работы, публичны по определению — это нормально. Опасны не любопытные глаза, а забытые записи (лазейка для перехвата поддомена) и отсутствие контроля изменений: смотреть на вашу зону должны не только чужие, но и ваш собственный робот.