После смены DNS-записей или NS-серверов домен не сразу «переключается» на новую конфигурацию. DNS-серверы по всему миру кэшируют ответы и обновляют их с разной скоростью. Период, пока все серверы не перейдут на новые данные, называется пропагацией.
Проверить текущее состояние DNS с разных серверов можно с помощью DNS Lookup на rechecker.ru.
Как работает DNS-кэширование
- Пользователь запрашивает example.com
- Резолвер (провайдер, Google 8.8.8.8 и т.д.) проверяет кэш
- Если запись есть и TTL не истёк — отдаётся кэшированное значение
- Если нет — запрос идёт к authoritative NS и ответ кэшируется на время TTL
Пока TTL не истёк, старые данные продолжают отдаваться. Пропагация — это процесс, когда все резолверы постепенно получают обновлённые записи.
Факторы, влияющие на время пропагации
TTL (Time To Live)
Время жизни записи в секундах. DNS-сервер кэширует ответ на этот период.
| TTL | Время жизни в кэше |
|---|---|
| 300 | 5 минут |
| 3600 | 1 час |
| 86400 | 24 часа |
Чем больше был TTL до смены, тем дольше старые данные могут оставаться в кэше. Рекомендация: за 24–48 часов до смены снизить TTL до 300–600.
Иерархия DNS
Запрос проходит цепочку: root → TLD (.com) → authoritative NS домена. Каждый уровень может кэшировать. NS-записи TLD-зоны (.com, .ru) кэшируются на 24–48 часов у многих провайдеров.
Смена NS vs смена A-записи
| Действие | Сложность | Типичное время |
|---|---|---|
| Смена A-записи | Низкая | От минут до TTL |
| Смена NS | Высокая | 24–72 часа, иногда до 48 часов |
При смене NS меняется authoritative сервер. Пока TLD-серверы не обновят кэш NS-записей, запросы идут на старые NS.
Смена NS: пошаговый план
1. Подготовка (за 24–48 часов)
- Создайте зону на новых NS с нужными записями
- Убедитесь, что A, MX, TXT и т.д. настроены корректно
- Проверьте доступность по прямым запросам к новым NS:
dig @ns1.new-host.com example.com
2. Снижение TTL
На старых NS уменьшите TTL для критичных записей до 300–600. Это ускорит обновление после смены.
3. Смена NS у регистратора
В панели регистратора укажите новые NS (ns1.new-host.com, ns2.new-host.com и т.д.). Сохраните изменения.
4. Ожидание
Обычно 24–72 часа. В редких случаях — до 48 часов. Проверяйте с разных серверов.
5. Проверка пропагации
dig @8.8.8.8 example.com NS
dig @1.1.1.1 example.com NS
dig example.com A
Онлайн: DNS Lookup — проверка с разных DNS-серверов.
Смена A-записи (без смены NS)
Проще: меняется только значение A на authoritative NS. Резолверы обновят кэш после истечения TTL.
Рекомендация: за сутки до смены снизить TTL до 300. После смены подождать 1–2 TTL и при необходимости вернуть TTL к 3600–86400.
Смена хостинга (тот же NS)
Если NS не меняются (например, вы используете DNS хостинга), достаточно обновить A-запись на новый IP. Пропагация зависит от TTL.
Проблемы при пропагации
Сайт недоступен
- Убедитесь, что на новых NS зона настроена и отдаёт A-запись
- Проверьте, что NS-серверы домена действительно указывают на новый хостинг
Почта не доходит
- MX-записи должны быть на новых NS
- SPF, DKIM, DMARC — на новых NS
Разные результаты с разных серверов
Нормально во время пропагации. Часть резолверов уже обновилась, часть — нет. Подождите или перезапустите DNS-кэш локально (если тестируете со своего сервера).
Ускорение пропагации
Полностью ускорить нельзя — кэши контролируют провайдеры. Можно:
- Заранее снизить TTL
- Синхронно обновить зону на старых и новых NS (чтобы не было «провала»)
- Использовать сервисы с коротким TTL (например, Cloudflare)
Проверка с разных серверов
| Сервер | Адрес |
|---|---|
| 8.8.8.8, 8.8.4.4 | |
| Cloudflare | 1.1.1.1, 1.0.0.1 |
| Quad9 | 9.9.9.9 |
| OpenDNS | 208.67.222.222 |
dig @8.8.8.8 example.com +short
dig @1.1.1.1 example.com +short
Если результаты разные — пропагация ещё идёт.
Рекомендации
- Не планируйте смену NS на пятницу — выходные усложняют поддержку
- Держите старую зону рабочими до 72 часов после смены
- Справочник по типам записей: DNS записи: A, AAAA, CNAME, MX, TXT — полный справочник