DNS Windows 10Windows 11

DNS-запись с большим TTL задерживает переход сайта на новый сервер

  • Обновлено
  • Чтение ≈ 2 минуты

Краткий ответ

TTL у DNS-записи показывает, сколько секунд рекурсивный сервер вправе хранить полученный ответ. Если большой TTL был установлен ДО смены IP, уменьшение его уже после смены обычно не удаляет старые ответы из существующих кэшей. При плановом переносе TTL уменьшают заранее, выдерживают старый срок, затем меняют IP.

В этой статье
  1. Что происходит и как отличить проблему
  2. Возможные причины
  3. Пошаговая проверка и устранение
  4. Проверка результата и дальнейшие действия

#Что происходит и как отличить проблему

TTL у DNS-записи показывает, сколько секунд рекурсивный сервер вправе хранить полученный ответ. Если большой TTL был установлен ДО смены IP, уменьшение его уже после смены обычно не удаляет старые ответы из существующих кэшей. При плановом переносе TTL уменьшают заранее, выдерживают старый срок, затем меняют IP.

#Возможные причины

Возможная причинаКак узнатьЧто делать
Большой TTL старой записиПровайдер держит старый адрес законное время.Ответы расходятся, а у старого ответа TTL постепенно уменьшается.Дождаться истечения ранее заданного TTL.
План переноса не учёл кэшTTL снижен уже одновременно со сменой адреса.На авторитетном сервере новый TTL, но часть пользователей видит старый IP.При следующем переносе снижать TTL заранее.

#Пошаговая проверка и устранение

  1. Проверьте, что изменяли именно текущую зонуОткройте панель своего DNS-провайдера и найдите нужное имя, тип A/AAAA и нынешний TTL. Сверьте адрес с ожидаемым. Отдельно проверьте у регистратора, что NS указывают на этого поставщика. Если владелец сайта вы не вы, изменения на этом шаге не выполняйте: попросите администратора прислать дату и прежние значения.
  2. Посмотрите оставшийся TTL у рекурсивного сервераВ Windows откройте PowerShell через Win+X → «Терминал» без повышенных прав. Выполните Resolve-DnsName -Name www.example.com -Type A -Server 1.1.1.1 -DnsOnly, заменив домен своим. Найдите запись с TTL и IP; через некоторое время повторите. TTL относится к данному ответу и серверу, а не является гарантией синхронизации интернета по единому таймеру.
  3. Различите старую и новую записьПовторите такой же запрос к другому DNS, например к 8.8.8.8, и запишите оба IP. Если один возвращает старый IP, не заставляйте всех пользователей очищать кэш: на них влияет ещё и кэш провайдера. Убедитесь, что новый сервер уже обслуживает сайт, а старый остаётся готовым принимать остаточные обращения.
  4. Измените TTL правильно при следующей миграцииЗа время не меньше текущего старого TTL до следующей запланированной смены адреса откройте DNS-зону и, если поставщик это разрешает, установите небольшой TTL, например 300 секунд. Сохраните, дождитесь прежнего срока, проверьте актуальный TTL несколькими запросами, только затем меняйте A/AAAA. У записей, проходящих через прокси, TTL может назначаться автоматически.
  5. Проверьте результат и восстановите спокойный режимДождитесь максимального старого времени хранения; в этот период следите за обращениями на оба сервера и их журналами. Когда рекурсивные DNS показывают новый IP и посетители открывают сайт, верните разумный TTL для стабильной работы. Если часть пользователей всё ещё попадает на старый сайт после ожидаемого срока, проверьте IPv6, дополнительные A и CDN.

#Проверка результата и дальнейшие действия

Смена завершена, когда авторитетные ответы согласованы, рекурсивные кэши перестали отдавать старый IP, а сайт доступен по имени. Разные TTL у разных провайдеров и задержки их кэшей возможны; точный момент появления нового адреса у всех предсказать нельзя.

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.