Пошаговая диагностика DNS после переноса: NS, A/AAAA, CNAME, MX и TXT, авторитетный ответ и кэш резолвера, проверка веба и почты, точечный возврат записей.
Зафиксируйте точный симптом и имя
Диагностика начинается с полного имени и операции: не открывается example.com, не работает www, не приходит почта или сервис не видит TXT подтверждения. Это разные запросы. Запишите время, сеть, браузер или программу, ожидаемый результат и последнее изменение. Фраза «DNS ещё не обновился» без имени, типа и ответа не объясняет, что именно нужно ждать.
Сайт может разрешаться в правильный IP, но отвечать HTTP 500 из-за приложения. Сертификат может не включать www, хотя DNS работает. Почтовая ошибка может быть связана с политикой отправителя, а не MX. Сначала определите, на каком слое отказ: разрешение имени, соединение, TLS, HTTP или приложение. Не меняйте всю зону ради одной ошибочной страницы.
Найдите действующего поставщика DNS
Регистратор хранит делегирование на NS, а сами записи обслуживаются авторитетной DNS-системой. Панель старого хостинга может продолжать показывать редактируемую зону, которая уже не используется доменом. Поэтому перед изменением сверяйте действующие NS с тем поставщиком, в кабинете которого собираетесь работать.
| Тип | Для чего нужен | Частая ошибка |
|---|---|---|
| NS | Делегирование зоны | Редактировать неиспользуемую панель |
| A / AAAA | Адрес IPv4 / IPv6 | Обновить A, оставив старый AAAA |
| CNAME | Алиас другого имени | Путать имя назначения с URL страницы |
| MX | Почтовые серверы приёма | Заменить веб-IP и ожидать почтовой миграции |
| TXT | Текстовые данные и подтверждения | Удалить чужие служебные записи без разбора |
| CAA / DS | Отдельные политики и DNSSEC | Менять защитные записи без плана |
Сохраните полную исходную зону и старые NS до работ. Учитывайте поддомены, внешние сервисы, почту и DNSSEC. Восстановление одной A-записи не возвращает потерянные MX и проверочные TXT. Если доступа к действующей зоне нет, решайте вопрос полномочий с владельцем, а не создавайте новую зону вслепую.
Выполните отдельные запросы нужных типов
dig — средство чтения DNS. Оно не меняет записи. В примерах используется зарезервированное имя example.com; замените его своим разрешённым доменом, а не запускайте поиск закрытых имён чужой инфраструктуры. На Windows без dig можно использовать штатный Resolve-DnsName или согласованную утилиту администратора. Установка дополнительного инструмента не обязательна для понимания последовательности.
dig example.com NS
dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com TXTКороткий вывод удобен после понимания ответа, но в первом протоколе может скрыть важный статус. Отсутствие A в одной выборке не означает, что домен не существует: может быть алиас, другой тип или ошибка запроса. Сначала прочитайте заголовок и цепочку ответа. Не вставляйте в отчёт закрытые TXT-токены, если они не нужны получателю.
Различайте NXDOMAIN, пустой ответ и SERVFAIL
NXDOMAIN указывает на ответ об отсутствии запрошенного имени, тогда как успешный ответ без нужной записи может означать отсутствие конкретного типа. SERVFAIL сообщает о неуспехе обработки запроса; причиной могут быть недоступность авторитетных серверов, ошибка делегирования или проблема валидации DNSSEC. Сам по себе этот статус не говорит, какую строку нужно удалить.
| Наблюдение | Что проверить дальше |
|---|---|
| NXDOMAIN | Точное написание, уровень имени и действующую зону |
| NOERROR без нужного типа | Есть ли этот тип и не используется ли CNAME |
| SERVFAIL | Делегирование, доступность серверов, DNSSEC |
| Timeout | Сеть, выбранный резолвер и доступность DNS |
| Правильный IP, но HTTP 500 | Веб-сервер и приложение, а не случайную смену NS |
Сохраните исходный ответ до повторного изменения. Если предыдущая правка произошла только что, отсутствие новой записи в кэше требует сравнения с авторитетным ответом. Если авторитетная сторона тоже содержит ошибку, ожидание TTL не исправит её самостоятельно. Нужно изменить фактическое неверное значение у действующего поставщика.
Сравните авторитетный ответ и рекурсивный кэш
Определите авторитетный сервер по действующей схеме и выполните запрос к нему, затем сравните с используемым рекурсивным резолвером. Подставляйте реальное имя сервера из проверенного NS-ответа. Если используются разные DNS-поставщики или сложное делегирование, сначала уточните схему у администратора. Не считайте первый сервер из случайной инструкции авторитетным для вашего домена.
dig @ns1.example.com example.com A +norecurse
dig @ns1.example.com example.com AAAA +norecurseЕсли авторитетный ответ новый, а резолвер возвращает старый, изучите оставшийся TTL и кэш. Снижение TTL после того, как старое значение уже сохранено, не сокращает автоматически срок жизни существующей копии. Учитывайте и отрицательное кэширование для ранее отсутствовавшего имени. Обещание «везде обновится через пять минут» без исходных TTL и схемы не имеет основания.
Проверьте IPv4, IPv6 и алиасы
После переноса часто меняют A, оставляя AAAA со старой площадкой. Тогда часть клиентов может попадать по IPv6 на прежний сервер и видеть другую страницу или ошибку HTTPS. Проверяйте оба типа, даже если сами пользуетесь сетью без IPv6. Не удаляйте AAAA автоматически: сначала подтвердите, поддерживает ли новая площадка этот маршрут и какое значение должно быть.
Для www и других алиасов проверьте всю цепочку назначения. CNAME содержит DNS-имя, а не https:// и путь страницы. Учитывайте правила конкретного DNS-поставщика для корня зоны и поддерживаемых им механизмов алиасов. Возможность интерфейса не переносится на все системы. Также проверьте, что целевой сервер настроен обслуживать это имя и имеет соответствующий сертификат.
Почту и подтверждающие TXT проверяйте отдельно
Для входящей почты нужны ожидаемые MX и доступность указанных серверов. Для исходящей важны параметры почтового поставщика и аутентификация отправителя; одна правильная MX-запись не гарантирует доставку писем из WordPress. Сохраняйте точные значения из официальной инструкции своего сервиса, включая селектор DKIM и параметры SPF/DMARC.
Не создавайте второй независимый SPF-текст по принципу «добавим рядом ещё один»: состав разрешённых отправителей нужно согласовать в одной корректной политике для имени. Не копируйте DKIM другого домена и не заменяйте все TXT при подключении нового сервиса. Для проверки отправьте обезличенное сообщение в согласованный ящик и изучите результат аутентификации получателя, не раскрывая клиентскую переписку.
Внесите одну подтверждённую правку и проверьте сервис
Когда найдено расхождение, зафиксируйте старое и новое значение, имя, тип, TTL, причину и ответственного. Изменяйте только нужную запись в действующей зоне. Если требуется смена NS, это отдельная операция с полной подготовленной зоной. Для DNSSEC согласуйте обновление соответствующих данных с поставщиком, а не отключайте защиту вслепую.
- Сверьте ожидаемое значение с официальной инструкцией услуги.
- Сохраните исходную запись и связанные зависимости.
- Внесите точечное изменение у действующего DNS-поставщика.
- Прочитайте авторитетный ответ и затем используемый резолвер.
- Проверьте сам сайт, HTTPS, почту или подтверждение сервиса.
- Зафиксируйте результат и оставшиеся кэшированные ответы.
Не повторяйте правку только потому, что один браузер ещё показывает старый ответ. Сначала сравните уровни. Частая смена значений создаёт несколько состояний в разных кэшах и делает ситуацию менее понятной. DNS-проверка не заменяет функциональную приёмку приложения.
Возврат и полезный запрос в поддержку
Для возврата используйте сохранённое исходное значение и оцените, какие изменения успели поступить на новую площадку. Возврат веб-IP не переносит новые заказы обратно в старую базу. Если проблема только в почтовой записи, не возвращайте весь сайт. После отката снова проверьте авторитетную сторону, кэши и сервис.
В поддержку передайте домен, тип записи, ожидаемое и фактическое значение, время с часовым поясом, используемый резолвер и код ошибки. Уберите пароли и токены. Запрос «не работает DNS» без этих данных требует повторного сбора. При неизвестной причине честно укажите гипотезу, а не объявляйте провайдера виновным по одному тайм-ауту.
FAQ и итог диагностики
Почему у меня открывается, а у коллеги нет?
Возможны разные кэши, резолверы, IPv4/IPv6 и сети. Сравните точное имя, A/AAAA, TTL и фактический ответ, а не только браузер.
Очистка кэша браузера сбрасывает DNS везде?
Нет. Существуют локальные и рекурсивные кэши, а также кэш приложения и CDN. Нужно определить конкретный слой.
Правильный A гарантирует работающий HTTPS?
Нет. Сервер должен принимать это имя и иметь подходящий сертификат. Соединение и приложение проверяются отдельно.
Нужно ли ждать, если авторитетный сервер отдаёт ошибочную запись?
Сначала исправьте подтверждённое неверное значение. Время само не заменит ошибку в действующей зоне правильной записью.
Диагностика завершена, когда понятен источник ответа, ожидаемые записи совпадают с фактическими, а нужный сервис прошёл собственную проверку. Сохраните паспорт зоны и протокол изменения для следующего переноса.
Источники и дата
Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.
