TTL в DNS означает, сколько секунд резолвер может повторять сохранённый ответ, не спрашивая ваш DNS-сервер. Для записей, которые не меняются, ставьте 3600 секунд (час) или больше; перед переездом снизьте TTL до 300, но не позже чем за один старый TTL до переключения: если стояло 86400, то минимум за сутки. Значение, сниженное в момент смены IP, не помогает: на нашем стенде такая запись отдавала старый адрес ещё 59 минут 53 секунды.
Как мы проверяли
10 ноября 2026 года в изолированном контейнере Ubuntu 24.04 мы запустили авторитетный сервер BIND 9.18.39 и три кэширующих резолвера: Unbound 1.19.2 с настройками по умолчанию, второй Unbound с принудительными границами TTL (не меньше 300 и не больше 900 секунд) и dnsmasq 2.91 в роли «домашнего роутера». Записи меняли через nsupdate, резолверы опрашивали каждые 5-10 секунд и записывали адрес и остаток TTL; самый длинный сценарий шёл 67 минут. Нормы взяли из RFC 1035, 2181, 2308 и 8767, ограничения публичных сервисов из документации Google, Cloudflare и NLnet Labs (проверено 10.11.2026). Это тестовый стенд, а не измерения на серверах RichHost.
Что на самом деле задаёт TTL
TTL (time to live) задаётся отдельно для каждого набора записей: все A-записи одного имени имеют один TTL, а MX того же домена может иметь другой. По RFC 2181 это целое число секунд от 0 до 2147483647. Важны три вещи, которые часто путают.
- Отсчёт идёт от момента запроса, а не от момента вашего изменения. Резолвер, взявший запись в 10:00 с TTL 3600, будет держать её до 11:00, а другой, спросивший в 10:40, до 11:40. Поэтому у разных людей изменение «применяется» в разное время.
- Кэши в цепочке не складываются. Между вами и DNS-сервером могут стоять браузер, система, роутер и резолвер провайдера. На стенде роутер (dnsmasq) спросил резолвер через 40 секунд после того, как тот закэшировал запись с TTL 120, и получил не 120, а остаток 80. После изменения оба перешли на новый адрес в одну и ту же секунду.
- Поле minimum в SOA не является TTL по умолчанию. Так было в RFC 1035, но с RFC 2308 оно задаёт время негативного кэша. TTL по умолчанию в файле зоны задаёт директива
$TTLили поле TTL в панели.
Как эти кэши вместе определяют время ожидания после любого изменения DNS, мы отдельно измерили в статье о том, сколько обновляются DNS. Здесь речь о другом: какое число поставить и когда его менять.
Какое значение TTL ставить для каждого типа записи
| Запись | Обычный TTL | Перед изменениями | Что учитывать |
|---|---|---|---|
| A, AAAA, CNAME сайта | 3600 | 300 | Смена IP при переезде; в Cloudflare значение Auto равно 300 |
| MX | 3600-14400 | 300 | Пока действует старый TTL, часть писем идёт на старый сервер, значит, он должен принимать почту |
| TXT для SPF и DMARC | 3600 | 300 | Новый сервис рассылки добавляйте в SPF до того, как начнёте с него отправлять |
| TXT для DKIM | 3600 | не нужно | Новый ключ публикуйте под новым селектором заранее и не запрашивайте его до публикации |
| NS и glue | 86400 | не поможет | Действует TTL делегирования в зоне реестра (.com 172800), а не ваш |
| SOA (TTL и minimum) | 3600 и 300-3600 | 300 для minimum | Меньшее из двух чисел задаёт, сколько кэшируется ответ «записи нет» |
Очень низкий TTL на постоянной основе не ускоряет сайт: каждые N секунд каждый резолвер снова спрашивает ваш DNS-сервер, а посетитель после истечения кэша ждёт дополнительный запрос. Очень высокий TTL делает любое срочное изменение медленным. Разумная середина для большинства сайтов: 3600 в обычное время и 300 на несколько дней вокруг переезда. Что означает каждый тип записи, объяснено в статье DNS для начинающих, а порядок настройки почты в инструкции настройка SPF, DKIM и DMARC.
С NS-записями отдельная история: резолвер берёт время кэша делегирования из родительской зоны, поэтому TTL в вашей зоне здесь почти ничего не решает. Сами серверы меняют по инструкции как сменить DNS-серверы домена.
Снизить, переключить, вернуть: проверка на стенде
Мы взяли две записи с TTL 3600 и одинаковым адресом. Резолвер закэшировал обе в 15:12:10. В 15:12:20 записи late одновременно сменили IP и снизили TTL до 300, как часто делают в последний момент. Записи plan только снизили TTL до 300, а IP сменили через час, в 16:12:43. В выводе R1 означает Unbound по умолчанию, R2 Unbound с границами 300/900, а число в скобках показывает секунды от изменения.
15:12:10 R1 late.lab A NOERROR 192.0.2.10 3600 15:12:10 R1 plan.lab A NOERROR 192.0.2.10 3600 15:12:20 nsupdate: late.lab A 198.51.100.20 TTL 300; plan.lab A 192.0.2.10 TTL 300 15:27:04 R2 late.lab A NOERROR 192.0.2.10 6 15:27:15 R2 late.lab A NOERROR 198.51.100.20 300 (+895 s) 16:12:03 R1 late.lab A NOERROR 192.0.2.10 7 16:12:13 R1 late.lab A NOERROR 198.51.100.20 300 (+3593 s) 16:12:13 R1 plan.lab A NOERROR 192.0.2.10 300 16:12:43 nsupdate: plan.lab A 198.51.100.20 TTL 300 16:17:06 R1 plan.lab A NOERROR 192.0.2.10 7 16:17:16 R1 plan.lab A NOERROR 198.51.100.20 300 (+273 s)
Запись, у которой TTL снизили вместе со сменой адреса, перешла на новый сервер через 59 минут 53 секунды: резолвер честно дожидался конца старых 3600 секунд. Запись, подготовленная заранее, переключилась через 4 минуты 33 секунды после смены IP. Резолвер с границей 900 секунд перевёл late уже через 14 минут 55 секунд, так что в жизни часть посетителей увидит новый сайт раньше, а часть позже, и старый сервер должен работать до конца самого длинного TTL.
Отсюда рабочий план:
- Узнайте текущий TTL:
dig +norec @ns1.your-dns.example example.com A. Это число и есть минимальное время подготовки. - Снизьте TTL до 300 за старый TTL плюс запас: при 3600 за 2 часа, при 86400 за сутки-двое.
- Проверьте публичные резолверы:
dig @8.8.8.8 example.comдолжен показывать TTL не больше 300. - Смените IP или MX. Старый сервер не выключайте ещё минимум сутки: резолверы со своими правилами существуют.
- Через 1-2 суток верните 3600 или больше.
Перенос файлов, базы и почты пошагово описан в статье о переезде хостинга без потерь.
Резолверы, которые переписывают ваш TTL
Спецификация разрешает резолверам ограничивать TTL, и они этим пользуются. Unbound по умолчанию не держит записи дольше суток (cache-max-ttl 86400) и негативные ответы дольше часа; администратор может задать и нижнюю границу cache-min-ttl, хотя документация Unbound прямо предупреждает, что значения больше часа приводят к расхождениям с настоящими данными. Вот что отдали два резолвера на одинаковые записи:
| TTL в зоне | Unbound по умолчанию | Unbound с границами 300/900 |
|---|---|---|
| 0 | 0, новый адрес с первого запроса после изменения | 300, старый адрес ещё 4 мин 58 с |
| 30 | 30, переключился через 27 с | 300, старый адрес ещё 4 мин 58 с |
| 3600 | 3600 | 900 |
| 172800 | 86400 | 900 |
| негативный 120 | 120 | 300 |
| негативный 86400 | 3600 | 900 |
У публичных сервисов тоже есть границы. Google Public DNS в FAQ (обновлено 06.11.2026) пишет, что TTL обычно ограничен шестью часами, даже если настоящий больше. Cloudflare как DNS-хостинг не даёт поставить меньше 60 секунд (30 на тарифе Enterprise) и больше суток, а для проксируемых записей TTL всегда 300. Вывод: TTL ниже 60-300 секунд не гарантирует более быстрого переключения, а TTL больше 6 часов часть мира всё равно обрежет.
Негативный кэш: запись, которой ещё не было
Если кто-то запросил имя до того, как вы его создали, резолвер запоминает ответ «нет» (NXDOMAIN) или «имя есть, но такого типа нет» (NODATA). По RFC 2308 это время равно меньшему из двух чисел: TTL самой SOA и поля minimum. Сервер BIND сразу отдаёт в негативном ответе уже вычисленное значение:
dig @127.0.21.10 new.neg1.lab +norec (SOA TTL 3600, minimum 300) status: NXDOMAIN neg1.lab. 300 IN SOA ... 1 7200 3600 1209600 300 dig @127.0.21.10 new.neg2.lab +norec (SOA TTL 120, minimum 3600) status: NXDOMAIN neg2.lab. 120 IN SOA ... 1 7200 3600 1209600 3600 15:12:21 R1 new.neg2.lab A NXDOMAIN SOA-ttl 120 15:12:26 nsupdate: add new.neg1.lab A, new.neg2.lab A, www.neg1.lab AAAA 15:14:26 R1 new.neg2.lab A NOERROR 198.51.100.20 300 15:17:24 R1 new.neg1.lab A NOERROR 198.51.100.20 300 15:17:24 R1 www.neg1.lab AAAA NOERROR 2001:db8::20 3600
Новая запись в зоне с негативным TTL 120 появилась через 2 минуты, в зоне с 300 через 4 минуты 58 секунд. То же касается NODATA: когда мы добавили AAAA-запись к уже существующему имени, IPv6-адрес появился только после истечения негативного кэша. RFC 2308 советует 1-3 часа как типовое значение, но если вы часто добавляете поддомены или публикуете TXT-записи для подтверждения сервисов, minimum 300 удобнее. Как отличить такой кэш от настоящего отсутствия записи, показано в разборе ошибки DNS_PROBE_FINISHED_NXDOMAIN. Ещё одна ловушка: резолвер с нижней границей поднял негативные 120 секунд до 300.
Кэш браузера и операционной системы
Между вами и резолвером есть ещё два уровня. Chromium, получая адрес через системный резолвер, держит его 60 секунд, а во встроенном резолвере следует TTL, но не меньше минуты (по объяснению Эрика Лоуренса, 2022). Сбросить этот кэш можно кнопкой Clear host cache на странице chrome://net-internals/#dns, в Firefox кнопкой на about:networking#dns. Кэш системы тоже живёт по TTL: в Windows ipconfig /displaydns показывает остаток для каждой записи, а в Linux с systemd-resolved кэш сбрасывает resolvectl flush-caches. Эти кэши короткие и обычно не виноваты в часовых задержках; настоящую задержку даёт резолвер провайдера или публичный DNS, который вы не можете очистить со своего компьютера.
Если X, делайте Y
| Ситуация | Что делать |
|---|---|
| Переезд через неделю, сейчас TTL 86400 | Сегодня снизьте A и MX до 300, переключайте не раньше чем через сутки |
| Переезд уже завтра, а TTL 86400 | Снизьте сейчас и перенесите переключение на сутки; если нельзя, держите старый сервер рабочим ещё сутки |
| Меняете почтовый сервер | MX 300 заранее, старый сервер принимает письма ещё старый TTL, потом проверьте, не осталось ли там писем |
| Добавляете новый сервис рассылки | Сначала обновите SPF, отправляйте с нового сервиса не раньше чем через TTL TXT-записи |
| Меняете ключ DKIM | Новый селектор публикуйте за сутки до переключения, старый удаляйте через неделю |
| Часто создаёте поддомены | minimum в SOA 300, не проверяйте имя до того, как создали запись |
| Меняете NS-серверы | TTL записей не поможет; ждите TTL делегирования в зоне реестра |
| Записи годами не меняются | 3600-86400 для A и MX, 86400 для NS |
| Хотите TTL 0 или 10 «для скорости» | Ставьте не меньше 60: резолвер с нижней границей всё равно поднимет значение |
Если вы переносите сайт на новый хостинг, например на тарифы RichHost, снизьте TTL у старого DNS-провайдера до того, как начнёте копировать файлы: пока идёт перенос, старое значение как раз успеет истечь.
Частые вопросы
Почему я снизил TTL до 300, а изменения всё равно шли час?
Потому что резолверы закэшировали запись ещё со старым TTL 3600 и держат её до конца. Новое значение они увидят только при следующем запросе. Снижать нужно за один старый TTL до изменения.
Можно ли поставить TTL 0?
Можно, Unbound по умолчанию тогда не повторяет ответ из кэша. Но резолвер с нижней границей на стенде отдавал такую запись ещё 300 секунд после изменения, а часть DNS-хостингов не разрешает меньше 60.
Как узнать, сколько ещё проживёт старый ответ?
Спросите нужный резолвер, например dig @8.8.8.8 example.com: число во второй колонке ответа показывает остаток TTL в его кэше. Настоящий TTL записи виден в запросе к вашему DNS-серверу с +norec.
Влияет ли TTL на скорость сайта?
Мало. Дополнительный DNS-запрос посетитель делает не чаще раза за TTL, и браузер его кэширует. Разница между 300 и 3600 для обычного сайта почти незаметна, поэтому 3600 в спокойное время вполне нормальное значение.
Нужно ли возвращать TTL после переезда?
Да, через 1-2 суток, когда убедитесь, что возвращаться на старый сервер не придётся. 300 навсегда не вредит, но даёт лишние запросы к DNS-серверу и ничего не выигрывает.
