GitOps для DNS-зон: где IaC помогает, а где ломает консистентность

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

Правильный поток простой: PR → валидация синтаксиса и политики → сборка zone file или API-вызов → публикация → контроль SOA/serial и выборочная проверка резолвом. Стабильность DNS — это фундамент, а не опция. Если шаг деплоя не детерминирован, GitOps превращается в дорогой журнал пожеланий.

Что обязательно автоматизировать:
— проверку zone lint и конфликтов имён;
— запрет прямых правок вне репозитория;
— review на изменения NS, MX, CNAME, TXT;
— откат на предыдущий commit как штатную операцию;
— сравнение фактической зоны с эталоном, а не веру в «всё применилось».

Отдельно следите за TTL и serial policy. Низкий TTL не лечит плохой процесс, а сериал без понятного правила только усложняет репликацию между primary и secondary. Исключаем Human Error через автоматизацию.

Если Git — источник истины, то у DNS не должно быть второго, ручного источника правды. Иначе любая «мелкая правка» рано или поздно превращается в спор между репозиторием и реальностью.