Як TTL вашого домену тихо саботує зміни на сайті - і ви навіть не підозрюєте
Ви змінили IP-адресу в DNS-записі, сіли чекати - і нічого не відбулося. Година. Дві. Шість. Сайт досі показує стару сторінку, клієнти пишуть в підтримку, а ви гарячково гуглите "DNS propagation stuck". Знайомо? У 90% випадків винуватець - маленьке число, яке ви ніколи свідомо не редагували. Це TTL - Time To Live. Три літери, які визначають, скільки годин (або хвилин) весь інтернет буде ігнорувати ваші зміни. І сьогодні ми розберемо цю штуку так, щоб ви більше ніколи не сиділи перед монітором, чекаючи на DNS-чудо.
Що таке TTL і чому його порівнюють із терміном придатності
Уявіть, що DNS-запис - це етикетка на молоці. TTL - це дата, до якої кожен DNS-резолвер у світі вважає інформацію свіжою. Поки "термін придатності" не вийшов, резолвер навіть не думає перевіряти, чи змінилось щось на авторитетному сервері. Він просто бере відповідь з кешу. Швидко. Тихо. І абсолютно без вашого відома.
TTL вимірюється в секундах. Значення 3600 означає одну годину. 86400 - добу. Деякі реєстратори за замовчуванням ставлять 86400 або навіть 172800 (двоє діб). Тобто після зміни А-запису частина відвідувачів побачить нову версію через 5 хвилин, а інші - через 48 годин. Це не баг. Це ваш TTL працює рівно так, як ви його залишили.
Анатомія DNS-запиту: де саме TTL вступає в гру
Коли користувач набирає вашу адресу в браузері, запит проходить ланцюжок:
- Браузерний кеш - Chrome, Firefox та інші зберігають DNS-відповіді від 60 секунд до кількох хвилин. Цей кеш ви не контролюєте напряму.
- ОС-кеш - операційна система має власний DNS-резолвер. Windows, наприклад, кешує записи незалежно від браузера.
- Рекурсивний резолвер провайдера (або Google 8.8.8.8, Cloudflare 1.1.1.1) - саме тут TTL має найбільший вплив. Резолвер запам'ятовує відповідь рівно на стільки секунд, скільки вказано у TTL.
- Авторитетний DNS-сервер - тут живе "істина". Але до нього запит дістається лише коли кеш на попередніх рівнях прострочився.
Бачите проблему? Навіть якщо ви змінили запис на авторитетному сервері, кешовані копії на тисячах рекурсивних резолверів по всьому світу живуть своїм життям. Вони не знають, що ви щось міняли. Їм все одно. Вони дивляться лише на TTL.
"TTL - це не про швидкість. Це про контроль. Хто контролює TTL, той контролює, як швидко інтернет побачить його зміни." - Paul Vixie, один з архітекторів сучасної DNS-інфраструктури
Низький чи високий TTL: порівняння, яке заощадить вам нерви
Тут немає універсальної відповіді - "ставте 300 і живіть спокійно". Вибір TTL - це завжди компроміс між швидкістю реагування та продуктивністю. Давайте порівняємо наочно.
| Параметр | Низький TTL (60-300 сек) | Середній TTL (3600 сек) | Високий TTL (86400+ сек) |
|---|---|---|---|
| Час "поширення" змін | 1-5 хвилин | ~1 година | 24-48 годин |
| Навантаження на DNS-сервер | Високе (багато запитів) | Помірне | Мінімальне |
| Швидкість завантаження для користувача | Трохи повільніше (частіше DNS-lookup) | Оптимально | Максимально швидко |
| Зручність при міграції | Ідеально | Прийнятно | Катастрофа |
| Стійкість до збоїв DNS | Низька (кеш швидко "протухає") | Середня | Висока |
Зверніть увагу на останній рядок. Якщо ваш авторитетний DNS-сервер ляже на 20 хвилин, а TTL у вас 60 секунд - через хвилину користувачі вже не зможуть потрапити на сайт. З TTL 86400 у вас є доба "запасу" в кешах по всьому світу. Це як повний бак бензину проти чверті бака - обидва варіанти працюють, але запас міцності різний.
Стратегія двох етапів: трюк, який знають досвідчені адміни
Ось рецепт, яким користуються ті, хто вже набив шишки:
За 24-48 годин до планових змін знизьте TTL до 300 секунд (5 хвилин). Дайте старому високому TTL "вимерти" з кешів. Потім зробіть потрібну зміну - переїзд на інший хостинг, зміну IP, підключення CDN. Весь інтернет побачить нову адресу максимум за 5 хвилин. Після стабілізації - поверніть TTL назад до комфортних 3600-86400.
Ця техніка називається TTL lowering before migration і вона працює безвідмовно. Але є нюанс: якщо ви забудете знизити TTL заздалегідь і одразу зміните IP - весь план летить у кошик. Старий TTL вже закешований, і резолвери ігноруватимуть вашу нову адресу стільки, скільки залишилось до "протухання".
Покроковий план:
- Перевірте поточний TTL через dig або nslookup (dig yourdomain.com +short - покаже IP, dig yourdomain.com - покаже TTL у відповіді)
- Знизіть TTL до 300 у DNS-панелі і зачекайте період, що дорівнює старому TTL
- Виконайте заплановану зміну (IP, CNAME, MX - що завгодно)
- Переконайтесь, що все працює коректно протягом 2-4 годин
- Поверніть TTL на робоче значення (3600 для більшості сайтів - золота середина)
Типові записи та їхні оптимальні TTL
Не всі DNS-записи заслуговують однакового TTL. А-запис для лендінгу, який живе на одному сервері роками, і MX-запис для пошти - це зовсім різні ситуації.
A та AAAA записи для стабільних сайтів - 3600-14400 секунд (1-4 години). Це дає баланс між продуктивністю і гнучкістю. Для сайтів, що використовують DNS-фейловер (автоматичне перемикання на резервний сервер) - 60-300 секунд. Так, це створює навантаження на DNS, але дозволяє перемикатись між серверами за хвилини.
MX записи для пошти - 3600-86400. Поштові сервери змінюються рідко, а висока кешованість зменшує ризик тимчасової недоступності пошти при збоях DNS.
TXT записи (SPF, DKIM, DMARC) - 3600. Вони важливі для автентифікації пошти, і якщо ви помилились у SPF-записі, то з TTL 86400 ваші листи будуть падати в спам цілу добу.
CNAME записи - 3600-43200. Зверніть увагу: CNAME додає ще один DNS-запит у ланцюжок (браузер спочатку резолвить CNAME, потім А-запис цілі). Занадто низький TTL подвоює навантаження.
Інструменти для перевірки TTL: довіряй, але верифікуй
Теорія - це чудово, але як побачити реальний TTL вашого домену прямо зараз?
У терміналі Linux/Mac:
dig yourdomain.com - шукайте число в секції ANSWER, третя колонка. Це залишок TTL у кеші конкретного резолвера, через який ви питаєте. Запустіть команду двічі з інтервалом 10 секунд - число зменшиться на 10. Так ви побачите "зворотний відлік" наживо.
Онлайн-інструменти, які я рекомендую:
- whatsmydns.net - показує, як ваш домен резолвиться з десятків точок по всьому світу. Незамінний при міграції.
- dnschecker.org - аналог, але з детальнішою інформацією про TTL кожного резолвера.
- MXToolbox - найкращий для перевірки MX, SPF, DKIM з поточними TTL.
Порада, яку мало хто дає: перевіряйте TTL не через свій звичний резолвер (він може мати кешовану відповідь), а через свіжий. Наприклад, dig @1.1.1.1 yourdomain.com - запит напряму до Cloudflare DNS, або dig @8.8.8.8 yourdomain.com - до Google.
Колись TTL врятував мені проєкт о третій ночі
Справжня історія. Клієнт переїжджав із одного хостинг-провайдера на інший. Менеджер проєкту "забув" попередити мене, і TTL залишився на рівні 86400. О другій ночі змінили А-запис. О третій - паніка: половина користувачів бачить старий сайт, половина - новий, а на старому сервері вже вимкнули базу даних. Помилки 500 сипались як конфеті.
Виправити ситуацію вдалось тільки тимчасовим увімкненням старого сервера назад і правильним зниженням TTL. Увесь "переїзд" розтягнувся на три дні замість двох годин. Три дні. Через одне число, яке ніхто не перевірив.
Золоте правило: будь-яка DNS-міграція починається з перевірки TTL, а не зі зміни IP. Запам'ятайте це як мантру.
А тепер чесне питання до вас: ви знаєте, який TTL стоїть у записах вашого домену прямо зараз? Якщо ні - відкрийте термінал і наберіть dig. П'ять секунд - і ви вже розумієте свою DNS-інфраструктуру краще, ніж 80% власників сайтів. Може, саме ці п'ять секунд врятують вас від безсонної ночі.