Перевірка поширення DNS онлайн

Як ми перевіряємо — і чого ця перевірка не показує

Запити йдуть із нашого сервера до 15 публічних резолверів різних операторів через DNS-over-HTTPS і напряму до авторитетних NS домену. Більшість публічних DNS працюють за anycast: на запит відповідає точка присутності, найближча до нашого сервера, а не сервери в різних країнах. Тому це порівняння «як домен бачать різні публічні DNS», а не перевірка «з 30 країн світу».

Резолвер вашого інтернет-провайдера, роутера та кеш вашого комп’ютера ми не бачимо: вони можуть тримати стару відповідь, навіть коли всі публічні DNS уже оновилися. Результат кешується на 60 секунд.

Чому зміна DNS «розходиться» до 24–48 годин

Нове значення з’являється на авторитетних NS майже одразу після збереження в панелі. Але кожен резолвер, який уже запитував запис, тримає стару відповідь у кеші до кінця її TTL і лише потім питає знову. При TTL 3600 це до години, при 86400 — до доби.

Найдовше триває зміна NS-серверів у реєстратора: делегування в доменній зоні (.com, .ua, .pl…) часто кешується на 1–2 доби. Звідси й звичні «24–48 годин». Подробиці, як пришвидшити переїзд і скинути локальний кеш, — у посібнику нижче.

Інструмент показує, чи оновилися DNS-записи домену в різних публічних резолверів. Ми паралельно опитуємо 15 сервісів (Google Public DNS, Cloudflare, Quad9, OpenDNS, AdGuard, NextDNS, Control D, Mullvad, DNS.SB, AliDNS, DNS4EU, SWITCH, CZ.NIC, Яндекс, IIJ) через DNS-over-HTTPS і напряму — авторитетні NS зони. Для кожної відповіді видно значення, залишковий TTL і час відповіді; однакові відповіді згруповано, розбіжності підсвічено. Можна вказати очікуване значення — наприклад, новий IP — і одразу побачити, хто його вже віддає. Перевірка безкоштовна, результат кешується на 60 секунд.

15 публічних DNS-резолверів різних операторів, опитування паралельно за 1–2 секунди

Прямий запит до авторитетних NS домену — еталон, з яким порівнюються решта

Типи записів A, AAAA, CNAME, MX, TXT, NS, SOA і CAA, зокрема піддомени на кшталт www і _dmarc

Залишковий TTL у кожного резолвера й оцінка, скільки ще може триматися стара відповідь

Групування однакових відповідей і підсвічування розбіжностей

Поле «очікуване значення»: позначка в кожного резолвера, чи віддає він уже новий IP або запис

Як користуватися

Введіть домен або піддомен (можна вставити адресу сторінки — візьмемо з неї ім’я хоста)
Оберіть тип запису й, якщо потрібно, впишіть очікуване значення — наприклад, новий IP сервера
Порівняйте відповіді з авторитетними NS; якщо частина резолверів відстає, натисніть «Перевірити знову» пізніше — орієнтир дає їхній TTL

FAQ

Ні, і ми її такою не видаємо. Усі запити йдуть із нашого сервера, а більшість публічних DNS працюють за anycast і відповідають із найближчої до нього точки. Інструмент показує, як домен бачать різні оператори DNS і самі авторитетні сервери домену — цього досить, щоб зрозуміти, чи розійшлася зміна.

Не довше за попередній TTL цього запису: резолвери, що закешували старе значення, перезапитають його після спливання TTL. Зміна NS у реєстратора триває довше — до 24–48 годин, бо делегування в доменній зоні кешується на одну-дві доби.

Так працюють CDN, балансувальники та GeoDNS: авторитетний сервер віддає різні адреси залежно від того, хто питає, або по колу. Якщо авторитетні NS у нашому звіті теж відповідають по-різному, розбіжність — норма, а не проблема поширення.

Стару відповідь тримає DNS вашого провайдера, роутер, операційна система або браузер — їх ми перевірити не можемо. Скиньте кеш DNS на комп’ютері й у браузері або тимчасово перейдіть на публічний DNS; як це зробити, описано в посібнику на цій сторінці.

До 6 перевірок на хвилину з одного IP і добовий ліміт безкоштовних перевірок; після безкоштовної реєстрації він утричі більший. Повторний запит того самого домену й типу протягом 60 секунд віддається з кешу й добовий ліміт не витрачає.

Що таке поширення DNS і чому записи оновлюються не одразу

«Поширення DNS» — неточний, але усталений термін. Записи нікуди не розсилаються: після збереження в панелі нове значення майже одразу з’являється на авторитетних NS-серверах вашої зони. Затримку створюють кеші. Кожен резолвер (DNS провайдера, Google, Cloudflare, роутер, операційна система, браузер), який уже запитував ваш домен, зберігає стару відповідь до кінця її TTL і лише потім питає знову. Тому перевірка оновлення DNS — це завжди питання «в кого в кеші ще старе значення».

У звіті вище це видно напряму: рядок авторитетних NS показує поточне значення зони, рядки публічних резолверів — що вони віддають користувачам просто зараз. Якщо NS уже віддають нове значення, а частина резолверів — старе, ви нічого не зламали: треба дочекатися, поки в них спливе TTL.

TTL: як прочитати і скільки чекати

TTL (time to live) — кількість секунд, на яку резолвер може закешувати запис. На авторитетному сервері ви бачите повний TTL, у публічного резолвера — залишок: скільки секунд він ще віддаватиме те, що вже знає.

