Сколько обновляются DNS: реальное время и как его ускорить
Изменения DNS никуда не «рассылаются» — старые ответы просто истекают в кешах. Разбираем, от чего на самом деле зависит время обновления DNS и как уложить следующее изменение в минуты.

Время обновления DNS (его ещё называют распространением DNS) — это задержка между сохранением изменения и моментом, когда все резолверы в интернете начинают отдавать новый ответ. При обычной правке записи это, как правило, от нескольких минут до старого TTL записи; при смене NS-серверов — до 24–48 часов, потому что записи делегирования в родительской зоне кешируются дольше.
Слово «распространение» немного вводит в заблуждение. Ничего не рассылается по интернету. Ваш авторитативный DNS-сервер знает новое значение в ту же секунду, как вы нажали «сохранить». Ждёте вы того, чтобы тысячи независимых кешей — у провайдеров, публичных резолверов, роутеров и операционных систем — выбросили сохранённый ранее ответ и запросили его заново.
Почему изменения DNS не применяются мгновенно
Каждый ответ DNS несёт TTL (time to live) — число секунд, в течение которых резолвер может повторно использовать ответ, не спрашивая снова. Если у вашей A-записи был TTL 3600, когда резолвер провайдера посетителя её запросил, этот резолвер может отдавать старый IP до часа после изменения, как бы быстро ни работал ваш DNS-провайдер.
Вот и весь механизм. Разные резолверы получили вашу запись в разные моменты, поэтому их копии истекают в разное время. Поэтому один знакомый уже видит новый сайт, а другой — ещё старый, и поэтому онлайн-сервисы проверки обновления DNS какое-то время показывают пёструю карту из зелёных и красных точек.
Сколько обновляются DNS: типичные сроки
Ответ зависит от того, что именно вы изменили. В таблице ниже — реалистичные диапазоны при условии, что кеши соблюдают TTL (крупные резолверы в основном соблюдают).
| Изменение | От чего зависит задержка | Типичное время |
|---|---|---|
| Правка записи A, AAAA или CNAME | Старый TTL этой записи | От 1 минуты до старого TTL (часто от 5 минут до 1 часа) |
| Добавление совершенно новой записи | Негативное кеширование (минимум из SOA) | Мгновенно, если её никто не запрашивал; иначе от минут до примерно часа |
| Смена MX или TXT (SPF, DKIM, верификация) | Старый TTL набора записей | От минут до нескольких часов |
| Смена NS-серверов у регистратора | TTL NS-записей в зоне TLD | Несколько часов, до 24–48 часов |
| Регистрация нового домена | Публикация делегирования реестром | Обычно минуты |
Строка про «новую запись» многих удивляет. Если вы или какой-то инструмент запросили app.example.com до того, как она появилась, резолверы закешировали ответ «не существует». Этот негативный ответ тоже кешируется — на срок, вычисляемый из SOA-записи зоны, как описано в RFC 2308. Не проверяйте имя хоста до того, как его создали.
Смена записей и смена NS-серверов
Изменение записей внутри одной зоны
Когда вы только правите записи — например, переносите сайт на новый сервер, обновив A-запись, — вы имеете дело с одним уровнем кеша и одним TTL. Если TTL был 300 секунд, практически все увидят новый IP примерно через пять минут. Это быстрый и предсказуемый случай — именно он происходит, если следовать нашему гиду о том, как привязать домен к VPS.
Смена NS-серверов
Смена NS-серверов переносит всю зону к другому DNS-провайдеру. Резолверы узнают, какие NS-серверы авторитативны, от серверов самой TLD, а у крупных зон эти записи делегирования обычно имеют TTL в сутки-двое. Снизить этот TTL нельзя — его задаёт реестр. Отсюда и берутся знаменитые «до 48 часов».
В этом окне одни резолверы ещё обращаются к старому провайдеру, а другие — уже к новому. Если две зоны не идентичны, посетители получают разные ответы. Безопасная схема — сначала воссоздать все записи у нового провайдера, проверить их напрямую и только потом менять NS-серверы. Если вы ещё решаете, стоит ли вообще переносить DNS, сначала прочитайте DNS Cloudflare или DNS регистратора.
Как ускорить обновление DNS на практике
Заставить чужие резолверы очистить кеш нельзя, но можно сделать так, чтобы ждать было почти нечего. Планируйте изменение так:
- Снизьте TTL заранее — минимум за один полный период старого TTL до изменения (при TTL в 1 час — за несколько часов) поставьте затрагиваемым записям 60–300 секунд.
- Подготовьте новую точку — убедитесь, что новый сервер, почтовый ящик или сервис уже корректно отвечает, чтобы обработать трафик, пришедший раньше.
- Внесите изменение — обновите запись. Поскольку кеши теперь держат её минуту-пять, переключение расходится почти сразу.
- Проверьте снаружи — опросите несколько публичных резолверов и авторитативный сервер напрямую (см. следующий раздел).
- Не выключайте старую точку сразу — оставьте старый сервер работать минимум на старый TTL плюс запас, чтобы отставшие запросы не попадали на мёртвый IP.
- Снова поднимите TTL — когда всё стабильно, верните длинное значение, например 3600, чтобы сократить число запросов и повысить устойчивость.
Как проверить обновление DNS
Начните с первоисточника: спросите авторитативный NS-сервер напрямую. Если он возвращает новое значение, ваша часть работы сделана, остальное — кеширование. Типичные команды:
dig +short example.com A @ns1.yourprovider.com— авторитативный ответ.dig +short example.com A @1.1.1.1и@8.8.8.8— что сейчас отдают два крупных публичных резолвера. TTL в полном выводеdigотсчитывается вниз; когда он дойдёт до нуля, следующий запрос получит новое значение.nslookup example.com— доступен в Windows, если dig нет.dig NS example.com +trace— проходит делегирование от корня; полезно, чтобы подтвердить смену NS-серверов на уровне TLD.
Сайты для глобальной проверки обновления DNS выполняют те же запросы из многих стран. Они удобны для наглядной картины, но помните: они отражают несколько резолверов, а не каждого провайдера.
Очистка собственных кешей
Часто устаревший ответ хранится на вашем же компьютере. Очистите кеш ОС (ipconfig /flushdns в Windows, sudo resolvectl flush-caches во многих Linux-системах, sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder в macOS), перезапустите браузер или проверьте через мобильный интернет, чтобы обойти домашний роутер.
Пример: перенос сайта на новый сервер
Допустим, вы переносите сайт со старого виртуального хостинга на новый VPS, а у A-записи сейчас TTL 3600 секунд. План переезда без простоя может выглядеть так:
- Понедельник утром: снизьте TTL записей A и www до 300 секунд. Подождите минимум час, пока истекут старые часовые кеши, или для надёжности переключайтесь на следующий день.
- Перед переключением: скопируйте файлы и базу данных на новый сервер и протестируйте сайт на новом IP через файл hosts на своём компьютере.
- Переключение: обновите A-запись. Поскольку кеши держат её максимум пять минут, трафик начинает идти на новый сервер в течение нескольких минут.
- На следующий день: когда в логах старого сервера больше не будет визитов, выключите его и верните TTL на 3600.
Для сайтов с базой данных ненадолго приостановите запись — комментарии или заказы — на время переключения; иначе последние записи, попавшие на старый сервер, могут так и не дойти до нового. Если переносите почту, примените ту же логику к MX-записям и держите старый ящик открытым ещё несколько дней.
Частые проблемы с обновлением DNS и их решения
- У вас работает, у других нет — проверьте авторитативный сервер; если там всё верно, вы ждёте кеши. Если нет — запись сохранена не в той зоне или не у того провайдера.
- Через 48 часов всё ещё старое — обычно домен использует другие NS-серверы, а не те, где вы вносили правки. Сравните NS-записи у регистратора с тем местом, где вы меняли записи.
- Почта возвращается после переезда — записи MX, SPF и DKIM не скопировали в новую зону до смены NS-серверов.
- SSL-сертификат не выпускается — проверка удостоверяющего центра попала на старый IP или её блокирует запись CAA. Дождитесь истечения TTL и повторите.
Время обновления DNS в mistREG
DNS-зона доменов, зарегистрированных в mistREG, размещается в авторитативной сети Cloudflare и управляется из панели mistREG, поэтому правки появляются на авторитативных серверах почти мгновенно. Можно выбрать любой TTL от 60 до 86 400 секунд или оставить «auto» — так описанную выше схему «сначала снизить TTL» легко соблюдать.
Записи обслуживаются в режиме DNS only: посетители получают ровно тот IP, который вы указали. Если предпочитаете свои NS-серверы, их можно задать в любой момент — тогда домен выходит из зоны на Cloudflare, и действует обычное окно обновления NS. Вы можете найти домен среди 200+ зон, прочитать FAQ или написать в поддержку в Telegram @mistnetwork либо через систему тикетов в панели. Как всегда, использование сервиса регулируется условиями провайдера.


