Мониторинг DNS

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

Для чего подходит

Для чего не подходит

DNS-монитор читает запись. Он никогда не подключается к тому, на что она указывает:

Что делает каждая проверка

DNS проверяется только с чекеров, а не с сервера PingZen: по умолчанию с московского чекера или с тех чекеров, которые вы выберете в форме монитора. Монитор, созданный без чекера через API, MCP или импорт CSV, получает публичный чекер, в первую очередь московский.

По умолчанию — один запрос выбранного вами типа записи к Google Public DNS (8.8.8.8). Если 8.8.8.8 не ответил вовремя, вернул SERVFAIL не из-за DNSSEC, отказал в запросе или не дал пригодного ответа, проверка задаёт тот же вопрос ещё раз через Cloudflare (1.1.1.1) и судит по его ответу, так что из-за сбоя одного резолвера проверка не падает. NXDOMAIN, отсутствие записи, сбой DNSSEC и ответ, не совпадающий с ожидаемыми значениями, считаются окончательными: второй раз такой запрос не задают. Если 8.8.8.8 подвёл, а в ответе 1.1.1.1 нет ожидаемого значения, текст ошибки называет оба резолвера: Не найдены ожидаемые значения: 9.9.9.9. Получено: 1.2.3.4 (8.8.8.8: таймаут 10 с; 1.1.1.1: ответил).

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

• Полученные значения — весь список вернувшихся записей, он сохраняется с каждым результатом проверки
• Время резолва — сколько занял ответ, в миллисекундах

По умолчанию запрос идёт через публичный рекурсивный резолвер, поэтому вы видите то, что видит публичный интернет, вместе с закэшированными ответами. Запись, изменённая минуту назад, может появиться здесь только после истечения старого TTL. Для монитора это обычно и нужно: он показывает ответ, который на самом деле получают ваши пользователи. Если у монитора свой DNS-сервер, вы видите ответ именно этого сервера.

Типы записей

Этими восемью список исчерпывается. Любой другой тип — SRV, CAA и прочие — не даст сохранить монитор ни через API, ни через MCP: в ответе придёт сообщение со списком поддерживаемых типов.

Ожидаемые значения

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

• Каждое перечисленное значение должно целиком совпасть с одним из значений ответа. Это не поиск подстроки и не шаблон.
• В ответе может быть больше записей, чем вы перечислили. Две A-записи при одной ожидаемой — это нормально, важно лишь наличие перечисленной.
• Если какого-то значения нет, проверка падает, а сообщение об ошибке показывает и чего не хватило, и что пришло вместо этого — новое значение видно прямо на странице монитора.
• Полученные значения записываются и при упавшей проверке, так же как при успешной.
• Имена совпадают в любом регистре, с точкой на конце и без неё: Mail.Example.com совпадёт с ответом mail.example.com.. Значения TXT сравниваются ровно так, как написаны, с учётом регистра и пробелов. У значений MX впереди стоит приоритет, его тоже пишите: 10 mail.example.com.
• До 100 значений на монитор.

Ожидаемые значения задаются в форме монитора, по одному в строке, а также через API или инструменты MCP.

Логика статусов

DNS-монитор либо работает, либо нет. Состояния деградации у него нет, порога на медленный ответ тоже: долгий, но правильный ответ — это по-прежнему UP. Ответ, не совпадающий с ожидаемыми значениями, — такой же DOWN, красный, как любая другая неудача, но на бейдже написано «Ответ не совпадает» («Не совпадает», где мало места): так его не спутать с именем, которое перестало резолвиться.

У каждой из этих неудач своя причина на странице монитора — «Такого домена нет», «Нет записи этого типа», «Подпись DNSSEC не проходит проверку», «DNS-серверы домена дали сбой», «Публичный DNS не ответил», «Ваш DNS-сервер не ответил или отказал», «Ответ не совпадает с ожидаемым». Когда сбоят резолверы, в тексте ошибки видно, что ответил каждый из них, например DNS-серверы домена example.com дали сбой (8.8.8.8: REFUSED; 1.1.1.1: SERVFAIL). На домен со сломанной подписью DNSSEC Google 8.8.8.8 иногда отвечает обычным SERVFAIL без пояснения; тогда проверка спрашивает 1.1.1.1, и уже его ответ указывает на DNSSEC. Если у монитора свой DNS-сервер, его ответ окончательный: 1.1.1.1 не спрашивают, а текст ошибки называет ваш сервер, например DNS-серверы домена example.com дали сбой (10.0.0.53: SERVFAIL).

Под заголовком со статусом — карточка Текущий ответ: последний ответ, который получила проверка, и сервер, который спрашивают проверки. Если ответ не совпадает с ожидаемыми значениями, карточка показывает, каких ожидаемых значений нет в ответе и какие значения ответа не входят в список ожидаемых; если запись меняли вы сами, кнопка Да, принять новый ответ делает текущие значения ожидаемыми. При любой другой неудаче над карточкой появляется баннер с причиной простыми словами и одним следующим шагом.

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

Настройки

Ключевые возможности

• Восемь типов записей: A, AAAA, CNAME, MX, TXT, NS, SOA и PTR
• Необязательные ожидаемые значения, и при ошибке видно и чего не хватило, и что пришло
• Полученные значения и время резолва записываются при каждой проверке, успешной и упавшей
• Понятная причина и один следующий шаг для каждого способа не получить ответ вместо плоского «упало»
• Показывает ответ публичного резолвера, то есть тот ответ, который получают ваши пользователи
• Может спрашивать вместо него ваш DNS-сервер, в том числе адрес в локальной сети — через приватный чекер в этой же сети