GitOps для DNS-зон: где ломается «инфраструктура как код» и как это чинить

Давайте разберем флоу запроса: источник истины — Git, а не панель с ручными правками. Для зоны это означает один формат данных, один механизм валидации и один путь доставки в authoritative-сервис. Иначе получаем два конфликта: дрейф конфигурации и человеческие правки, которые «временно» живут годами.

Базовый набор контроля:
— schema/zone lint до merge: синтаксис, SOA, NS, CNAME-цепочки, TTL
— запрет опасных паттернов: CNAME на apex, дубли MX/NS, случайные wildcard
— review с доменной экспертизой: изменения DNS нельзя мерить только diff’ом текста
— автодеплой только после успешной проверки зоны и генерации serial

Отдельно смотрим на rollback. Для DNS он не равен «откатили Git — и всё хорошо». Если serial уже ушел в кэш рекурсоров, старые записи будут жить до TTL. Поэтому план отката должен учитывать время распространения и консистентность зон, особенно при смене NS, MX и A/AAAA для критичных сервисов. Стабильность DNS — это фундамент, а не опция.

Еще один риск — смешивание ручного и автоматического управления. Если кто-то правит зону напрямую на сервере, GitOps превращается в декоративную дисциплину. Исключаем Human Error через автоматизацию: запрещаем out-of-band изменения, а расхождения между Git и фактической зоной проверяем регулярно.

Практика простая: Git должен быть единственным местом, где живет intent, а пайплайн — единственным механизмом, который превращает intent в опубликованную зону. Всё остальное быстро превращается в костыль с красивой историей.