Скільки оновлюються DNS і як пришвидшити оновлення
Ви змінили DNS-запис — перенесли сайт на новий сервер, змінили поштовий сервіс, підключили домен до Cloudflare, — і тепер в одних відкривається новий сайт, а в інших старий. Хостинги зазвичай відповідають: «оновлення DNS триває 24–48 годин». Насправді все залежить від того, що саме ви змінили, і від одного числа, яким ви керуєте самі, — TTL. Із невеликою підготовкою звичайна зміна запису займає хвилини, а не добу.
Що насправді називають «оновленням DNS»
Інтернетом нічого не розсилається. Коли ви зберігаєте запис, авторитетні сервери імен вашого DNS-провайдера починають віддавати нове значення майже одразу. Затримка виникає через кеші. Кожен резолвер, що вже звертався до вашого домену, — DNS провайдера, Google Public DNS, Cloudflare 1.1.1.1, роутер в офісі, операційна система, браузер — зберігає стару відповідь, доки не сплине термін її копії, і лише тоді питає знову. «Чекати оновлення DNS» насправді означає чекати, поки ці кеші застаріють. Англійською це називають DNS propagation — «поширення».
TTL — число, яке задає очікування
Кожен DNS-запис має TTL (time to live, час життя) у секундах. Він каже резолверам, скільки можна зберігати відповідь. Запис із TTL 3600 може віддаватися з кешу до години після отримання, з TTL 86400 — до доби.
| TTL | Скільки може жити стара відповідь | Де трапляється |
|---|---|---|
| 60–300 | 1–5 хвилин | Записи, підготовлені до переїзду, балансування, проксійовані записи Cloudflare |
| 3600 | До години | Часте значення за замовчуванням у реєстраторів і хостингів |
| 14400–86400 | 4–24 години | MX, TXT і старі зони, яких давно ніхто не торкався |
| 172800 | До 2 діб | Делегування NS у зонах .com, .net і багатьох інших |
Каверза в тому, що резолвери тримають старий TTL, а не новий. Якщо в запису був TTL 86400 і ви знизили його до 300 одночасно зі зміною IP, резолвер, що отримав запис учора, зберігатиме старе значення — зі старим терміном у добу, — доки той не сплине. Про новий TTL він дізнається лише під час наступного запиту.
Чому «24–48 годин» — лише емпіричне правило
Ця цифра — найгірший випадок. Делегування серверів імен у популярних зонах на кшталт .com публікується з TTL у дві доби, а записи з довгим TTL тримаються в кеші добу. Додайте резолвери, які нав'язують власний мінімальний строк кешування або віддають прострочену відповідь, коли не можуть достукатися до ваших серверів, — і «до 48 годин» стало безпечним формулюванням для підтримки. Під час звичайної зміни запису A з TTL 300–3600 секунд більша частина інтернету, як правило, бачить нове значення в межах від кількох хвилин до години. Точного часу для кожної мережі не пообіцяє ніхто: частина резолверів дотримується TTL нестрого.
Зміна запису і зміна серверів імен — різні речі
Це дві різні операції, і оновлюються вони по-різному.
- Зміна запису (A, AAAA, CNAME, MX, TXT) у зоні, якою ви вже користуєтеся: чекати треба старий TTL цього запису. Його ви повністю контролюєте.
- Зміна серверів імен (перенесення DNS до іншого провайдера, підключення домену до Cloudflare): ви змінюєте NS у реєстратора, реєстратор передає їх до реєстру доменної зони, а резолвери, які вже знають старе делегування, тримають його до закінчення TTL записів NS у батьківській зоні — для .com це до двох діб. Цей TTL ви не контролюєте.
Безпечний спосіб змінити сервери імен — зробити зону однаковою в обох провайдерів до перемикання: перенести всі записи A, AAAA, CNAME, MX і TXT (зокрема SPF, DKIM і рядки підтвердження сайту), змінити NS у реєстратора і не видаляти стару зону щонайменше дві доби. Тоді неважливо, до якого провайдера звернеться резолвер, — відповідь буде правильною. Якщо ввімкнено DNSSEC, плануйте зміну запису DS за інструкціями обох провайдерів: DS, що не збігається з ключами нового провайдера, ламає домен для резолверів із валідацією.
Негативне кешування: «не знайдено» теж кешується
Якщо хтось запитав new.example.com до того, як ви створили запис, резолвери закешували відповідь «не існує» (NXDOMAIN). Скільки її зберігати, визначає запис SOA зони — береться менше з TTL самого SOA та його поля minimum. Тому спершу створюйте записи, а потім перевіряйте: запит імені «подивитися, чи вже працює» до його створення може змусити чекати довше.
Як пришвидшити: заздалегідь знизити TTL
- За добу або раніше до зміни знизьте TTL записів, які збираєтеся змінювати (наприклад, A та AAAA), до 300 секунд.
- Перечекайте старий TTL. Переконайтеся, що публічні резолвери більше не показують для цих записів TTL понад 300.
- Внесіть зміну. Більшість резолверів підхопить нове значення приблизно за п'ять хвилин.
- Не вимикайте старий сервер щонайменше добу. Частина провайдерів і корпоративних мереж ігнорує короткі TTL і ще якийсь час надсилатиме відвідувачів туди. Для пошти старий сервер має приймати листи принаймні протягом старого TTL запису MX — нові записи перевірте в перевірці MX.
- Поверніть TTL назад до 3600 або вище, коли все стабілізується: так менше навантаження на DNS і вища стійкість.
Локальні кеші: очистьте їх, перш ніж панікувати
Часто інтернет уже оновився, а відстає лише ваш комп'ютер. Очистьте кеші між вами та резолвером:
| Де | Команда або дія |
|---|---|
| Windows | ipconfig /flushdns у командному рядку від імені адміністратора |
| macOS | sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder |
| Linux із systemd-resolved | resolvectl flush-caches |
| Chrome, Edge | chrome://net-internals/#dns → «Clear host cache»; потім #sockets → «Flush socket pools» |
| Firefox | about:networking#dns → «Clear DNS Cache» |
| Роутер | Перезавантажте: багато домашніх роутерів тримають власний DNS-кеш |
Перевірте й файл hosts (C:\Windows\System32\drivers\etc\hosts або /etc/hosts): забутий рядок у ньому перекриває будь-який DNS. А якщо браузер використовує власний «безпечний DNS», браузер і командний рядок можуть показувати різне. У Google Public DNS і Cloudflare 1.1.1.1 є вебсторінки, де можна запросити оновлення кешу для конкретного імені; кеш провайдера так не очистити, але можна тимчасово перемкнути пристрій на публічний резолвер.
Як перевірити оновлення DNS
Скористайтеся перевіркою поширення DNS. Вона паралельно опитує набір публічних резолверів DNS-over-HTTPS та авторитетні сервери імен вашої зони. Читати результат так:
- Авторитетні сервери віддають нове значення, частина публічних резолверів — старе — усе налаштовано правильно, ці резолвери чекають кінця TTL. Залишок TTL у кожному рядку приблизно показує, скільки ще.
- Авторитетні сервери ще віддають старе значення — зміна не збереглася, внесена не в ту зону або ви редагуєте DNS у провайдера, яким домен не користується. Перевірте записи NS і дані реєстратора у WHOIS.
- Авторитетні сервери відповідають по-різному — зона розсинхронізована між ними, це проблема на боці провайдера.
З командного рядка dig example.com @8.8.8.8 питає один публічний резолвер, а dig example.com @ns1.your-dns-provider.com — безпосередньо ваш авторитетний сервер. Усі записи домену разом покаже DNS Lookup, а на яку IP дивиться сайт — перевірка IP за доменом. Типи записів розібрано у статті перевірка DNS-записів домену, а практичні способи дізнатися адресу сайту — у статті як дізнатися IP-адресу сайту.