Мы привыкли считать, что если сервер доступен и SSL в порядке — значит, всё под контролем. Но иногда сбой происходит раньше, ещё до того, как запрос дошёл до сервера.

Меня зовут Михаил Шпаков, я создаю и развиваю сервис мониторинга Statuser.

Недавно я общался с руководителем IT-отдела одной компании, которая использует Statuser для мониторинга своих сервисов. Он поделился интересным кейсом: несколько часов подряд у них перестала отправляться почта с корпоративного домена. Сайт работал, сервер был доступен, SSL-сертификат в порядке — всё зелёное, а письма не уходят. Проблема выглядела случайной: часть писем доставлялась, часть возвращалась с ошибкой, а из-за этого срывались заказы и возникали прямые убытки.

Когда их команда начала разбираться, выяснилось, что недавно один из сотрудников сменил почтового провайдера и добавил новые MX-записи в DNS, но старые при этом не удалил. В результате часть писем уходила на старый сервер, который уже не принимал почту, а часть — на новый. Снаружи всё выглядело исправно, но на деле домен был «раздвоен» между двумя почтовыми системами.

После этого разговора я понял, что в Statuser не хватает отдельного типа мониторинга — контроля DNS-записей. HTTP, SSL и Ping могут быть зелёными, но если в DNS остались старые MX, сервис уже фактически неисправен.

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

❯ Как это устроено под капотом

Снаружи идея кажется простой: периодически получать DNS-ответы и искать различия. Но даже такой процесс сталкивается с массой нюансов — от непостоянных ответов серверов до временных расхождений между зонами.

Проверки в Statuser периодически получают актуальные записи выбранных типов — A, AAAA, CNAME, MX, TXT, NS, PTR, SRV, SOA — и сохраняют их как «снимок состояния» домена.

Перед сравнением ответы проходят нормализацию: значения сортируются, очищаются от лишних пробелов и преобразуются к единому формату.

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

Когда приходит новый результат, Statuser сравнивает нормализованные данные с предыдущим снимком и определяет, какие записи действительно изменились, появились или исчезли.

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

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

1. Отложенные уведомления.

При первом обнаружении изменения Statuser не спешит с уведомлением — система делает паузу на 15 минут, чтобы убедиться, что результат действительно устойчивый.

За это время ответы от разных NS успевают выровняться: если один из серверов временно отдал неполные или кэшированные данные, расхождение исчезает само.

2. Подтверждение изменением в нескольких циклах.

Уведомление отправляется только после трёх последовательных подтверждений, что новая запись действительно закрепилась и больше не меняется.

Это также позволяет отсеять флаппинг и короткие периоды рассинхронизации между серверами.

3. Сравнение SOA serial.

Если зона поддерживает SOA-запись, Statuser использует её как дополнительный индикатор версии.

Если serial не изменился — значит, зона, скорее всего, не обновлялась, и найденные отличия стоит считать временными.

Это позволяет фиксировать только реальные изменения — например, добавление новой MX-записи или замену IP-адреса — без лишнего шума.

В итоге снаружи всё выглядит просто: Statuser показывает, когда и какие DNS-записи изменились. Но под капотом — множество проверок, которые отсекают случайный шум и оставляют только подтверждённые изменения.

❯ Что показал запуск

С момента запуска прошло совсем немного времени, но первые клиенты уже начали подключать мониторинг DNS и делиться обратной связью.

Фича быстро нашла своё место: кто-то использует её, чтобы отслеживать изменения при миграции на новый хостинг, кто-то — чтобы контролировать стабильность внешних DNS-провайдеров.

Пользователи делятся кейсами, где мониторинг помог заметить изменения, о которых они не знали.

Например, один клиент обнаружил, что DNS-провайдер при автоматическом обновлении зоны добавил лишнюю служебную запись, из-за чего ответы начали различаться между NS-серверами.

Другой заметил, что после переноса домена часть записей сохранилась из старой конфигурации и несколько часов возвращала устаревшие значения.

Появились и предложения по развитию — собираю идеи и планирую, какие из них можно будет реализовать в следующих обновлениях.

DNS — одна из тех вещей, о которых вспоминают только во время сбоя.

Мониторинг этого уровня помогает замечать ошибки и подмены ещё до того, как они превращаются в простои и потери.

❯ В заключении

Спасибо, что дочитали до конца.

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

Сейчас мониторинг DNS доступен в платных тарифах Pro и Team, но после регистрации можно активировать триал на 30 дней и посмотреть, как работает весь функционал Statuser без ограничений.

Перейти на сайт Statuser

Если интересно, можно почитать и другие истории из разработки Statuser:

• Как я по вечерам разрабатывал Statuser — платформу для мониторинга доступности приложений

• Почему мониторинг — это ещё не всё. История появления статус-пейджей в Statuser

Буду рад вашей обратной связи — вопросам, идеям или просто впечатлениям.

Пишите в комментариях или напрямую в Telegram: @mshpakov.

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