GitOps для DNS-зон: как не превратить IaC в фабрику аварий и откатов

GitOps для DNS-зон: как не превратить IaC в фабрику аварий и откатов

GitOps в DNS работает только тогда, когда зона описана как код, а не как набор ручных правок в панели. Давайте разберем флоу запроса: commit → review → render zone → validate → deploy → serial bump → reload. Если хотя бы один шаг выполняется «на глаз», консистентность начинает зависеть от памяти оператора, а это уже антиархитектура.

Что проверять до мерджа:
— синтаксис zone file и корректность SOA/NS;
— отсутствие конфликтов TTL, CNAME-ловушек и циклов;
— порядок записей, влияющий на diff и ревью;
— детерминированную генерацию из шаблонов, без скрытой логики в скриптах.

Отдельный риск — serial management. Если номер зоны меняется неатомарно или руками, репликация может вести себя предсказуемо только на бумаге. Исключаем Human Error через автоматизацию: один источник истины, один пайплайн, одна точка валидации. А если нужен rollback, он должен откатывать и зону, и связанный serial, иначе secondary-сервера будут жить в разных реальностях.

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