Снижение TTL перед миграцией сайта: зачем это нужно и как сделать

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

Что на самом деле регулирует TTL

TTL (Time To Live) — это число в секундах, которое прикреплено к каждой DNS-записи. Когда резолвер провайдера или офисный роутер получает ответ о вашем домене, он хранит его в кеше указанное время и повторно не спрашивает. Если у записи A TTL равен 86400, ответ может не обновляться целые сутки. В обычные дни это полезно: меньше запросов, быстрее открывается сайт, ниже нагрузка на DNS-сервер.

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

Как узнать текущее значение

Прежде чем что-то менять, выясните текущие TTL. Надёжнее всего спрашивать авторитативный сервер домена напрямую: промежуточные резолверы показывают уже уменьшающийся остаток. Команды ниже работают в Linux, macOS и WSL на Windows:

# На каких NS-серверах находится домен
dig NS example.uz +short

# Запись A и её TTL с авторитативного сервера
dig @ns1.example.uz example.uz A +noall +answer

# SOA: последнее поле задаёт кеширование отрицательных ответов
dig @ns1.example.uz example.uz SOA +noall +answer

Второй столбец в ответе — это TTL. Проверьте не только основной домен, но и www, mail и другие поддомены: у них нередко свои значения. Последнее поле SOA определяет, сколько кешируется ответ «такого имени нет», что важно, если во время переезда вы добавляете новые поддомены.

Пошаговый план

Возьмём для примера ташкентский интернет-магазин одежды на домене example.uz. TTL записи A — 86400, переезд запланирован на субботнее утро. Правильная последовательность выглядит так:

1. В четверг утром, то есть минимум за 24 часа, снизьте TTL записей A и www до 300. IP-адрес пока остаётся старым, меняется только TTL.
2. В пятницу проверьте авторитативный сервер и пару публичных резолверов: везде TTL должен быть 300 или меньше.
3. В субботу перенесите файлы и базу, проверьте сайт по новому IP.
4. Если всё в порядке, переключите запись A на новый IP. В течение пяти минут большинство посетителей окажутся на новом сервере.
5. После одного-двух дней стабильной работы верните TTL на 3600 или выше.

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

Проверка нового сервера до смены DNS

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

# Linux/macOS: /etc/hosts, Windows: C:\Windows\System32\drivers\etc\hosts
203.0.113.25  example.uz www.example.uz

# Или без правки файла, через curl
curl -I --resolve example.uz:443:203.0.113.25 https://example.uz/

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

Типичные ошибки

Самая частая ошибка — снижать TTL в ту же минуту, когда меняется IP. Пользы от этого почти нет, ведь резолверы держат ответ, сохранённый со старым длинным TTL. Вторая ошибка — изменить только основной домен и забыть про www: example.uz уходит на новый сервер, а www.example.uz остаётся на старом, и заказы разъезжаются по двум базам.

Третья ошибка связана с почтой. Если MX-запись тоже переезжает, заранее снизьте и её TTL, а старый почтовый ящик не удаляйте сразу: часть писем какое-то время может приходить туда. Наблюдайте за обоими ящиками несколько дней. И наконец, не стоит забывать низкий TTL навсегда: это создаёт лишние DNS-запросы и иногда немного замедляет первое открытие сайта.

Смена NS-серверов — отдельный случай

Описанный план полностью работает, когда записи A, CNAME и MX остаются на том же DNS-сервере и меняется лишь их значение. Если же вы переносите домен на совершенно другие NS-серверы, всё сложнее. NS-записи хранятся уровнем выше, в реестре зоны .uz, и их TTL вы не контролируете. В таком случае безопаснее заранее полностью скопировать все записи на новый DNS-сервер и не отключать старый на время переходного периода.

В кабинете sayt.uz при редактировании DNS-записей домена можно указать и TTL. Если переезд запланирован, возьмите за правило менять это поле за сутки до него.

Какое значение когда уместно

Ставить меньше 60 секунд не рекомендуется: некоторые резолверы игнорируют слишком маленький TTL и применяют собственный минимум. 300 секунд на практике достаточно быстро и одинаково работает везде. Следуя этому простому правилу, вы проведёте следующий переезд почти незаметно для клиентов.