Проверка распространения 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 онлайн

Инструмент показывает, обновились ли 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-записей».