Аналоги WhatsMyDNS: проверка DNS propagation

WhatsMyDNS.net — популярный сервис для проверки DNS propagation: обновилась ли DNS-запись (A, CNAME, MX, TXT) на публичных резолверах по всему миру. Нужен после смены хостинга, IP или почтовых настроек. Минусы: только английский, нет русских резолверов в приоритете, нет смежных проверок.

Честно: у WhatsMyDNS больше точек проверки по всему миру (20+ локаций) — если нужна максимально широкая география распространения, он покрывает больше стран.

• Меняли хостинг/IP и хотите проверить обновление с приоритетом на Россию и СНГ;
• Нужен русский интерфейс;
• Хотите заодно посмотреть все DNS-записи через DNS Lookup.

• DNSChecker.org — похожая проверка, много локаций;
• dig / nslookup — из терминала, но проверяют только ваш резолвер;
• Google Dig (toolbox) — проверка через резолвер Google.

Ничего не распространяется. Никакая волна обновлений не бежит по интернету. Происходит вещь более узкая и понятная: каждый рекурсивный резолвер, который раньше отвечал на запрос по вашему имени, закэшировал ответ и будет отдавать старое значение, пока не истечёт выданный ему TTL. Независимо от всех остальных резолверов.

Из одного этого факта следует всё, что обычно вызывает вопросы:

• Разные точки показывают разное. Это не частичное выкатывание — просто резолверы закэшировали в разные моменты, и TTL у них истекают в разные моменты.
• Ускорить после правки нельзя. Ожиданием управляет TTL, привязанный к старой записи, и он был роздан ещё до вашей правки. Снижение TTL сейчас повлияет на следующее изменение, а не на это.
• «48 часов» — фольклор. Реальный потолок — TTL старой записи. Было 300 секунд — ждёте пять минут. Кто-то поставил 86400 — ждёте сутки, и это не сократит ни один сервис, ни одно обращение в поддержку.

То есть чекер не измеряет прогресс. Он снимает состояние кэшей фиксированного набора публичных резолверов на текущий момент — это полезно, но это другое, чем обещает название.

Длительность ожидания определяется до правки, а не после. Последовательность, которая его убирает:

1. Сначала снизить TTL и выждать старый. Поставьте записи 300 секунд и подождите не меньше длительности предыдущего TTL, чтобы все кэшированные копии со старым значением успели протухнуть.
2. Только теперь менять саму запись. С этого момента худший случай — пять минут, потому что именно столько последний раз сказали резолверам.
3. После — вернуть TTL обратно. Постоянно низкий TTL означает больше запросов и более тяжёлый отказ, если у DNS-провайдера случится сбой.

Пропуск первого шага — и есть причина, по которой переезд «занимает сутки». Сделать его стоит одного дополнительного ожидания, запланированного заранее, вместо незапланированного прямо во время переключения.

Частый и сбивающий с толку случай: глобальный чекер показывает новое значение везде, а на ноутбуке по-прежнему открывается старый сайт. Чекер спрашивает публичные резолверы напрямую, а ваша машина идёт через несколько кэшей, которых чекер вообще не касается.

• Кэш операционной системы. Отдельный и от браузера, и от резолвера.
• Собственный кэш браузера. У Chrome он свой, и жёсткая перезагрузка его не чистит.
• Роутер или корпоративный резолвер. Часто именно он виноват, и нередко со своим длинным TTL.

Проверьте dig @1.1.1.1 example.com, затем dig example.com: если первое верно, а второе нет — устаревшая копия лежит между вами и интернетом, а не в DNS вообще.