DNS-пропагація: чому ваш новий домен не працює і коли панікувати насправді
Ви щойно купили домен, прив'язали його до хостингу, все налаштували правильно - а сайт не відкривається. Колега каже, що у нього все працює. Телефон показує стару сторінку. Ноутбук - помилку. І ви сидите, дивитесь на екран і думаєте: «Я щось зламав». Знайома ситуація? Ласкаво просимо у світ DNS-пропагації - процесу, який змусив понервуватись навіть досвідчених адмінів. Давайте розберемось, що насправді відбувається між натисканням кнопки «Зберегти» і моментом, коли весь світ бачить ваш сайт.
Що таке DNS-пропагація і чому вона нагадує пошту XVIII століття
Уявіть, що ви переїхали на нову адресу і відправили листи всім знайомим з повідомленням. Хтось отримає його за день, хтось - за три, а тітка Галя з села дізнається через тиждень. DNS-пропагація працює приблизно так само, тільки замість листів - оновлення DNS-записів, а замість знайомих - тисячі DNS-серверів по всьому світу.
DNS (Domain Name System) - це, по суті, телефонна книга інтернету. Коли ви вводите example.com, ваш браузер запитує DNS-сервер: «Яка IP-адреса у цього домену?» Сервер відповідає, і ви потрапляєте на потрібний сайт. Проблема в тому, що цих DNS-серверів - не один і не два. Їх мільйони.
Коли ви змінюєте DNS-записи (наприклад, переносите домен на новий хостинг), оновлення мусить «дістатись» до кожного з цих серверів. І кожен має свій кеш - тимчасову пам'ять, де зберігається стара інформація. Поки кеш не оновиться, частина користувачів бачитиме стару версію сайту. Це і є DNS-пропагація - період, поки всі DNS-сервери планети дізнаються про ваші зміни.
TTL - таймер, який ви ігноруєте, а він вирішує все
Є один параметр, про який новачки зазвичай навіть не знають, а досвідчені фахівці іноді забувають. Це TTL - Time to Live. Саме він визначає, скільки секунд DNS-сервер зберігатиме вашу стару запис у кеші, перш ніж запитає оновлену.
Типовий TTL за замовчуванням - 86400 секунд. Це 24 години. Тобто якщо ви змінили A-запис домену, деякі сервери перевірять оновлення лише через добу. Але ось хитрість, яку знають не всі:
«Якщо ви знаєте, що плануєте міграцію, зменште TTL до 300-600 секунд за 24-48 годин ДО зміни. Тоді після оновлення DNS-записів пропагація займе хвилини, а не години.» - рекомендація Cloudflare у документації для розробників
Простими словами: знизьте TTL заздалегідь - і ваша міграція пройде майже непомітно. Підвищте TTL назад після завершення - і зменшите навантаження на DNS-сервери.
- За 48 годин до міграції встановіть TTL на 300 секунд (5 хвилин)
- Переконайтесь, що старий TTL «протух» - зачекайте попередній період TTL
- Зробіть зміну DNS-записів
- Перевірте пропагацію через сервіси моніторингу (про них нижче)
- Через 24-48 годин поверніть TTL до 3600-86400 секунд
Типи DNS-записів: яка різниця і що змінювати
Не всі DNS-записи однакові. І не всі впливають на пропагацію однаково. Ось коротка карта, щоб ви не заблукали.
| Тип запису | Що робить | Коли змінюється | Типовий час пропагації |
|---|---|---|---|
| A | Прив'язує домен до IPv4-адреси | Переїзд на новий сервер | 1-48 годин |
| AAAA | Прив'язує домен до IPv6-адреси | Переїзд або додавання IPv6 | 1-48 годин |
| CNAME | Псевдонім одного домену на інший | Піддомени, CDN | 1-24 години |
| MX | Вказує поштовий сервер | Зміна пошти (Google Workspace, Zoho) | 1-48 годин |
| NS | Вказує на DNS-сервери домену | Зміна DNS-провайдера | 24-72 години |
| TXT | Текстові дані (SPF, DKIM, верифікація) | Налаштування пошти, верифікація | 1-24 години |
Зверніть увагу: зміна NS-записів займає найбільше часу - до 72 годин. Це тому, що інформація про nameсервери зберігається на рівні реєстру доменної зони (.ua, .com тощо), а не тільки у вашого провайдера. Саме тому перенесення домену між DNS-провайдерами - найболючіший процес.
Інструменти перевірки: як перестати гадати і почати бачити
Оновлювати сторінку кожні 30 секунд і питати у колег «а у тебе працює?» - не стратегія. Це невроз. Є набагато кращі способи відстежити, як просувається пропагація.
- whatsmydns.net - показує, що бачать DNS-сервери у 30+ країнах. Безкоштовно, наочно, працює за секунди.
- dnschecker.org - аналогічний інструмент з більшою кількістю точок перевірки та підтримкою всіх типів записів.
- dig та nslookup - командний рядок для тих, хто не боїться терміналу. Дозволяє запитувати конкретні DNS-сервери напряму.
- Google Admin Toolbox Dig - веб-версія dig від Google. Зручна, якщо ви працюєте з планшета чи чужого комп'ютера.
Порада з практики: відкрийте whatsmydns.net, введіть ваш домен, оберіть тип запису (зазвичай A) - і побачите мапу світу з зеленими та червоними маркерами. Зелені - сервери, які вже «побачили» нову адресу. Червоні - ще тримають стару. Коли все зелене - можна видихнути.
А ще є лайфхак для нетерплячих. Якщо ваш комп'ютер досі показує стару версію сайту, спробуйте очистити локальний DNS-кеш:
- Windows: відкрийте командний рядок і введіть ipconfig /flushdns
- macOS: в терміналі виконайте sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Linux: sudo systemd-resolve --flush-caches або перезапустіть nscd
- Браузер: очистіть кеш або відкрийте сайт в інкогніто-режимі
5 помилок, через які пропагація перетворюється на кошмар
За 15 років я бачив десятки ситуацій, коли люди самі собі ускладнювали життя. Ось топ помилок, які повторюються з дивовижною стабільністю.
Помилка 1: Змінити NS і A-записи одночасно. Якщо ви переїжджаєте на новий DNS-провайдер, спочатку створіть усі потрібні записи на новому DNS, а потім змініть NS. Інакше буде період, коли нові nameсервери вже відповідають за домен, але записів на них ще немає. Результат - сайт і пошта лежать.
Помилка 2: Не перевірити MX-записи після міграції. Сайт запрацював - і ви святкуєте. А пошта тихо помирає. Листи від клієнтів летять у нікуди. Перевіряйте MX-записи окремо.
Помилка 3: Забути про www-версію. У вас працює example.com, але www.example.com показує помилку. Класика. Переконайтесь, що CNAME для www вказує на правильну адресу.
Помилка 4: Паніка через 30 хвилин. Пропагація - це не миттєвий процес. Якщо TTL був 86400, чекайте відповідний час. Телефонувати в підтримку через пів години після зміни - марна трата вашого часу і нервів.
Помилка 5: Вимкнути старий сервер до завершення пропагації. Доки частина DNS-серверів ще направляє трафік на стару IP-адресу, старий сервер мусить працювати. Вимкнете його раніше - частина відвідувачів побачить помилку. Тримайте старий сервер активним мінімум 72 години після зміни DNS.
Cloudflare, Google DNS і прискорена пропагація: чи працює магія
Часто чую запитання: «Якщо я використовую Cloudflare, пропагація буде швидшою?» Коротка відповідь - частково так. Cloudflare керує DNS через свою мережу з 300+ дата-центрів і оновлює записи за секунди всередині своєї системи. Але ось нюанс: інші DNS-сервери (наприклад, DNS вашого провайдера інтернету) все одно триматимуть стару інформацію в кеші до закінчення TTL.
Тобто Cloudflare прискорює те, що може контролювати. Решту контролює TTL та кешування на чужих серверах. Це як мати найшвидшу машину, але стояти в заторі разом з усіма.
Цікавий факт: Google Public DNS (8.8.8.8) дозволяє примусово очистити кеш для конкретного домену через сторінку developers.google.com/speed/public-dns/cache. Це не вплине на всіх користувачів, але допоможе, якщо ви тестуєте через Google DNS.
А ось що дійсно допомагає прискорити весь процес:
- Зменшення TTL заздалегідь (ми вже це обговорили - але це настільки важливо, що варто повторити)
- Використання Anycast DNS-провайдерів (Cloudflare, AWS Route 53, Google Cloud DNS)
- Уникнення зміни NS-записів без крайньої необхідності
Головне правило: плануйте DNS-зміни на період мінімального трафіку. Якщо ваша аудиторія в Україні - робіть зміни о 3-4 годині ночі. Навіть якщо пропагація затягнеться, більшість користувачів цього не помітять.
DNS-пропагація - не баг, не помилка і не змова хостерів. Це фундаментальна особливість архітектури інтернету, яка існує з 1983 року. Її не можна скасувати. Але можна зрозуміти, підготуватись і перетворити 72 години невизначеності на 15 хвилин спокійного очікування. Питання лише одне: ви плануєте наступну міграцію - чи чекаєте, поки вона сама спланує ваш вихідний?