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

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

Выражение «DNS-пропагация занимает 24-48 часов» - упрощение, которое прижилось в документации хостинг-провайдеров. Реальный срок зависит от конкретного значения TTL предыдущей версии записи и может составлять от нескольких минут до нескольких суток.

Как устроено кэширование DNS

DNS работает иерархически. Когда ваш компьютер (или почтовый сервер) запрашивает запись, запрос проходит через цепочку:

1. Stub resolver на вашей машине обращается к рекурсивному резолверу (8.8.8.8, 1.1.1.1, резолвер вашего провайдера).
2. Рекурсивный резолвер проверяет свой кэш. Если запись есть и TTL не истёк, возвращает ответ из кэша.
3. Если записи в кэше нет, резолвер обращается к корневым серверам, затем к серверам зоны (.com, .ru), затем к авторитативному серверу вашего домена.
4. Полученный ответ сохраняется в кэше на время, указанное в поле TTL.

Ключевой момент: пока кэш действителен, резолвер не обращается к авторитативному серверу. Он не знает, что вы изменили запись. И это поведение корректно - оно описано в RFC 1034 и является основой масштабируемости DNS.

TTL определяет скорость пропагации

Реальное время пропагации определяется значением TTL предыдущей версии записи, а не новой. Это принципиальный момент, который часто упускают:

• Старый TTL = 300 секунд (5 минут). Через 5 минут все резолверы, закэшировавшие запись, обратятся за свежей версией.
• Старый TTL = 3600 секунд (1 час). Пропагация займёт до часа.
• Старый TTL = 86400 секунд (24 часа). Максимальное ожидание - сутки.

Если старая запись имела TTL 86400, а вы установили новый TTL 300, это не поможет ускорить текущее обновление. Резолверы, которые уже закэшировали старое значение, будут держать его до 24 часов. Новый короткий TTL вступит в силу только для следующих изменений.

Пропагация и электронная почта

Для email DNS-пропагация создаёт несколько категорий проблем:

• Миграция MX. При переезде с одного почтового сервера на другой часть MTA в интернете продолжает видеть старую MX-запись. Входящие письма разделяются между старым и новым сервером. Если старый уже выключен - письма теряются.
• Публикация SPF. После добавления SPF-записи часть принимающих серверов ещё не видит её. Для них результат SPF - «none» (запись не найдена), а не «pass». В зависимости от DMARC-политики получателя это может привести к отклонению писем.
• Ротация DKIM-ключа. Если вы удалили старый ключ из DNS и опубликовали новый, часть серверов ещё видит старый ключ (и проверяет подпись успешно), а часть не видит никакого ключа (и DKIM fail). Правильная практика - сначала опубликовать новый ключ, дождаться завершения пропагации, переключить подписание на новый ключ, и только потом удалить старый.
• Ужесточение DMARC. Переход с p=none на p=reject. Если часть серверов уже видит reject, а другие ещё работают с none, поведение становится непредсказуемым. Рекомендуется промежуточный шаг через p=quarantine с параметром pct.

Как минимизировать период несогласованности

Полностью ускорить пропагацию невозможно: вы не контролируете кэши чужих резолверов. Но можно сократить окно, в которое разные серверы видят разные значения:

1. Заранее снизьте TTL. За 1-2 дня до планируемого изменения установите TTL на 300 секунд. Подождите, пока старый TTL истечёт у всех резолверов. После этого выполните основное изменение - новое значение распространится за 5 минут.
2. Держите оба сервера в работе. При миграции MX не выключайте старый сервер до полного завершения пропагации. Настройте пересылку со старого на новый, чтобы письма не терялись.
3. Проверяйте из разных точек. Используйте dig с указанием конкретных резолверов (@8.8.8.8, @1.1.1.1, @9.9.9.9), чтобы убедиться, что изменение дошло до основных публичных DNS.
4. Не меняйте несколько записей одновременно. Если вы переключаете MX и одновременно меняете SPF, диагностика проблем усложняется. Разнесите изменения по времени: сначала SPF, дождитесь пропагации, затем MX.

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

Если резолвер запросил запись и получил ответ NXDOMAIN (домен не существует) или NODATA (запись данного типа не найдена), этот отрицательный результат тоже кэшируется. Время кэширования определяется полем SOA MINIMUM авторитативной зоны (обычно от 300 до 86400 секунд).

Это важно при первичном создании записей. Если кто-то запросил MX вашего нового домена до того, как вы настроили DNS, резолвер закэшировал «записи нет». Новая запись не будет видна этому резолверу, пока не истечёт TTL негативного кэша. Иногда это объясняет, почему «DNS не работает», хотя запись уже создана.

Пропагация и валидация email

Валидаторы email при каждой проверке обращаются к DNS: MX-записи, A-записи, разрешение имён хостов. Если DNS-записи домена были недавно изменены и пропагация не завершилась, результат проверки может оказаться некорректным. Домен переехал на новый MX, но валидатор получает ответ от резолвера, который видит старый IP - и фиксирует тайм-аут или отказ.

Профессиональные валидаторы учитывают этот фактор: используют несколько независимых DNS-резолверов, контролируют TTL и повторяют проверку при неоднозначных результатах.