GitOps для DNS-зон ломается не в коммитах, а в точках слияния и деплоя

GitOps для DNS-зон ломается не в коммитах, а в точках слияния и деплоя

Давайте разберем флоу запроса: источник истины — Git, генератор зон — CI, доставка — в authoritative-сервер. Если зона правится руками на сервере, GitOps превращается в декоративный журнал изменений.

Критичные правила:
— один PR = один смысловой change-set;
— TTL и SOA serial меняются предсказуемо, иначе ловите лишние кеши и рассинхрон;
— валидация до мержа: синтаксис, дубли, CNAME-конфликты, пустые NS;
— запрет на прямое редактирование в production, кроме аварийного окна с последующим backfill в Git.

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

Проверим влияние на RTT и консистентность зон: после выкладки нужен контроль AXFR/IXFR, сравнение SOA и выборочная проверка ответов с нескольких резолверов. Исключаем Human Error через автоматизацию, но оставляем ручной review там, где меняются MX, NS и DS.

Стабильность DNS — это фундамент, а не опция. Если Git не является единственным источником правды, то это не GitOps, а аккуратно упакованный ручной труд.