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

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

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

Рабочая схема проста:
— зона хранится в текстовом формате, удобном для diff и ревью;
— изменения проходят lint, синтаксическую проверку и контроль SOA/NS/CAA;
— деплой идёт атомарно, без частичных обновлений;
— после публикации выполняется сверка serial, TTL и доступности авторитативных серверов.

Слабое место GitOps для DNS — не сам Git, а человеческая дисциплина вокруг него. Если не валидировать делегирование, glue-записи и соответствие NS на всех уровнях, можно получить репозиторий с идеальной историей коммитов и полностью сломанной зоной в проде. Стабильность DNS — это фундамент, а не опция.

Ещё один обязательный слой — политика изменений: кто может трогать продовые зоны, как откатываются правки, и что считается невалидным merge. Исключаем Human Error через автоматизацию: запрещаем ручной edit на авторитативных серверах, а любое исключение оформляем как временный контролируемый обход.

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