Почему DNS обновляется не сразу: TTL и распространение

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

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

Пока кэш не истёк, резолвер не спрашивает заново. Поэтому одни пользователи видят новый сайт, а другие — старый.

Что такое TTL

TTL (time to live) — число секунд, которое указано у каждой записи. Оно говорит резолверу: «этот ответ можно хранить столько времени».

• 300 — 5 минут;
• 3600 — 1 час;
• 86400 — сутки.

Важно: TTL работает для того значения, которое уже лежит в кэше. Если запись стояла с TTL 86400, а вы поменяли IP и одновременно поставили TTL 300, резолверы, получившие старый ответ, всё равно будут держать его до суток.

Откуда ещё берутся задержки

• Кэш браузера и ОС. Даже когда резолвер уже знает новый адрес, компьютер может помнить старый.
• Смена NS-серверов. Когда вы переносите DNS к другому провайдеру, записи NS в зоне домена верхнего уровня (.com, .uz и т. д.) имеют свой TTL, который вы не контролируете. Такая смена обычно занимает дольше, чем правка A-записи.
• Негативный кэш. Если кто-то запросил имя до того, как вы его создали, резолвер запомнил ответ «такого нет» на время, указанное в SOA-записи зоны.
• Резолверы, не соблюдающие TTL. Некоторые держат кэш дольше заявленного. Полностью на это повлиять нельзя.

Как проверить, что изменения применились

Сначала убедитесь, что новое значение отдаёт авторитетный сервер — это исключает ошибку в панели:

# узнать NS домена
dig example.com NS +short

# спросить авторитетный сервер напрямую
dig @ns1.dns-provider.com example.com A +short

Затем проверьте публичные резолверы и посмотрите, сколько TTL у них осталось:

dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

Число во втором столбце ответа — оставшиеся секунды кэша. Для быстрой картины по разным странам подходят онлайн-сервисы проверки DNS, которые опрашивают резолверы в разных регионах.

Чтобы сбросить локальный кэш:

# Windows
ipconfig /flushdns

На macOS и Linux команды зависят от версии системы — проще проверить через dig, который обходит кэш браузера.

Как подготовить плановый переезд

Если вы заранее знаете дату смены сервера, задержку можно сократить почти до нуля.

1. Посмотрите текущий TTL записей, которые будете менять.
2. Снизьте TTL до 300 секунд минимум за один старый TTL до переезда. Если стояли сутки — снижайте за сутки (лучше с запасом).
3. Дождитесь, пока старые кэши истекут. Теперь все резолверы держат запись не дольше 5 минут.
4. Поменяйте значение записи на новый адрес.
5. Держите старый сервер включённым ещё какое-то время: часть трафика может прийти туда из упрямых кэшей.
6. Верните TTL к привычному значению, когда убедитесь, что всё работает.

Частые ошибки

• Снижать TTL одновременно со сменой IP. Эффекта не будет для тех, у кого уже в кэше старое значение с большим TTL.
• Выключать старый сервер сразу после переключения. Пользователи с устаревшим кэшем увидят ошибку.
• Держать постоянно очень низкий TTL. Это увеличивает число запросов к DNS и немного замедляет первое открытие сайта. Для стабильных записей разумен TTL от часа.
• Проверять только в своём браузере. Ваш локальный кэш не показывает, что видят другие.