Мониторинг сайта

Как проверить DNS сайта после изменений

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

Александр Шестопалов··10 мин

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

Ниже — проверяемый маршрут для владельца сайта и маркетолога. Он дополняет общую систему мониторинга сайта и не повторяет отдельную инструкцию про срок домена и SSL-сертификата.

Короткий ответ. Зафиксируйте ожидаемые серверы имён и записи. Сначала запросите их у авторитетного сервера, затем у двух публичных преобразователей имён. Сравните адреса и оставшееся время кэширования. После этого откройте критические страницы и проверьте ответ в Яндекс Вебмастере.

Что именно проверять в DNS

Доменное имя проходит несколько независимых точек. Регистратор хранит делегирование на серверы имён. Авторитетный сервер отвечает за записи зоны. Рекурсивный преобразователь получает эти ответы и временно хранит их. Только затем браузер обращается к найденному адресу и получает ответ сайта.

Четыре слоя проверки DNS: делегирование, авторитетные записи, кэш преобразователя и ответ сайта
Зелёный ответ на одном слое не подтверждает следующий. Проверка идёт от источника DNS к фактической странице.
СлойЧто сверитьПризнак проблемы
ДелегированиеСписок записей NS у родительской зоныУказаны старые или недоступные серверы имён
Авторитетная зонаЗаписи A, AAAA, CNAME и их время кэшированияОтвет отсутствует, ведёт на старый адрес или образует ошибочную цепочку
Публичный преобразовательЗначение записи и оставшееся время храненияЧасть преобразователей ещё отдаёт прежний или отрицательный ответ
СайтHTTP-ответ, сертификат и критический путьDNS верен, но сервер, маршрут или приложение не отвечают

Шаг 1. Зафиксируйте ожидаемый результат

До проверки запишите, какие серверы имён должны обслуживать домен, какой адрес должен возвращать основной домен и поддомен www, используется ли IPv6 и где заканчивается цепочка CNAME. Без этой базовой линии два разных ответа нельзя разделить на «старый» и «новый».

Если менялся только адрес сервера, не меняйте одновременно делегирование и дополнительные записи. Если менялись серверы имён, убедитесь, что новая зона заранее содержит полный набор записей. Почтовые MX, TXT для подтверждений и другие служебные записи тоже могут пострадать, хотя сайт по HTTP продолжит открываться.

Шаг 2. Сверьте авторитетный ответ

Сначала найдите серверы имён, которые указаны у родительской зоны. Затем запросите нужный тип записи непосредственно у каждого из них. Для специалиста удобна команда dig; в Windows ту же задачу можно решить через nslookup или веб-инструмент поставщика DNS.

dig NS example.ru
dig @ns1.example.net example.ru A
dig @ns1.example.net www.example.ru CNAME

Сравните ответы всех авторитетных серверов. Если один отдаёт старую запись, проблема находится в зоне или её синхронизации, а ожидание на стороне пользователя не исправит источник. Если все авторитетные ответы совпадают, переходите к кэшу.

Шаг 3. Проверьте кэш и отрицательные ответы

Запросите ту же запись как минимум у двух независимых публичных преобразователей имён. Веб-форма Google Public DNS позволяет выбрать тип записи и увидеть подробный ответ. В официальной инструкции Google, проверенной 24 августа 2026 года, отдельно описаны ошибки делегирования, серверов имён, DNSSEC и неверных ответов.

Параметр TTL — это время в секундах, в течение которого запись может храниться до следующего обращения к источнику. Его смысл закреплён в RFC 8767. Ошибки вида NXDOMAIN и отсутствие данных тоже могут кэшироваться: правила отрицательного кэширования описаны в RFC 2308. Поэтому создание пропущенной записи не всегда мгновенно меняет ответ каждого преобразователя.

Ограничение. Не называйте универсальный срок «распространения DNS». Фактическое ожидание зависит от прежнего TTL, отрицательного ответа, поведения преобразователя и момента последнего запроса. Фиксируйте конкретный остаток времени в каждом полученном ответе.

Как связать симптом с причиной

Дерево диагностики DNS: домен не существует, ведёт на старый адрес или открывается не у всех
Одинаковый внешний симптом требует разных действий: исправить источник, дождаться конкретного кэша или проверить сервер.
  • NXDOMAIN. Проверьте существование записи на авторитетном сервере и остаток отрицательного кэша.
  • Старый адрес. Сравните авторитетный ответ и публичные преобразователи. Если источник уже новый, запишите TTL старого ответа.
  • Сайт открывается не у всех. Сравните сети, регионы, IPv4 и IPv6. Подробный маршрут есть в статье «Сайт то открывается, то нет».
  • DNS верен, но страница недоступна. Проверяйте сервер, сертификат, перенаправления и приложение. Это уже не доказанная ошибка DNS.

Шаг 4. Подтвердите ответ для робота и пользователя

Яндекс Вебмастер может показать ошибку DNS и проверить доступность страницы для робота. В официальной справке «Проверка ответа сервера», проверенной 24 августа 2026 года, указано: при недавнем изменении DNS данные инструмента могут обновляться до суток. Это граница конкретного инструмента Яндекса, а не универсальный срок обновления DNS.

После серверной проверки откройте основной домен, вариант с www и две-три критические страницы. Проверьте HTTP-статус, конечный адрес после перенаправлений, сертификат и ключевое действие. Для поискового контура дополнительно используйте разбор мониторинга важных страниц.

Шаг 5. Зафиксируйте доказательство восстановления

Цикл доказательства восстановления DNS: базовая линия, источник, публичные ответы, страницы и повторная проверка
Исправление подтверждается только когда совпали источник DNS, внешние ответы и фактический пользовательский путь.
  1. Сохраните дату, время, тип записи и ожидаемое значение.
  2. Зафиксируйте ответы всех авторитетных серверов.
  3. Запишите ответы двух публичных преобразователей и их TTL.
  4. Проверьте основной домен, поддомены и критические страницы.
  5. Повторите проверку после окончания кэша и сохраните итог.

Снимок одной команды без времени и названия источника слабее короткого журнала. Для передачи подрядчику достаточно таблицы: условие, ожидаемый ответ, фактический ответ, источник, время, владелец следующего шага.

Где проходит граница со сроком домена

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

Что может и не может STRIX

STRIX не управляет DNS и не обещает непрерывную проверку доменных записей. Он ежедневно проверяет подключённые данные Яндекс Метрики и Директа и показывает события и рекомендации в кабинете. Изменение трафика или целей может стать поводом начать диагностику, но DNS, сервер и фактический путь команда подтверждает отдельными источниками.

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

Как проверить DNS сайта после изменений?

Сначала зафиксируйте ожидаемые серверы имён и записи. Затем запросите их у авторитетного сервера и у двух публичных преобразователей имён, сравните значения и оставшееся время кэширования. В конце откройте критические страницы и проверьте ответ в Яндекс Вебмастере.

Почему DNS уже исправлен, а сайт открывается не у всех?

Часть преобразователей имён и устройств может хранить прежний или отрицательный ответ до окончания времени кэширования. Сравните авторитетный ответ с ответами нескольких публичных преобразователей и повторите проверку после истечения их остаточного времени.

Проверка DNS заменяет контроль срока домена?

Нет. Корректные DNS-записи не доказывают, что договор на домен продлён. Срок, владельца договора, автопродление и оплату проверяйте отдельно в кабинете регистратора и по правилам доменной зоны.

Дальше по теме

Поделиться