Коли ви змінюєте DNS-записи (NS-сервери, A-запис, MX), зміни не застосовуються миттєво. DNS-сервери по всьому світу зберігають кешовані записи протягом часу, вказаного в TTL.
Типовий час поширення DNS
| Тип зміни | Мінімум | Зазвичай | Максимум |
|---|---|---|---|
| Зміна NS-серверів | 30 хв | 4–8 годин | 48–72 години |
| Зміна A-запису | 5 хв | 1–4 години | 24 години |
| Зміна MX-запису | 5 хв | 1–4 години | 24 години |
| Новий CNAME/TXT | 5 хв | 15–60 хв | 4 години |
Чому DNS поширюється не миттєво
Кожен DNS-сервер кешує записи на час TTL (Time-To-Live). Поки TTL не сплив, сервер віддає старе значення з кешу, не запитуючи оновлення в авторитетного DNS.
Перевірка DNS Propagation
dig (Linux/Mac)
# Перевірити A-запис
dig example.com A
# Через конкретний DNS-сервер (Google)
dig @8.8.8.8 example.com A
# Через Cloudflare DNS
dig @1.1.1.1 example.com A
# Перевірити NS-сервери
dig example.com NSnslookup (Windows/Linux)
nslookup example.com 8.8.8.8Онлайн-сервіси
- dnschecker.org — перевірка зі 100+ точок світу
- whatsmydns.net — карта поширення
- mxtoolbox.com — перевірка MX-записів
Прискорення DNS propagation
# Скинути DNS-кеш на Windows
ipconfig /flushdns
# На macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# На Ubuntu/Debian
sudo systemd-resolve --flush-cachesЧасті повідомлення про помилки під час перевірки DNS
| Відповідь dig/nslookup | Що означає | Що робити |
|---|---|---|
;; connection timed out; no servers could be reached | Вказаний DNS-сервер недоступний або заблокований фаєрволом мережі | Перевірити інший публічний резолвер (1.1.1.1, 8.8.8.8), переконатися, що UDP/53 не заблоковано |
NXDOMAIN | Домен не існує в цій зоні — або не зареєстрований, або помилка в імені | Перевірити точне написання домену, статус реєстрації через whois |
SERVFAIL | Авторитетний DNS-сервер домену не відповідає коректно — помилка в зоні або сервер недоступний | Перевірити NS-сервери домену, конфігурацію зони на боці DNS-провайдера |
| NOERROR, але ANSWER SECTION порожній | Зона існує і відповідає, але запитаного типу запису для цього імені немає | Перевірити, що запис створено саме з потрібним типом (наприклад, шукаєте AAAA, а створено лише A) |
Що означає NOERROR із порожнім ANSWER SECTION
Це не помилка поширення — резолвер успішно зв'язався з авторитетним сервером домену й отримав відповідь «запису такого типу немає». Чекати в цьому випадку марно: потрібно створити запис, а не чекати TTL.
Коли DNS не оновиться вчасно, навіть якщо все зроблено правильно
- Резолвер інтернет-провайдера кешує записи довше за оголошений TTL — трапляється в частини мобільних операторів, які округлюють TTL до власних внутрішніх значень
- NS-сервери старого хостингу вже вимкнено до завершення TTL — резолвери, які ще не оновили кеш, отримають помилку замість нового значення
- Корпоративний DNS-сервер налаштований із власним примусовим TTL незалежно від авторитетної відповіді
- Частина публічних Wi-Fi і провайдерських DNS роками не скидає кеш для «прогрітих» популярних доменів — єдиний обхідний шлях для користувача — змінити DNS-сервер вручну на 1.1.1.1 або 8.8.8.8
Рівні DNS-кешу та їхній типовий час життя
| Рівень кешу | Типовий час життя | Як скинути |
|---|---|---|
| Кеш браузера | Приблизно 60 секунд у більшості сучасних браузерів | Перезапустити браузер або очистити кеш DNS у налаштуваннях |
| Кеш операційної системи | Дорівнює TTL запису, але не менше кількох секунд | ipconfig /flushdns (Windows), systemd-resolve --flush-caches (Linux) |
| Кеш резолвера інтернет-провайдера | Дорівнює TTL запису, іноді більше у великих провайдерів | Не скидається користувачем — лише зміна резолвера на інший (1.1.1.1, 8.8.8.8) |
| Кеш вторинних (secondary) DNS-серверів | Визначається полем Refresh у SOA-записі зони, зазвичай 3600–86400 секунд | Налаштовується лише власником зони через SOA-запис |
Повне поширення зміни завершується лише коли сплинули всі рівні кешу одночасно — тому реальний час часто більший, ніж один TTL, вказаний у записі.
На практиці зручно орієнтуватися на правило: якщо після завершення подвоєного значення старого TTL хоча б частина резолверів досі віддає старий запис — проблема не в поширенні, а в конфігурації (наприклад, забули видалити стару A-запис або NS-сервери старого хостингу вже недоступні). Такий запас у два TTL покриває майже всі випадки округлення і повторної перевірки на боці резолверів, і саме його варто закладати в план міграції, а не єдине значення TTL з документації.