Как проверить, что перенос DNS прошёл без сбоев

Перенос DNS (смена провайдера, переход на новую схему серверов имён или перестройка большого набора записей) несёт больше риска, чем большинство инфраструктурных изменений, именно потому, что ошибка не проявляется громко. Сломанная запись просто тихо перестаёт разрешаться или разрешается не туда, а первым сигналом часто становится обращение в поддержку, а не оповещение.

Перед переносом

• Экспортируйте все существующие записи у текущего провайдера: полный файл зоны или его эквивалент, а не только те записи, которые вы помните.
• Уменьшите TTL у записей, которые изменятся, как минимум за один полный цикл TTL до переноса.
• Запишите текущие значения всего: A/AAAA, CNAME, MX, TXT (включая SPF/DKIM/DMARC) и любых менее распространённых используемых типов записей.

После переноса

1. Запросите новые авторитативные серверы имён напрямую по каждой перенесённой записи и сравните каждый ответ с экспортом, сделанным до переноса.
2. Проверьте A и AAAA независимо для каждого имени хоста, у которого раньше была любая из них: легко перенести одно семейство адресов и забыть другое.
3. Отдельно проверьте MX и сопутствующие записи аутентификации почты: сбои почты из-за переноса DNS случаются непропорционально часто и причиняют непропорционально много проблем.
4. Перепроверьте через более чем один резолвер и, в идеале, из более чем одной сетевой точки, прежде чем объявлять перенос завершённым.
5. Дождитесь истечения окна прежнего TTL и проверьте ещё раз: чистый результат сразу после переключения не гарантирует, что все кеширующие резолверы по всему миру уже обновились.

Массовая проверка по полному списку имён хостов, выполненная один раз сразу после переключения и ещё раз после истечения окна прежнего TTL, превращает ручную проверку каждой записи в один повторяемый шаг и даёт экспортируемый отчёт о том, что именно было проверено и когда.

Не сворачивайте старую сторону слишком рано

Чаще всего после переноса жалеют не о пропущенной записи, а о том, что аккаунт или серверы имён прежнего провайдера отключили в тот же день, когда заработали новые. Поскольку часть резолверов по всему миру до истечения TTL продолжает работать с кешированными ответами, указывающими на старую схему, сохранить прежнего провайдера активным (даже если на него больше ничего не указывает) хотя бы на одно полное окно старого TTL после переключения — дешёвая страховка. Если понадобится быстрый откат, то работающая старая сторона — разница между возвратом серверов имён за минуты и восстановлением файла зоны по памяти под давлением.

Пробный прогон позволяет поймать большинство проблем до того, как они станут настоящими

Если новый DNS-провайдер это позволяет, заранее разверните полную новую зону (полностью настроенную, но пока не делегированную) и запрашивайте её напрямую, в обход обычного делегирования: либо указав инструменту проверки её серверы имён явно, либо с помощью собственной функции предварительного просмотра провайдера. Так проверка переноса из суматохи после переключения превращается в проверку до переключения, которая не затрагивает пользователей, если что-то не так. Любая отсутствующая, неверно настроенная или просто отличающаяся от задуманного запись проявится до того, как её увидит хоть один настоящий резолвер, а это заметно менее стрессовый момент для обнаружения ошибки, чем после того, как переключение уже состоялось.