TTL	Скільки живе стара відповідь	Де трапляється
60–300	1–5 хвилин	Cloudflare з проксуванням (Auto = 300), записи перед переїздом, балансування
3600	до години	значення за замовчуванням у багатьох реєстраторів і хостингів
14400–86400	4–24 години	MX, TXT, NS; старі зони, де TTL ніхто не змінював
172800	до 2 діб	NS-делегування в зоні .com/.net і багатьох інших доменних зонах

Важлива деталь: чекати треба за старим TTL. Якщо запис жив із TTL 86400, а ви разом зі зміною IP поставили 300, резолвери, що отримали відповідь учора, однаково триматимуть її до доби — нове значення TTL вони дізнаються лише під час наступного запиту.

Окремо кешуються негативні відповіді. Якщо ви відкрили new.example.com до того, як створили запис, резолвер запам’ятає NXDOMAIN на час із запису SOA зони (менше з TTL самого SOA і поля minimum). Ці значення видно, якщо обрати тип SOA в інструменті.

Як пришвидшити зміну A-запису (переїзд на новий сервер)

За добу (точніше — не пізніше ніж за один старий TTL) знизьте TTL A/AAAA-записів до 300.
Дочекайтеся, поки в публічних резолверів у звіті TTL перестане бути більшим за 300: отже, старий довгий TTL відпрацював.
Змініть IP. У поле «очікуване значення» впишіть нову адресу й перевіряйте: за 5–10 хвилин майже всі резолвери мають її віддавати.
Не вимикайте старий сервер ще добу: провайдери й корпоративні мережі, які ігнорують короткий TTL, якийсь час надсилатимуть відвідувачів туди.
Коли все стабільно, поверніть TTL до 3600 або вище.

З поштою так само: під час зміни MX старий поштовий сервер має приймати листи щонайменше протягом старого TTL MX-запису. Перевірити результат допоможуть перевірка MX-записів і перевірка SPF — під час переїзду пошти SPF часто забувають оновити.

Зміна NS-серверів: чому 24–48 годин і як пережити переїзд

Під час зміни DNS-провайдера ви змінюєте NS у реєстратора. Реєстратор передає їх у реєстр доменної зони зазвичай за хвилини чи годину, але резолвери, які вже знають старе делегування, тримають його до кінця TTL NS-записів у батьківській зоні — у .com це 172800 секунд, тобто дві доби. Поки кеш не сплив, частина відвідувачів питає старі NS, частина — нові.

Звідси головне правило: на старому й новому DNS-провайдері зона має бути однаковою весь час переїзду. Перенесіть усі записи (A, AAAA, CNAME, MX, TXT з SPF/DKIM/верифікаціями) на новий провайдер до зміни NS, а стару зону не видаляйте щонайменше дві доби. Тоді неважливо, до якого NS потрапить резолвер, — відповідь буде правильною.

Як перевірити: оберіть тип NS — публічні резолвери покажуть, яке делегування в них у кеші. Потім тип SOA: у ньому видно, який сервер указано головним (mname), і серійний номер зони. Якщо авторитетні NS у звіті відповідають по-різному, зона на них не синхронізована. Що записано в реєстратора, покаже WHOIS домену.

Cloudflare: помаранчева хмара і «чужі» IP у відповідях

Якщо запис у Cloudflare проксується (помаранчева хмара), резолвери віддають IP-адреси Cloudflare, а не вашого сервера, з TTL 300. Тому під час зміни сервера за Cloudflare поширення DNS чекати не треба: ви змінюєте IP origin у панелі, публічні адреси лишаються тими самими, і Cloudflare починає ходити на новий сервер майже одразу. Ваш реальний IP у звіті з’явиться, лише якщо перемкнути запис у режим «DNS only» (сіра хмара) — робити це заради перевірки не варто, так ви розкриєте адресу origin.

Зворотна ситуація: домен щойно підключили до Cloudflare, а у звіті в частини резолверів попередній IP хостингу. Це не помилка Cloudflare, а старі NS у кеші — дивіться розділ про зміну NS вище.

Чому в провайдера досі старий IP

Кеш провайдера. Деякі провайдери піднімають мінімальний TTL або віддають застарілу відповідь, якщо не можуть швидко отримати нову (serve-stale, RFC 8767). Цей резолвер ми не бачимо, тож у звіті може бути все зелене, а у вас — старий сайт.
Кеш пристрою та браузера. Windows, macOS і браузери тримають власний кеш DNS.
Файл hosts. Запис у C:\Windows\System32\drivers\etc\hosts або /etc/hosts, що лишився після тестів, перекриває будь-який DNS.
Захищений DNS у браузері. Якщо в Chrome увімкнено «Безпечний DNS», браузер питає обраного провайдера, а не системний DNS — результати в браузері й у командному рядку можуть різнитися.

Як скинути кеш DNS: Windows, macOS, Linux, Chrome

Windows (командний рядок від імені адміністратора):

ipconfig /flushdns

macOS (Термінал):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux із systemd-resolved:

resolvectl flush-caches

Chrome: відкрийте chrome://net-internals/#dns і натисніть «Clear host cache», потім на вкладці chrome://net-internals/#sockets — «Flush socket pools». У Firefox — about:networking#dns, кнопка «Clear DNS Cache».

Кеш великих публічних резолверів можна попросити оновити для конкретного імені: у Google Public DNS є сторінка Flush Cache, у Cloudflare 1.1.1.1 — Purge Cache. Кеш вашого провайдера так не скинути: лишається дочекатися TTL або тимчасово прописати публічний DNS у налаштуваннях мережі.

Повний список записів домену одним запитом показує DNS Lookup, а що означає кожен тип запису — розібрано в статті про перевірку DNS-записів.