Мониторинг изменений DNS в большом портфеле доменов

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

За чем на самом деле стоит следить

Как сделать это устойчивым

Практическое решение — превратить проверку в то, что выполняется по собственному расписанию, а не в то, о чём человеку нужно помнить. Периодическая задача, которая через заданный интервал заново разрешает весь портфель (раз в час, раз в сутки, с той периодичностью, что соответствует ожидаемой частоте значимых изменений) и показывает только то, что изменилось с прошлого раза, превращает легко пропускаемую ручную рутину в пассивную страховочную сетку. В сочетании с экспортируемыми результатами (CSV или JSON) это позволяет легко сравнивать один прогон с предыдущим и автоматически замечать дрейф, а не разглядывать длинный список вручную.

Конкретный риск, который это выявляет: «висячий» DNS в больших масштабах

Большой портфель доменов накапливает старые поддомены так же, как любая кодовая база накапливает мёртвый код: поддомен посадочной страницы маркетинговой кампании, выведенная из эксплуатации тестовая среда, CNAME на пробный период SaaS, который так и не продлили. Каждый из них — потенциальная цель для захвата поддомена, если сервис, на который он когда-то указывал, станет доступен для регистрации кем-то другим. Плановый мониторинг всего портфеля — один из немногих практичных способов заметить такой дрейф раньше злоумышленника: поддомен, который раньше разрешался без проблем, а теперь выдаёт ошибку или разрешается у незнакомого провайдера, — именно тот сигнал, на который стоит взглянуть ещё раз.

Кто в итоге отвечает за это в организации

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

Начинайте с перечня, а не с догадок

Шаг, который чаще всего пропускают, — составление самого списка доменов, за которыми стоит следить. Панели регистраторов и DNS-провайдеров покажут все домены в одном аккаунте, но в большой организации домены часто разбросаны по нескольким регистраторам и провайдерам: они копились годами из-за поглощений, кампаний и покупок на уровне команд, которые никто централизованно не учитывал. Собрать этот полный перечень один раз (пусть и несовершенный) и использовать его как исходный список для постоянного мониторинга ценнее, чем технически изощрённая система мониторинга, наблюдающая лишь за той частью доменов, о существовании которых кто-то случайно вспомнил.