DNS после переноса сайта: что проверить, если домен ведёт не туда

После переноса сайта часто кажется, что работа закончена: файлы лежат на новом сервере, база импортирована, SSL выпущен, главная открывается. Но часть пользователей всё ещё видит старый сайт, почта перестала принимать письма, www ведёт не туда, а поддомен открывает заглушку хостинга. В таких случаях нужно смотреть DNS.

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

A-запись

A-запись указывает IPv4-адрес сервера. Если сайт перенесли на новый сервер, именно здесь часто остаётся старый IP.

dig example.ru A
dig www.example.ru A

Если домен без www и домен с www должны открывать один сайт, нужно проверить оба варианта. Иногда основной домен уже переключили, а www забыли.

AAAA-запись

AAAA-запись указывает IPv6-адрес. Её часто не замечают. В итоге A-запись уже ведёт на новый сервер, а AAAA продолжает вести на старый. У пользователей с IPv6 сайт может открываться иначе.

dig example.ru AAAA

Если IPv6 на новом сервере не настроен, лишнюю AAAA-запись лучше убрать или настроить корректно. Иначе часть трафика будет уходить не туда.

CNAME для www и поддоменов

www часто настраивают через CNAME на основной домен. Это нормально, если сделано осознанно.

www.example.ru. CNAME example.ru.

Но после переезда в DNS могут остаться старые CNAME на технический домен хостинга. Тогда www или отдельный поддомен открывает не тот сервер.

dig www.example.ru CNAME
dig cdn.example.ru CNAME

MX и почта

Если переносится только сайт, MX-записи почты обычно трогать не нужно. Частая ошибка — поменять DNS у домена целиком и потерять записи почтового сервиса. В результате сайт открывается, но почта домена перестаёт принимать письма.

dig example.ru MX

Если почта обслуживается внешним сервисом, его MX должны остаться в DNS. Дополнительно нужно проверить TXT-записи SPF, DKIM и DMARC.

dig example.ru TXT
dig _dmarc.example.ru TXT

TTL и ожидание обновления

TTL показывает, как долго DNS-ответ может храниться в кэше. Если перед переносом TTL был большим, часть пользователей может ещё видеть старый IP.

dig example.ru A +ttlunits

Перед плановым переездом TTL лучше снижать заранее. Например, за день до переноса поставить 300 секунд. После стабилизации можно вернуть более спокойное значение.

Проверка через разные DNS-серверы

Иногда локальный провайдер уже видит новый IP, а публичный DNS ещё нет. Для сравнения можно спрашивать разные резолверы.

dig @8.8.8.8 example.ru A
dig @1.1.1.1 example.ru A

Если ответы отличаются, это не всегда ошибка. Возможно, DNS ещё обновляется. Но если прошло много времени, нужно проверить авторитетные NS-записи.

NS-записи

Если домен перевели на новые nameserver, старые DNS-записи в прежней панели уже не имеют значения. Иногда правки делают не там: редактируют DNS у старого хостинга, а домен уже смотрит на DNS регистратора.

dig example.ru NS

После этого нужно открыть именно ту панель, nameserver которой обслуживает домен.

SSL после DNS

SSL-сертификат выпускается и проверяется по домену. Если DNS ведёт не на тот сервер, сертификат может не выпуститься или сайт будет показывать чужой сертификат.

curl -I https://example.ru/
openssl s_client -connect example.ru:443 -servername example.ru

Короткий чек-лист после переноса

1. Проверить A-запись основного домена.
2. Проверить A или CNAME для www.
3. Проверить лишнюю AAAA-запись.
4. Проверить MX, если почта должна остаться рабочей.
5. Проверить TXT: SPF, DKIM, DMARC.
6. Проверить TTL и ответы разных DNS-серверов.
7. Проверить NS и убедиться, что правки делаются в правильной панели.
8. Проверить HTTPS после обновления DNS.

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