Що таке DNS propagation
Після зміни DNS-запису сервери по всьому світу кешують старе значення до закінчення TTL. Це називається DNS propagation — поширення може зайняти від 5 хвилин до 48 годин.
Термін трохи вводить в оману: насправді нічого нікуди активно не «поширюється». Ваш авторитетний сервер віддає нове значення одразу після збереження запису. Затримка виникає лише там, де чужий резолвер — у інтернет-провайдера, у браузері, в операційній системі — встиг закешувати стару відповідь і справно віддає її повторним запитам, поки не спливе TTL запису, який був встановлений ДО зміни.
Перевірка через командний рядок
# Перевірка A-запису
dig yourdomain.com A
# Перевірка через Google DNS
dig @8.8.8.8 yourdomain.com A
# Перевірка через Cloudflare DNS
dig @1.1.1.1 yourdomain.com A
# Швидка відповідь без кешу
nslookup yourdomain.com 8.8.8.8
# Повний шлях резолвінгу від кореневих серверів до вашого
dig +trace yourdomain.com AОстання команда корисна, коли незрозуміло, на якому саме етапі ланцюжок ламається: вона показує, до яких серверів резолвер звертався послідовно — від кореневих через сервер зони верхнього рівня до авторитетних NS вашого домену — і на якому кроці відповідь розійшлася з очікуваною.
Онлайн-інструменти
| Інструмент | Застосування |
|---|---|
| whatsmydns.net | Перевірка з 20+ локацій світу |
| dnschecker.org | Глобальна перевірка всіх типів записів |
| mxtoolbox.com | MX, SPF, DKIM, blacklist перевірки |
| intodns.com | Повний аналіз DNS-зони |
Різниця між цими сервісами і локальним dig у тому, що вони опитують резолвери з десятків країн одночасно і показують карту факту поширення, а не просто одну відповідь із найближчого до вас сервера. Це зручно, щоб зрозуміти, чи поширилася зміна глобально, чи затримка стосується лише вашого провайдера.
Як прискорити оновлення DNS
- Очистити DNS-кеш браузера:
ipconfig /flushdns(Windows),sudo dscacheutil -flushcache(macOS) - Очистити кеш на Linux:
systemd-resolve --flush-caches - Перевірити через мобільний інтернет (інший DNS-resolver)
Окрема пастка — негативне кешування. Якщо домен раніше не існував і резолвер уже отримав відповідь NXDOMAIN, цей негативний результат теж кешується — за RFC 2308 на термін, заданий полем minimum у записі SOA зони. Щойно створений запис може бути не видно рівно з цієї причини, а не через звичайний TTL.
Типові повідомлення при перевірці DNS
| Повідомлення | Значення | Дія |
|---|---|---|
| ;; connection timed out; no servers could be reached (dig) | Резолвер недоступний або вказано невірний IP DNS-сервера | Перевірити, що 8.8.8.8 відповідає взагалі, спробувати інший резолвер |
| ** server can't find yourdomain.com: NXDOMAIN (nslookup) | Ім'я ще не існує в зоні або в ньому одруківка | Перевірити точне написання імені та наявність запису в панелі |
| ;; ANSWER: 0 у виводі dig | Запитаний тип запису відсутній для цього імені — наприклад, AAAA за відсутності IPv6 | Це нормально, якщо запис такого типу справді не створювався |
| Chrome: DNS_PROBE_FINISHED_NXDOMAIN | Або запис ще не поширився, або домен не делегований | Перевірити dig NS і в реєстратора, і в хостингу |
У виводі dig три розділи відповідають за різні речі: ANSWER — самі запитані записи, AUTHORITY — які сервери вважаються авторитетними для цієї зони, ADDITIONAL — допоміжні записи на кшталт IP цих серверів. Якщо ANSWER порожній, а AUTHORITY заповнений записом SOA, це означає: зона існує, але саме такого запису в ній немає — це NXDOMAIN для конкретного типу, а не для домену загалом.
Скільки реально чекати за типом зміни
| Що змінювали | Типовий час | Від чого залежить |
|---|---|---|
| A/AAAA-запис із TTL 3600 | до 1 години плюс кеш резолверів | старий TTL запису до зміни |
| NS-делегування (зміна серверів імен) | від 2 до 48 годин | TTL запису NS у батьківській зоні, зазвичай 1–2 дні |
| MX-запис | до кількох годин | TTL запису і кеш поштових серверів-відправників |
| Реєстрація нового домену | від 15 хвилин до кількох годин | швидкість публікації в реєстрі зони |
Коли пропагація ні до чого
- Правки внесено не в тій зоні, де реально стоїть делегування — домен на зовнішніх NS, а редагували в іншій панелі
- Браузер або ОС тримають власний DNS-кеш довше за TTL запису — очищення кешу вирішує миттєво, пропагація тут ні до чого
- CDN або проксі, наприклад Cloudflare в режимі Proxied, віддає свій IP замість вашого — це очікувана поведінка, а не затримка поширення
- Одруківка в самому записі — скільки не чекай, правильна відповідь не з'явиться, потрібна повторна перевірка конфігурації, див. перевірку DNS-зони через dig
Часті питання
Якщо забули знизити TTL перед зміною DNS, чи можна щось зробити постфактум, щоб пришвидшити перемикання?
Знизити TTL вже після зміни можна, але ефекту це не дасть негайно: резолвери, які встигли закешувати старий запис зі старим терміном життя, усе одно продовжать віддавати його до спливання саме того терміну. Нове, коротше значення TTL почне працювати лише для запитів, які потраплять у кеш вже після зміни, тому реального пришвидшення варто чекати з наступного циклу оновлення.
Якщо онлайн-інструмент на кшталт whatsmydns.net показує оновлений результат, чи гарантує це, що у вашого інтернет-провайдера буде те саме?
Ні, такий інструмент опитує безліч резолверів по світу, але не обов'язково саме той, яким користується ваш провайдер цієї миті. Локальний резолвер міг закешувати стару відповідь раніше і віддаватиме її до спливання власного TTL незалежно від того, що показують зовнішні перевірки, тому остаточним підтвердженням лишається перевірка з пристрою, під'єднаного через потрібного вам провайдера.
Чи може затримка поширення призводити до втрати листів, чи вона стосується лише вебтрафіку?
Затримка стосується будь-якого сервісу, що спирається на DNS-запис, включно з поштою: якщо MX-запис змінився, а сервер відправника ще пам'ятає старе значення, лист спробує піти за колишньою адресою і або затримається, або повернеться відправнику з помилкою доставки. Тому зміну MX-запису варто планувати так само ретельно, як зміну A-запису сайту, і заздалегідь знижувати TTL.
Чи небезпечно змінювати DNS-записи у робочий час, чи це варто робити лише вночі?
Сама по собі пора доби не відіграє ролі — важливіше заздалегідь знизити TTL і не змінювати водночас кілька пов'язаних параметрів на кшталт NS-делегування і адреси сайту. Нічне вікно має сенс не через особливості DNS, а через меншу видиму активність: якщо щось піде не так, наслідки помітить менше відвідувачів, поки триває діагностика і відкат змін.