DNS Checker

Сделайте baseline lookup перед любой сменой NS, переносом у регистратора или переключением почтового провайдера. Зафиксируйте в тикете A, AAAA, MX, TXT (SPF, DKIM, DMARC), NS и SOA вместе с текущими TTL и временной меткой. После cutover выполните тот же lookup и сравните ответы построчно. SOA serial у многих провайдеров растёт при изменении zone file — учитывайте это, когда support утверждает, что «propagation завершена», а на ноутбуке всё ещё старые маршруты почты.

Используйте DNS Checker при подключении SaaS, который просит verification TXT, при отладке доставляемости после ротации SPF или DKIM, при проверке CAA перед выпуском сертификатов или когда orange-cloud CDN меняет anycast A-ответы. Проверка dns records online быстрее установки bind-utils на заблокированных корпоративных ноутбуках и полнее, чем ping или nslookup — они не показывают MX, TXT и CAA в одном структурированном виде. Для команд без root-доступа это часто единственный быстрый способ собрать полную картину зоны.

Сочетайте полный lookup с WHOIS, если само делегирование под вопросом: если NS у регистратора не совпадают с публично возвращаемыми NS, вы можете править неактивную DNS-панель, пока мир опрашивает прежний хост. Для трассировки одного типа (только MX, только TXT, только NS) DIG на том же сайте возвращает answer section в формате резолвера — удобно вставлять в треды поддержки без переформатирования. Сохраняйте экспорт ответов в change ticket, чтобы через неделю не восстанавливать baseline из памяти.

Если DNS Checker показывает значения, не совпадающие с панелью управления, сначала сравните NS. Возможно, вы в child-zone editor, а apex делегирован elsewhere. Опросите авторитетные NS через DIG @ns1.example.com, когда рекурсивные кэши «врут» — наш checker использует настроенный резолверный путь и отражает то, что видит большинство посетителей, а не обязательно authoritative file секунду после Save.

TTL определяет, как долго живут старые ответы. Запись с TTL 86400 может до суток исчезать из каждого резолвера мира даже после исправления. За 24–48 часов до плановой смены снизьте TTL на стабильных записях, подтвердите меньший TTL через DNS Checker, примените новые данные, затем снова поднимите TTL после стабилизации. Не путайте «изменение сохранено в панели» с «ответ уже обновился у всех резолверов» — это разные события во времени.

Дублирующие SPF TXT на одном owner name полностью инвалидируют SPF — объедините include в одну строку. CNAME на метке, где также есть MX или TXT, недопустим по правилам DNS и даёт непредсказуемое поведение резолверов. DMARC без согласованных SPF или DKIM фиксирует сбои, но не исправляет их; относитесь к DMARC как к политике поверх работающей аутентификации, а не замене.

Географический anycast и proxied CDN могут возвращать разные A или AAAA в зависимости от локации резолвера. Это ожидаемо, а не баг propagation. При отладке маршрутизации к origin сравните grey-cloud и orange-cloud в DNS-панели и повторно запустите DNS Checker с того же резолверного пути после каждого переключения.

Входящая почта зависит от приоритетов MX и достижимости hostname обменников. Репутация исходящей — от SPF, DKIM и DMARC TXT на предсказуемых именах. DNS Checker группирует MX и TXT в одном ответе: можно подтвердить, что mail.example.com резолвится, что на apex только один SPF, что selector._domainkey публикует актуальный ключ, и что _dmarc.example.com задаёт нужную политику (none, quarantine или reject).

После onboarding Google Workspace, Microsoft 365 или любого SMTP relay проверьте все четыре семейства записей до массовой рассылки. Рабочая MX не означает корректный SPF — сравните исходящие SMTP IP с цепочкой include и документацией провайдера. Копируйте точный склеенный TXT из checker, а не перепечатывайте из PDF; разбитые в панели DKIM-строки в DNS-ответе склеиваются.

Когда заголовки Authentication-Results показывают spf=fail или dkim=fail, перезапросите live TXT через DNS Checker, исправьте зону, зафиксируйте TTL и дождитесь истечения кэша перед повторным тестом. Если deferrals сохраняются при чистой DNS-аутентификации, используйте Blacklist Checker для sending IP — DNS закрывает prerequisites доставляемости, но не заменяет работу с репутацией IP.

Этот инструмент показывает DNS-записи, которые возвращает наш resolver прямо сейчас — полный all-records lookup, включая TXT для DKIM и DMARC, сгруппированный по типам с кнопками копирования. Он для проверки конфигурации, документирования миграций и ответа на вопрос «что публичное DNS-дерево показывает для этого имени сегодня?» Он не строит карту мира различий резолверов и не претендует на одновременную проверку пятидесяти глобальных локаций.

Специализированные DNS propagation checker опрашивают множество региональных рекурсивных резолверов во времени и визуализируют, где ещё кэшируются старые A, MX или NS. Такой worldview помогает после крупных TTL-heavy изменений или смены NS, когда support спрашивает «уже propagated?» DN01 не копирует эту карту — мы фокусируемся на одном качественном снимке плюс история, API и companion tools (DIG, WHOIS, SSL) на том же сайте.

Propagation — не мгновенная телепортация. Это истечение старых кэшей по TTL плюс обновление glue у регистратора при смене NS. Низкий TTL в authoritative зоне ускоряет будущие изменения, но не может retroactively сбросить ответы, уже закэшированные на 86400 секунд. Используйте DNS Checker, чтобы подтвердить authoritative publish, затем propagation maps, если нужна географическая уверенность, что резолверы в разных регионах истекли старые данные.

Когда ответы расходятся между DNS Checker и propagation map, оба могут быть «правы» для своей точки наблюдения. Рекурсивные резолверы кэшируют независимо; офисный DNS, мобильный оператор и 8.8.8.8 могут расходиться до истечения TTL. Опросите authoritative NS напрямую через DIG, когда нужно полностью обойти кэш — если authoritative NS уже показывает новый MX, а checker ещё старый, вы наблюдаете cache lag, а не failed publish.

Выбирайте DN01, когда нужны все основные типы записей в одном окне, локализованный UI на восьми языках, локальная недавняя история и документированный API для автоматизации. Выбирайте propagation maps, когда вопрос именно «какие регионы ещё видят прежний IP?» — а не «верны ли мои строки MX и SPF?» Мы честны об этой границе: никакой fake propagation percentage bar и simulated global grid — только точные, удобные для копирования DNS-данные для операторов, которым нужно надёжно выпускать изменения почты, веба и сертификатов. Эта честная граница помогает не тратить время на ложные сигналы «99% propagated», когда MX или SPF всё ещё неверны.