#Что произошло и как распознать неисправность
После смены NS у регистратора и переноса сайта часть посетителей уже попадает на новый сервер, а часть видит прежнюю страницу. Причина не обязательно в «медленном обновлении интернета»: родительская зона, кеш рекурсоров, различающиеся наборы записей на NS и устаревшие адреса A/AAAA могут сочетаться. Начните с ответов родительской зоны и прямых запросов к новым NS, затем выясните, какой именно старый адрес получает пользователь. Нельзя менять IP наугад каждые пять минут: это усложняет диагностику и продлевает разнобой.
#Причины и отличительные признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Рекурсивные DNS сохранили старую делегациюЗаписи NS имеют TTL, и часть рекурсоров ещё использует предыдущие серверы. | Родительские NS уже новые, но некоторые публичные рекурсоры возвращают старые. | Дождаться истечения TTL при сохранении работоспособности обоих наборов NS. |
| Новые NS возвращают старый адресЗона скопирована со старой записью A либо AAAA. | Прямой dig @новый_NS показывает старый IP. | Исправить A/AAAA на всех новых авторитетных серверах. |
| У родителя делегация не обновиласьВ панели NS изменились, но реестр домена пока отдаёт прежний набор. | Запрос через dig +trace показывает старые NS у родителя. | Обратиться к регистратору и проверить статус операции. |
| Неполно обновлены вторичные серверыОдин новый NS отвечает устаревшей зоной. | SOA serial отличается между новыми серверами. | Исправить передачу и проверить SOA. |
#Пошаговая диагностика и исправление
- Зафиксируйте, какая версия сайта отображаетсяОткройте сайт из двух разных сетей, например домашней и мобильной, и запишите точный адрес, время, наличие HTTPS и различие содержимого. Не очищайте кеш браузера первым действием: он не показывает, какую DNS-запись использовал клиент. Если адрес в браузере меняется на другое имя, отдельно проверьте HTTP-перенаправление, а не только NS.
- Посмотрите делегирование у родительских серверовНа компьютере с dig выполните
dig +trace example.com NS, подставив ваш домен. В ответах проследите переход от корня к зоне верхнего уровня и делегацию на авторитетные NS. Если список у родителя всё ещё старый, проверьте состояние изменения NS в панели регистратора; изменение файла зоны на новом хостинге не заменяет делегирование у регистратора. - Сравните записи обоих наборов NSВ терминале выполните запросы
dig @oldns.example.net example.com A +shortиdig @newns.example.net example.com A +short, подставив фактические адреса старого и нового NS. Дополнительно сравните AAAA, CNAME для www и NS. Если оба набора обслуживают разных посетителей, до истечения срока кеша желательно поддерживать корректные ответы на обоих, а не немедленно выключать старый сервер. - Проверьте серийные номера на новых NSЗапросите
dig @ns1.example.com example.com SOA +shortи аналогично для ns2. Новые авторитетные DNS-серверы должны возвращать согласованные данные. Если номера отличаются, проверьте AXFR/IXFR или способ синхронизации панели хостинга. Ошибка синхронизации не устраняется ожиданием TTL: часть пользователей продолжит получать неправильный результат. - Проверьте конкретный рекурсор пострадавшего пользователяПопросите пользователя записать используемый DNS-адрес и ответ на
nslookup example.comилиdig example.com A. Учитывайте, что некоторые устройства применяют защищённый DNS и ответы могут отличаться от системного. Сравните сdig @1.1.1.1 example.com A +shortи другим рекурсором. Если один выдаёт старую делегацию в пределах её TTL, требовать немедленного обновления у него некорректно. - Исправьте фактические A, AAAA и www на новых NSВ панели того DNS-провайдера, чьи NS указаны у родителя, найдите зону нужного домена и проверьте IP веб-сервера. Сохраните скриншот/экспорт прежних значений и внесите только подтверждённые исправления. Не забудьте AAAA: браузер с IPv6 может открыть старый сайт, даже когда A уже правильный. Если www указывает через CNAME, следуйте цепочке до конечного IP.
- Поддерживайте оба сервера на время распространенияЕсли возможно, на старом веб-сервере временно сохраняйте правильный HTTPS и перенаправление на новый адрес, согласованное с планом переезда. Не удаляйте старую зону и не отзывайте сертификат до окончания периода кеширования и проверки логов. При смене почтового хостинга следите за MX/TXT отдельно, чтобы не потерять письма на переходе.
- Проверьте с нескольких сетей и определите момент завершенияЧерез известный TTL старого NS сделайте повторную выборку NS из родителя и запросы A/AAAA у независимых рекурсоров и обоих новых NS. Убедитесь, что все указывают на нужный сервер и сервер отвечает по HTTPS. Если старый адрес остаётся у одного NS — исправьте его данные; если только у конкретного пользователя — попросите перезапустить сетевое подключение после окончания TTL, не меняя делегирование снова.
- Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Как проверить результат и что делать при неуспехе
Успех подтверждён совпадением делегирования у родителя, согласованными зонами новых NS и корректными A/AAAA из нескольких независимых сетей. При несовпадении у родителя обращайтесь к регистратору.