Мониторинг DNS: узнайте, когда запись изменилась или перестала резолвиться

Что именно запрашивает проверка

Монитор DNS запрашивает у публичных рекурсивных резолверов, Google по адресу 8.8.8.8 и Cloudflare по адресу 1.1.1.1, выбранный вами тип записи и сравнивает ответ с тем, что вы задали как ожидаемое. Он пробует дважды с таймаутом до 10 секунд, а время запроса сохраняется как время ответа. Типы записей: A, AAAA, CNAME, MX, NS и TXT.

Поскольку запросы идут через рекурсивные резолверы, вы видите то, что видит публичный интернет, включая закешированные ответы. Запросить конкретный авторитетный нейм-сервер нельзя, и карты распространения вы не увидите. Плюс в том, что успешная проверка означает: настоящие посетители имя резолвят; минус — изменения появляются только после истечения TTL записи.

Ожидаемые значения: подмножество, а не точное совпадение

Укажите одно или несколько значений в поле ожидаемого, разделив запятыми или новыми строками. Каждое должно быть в ответе; дополнительные записи в ответе не мешают. Сравнение не учитывает регистр и точку в конце имени. Так что монитор A с ожидаемым 203.0.113.10 проходит, когда ответ — 203.0.113.10 и 203.0.113.11, и не проходит, как только 203.0.113.10 пропадает. Сообщение о сбое печатает то, что найдено, поэтому подмену или ошибочную правку легко прочитать.

Некоторые форматы стоят отдельного замечания. Ответы MX сопоставляются только по имени хоста или по приоритету плюс хост («10 mx1.clienta.com»). Фрагменты TXT перед сравнением склеиваются в одну строку, так что длинные ключи DKIM сравниваются как написано; монитору TXT нужно всё значение. Если оставить поле ожидаемого пустым, проверка потребует только существования записи: она ловит удаление, но не подмену. Задайте ожидаемое значение, когда хотите защиты от изменений.

Какие записи стоит отслеживать

Короткий перечень даёт большую часть безопасности:

• A или AAAA корня и www: классический детектор «кто-то направил сайт куда-то ещё».
• NS домена: задайте оба нейм-сервера как ожидаемые; это ещё и лучшая из доступных сигнализаций о подмене нейм-серверов, потому что сами регистрационные данные не отслеживаются.
• MX: почта, которая тихо перестала приходить, хуже сайта, который заметно не работает.
• TXT на _dmarc.clienta.com и для SPF: проверяет, что записи политик пережили миграцию DNS-провайдера.
• CNAME поддомена статуса или магазина, указывающий на SaaS: ловит «висячие» записи, которые могут быть перехвачены.

Cloudflare, CDN и сплющенные записи

Если имя проксируется, его A-запись показывает адреса провайдера: они общие и могут измениться без предупреждения. Ожидать именно их — хрупко. Следите за NS-записью, чтобы видеть, что зона по-прежнему делегирована провайдеру, а мониторингом сайта — что трафик доходит до вашего origin. Сплющивание CNAME, которое на корне делают некоторые провайдеры, заставляет ответ CNAME выглядеть как A-запись, так что выбирайте тот тип записи, который видит публика.

Плановые изменения без лишнего шума

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

Сбои конкретны: запись не найдена, SERVFAIL (серверы зоны сбоят или сломан DNSSEC), таймаут запроса или «record is X, expected Y». Мониторинг DNS начинается с тарифа Starter, а интервалы проверок зависят от тарифа: от 1 мин на Starter до 30 с на Pro. Все регионы, выполняющие проверки (сейчас 2 региона), обращаются к тем же двум публичным резолверам.