Распространение DNS (DNS propagation) — это время, необходимое для обновлений DNS, чтобы они дошли до всех резолверов по всему миру. Часто это понятие понимается не совсем правильно. Некоторые пользователи видят изменения практически мгновенно, а другие могут ожидать до 72 часов из-за кэширования. Понимание работы процесса резолюшн, механики TTL, уровней кэширования и заранее запланированных стратегий позволяет осуществлять миграции DNS без длительных простоев.
- Что такое DNS propagation и почему это не push-рассылка
- Процесс разрешения DNS
- Как TTL влияет на время DNS propagation
- Уровни кэширования
- Как ускорить DNS propagation: снижение TTL заранее
- Anycast DNS
- Реальное время DNS propagation: от минут до 72 часов
- Лучшие практики
- Типичные ошибки при работе с DNS
- DNS propagation checker: инструменты для проверки онлайн
- Ссылки
- Ответы на эти вопросы могут быть для вас полезными
Что такое DNS propagation и почему это не push-рассылка
Когда вы обновляете DNS-запись у своего регистратора или DNS-провайдера, изменения вступают в силу на авторитетных серверах имён (authoritative nameservers). Однако рекурсивные резолверы по всему миру продолжают возвращать старую запись до истечения её TTL. Процесс, в котором каждый резолвер получает обновлённую запись, называется DNS propagation.
📖 Определение — DNS propagation не является механизмом push-рассылки: фактически нет никакой рассылки. Каждый рекурсивный резолвер по своему усмотрению инвалидирует кэш на основе TTL, полученного из последнего ответа от авторитетного сервера.
Когда вы меняете TTL и DNS-маршрутизацию, полезно отдельно посмотреть Google Web Guide: что это такое, как работает и что означает для SEO, чтобы понимать, как инфраструктурные изменения могут отразиться на обходе и интерпретации сайта.
Процесс разрешения DNS
Понимание полного пути разрешения объясняет, почему распространение занимает время и где именно происходит кэширование.
Stub Resolver — Резолвер на уровне операционной системы (ОС) вашего устройства отправляет запрос настроенному рекурсивному резолверу — например, вашему интернет-провайдеру (ISP) или публичным адресам 1.1.1.1 / 8.8.8.8.
Рекурсивный резолвер — Проверяет свой кэш. Если запись найдена и TTL не истёк, немедленно возвращает закэшированный ответ. Если нет — начинает итеративное разрешение.
Корневые серверы — Рекурсивный резолвер запрашивает один из 13 кластеров корневых серверов, который отвечает адресом TLD-сервера имён (например, NS для .com).
TLD-сервер имён — Возвращает авторитетные NS-записи для конкретного домена (например, ns1.provider.com).
Авторитетный сервер имён — Возвращает фактическую запись (A, CNAME, MX и т. д.) вместе с её TTL. Рекурсивный резолвер кэширует этот ответ.
Ответ клиенту — Рекурсивный резолвер возвращает ответ устройству, которое также может закэшировать его локально.
💡 Каждый шаг в цепочке может кэшировать результаты. Записи корневых серверов и TLD NS кэшируются на длительные периоды — часто 48 часов — но записи вашего домена кэшируются в соответствии с их собственным TTL.
Как TTL влияет на время DNS propagation
TTL (Time To Live, время жизни записи), определённый в RFC 1035, — это 32-битное целое число, представляющее секунды. Когда резолвер кэширует запись, он уменьшает TTL с течением времени. При достижении нуля запись вытесняется из кэша и должна быть получена заново.
; Пример: A-запись с TTL 1 час
example.com. 3600 IN A 93.184.216.34
; Через 2000 секунд закэшированная копия у резолвера имеет:
; Оставшийся TTL = 3600 - 2000 = 1600 секунд| TTL (секунды) | Человекочитаемый вид | Окно распространения |
|---|---|---|
| 60 | 1 минута | ~1–5 минут глобально |
| 300 | 5 минут | ~5–15 минут |
| 3600 | 1 час | ~1–2 часа |
| 86400 | 24 часа | ~24–48 часов |
Уровни кэширования
DNS-ответы кэшируются на нескольких уровнях, каждый из которых имеет своё поведение при вытеснении записей. На практике я всегда проверяю минимум три уровня: локальный кэш ОС, кэш ISP-резолвера и кэш публичных резолверов вроде 1.1.1.1 и 8.8.8.8 — они ведут себя по-разному даже при одинаковом TTL.
⚡ Совет профессионала: Во время миграции тестируйте с нескольких резолверов. Используйте dig @1.1.1.1, dig @8.8.8.8 и dig @9.9.9.9, чтобы проверить, подхватили ли крупные публичные резолверы изменение. Резолвер вашего ISP может заметно отставать.
Как ускорить DNS propagation: снижение TTL заранее
Единственная наиболее важная техника для быстрых и плавных изменений DNS — это предварительное снижение TTL (TTL pre-lowering). Я убедился на собственном опыте: пропуск этого шага превращает плановую миграцию в многочасовой инцидент.
За 48 часов до изменения — Снизьте TTL записи, которую планируете изменить, до 60–300 секунд. Дождитесь, пока старый высокий TTL истечёт из всех кэшей.
Внесите изменение — Обновите DNS-запись до нового значения. Поскольку TTL теперь низкий, кэши истекают быстро.
Проверьте распространение — Используйте глобальный DNS-чекер (Global DNS Checker), чтобы убедиться, что новое значение видно из нескольких точек по всему миру.
После подтверждения — Верните TTL к его нормальному рабочему значению — например, 3600 или 86400.
# Шаг 1: Снизить TTL (за 48 часов до миграции)
example.com. 60 IN A 93.184.216.34 ; было 86400
# Шаг 2: Изменить запись (день миграции)
example.com. 60 IN A 104.21.45.67 ; новый сервер
# Шаг 3: После подтверждения распространения восстановить TTL
example.com. 3600 IN A 104.21.45.67🚫 Никогда не пропускайте шаг предварительного снижения TTL. Если ваша запись имеет TTL 24 часа и вы изменяете её без предварительного снижения, некоторые пользователи будут привязаны к старому IP до 48 часов.
Anycast DNS
Anycast — это техника маршрутизации, при которой один и тот же IP-адрес анонсируется из нескольких географических точек. DNS-провайдеры, такие как Cloudflare, Route 53 и Google Cloud DNS, используют anycast для маршрутизации запросов к ближайшему серверу, снижая задержку и повышая отказоустойчивость.
💡 Anycast означает, что два пользователя из разных стран, запрашивающие один и тот же IP резолвера — например, 1.1.1.1 — могут попасть на разные физические серверы с разным состоянием кэша. Именно поэтому распространение выглядит непоследовательным в разных регионах, и именно поэтому тестировать только с локальной машины недостаточно.
Реальное время DNS propagation: от минут до 72 часов
🎯 Для миграций без простоев держите старый сервер работающим до завершения распространения. Оба сервера — старый и новый — должны отдавать корректные ответы в течение всего переходного периода. Мой совет — не снимать старый сервер раньше времени: часть пользователей будет резолвить старый IP ещё несколько часов после смены записи.
| Сценарий | Ожидаемое время |
|---|---|
| TTL снижен до 60 с заранее | 1–5 минут |
| TTL 300 с, снижен заранее | 5–15 минут |
| TTL 3600 с без предварительного снижения | 1–2 часа |
| TTL 86400 с без предварительного снижения | 24–48 часов |
| Худший случай (ISP с нестандартным кэшем) | до 72 часов |
Лучшие практики
- Всегда предварительно снижайте TTL за 48 часов до любого изменения DNS.
- Держите старую инфраструктуру работающей параллельно в течение всего окна распространения.
- Используйте публичные резолверы (1.1.1.1, 8.8.8.8) для тестирования — они строго соблюдают TTL.
- Отслеживайте распространение из нескольких географических точек, а не только с вашей локальной машины.
- Используйте anycast DNS-провайдеров для снижения задержки запросов и более быстрого обновления кэша в разных регионах.
- Задокументируйте план отката до изменения DNS — знайте старые значения и способ их восстановления.
Типичные ошибки при работе с DNS
| Ошибка | Последствие | Решение |
|---|---|---|
| Не снижать TTL перед миграцией | Часы устаревшего DNS для части пользователей | Снизить до 60 с, подождать 48 ч, затем изменить |
| Немедленно отключить старый сервер | Простой для пользователей, всё ещё резолвящих старый IP | Держать старый сервер живым в течение 2× старого TTL |
| Тестировать только с локальной машины | Локальный кэш даёт ложноположительный результат | Сбросить локальный кэш + тестировать с нескольких резолверов |
| Забыть восстановить TTL после изменения | Избыточные запросы к авторитетному серверу, более медленное разрешение | Поднять TTL обратно до 3600+ после распространения |
| Игнорировать негативное кэширование (RFC 2308) | Удалённые записи остаются в кэшах как NXDOMAIN | Создавать записи заранее, до направления трафика |
DNS propagation checker: инструменты для проверки онлайн
Отслеживайте и проверяйте распространение DNS в реальном времени:
🔧 DNS Lookup — Запрашивайте любой тип записи у конкретных резолверов.
🔧 Global DNS Checker — Проверяйте статус распространения из 20+ точек по всему миру одновременно.
Ссылки
🎯 Главный вывод: DNS propagation — это не магия, а истечение срока кэша. Единственная наиболее эффективная техника — предварительное снижение TTL: опустите TTL до 60 секунд за 48 часов до изменения, внесите обновление, проверьте глобально, затем восстановите TTL. Держите старую инфраструктуру работающей в течение переходного периода и всегда тестируйте из нескольких географических точек, а не только с вашей локальной машины.
Ответы на эти вопросы могут быть для вас полезными
Почему один пользователь уже видит новый сайт, а другой — нет?
Каждый рекурсивный резолвер кэширует DNS-запись независимо и инвалидирует её только после истечения TTL. Пользователи с разными ISP или публичными резолверами получают обновление в разное время — это нормальное поведение системы, а не сбой.
Можно ли ускорить распространение DNS принудительно?
Принудительно обновить кэши сторонних резолверов нельзя. Единственный рабочий способ сократить время распространения — заблаговременно снизить TTL до 60–300 секунд и дождаться, пока старое значение вытеснится из всех кэшей естественным путём.
Что такое негативное кэширование и почему оно важно?
Негативное кэширование (RFC 2308) — это сохранение резолвером ответа NXDOMAIN (запись не найдена) на срок до минимального TTL из SOA-записи. Если вы удалили запись, а затем создали новую, часть резолверов будет возвращать «не найдено» ещё некоторое время. Решение — создавать новые записи заранее, до удаления старых.
Как правильно тестировать распространение DNS?
Используйте dig @1.1.1.1, dig @8.8.8.8 и dig @9.9.9.9 для проверки через разные публичные резолверы, а также Global DNS Checker для проверки из 20+ географических точек одновременно. Тестирование только с локальной машины ненадёжно из-за локального кэша ОС.
Нужно ли восстанавливать TTL после завершения миграции?
Да, и это важный шаг, который часто пропускают. Низкий TTL (60 секунд) означает, что каждый резолвер будет обращаться к авторитетному серверу каждую минуту — это создаёт избыточную нагрузку и замедляет разрешение. После подтверждения распространения верните TTL к рабочему значению: 3600 или 86400 секунд.
