Что такое DNS propagation
После изменения DNS-записи серверы по всему миру кэшируют старое значение до истечения TTL. Это называется DNS propagation — распространение может занять от 5 минут до 48 часов.
Термин немного вводит в заблуждение: на самом деле ничего никуда активно не «распространяется». Ваш авторитетный сервер отдаёт новое значение сразу же после сохранения записи. Задержка возникает только там, где чужой резолвер — у интернет-провайдера, в браузере, в операционной системе — успел закешировать старый ответ и исправно отдаёт его повторным запросам, пока не истечёт TTL записи, который был установлен ДО изменения.
Проверка через командную строку
# Проверка A-записи
dig yourdomain.com A
# Проверка через Google DNS
dig @8.8.8.8 yourdomain.com A
# Проверка через Cloudflare DNS
dig @1.1.1.1 yourdomain.com A
# Быстрый ответ без кэша
nslookup yourdomain.com 8.8.8.8
# Полный путь резолвинга от корневых серверов до вашего
dig +trace yourdomain.com AПоследняя команда полезна, когда непонятно, на каком именно этапе цепочка ломается: она показывает, к каким серверам резолвер обращался последовательно — от корневых через сервер зоны верхнего уровня до авторитетных NS вашего домена — и на каком шаге ответ разошёлся с ожидаемым.
Онлайн-инструменты
| Инструмент | Применение |
|---|---|
| whatsmydns.net | Проверка из 20+ локаций мира |
| dnschecker.org | Глобальная проверка всех типов записей |
| mxtoolbox.com | MX, SPF, DKIM, blacklist проверки |
| intodns.com | Полный анализ DNS-зоны |
Разница между этими сервисами и локальным dig в том, что они опрашивают резолверы из десятков стран одновременно и показывают карту факта распространения, а не просто один ответ с ближайшего к вам сервера. Это удобно, чтобы понять, распространилось ли изменение глобально, или задержка касается только вашего провайдера.
Как ускорить обновление DNS
- Очистить DNS-кэш браузера:
ipconfig /flushdns(Windows),sudo dscacheutil -flushcache(macOS) - Очистить кэш на Linux:
systemd-resolve --flush-caches - Проверить через мобильный интернет (другой DNS-resolver)
Отдельная ловушка — негативное кеширование. Если домен раньше не существовал и резолвер уже получил ответ NXDOMAIN, этот отрицательный результат тоже кешируется — по RFC 2308 на срок, заданный полем minimum в записи SOA зоны. Только что созданная запись может быть не видна ровно по этой причине, а не из-за обычного TTL.
Типичные сообщения при проверке DNS
| Сообщение | Значение | Действие |
|---|---|---|
| ;; connection timed out; no servers could be reached (dig) | Резолвер недоступен или указан неверный IP DNS-сервера | Проверить, что 8.8.8.8 отвечает вообще, попробовать другой резолвер |
| ** server can't find yourdomain.com: NXDOMAIN (nslookup) | Имя ещё не существует в зоне либо в нём опечатка | Проверить точное написание имени и наличие записи в панели |
| ;; ANSWER: 0 в выводе dig | Запрошенный тип записи отсутствует для этого имени — например, AAAA при отсутствии IPv6 | Это нормально, если запись такого типа действительно не создавалась |
| Chrome: DNS_PROBE_FINISHED_NXDOMAIN | Либо запись ещё не распространилась, либо домен не делегирован | Проверить dig NS и у регистратора, и у хостинга |
В выводе dig три раздела отвечают за разные вещи: ANSWER — сами запрошенные записи, AUTHORITY — какие серверы считаются авторитетными для этой зоны, ADDITIONAL — вспомогательные записи вроде IP этих серверов. Если ANSWER пуст, а AUTHORITY заполнен записью SOA, это значит: зона существует, но именно такой записи в ней нет — это NXDOMAIN для конкретного типа, а не для домена целиком.
Сколько реально ждать по типу изменения
| Что меняли | Типичное время | От чего зависит |
|---|---|---|
| A/AAAA-запись с TTL 3600 | до 1 часа плюс кеш резолверов | старый TTL записи до изменения |
| NS-делегирование (смена серверов имён) | от 2 до 48 часов | TTL записи NS в родительской зоне, обычно 1–2 дня |
| MX-запись | до нескольких часов | TTL записи и кеш почтовых серверов-отправителей |
| Регистрация нового домена | от 15 минут до нескольких часов | скорость публикации в реестре зоны |
Когда пропагация ни при чём
- Правки внесены не в той зоне, где реально стоит делегирование — домен на внешних NS, а редактировали в другой панели
- Браузер или ОС держат собственный DNS-кеш дольше TTL записи — флаш кеша решает мгновенно, пропагация тут ни при чём
- CDN или прокси, например Cloudflare в режиме Proxied, отдаёт свой IP вместо вашего — это ожидаемое поведение, а не задержка распространения
- Опечатка в самой записи — сколько ни жди, правильный ответ не появится, нужна повторная проверка конфигурации, см. проверку DNS-зоны через dig
Частые вопросы
Если забыли снизить TTL перед изменением DNS, можно ли что-то сделать постфактум, чтобы ускорить переключение?
Снизить TTL уже после изменения можно, но эффекта это не даст немедленно: резолверы, которые успели закешировать старую запись со старым сроком жизни, всё равно продолжат отдавать её до истечения именно того срока. Новое, более короткое значение TTL начнёт работать только для запросов, которые попадут в кеш уже после изменения, поэтому реального ускорения стоит ждать со следующего цикла обновления.
Если онлайн-инструмент вроде whatsmydns.net показывает обновлённый результат, гарантирует ли это, что у вашего интернет-провайдера будет то же самое?
Нет, такой инструмент опрашивает множество резолверов по миру, но не обязательно именно тот, которым пользуется ваш провайдер в данный момент. Локальный резолвер мог закешировать старый ответ раньше и будет отдавать его до истечения собственного TTL независимо от того, что показывают внешние проверки, поэтому финальным подтверждением остаётся проверка с устройства, подключённого через интересующего вас провайдера.
Может ли задержка распространения приводить к потере писем, или она затрагивает только веб-трафик?
Задержка затрагивает любой сервис, который опирается на DNS-запись, включая почту: если MX-запись изменилась, а сервер отправителя ещё помнит старое значение, письмо попытается уйти по прежнему адресу и либо задержится, либо вернётся отправителю с ошибкой доставки. Поэтому смену MX-записи стоит планировать так же аккуратно, как смену A-записи сайта, и заранее снижать TTL.
Опасно ли менять DNS-записи в рабочее время, или это стоит делать только ночью?
Само по себе время суток не играет роли — важнее заранее снизить TTL и не менять одновременно несколько связанных параметров вроде NS-делегирования и адреса сайта. Ночное окно имеет смысл не из-за особенностей DNS, а из-за меньшей видимой нагрузки: если что-то пойдёт не так, последствия заметит меньше посетителей, пока идёт диагностика и откат изменений.