DNS-пропагация: почему изменения DNS не применяются мгновенно

Каждый веб-разработчик и администратор сталкивался с ситуацией: вы изменили DNS Lookup, но через час (или даже сутки) часть пользователей всё ещё видит старый сайт. Это явление называется DNS-пропагацией — процессом распространения изменений DNS по всей глобальной сети. Разберём, почему это происходит и как с этим работать.

Как работает DNS

Прежде чем понять пропагацию, нужно вспомнить, как работает разрешение DNS-имён.

Иерархия DNS

DNS — это распределённая иерархическая система. Когда вы вводите example.com в браузере, запрос проходит через несколько уровней:

1. Локальный кеш — браузер и операционная система проверяют свой кеш
2. Рекурсивный резолвер — DNS-сервер вашего провайдера или публичный (8.8.8.8, 1.1.1.1)
3. Корневые серверы — указывают на серверы зоны .com
4. TLD-серверы — серверы зоны .com указывают на авторитативные серверы домена
5. Авторитативный DNS — сервер, хранящий реальные записи домена, возвращает IP геолокацию

Каждый уровень может кешировать ответ, и именно это кеширование создаёт задержку при обновлении записей.

Рекурсивные резолверы

Рекурсивные DNS-серверы — ключевые участники процесса. Они выполняют полный цикл разрешения имени и кешируют результат. В мире работают тысячи рекурсивных резолверов: серверы интернет-провайдеров, корпоративные DNS-серверы, публичные сервисы (Google DNS, Cloudflare DNS, Яндекс DNS).

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

TTL — Time to Live

TTL — это время (в секундах), которое DNS-запись может храниться в кеше. Когда вы создаёте DNS-запись, вы указываете TTL. Рекурсивные резолверы кешируют запись на указанное время и не обращаются к авторитативному серверу до истечения TTL.

Типичные значения TTL

Как TTL влияет на пропагацию

Если TTL вашей A-записи — 86400 секунд (24 часа), то после изменения IP-адреса рекурсивные резолверы будут отдавать старый IP до истечения кешированного TTL. В худшем случае (резолвер запросил запись за секунду до изменения) обновление займёт полные 24 часа.

Почему пропагация занимает время

1. Кеш рекурсивных резолверов

Это основная причина. Тысячи DNS-серверов по всему миру хранят кешированные копии ваших записей. Каждый сервер обновится только после истечения TTL записи в его кеше.

2. Негативное кеширование

Если DNS-запись не существовала и кто-то запросил её до создания, резолвер может закешировать «негативный» ответ (NXDOMAIN). SOA-запись домена содержит параметр minimum TTL, определяющий время кеширования негативных ответов.

3. Кеш операционной системы

Операционная система также кеширует DNS-ответы. В Windows кеш можно очистить командой ipconfig /flushdns, в macOS — sudo dscacheutil -flushcache, в Linux — systemd-resolve --flush-caches.

4. Кеш браузера

Браузеры имеют собственный DNS-кеш, обычно с коротким TTL (1–2 минуты). В Chrome его можно очистить через chrome://net-internals/#dns.

5. Промежуточные кеши

Корпоративные firewall, прокси-серверы и VPN могут иметь собственные DNS-кеши, часто с увеличенным TTL для снижения нагрузки.

Как ускорить DNS-пропагацию

Подготовка заранее

Самая эффективная стратегия — снизить TTL заблаговременно:

1. За 24–48 часов до планируемого изменения уменьшите TTL до 300 секунд (5 минут)
2. Дождитесь, пока старый TTL истечёт во всех кешах
3. Внесите изменение — теперь пропагация займёт максимум 5 минут
4. После подтверждения работоспособности верните TTL к нормальному значению

Использование Anycast DNS

Anycast DNS-провайдеры (Cloudflare, AWS Route 53, Google Cloud DNS) имеют серверы по всему миру. Запросы обрабатываются ближайшим сервером, что сокращает задержку и повышает надёжность.

DNS Notify

Протокол DNS Notify позволяет мастер-серверу уведомлять подчинённые серверы об изменениях. Это ускоряет синхронизацию между авторитативными серверами, но не влияет на рекурсивные резолверы.

Как проверить состояние DNS-пропагации

Для мониторинг сайтов распространения DNS-изменений:

• DNS Lookup enterno.io — проверка текущих DNS-записей вашего домена
• dnschecker.org — проверка DNS из множества точек по всему миру
• dig — утилита для детальных DNS-запросов из командной строки

Пример проверки через dig с указанием конкретного резолвера:

# Проверка через Google DNS
dig @8.8.8.8 example.com A

# Проверка через Cloudflare DNS
dig @1.1.1.1 example.com A

# Проверка через авторитативный сервер (без кеша)
dig @ns1.example.com example.com A

Типы DNS-записей и их особенности при обновлении

A и AAAA записи

Основные записи, направляющие домен на IP-адрес. При смене хостинга или сервера обновляются чаще всего. Рекомендуемый TTL при планируемых изменениях — 300 секунд.

CNAME записи

Создают алиас одного домена на другой. Важно помнить, что CNAME для поддомена требует разрешения целевой записи, что добавляет дополнительный шаг (и дополнительный кеш).

MX записи

Управляют маршрутизацией почты. Ошибка при обновлении MX может привести к потере email. Рекомендуется устанавливать высокий TTL и менять с особой осторожностью.

NS записи

Указывают авторитативные серверы домена. Обновление NS — самая ответственная операция с DNS. Пропагация NS-записей может занимать до 48 часов, так как они кешируются на уровне TLD-серверов.

TXT записи

Используются для SPF, DKIM, DMARC, верификации домена. При обновлении SPF-записи старые серверы могут отклонять или помечать как спам вашу почту до завершения пропагации.

Частые проблемы

• «У меня работает, у клиента — нет» — разные DNS-серверы, разные кеши. Проверьте через несколько резолверов
• Пропагация более 48 часов — вероятно, проблема не в кеше, а в ошибке конфигурации. Проверьте записи через DNS Lookup
• Разный ответ при каждом запросе — Round Robin DNS или проблемы с синхронизацией между авторитативными серверами
• SERVFAIL после изменения NS — новые NS-серверы ещё не сконфигурированы или не отвечают. Всегда настраивайте новые NS до изменения делегирования

Чек-лист для миграции DNS

1. За 48 часов снизьте TTL всех записей до 300 секунд
2. Убедитесь, что новый сервер полностью готов и работает
3. Внесите изменения в DNS
4. Проверьте пропагацию через несколько DNS-серверов
5. Не выключайте старый сервер минимум 48 часов
6. Мониторьте трафик на обоих серверах
7. После завершения миграции верните TTL к нормальному значению
8. Через неделю проверьте, что старый сервер не получает трафик