DNS-запись проходит через несколько кешей с разным оставшимся временем хранения
Сети

TTL и кеш DNS: когда изменения увидят посетители

Объясняем TTL, положительный и отрицательный DNS-кеш, подготовку к смене адреса, проверку авторитетного ответа и безопасный возврат.

Содержание

После смены IP-адреса один посетитель уже видит новый сайт, а другой продолжает попадать на старый сервер. Обычно это не случайное «распространение DNS», а работа кешей: каждый резолвер хранит прежний ответ до окончания разрешённого срока.

TTL задаёт этот срок в секундах. Чтобы перенос прошёл предсказуемо, уменьшайте TTL заранее, держите старый сервер доступным и отличайте авторитетный ответ от данных, оставшихся в кеше.

Зачем DNS кеширует ответы

Без кеша рекурсивному резолверу пришлось бы повторять полный поиск для каждого открытия страницы. Кеш сокращает задержку и нагрузку на авторитетные серверы. Получив запись, резолвер сохраняет её вместе со временем жизни.

TTL расшифровывается как time to live — время жизни. В DNS это число секунд, в течение которых запись разрешено использовать без повторного обращения к источнику. Например, TTL 3600 допускает хранение ответа один час.

Отсчёт начинается в конкретном кеше в момент получения записи. Если один резолвер запросил её 50 минут назад, он покажет оставшиеся 10 минут. Другой резолвер мог обратиться только что и сохранит ответ почти на полный час. Поэтому посетители переходят на новый адрес не одновременно.

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

Новое значение не сокращает уже сохранённый срок

Предположим, у A-записи был TTL 86400 секунд, то есть сутки. Вы одновременно меняете IP и устанавливаете TTL 300. Резолвер, который получил старую запись утром, имеет право использовать её до конца прежних суток. Новые пять минут он увидит только после следующего обращения к авторитетному серверу.

Поэтому TTL уменьшают до переноса. Последовательность выглядит так:

  1. выберите временный TTL, который поддерживает DNS-провайдер;
  2. установите его у записи, которую будете менять;
  3. подождите как минимум прежний TTL, чтобы старые кеши успели обновиться;
  4. подготовьте и проверьте новый сервер;
  5. измените адрес;
  6. поддерживайте старую площадку во время перехода;
  7. после стабильной работы верните обычный TTL.

Слишком низкое значение на постоянной основе увеличивает число запросов к авторитетным серверам и зависимость от их доступности. Слишком высокое замедляет аварийную смену. Универсальной цифры нет: учитывайте стабильность адреса, возможности DNS-провайдера и план восстановления.

Кешируется и отсутствие записи

DNS может сохранить ответ, что имени не существует. Такой ответ называется NXDOMAIN. Также кешируется ситуация, когда имя есть, но записи запрошенного типа нет. Это отрицательное кеширование: оно не означает блокировку, а предотвращает повторение одинаковых бесполезных запросов.

Практический пример: вы сначала открыли api.example.com, получили сообщение об отсутствии имени, а затем создали запись. Некоторое время тот же резолвер может продолжать возвращать старый отрицательный ответ. Срок определяется служебной записью SOA зоны и правилами стандартов DNS, а не TTL новой A-записи, которой раньше не существовало.

Не пытайтесь исправить такой случай многократным удалением и созданием записи. Сначала убедитесь, что авторитетные серверы уже дают верный ответ, затем учтите отрицательный кеш.

Отличайте источник данных от кеша

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

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

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

Смена DNS-серверов добавляет кеш делегирования. Тогда старые резолверы могут обращаться к прежним NS, поэтому старую и новую зоны временно держат одинаковыми. Порядок разобран в статье о делегировании домена.

Очистка своего устройства решает только локальную часть

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

Смена рекурсивного DNS-сервера тоже показывает состояние другого кеша, а не ускоряет весь интернет. Такой тест помогает сравнить ответы. Он не доказывает, что каждый пользователь уже видит новый адрес.

Для проверки сайта до публичного переключения лучше использовать служебный адрес площадки или локальное сопоставление имени с IP на тестовом компьютере. Не публикуйте новый DNS только для того, чтобы увидеть, работает ли ещё не проверенный сервер.

План возврата нужен до смены адреса

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

Для сайта с изменяемыми данными одного DNS недостаточно: записи пользователей могли разойтись между двумя площадками. Перенос базы и файлов требует отдельного плана синхронизации. TTL управляет поиском адреса, а не целостностью данных.

Перед изменением проверьте типы записей A, AAAA и CNAME, а после — доступность HTTP и HTTPS на обоих адресах. Общая последовательность подключения описана в уроке о подключении домена к хостингу.

Источники

Рекламное местоВаша компания здесьРазместить рекламу

Самопроверка

Проверьте, что материал усвоен

Ответьте на все вопросы. Результат сохранится только в этом браузере и будет учтён в статистике прочитанных материалов.

01Когда нужно уменьшать TTL перед плановым переносом?
02Где сначала проверяют новую DNS-запись?
03Что такое отрицательное кеширование?

Разбираем коротко

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

Что означает TTL 3600 в DNS-записи?

Это разрешённое время кеширования в секундах: 3600 секунд равны одному часу. Конкретный кеш отсчитывает оставшееся время с момента получения ответа.

Можно ли мгновенно очистить DNS-кеш у всех посетителей?

Нет. Владелец может исправить авторитетную зону и очистить собственные устройства, но не управляет каждым рекурсивным резолвером в интернете.

Почему новый поддомен не находится после его создания?

Предыдущий ответ NXDOMAIN мог быть сохранён как отрицательный кеш. После исправления зоны нужно учитывать его срок, заданный параметрами SOA и правилами резолвера.