Одна из самых частых вопросов при работе с доменами и хостингом — «Сколько ждать, пока DNS-записи обновятся?». Статус «Сроки уточняются» в панели управления регистратором или хостингом часто вызывает тревогу. В этой статье мы подробно разберем, от чего зависят сроки распространения (пропагации) DNS, какие бывают нормативы и как ускорить процесс.

Что такое DNS-пропагация и почему она не мгновенна?

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

Причина кроется в архитектуре DNS: это распределенная иерархическая система кэширования. Чтобы снизить нагрузку на авторитативные серверы и ускорить отклик для пользователей, промежуточные (рекурсивные/кэширующие) серверы провайдеров, корпоративных сетей и публичных резольверов (Google 8.8.8.8, Cloudflare 1.1.1.1, Яндекс DNS и др.) хранят копии записей определенное время.

Ключевой момент: Обновления не происходят мгновенно. Изменениям требуется время для глобального распространения из-за кэширования и разницы в скорости обновления записей на серверах.

Основные факторы, влияющие на скорость обновления

1. TTL (Time To Live) записи. Это главный параметр, задающийся администратором зоны. Он указывает (в секундах), как долго кэширующие серверы имеют право хранить запись, не обращаясь к авторитативному серверу.
   • Стандартные значения: от 300 сек (5 мин) до 86400 сек (24 часа) и выше.
   • Понижение TTL заранее (за сутки до плановых изменений) — лучший способ ускорить пропагацию.
2. Политики кэширующих серверов (Resolver Policies). Многие DNS-резольверы (особенно у крупных провайдеров) игнорируют слишком низкие TTL, устанавливая свой минимальный порог (например, не менее 5–15 минут или даже 1 часа). «Все администраторы задают минимальный порог, ниже которого частота обновления увеличиваться не будет».
3. Уровень изменения.
   • Изменение записей внутри зоны (A, AAAA, CNAME, TXT, MX): Обновляется относительно быстро после истечения TTL на авторитативных NS-серверах домена.
   • Смена NS-серверов (делегирование): Требует обновления данных в зоне верхнего уровня (TLD — .ru, .com, .net и др.). Это занимает больше времени, так как зависит от политик реестра TLD.
4. Специфика TLD (зона верхнего уровня). «Для .com эти обновления происходят довольно быстро (в течение нескольких минут), но для некоторых других зон TLD серверы имен могут применять обновления не так быстро».
5. Локальное кэширование ПО и ОС. Браузеры, операционные системы (Windows, Linux, macOS), антивирусы и даже некоторые приложения кэшируют DNS в памяти «на неопределенный срок (до тех пор, пока программу не перезапустят)».

Реальные сроки: от минут до дней

В интернете и в документации провайдеров встречаются разные цифры. Ниже сводная таблица на основе данных регистраторов, хостингов и технических сообществ (Stack Overflow, Хабр, Reddit, базы знаний Keyfinanz и др.).

Почему через 72 часа может не обновиться везде?

Если прошло 3 суток, а изменения не видно — это аномалия. Основные причины:

• Игнорирование TTL провайдером. Некоторые ISP принудительно держат записи в кэше неделю и более для экономии трафика.
• Ошибки на стороне нового хостинга/NS. «В случае переезда на другой хостинг, задержка..; может быть связанна с недоступностью DNS вашего нового провайдера с различных локаций». Проверьте доступность новых NS-серверов с разных точек мира.
• Ошибки в синтаксисе зоны. Опечатка в записи, отсутствие точки в конце CNAME, некорректный IP.
• Кэш на стороне пользователя. Браузер, ОС, роутер, VPN, антивирус.

Как проверить статус пропагации?

Не полагайтесь только на свой браузер. Используйте инструменты проверки с разных точек мира:

• Глобальные чекеры: dnschecker.org, whatsmydns.net, dnsmap.io, digwebinterface.com. Показывают, какие IP/NS видят серверы в разных странах.
• Консольные утилиты (для продвинутых):

  dig @8.8.8.8 example.com A +short
  dig @1.1.1.1 example.com NS +short
  nslookup example.com 8.8.8.8

• Проверка авторитативных серверов: Опрос напрямую ваших NS-серверов (указанных в WHOIS/регистраторе) покажет, что они уже отдают. Если они отдают новое — ждем кэширующих.

Что делать, чтобы не ждать долго? (Чек-лист)

1. Планируйте заранее. За 24-48 часов до переноса снизьте TTL на текущих NS до минимума (300-600 сек), если панель позволяет.
2. Делайте изменения в рабочее время. Чтобы в случае ошибки можно было быстро откатиться и связаться с поддержкой * (техподдержка регистратора/хостинга).
3. Проверяйте на авторитативных NS сразу после сохранения. Если они не отдают новые данные — проблема на стороне вашего DNS-хостинга/регистратора, а не в пропагации.
4. Очистите локальные кэши.
   • Windows: ipconfig /flushdns
   • macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
   • Linux (systemd-resolved): sudo systemd-resolve --flush-caches
   • Браузер: chrome://net-internals/#dns → «Clear host cache».
   • Перезагрузка роутера.
5. Используйте публичные DNS для тестов. Временно пропишите в настройках сети 1.1.1.1 (Cloudflare) или 8.8.8.8 (Google), они обычно обновляются быстрее провайдерских.

Резюме: что означает статус «Сроки уточняются»?

Если вы видите этот статус в панели управления (например, у регистратора * или хостинга *), это означает:

• Запрос на изменение принят в обработку.
• Авторитативные серверы обновляются или уже обновились.
• Система не может гарантировать точное время, когда все пользователи интернета увидят изменения, так как это зависит от третьих лиц (провайдеров, браузеров, ОС).

Статья подготовлена на основе данных технических сообществ (Хабр, Stack Overflow, Reddit), баз знаний хостинг-провайдеров (Keyfinanz, Hostings.info) и стандартов RFC на .