GitOps для DNS-зон ломают не баги, а слабые правила слияния

GitOps для DNS-зон ломают не баги, а слабые правила слияния

Когда зона живёт в Git, репозиторий становится источником истины. Это удобно ровно до момента, пока кто-то не правит SOA, NS и A-записи вручную в консоли. Дальше начинается рассинхрон: diff чистый, а в проде уже другой ответ. Стабильность DNS — это фундамент, а не опция.

Рабочая схема выглядит так: 1) зона хранится как текстовый артефакт; 2) изменения идут только через pull request; 3) CI валидирует синтаксис, дубликаты, TTL, пересечения и наличие обязательных записей; 4) после мержа контроллер применяет изменения атомарно. Давайте разберем флоу запроса: сначала контроль в Git, потом публикация, а не наоборот.

Ключевые правила: — запретить прямые правки в master-источнике; — отдельно проверять делегирование, CNAME-цепочки и glue; — не смешивать массовый рефакторинг с инцидентным патчем; — хранить шаблоны зон, а не копипасту. Иначе Human Error быстро превращается в «почему резолвер видит не то».

Полезный паттерн — проверка before/after на staging-окружении с теми же валидаторами, что и в проде. Так вы ловите ошибки до публикации, а не после жалоб на NXDOMAIN и таймауты.

Исключаем Human Error через автоматизацию: Git должен не просто хранить зоны, а принуждать к предсказуемому флоу изменений.