Срок годности ответа
Когда вы меняете DNS-запись, вступление изменений в силу занимает время, и виноват в этом TTL (time to live). Это число секунд, которое записано в каждом ответе и сообщает резолверам: этот ответ можно хранить столько-то. Пока срок не вышел, резолвер отдаёт клиентам запомненное значение и не обращается к авторитетному серверу. Механизм разумный: он снижает нагрузку и ускоряет ответы. Но оборотная сторона очевидна: новое значение появится у пользователей не сразу.
Не путайте с полем TTL в IP-пакете: там счётчик переходов, о нём есть страница ttl-paketa. В DNS тот же термин означает секунды.
Как ведёт себя кэш
Резолвер получает ответ с TTL, скажем 3600, и начинает обратный отсчёт. Каждый следующий клиент, спросивший то же самое, получает ответ с уменьшающимся значением. Когда счётчик доходит до нуля, запись удаляется, и следующий запрос снова идёт к авторитетному серверу. Поэтому разные пользователи видят обновление в разное время: у кого-то кэш истёк минуту назад, у кого-то ещё продержится почти час.
Кроме резолвера провайдера есть и другие уровни хранения: кэш операционной системы, кэш браузера, иногда кэш роутера. Они обсуждаются на странице dns-kesh. Итоговая задержка складывается из всех уровней.
Как готовить плановую смену адреса
Если переезд с одного сервера на другой запланирован, действуют заранее. За сутки-двое до изменения снижают TTL, например до 300 секунд. Ждут, пока истечёт старое, более длинное значение. Затем меняют адрес: новые ответы устареют уже через пять минут. После того как всё стабильно работает, TTL возвращают на прежний уровень. Такой порядок сводит период неопределённости к минимуму.
Если этот шаг пропустить и менять адрес при TTL в несколько часов, часть посетителей долго ходит на старый сервер. Поэтому старый узел стоит некоторое время не выключать.
Какое значение выбрать
Универсального числа нет. Короткий TTL, десятки секунд или минуты, удобен для записей, которые часто переключают: он даёт быструю реакцию, но увеличивает число запросов к авторитетным серверам. Длинный TTL, часы и сутки, подходит для стабильных записей вроде почтовых и служебных, он уменьшает нагрузку и делает работу устойчивее при кратковременных сбоях серверов имён.
Также значение TTL есть у отрицательных ответов, когда имя не найдено: они кэшируются на срок, заданный в записи SOA, и это объясняет, почему только что созданный поддомен иногда не открывается.
Как увидеть TTL
Команда dig example.com A показывает в ответе колонку с числом секунд. Повторите запрос через несколько секунд: если вы обращаетесь к кэширующему резолверу, число уменьшится. Запрос напрямую к авторитетному серверу покажет полное значение из зоны. Так можно понять, застряло ли обновление в кэше или запись вообще не была изменена.
Сбросить локальный кэш системы можно, но кэши провайдера и внешних резолверов вам неподвластны: остаётся дождаться их окончания срока.
Отрицательное кэширование и нюансы поведения
Отсутствующее имя тоже попадает в кэш. Ответ NXDOMAIN резолвер запоминает на срок, который определяется полем в записи SOA зоны. Поэтому только что созданная запись бывает невидимой для тех, кто спрашивал о ней минуту назад: у них в кэше «такого имени нет». Это частая причина фразы «я создал поддомен, а он не открывается».
Некоторые провайдеры и программы используют собственные ограничения: например, поднимают слишком маленький TTL до минимального порога или обрезают слишком большой. Браузеры тоже держат свой короткий кэш имён. Поэтому реальная картина на устройстве зависит от нескольких уровней сразу. Для проверки полезно получить ответ через разные резолверы и сравнить остаточные значения TTL, а затем сбросить кэш системы и браузера, чтобы исключить локальный уровень.
На практике для сайта с редкими изменениями подходит TTL от нескольких часов до суток, для записей, которые переключаются при сбоях, минуты. Главное, чтобы выбор был осознанным и соответствовал тому, как быстро вам нужно реагировать на сбой.