После смены хостинга, сервера имён или адреса сайта один посетитель может видеть новую версию, другой — старую, а робот — ошибку. Фраза «DNS ещё распространяется» ничего не доказывает: нужно определить, какой слой отвечает неверно и какой ответ уже успел попасть в кэш.
Ниже — проверяемый маршрут для владельца сайта и маркетолога. Он дополняет общую систему мониторинга сайта и не повторяет отдельную инструкцию про срок домена и SSL-сертификата.
Короткий ответ. Зафиксируйте ожидаемые серверы имён и записи. Сначала запросите их у авторитетного сервера, затем у двух публичных преобразователей имён. Сравните адреса и оставшееся время кэширования. После этого откройте критические страницы и проверьте ответ в Яндекс Вебмастере.
Что именно проверять в 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, отрицательного ответа, поведения преобразователя и момента последнего запроса. Фиксируйте конкретный остаток времени в каждом полученном ответе.
Как связать симптом с причиной
- NXDOMAIN. Проверьте существование записи на авторитетном сервере и остаток отрицательного кэша.
- Старый адрес. Сравните авторитетный ответ и публичные преобразователи. Если источник уже новый, запишите TTL старого ответа.
- Сайт открывается не у всех. Сравните сети, регионы, IPv4 и IPv6. Подробный маршрут есть в статье «Сайт то открывается, то нет».
- DNS верен, но страница недоступна. Проверяйте сервер, сертификат, перенаправления и приложение. Это уже не доказанная ошибка DNS.
Шаг 4. Подтвердите ответ для робота и пользователя
Яндекс Вебмастер может показать ошибку DNS и проверить доступность страницы для робота. В официальной справке «Проверка ответа сервера», проверенной 24 августа 2026 года, указано: при недавнем изменении DNS данные инструмента могут обновляться до суток. Это граница конкретного инструмента Яндекса, а не универсальный срок обновления DNS.
После серверной проверки откройте основной домен, вариант с www и две-три критические страницы. Проверьте HTTP-статус, конечный адрес после перенаправлений, сертификат и ключевое действие. Для поискового контура дополнительно используйте разбор мониторинга важных страниц.
Шаг 5. Зафиксируйте доказательство восстановления
- Сохраните дату, время, тип записи и ожидаемое значение.
- Зафиксируйте ответы всех авторитетных серверов.
- Запишите ответы двух публичных преобразователей и их TTL.
- Проверьте основной домен, поддомены и критические страницы.
- Повторите проверку после окончания кэша и сохраните итог.
Снимок одной команды без времени и названия источника слабее короткого журнала. Для передачи подрядчику достаточно таблицы: условие, ожидаемый ответ, фактический ответ, источник, время, владелец следующего шага.
Где проходит граница со сроком домена
DNS может отвечать правильно сегодня, хотя договор на домен закончится завтра. И наоборот: оплаченный домен не гарантирует корректное делегирование. Срок, владельца договора, оплату и автопродление проверяйте в кабинете регистратора, а технический ответ — по маршруту выше. Полный порядок собран в отдельной инструкции по сроку домена и сертификата.
Что может и не может STRIX
STRIX не управляет DNS и не обещает непрерывную проверку доменных записей. Он ежедневно проверяет подключённые данные Яндекс Метрики и Директа и показывает события и рекомендации в кабинете. Изменение трафика или целей может стать поводом начать диагностику, но DNS, сервер и фактический путь команда подтверждает отдельными источниками.
Частые вопросы
Как проверить DNS сайта после изменений?
Сначала зафиксируйте ожидаемые серверы имён и записи. Затем запросите их у авторитетного сервера и у двух публичных преобразователей имён, сравните значения и оставшееся время кэширования. В конце откройте критические страницы и проверьте ответ в Яндекс Вебмастере.
Почему DNS уже исправлен, а сайт открывается не у всех?
Часть преобразователей имён и устройств может хранить прежний или отрицательный ответ до окончания времени кэширования. Сравните авторитетный ответ с ответами нескольких публичных преобразователей и повторите проверку после истечения их остаточного времени.
Проверка DNS заменяет контроль срока домена?
Нет. Корректные DNS-записи не доказывают, что договор на домен продлён. Срок, владельца договора, автопродление и оплату проверяйте отдельно в кабинете регистратора и по правилам доменной зоны.
