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-записів A, CNAME, MX, TXT, а порядок налаштування пошти в інструкції налаштування SPF, DKIM і DMARC.
Із NS-записами окрема історія: резолвер бере час кешу делегування з батьківської зони, тому TTL у вашій зоні тут майже нічого не вирішує. Самі сервери змінюють за інструкцією як змінити DNS-сервери домену. Те саме стосується DS-запису при DNSSEC для домену: у нашому тесті резолвери віддавали SERVFAIL і після публікації правильного DS, поки в кеші жив старий запис із TTL 3600.
Знизити, перемкнути, повернути: перевірка на стенді
Ми взяли два записи з 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-сервера і нічого не виграє.
