Mist Network

Сколько обновляются DNS: реальное время и как его ускорить

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

Обновлено: 6 мин чтения
Схема обновления DNS: кеши резолверов сбрасывают старые записи по истечении TTL

Время обновления DNS (его ещё называют распространением DNS) — это задержка между сохранением изменения и моментом, когда все резолверы в интернете начинают отдавать новый ответ. При обычной правке записи это, как правило, от нескольких минут до старого TTL записи; при смене NS-серверов — до 24–48 часов, потому что записи делегирования в родительской зоне кешируются дольше.

Слово «распространение» немного вводит в заблуждение. Ничего не рассылается по интернету. Ваш авторитативный DNS-сервер знает новое значение в ту же секунду, как вы нажали «сохранить». Ждёте вы того, чтобы тысячи независимых кешей — у провайдеров, публичных резолверов, роутеров и операционных систем — выбросили сохранённый ранее ответ и запросили его заново.

Почему изменения DNS не применяются мгновенно

Каждый ответ DNS несёт TTL (time to live) — число секунд, в течение которых резолвер может повторно использовать ответ, не спрашивая снова. Если у вашей A-записи был TTL 3600, когда резолвер провайдера посетителя её запросил, этот резолвер может отдавать старый IP до часа после изменения, как бы быстро ни работал ваш DNS-провайдер.

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

Главное: время обновления определяется TTL, который был опубликован до изменения, а не тем, что вы ставите в момент изменения. Снизьте его заранее — и само переключение станет быстрым.

Сколько обновляются 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 на практике

Заставить чужие резолверы очистить кеш нельзя, но можно сделать так, чтобы ждать было почти нечего. Планируйте изменение так:

  1. Снизьте TTL заранее — минимум за один полный период старого TTL до изменения (при TTL в 1 час — за несколько часов) поставьте затрагиваемым записям 60–300 секунд.
  2. Подготовьте новую точку — убедитесь, что новый сервер, почтовый ящик или сервис уже корректно отвечает, чтобы обработать трафик, пришедший раньше.
  3. Внесите изменение — обновите запись. Поскольку кеши теперь держат её минуту-пять, переключение расходится почти сразу.
  4. Проверьте снаружи — опросите несколько публичных резолверов и авторитативный сервер напрямую (см. следующий раздел).
  5. Не выключайте старую точку сразу — оставьте старый сервер работать минимум на старый TTL плюс запас, чтобы отставшие запросы не попадали на мёртвый IP.
  6. Снова поднимите TTL — когда всё стабильно, верните длинное значение, например 3600, чтобы сократить число запросов и повысить устойчивость.
Совет: при смене NS-серверов держите старую DNS-зону онлайн и идентичной минимум 48 часов после переключения. Слишком раннее удаление — самая частая причина жалоб «сайт пропал у части пользователей».

Как проверить обновление 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» легко соблюдать.

60–86 400 сдиапазон TTL на выбор
20поддерживаемых типов записей
< 60 сзапуск VPS после оплаты

Записи обслуживаются в режиме DNS only: посетители получают ровно тот IP, который вы указали. Если предпочитаете свои NS-серверы, их можно задать в любой момент — тогда домен выходит из зоны на Cloudflare, и действует обычное окно обновления NS. Вы можете найти домен среди 200+ зон, прочитать FAQ или написать в поддержку в Telegram @mistnetwork либо через систему тикетов в панели. Как всегда, использование сервиса регулируется условиями провайдера.

Частые вопросы

Сколько обновляются DNS?
Правки записей обычно расходятся от нескольких минут до старого TTL записи — чаще всего от 5 минут до часа. Смена NS-серверов может занять до 24–48 часов, потому что записи делегирования в зоне TLD кешируются дольше.
Можно ли принудительно ускорить обновление DNS?
Очистить чужие кеши нельзя, но можно заранее снизить TTL записи до 60–300 секунд. Тогда само изменение разойдётся за несколько минут. Очистка кеша на своём устройстве поможет увидеть его раньше.
Почему я вижу сайт на новом сервере, а другие нет?
Разные резолверы закешировали старую запись в разное время, поэтому их копии истекают в разное время. Проверьте авторитативный NS-сервер напрямую: если там новое значение, остаётся только дождаться истечения кешей.
Смена NS-серверов занимает больше времени, чем смена A-записи?
Да. Смена A-записи зависит от TTL, которым управляете вы. Смена NS-серверов зависит от NS-записей, опубликованных реестром TLD, а их TTL часто составляет от одних до двух суток.
Какой TTL лучше ставить для DNS-записей?
300 секунд — разумное значение, если ожидаются изменения; для стабильных записей подойдёт 3600 секунд и больше. Снижайте TTL перед переездом и поднимайте после.

Похожие статьи

Mist NetworkMist Network