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

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

Давайте разберем флоу запроса: изменение в зоне должно проходить не «ручной правкой в проде», а через репозиторий, ревью и автоматическую публикацию. Для DNS это особенно критично: одна лишняя точка, сломанный TTL или неверный NS — и консистентность уезжает быстрее, чем успевает сработать откат.

Базовый минимум выглядит так:
— одна зона = один источник истины в Git;
— изменения проходят review двух пар глаз;
— CI валидирует синтаксис, SOA, NS, MX, CNAME-ограничения и пересечения;
— apply делает только сервисный аккаунт, без human write access к прод-слою.

Отдельно проверяйте merge-конфликты и порядок генерации файлов. В DNS «последний коммит победил» — плохая стратегия: можно случайно затереть serial, снять DS или выпустить несовместимый набор записей. Хорошая схема — шаблоны, policy-as-code и обязательный diff перед публикацией. Исключаем Human Error через автоматизацию.

Если зона большая, разделяйте изменения по типам: делегирование, почта, сервисные записи, emergency fixes. Так проще откатывать и проще объяснить, почему один innocuous commit не должен тянуть за собой пересборку половины домена. Стабильность DNS — это фундамент, а не опция.