Pourquoi versionner son DNS Cloudflare

Le DNS reste souvent un angle mort opérationnel. Beaucoup d’équipes ont industrialisé leurs serveurs, leurs conteneurs et leurs déploiements, mais continuent à modifier leurs enregistrements DNS directement dans l’interface Cloudflare. Le problème, c’est qu’un simple changement manuel mal relu peut casser un sous-domaine, empêcher la validation d’un certificat ou faire pointer un service vers la mauvaise cible.

Quand j’utilise Terraform Cloudflare DNS, je cherche surtout à obtenir trois bénéfices concrets : un historique Git de chaque modification DNS, une relecture du plan avant application et une structure réutilisable quand plusieurs zones ou plusieurs environnements entrent en jeu. Ce n’est pas du dogme infrastructure as code. C’est juste une manière plus fiable de traiter un composant critique.

Sur le terrain, ce gain est particulièrement visible dès que plusieurs personnes interviennent sur le DNS, ou quand un même domaine comporte des entrées applicatives, mail, validation TLS et sous-domaines de test. Sans garde-fous, les modifications finissent vite dispersées entre mémoire humaine, captures d’écran et tickets. Avec du code, tout devient plus lisible.

Ce que montre le dépôt utilisé comme preuve

Le dépôt source que j’utilise ici reste volontairement simple. J’y décris des zones DNS sous forme d’une map Terraform, puis je génère les enregistrements Cloudflare à partir d’une structure déclarative. L’intérêt, c’est de pouvoir ajouter, relire et appliquer plusieurs entrées sans recréer la logique à chaque fois.

La structure générale repose sur trois idées :

Dans ce dépôt, j’utilise notamment une variable dns_zones qui décrit chaque zone et ses enregistrements. Ensuite, un flatten permet de transformer cette structure en liste exploitable pour créer les ressources cloudflare_record du Cloudflare Terraform provider. Le résultat est compact, lisible et facile à faire évoluer quand de nouvelles entrées arrivent.

Si tu veux un accompagnement plus large sur la standardisation d’infrastructures, la gestion des changements ou la reprise d’une configuration devenue trop artisanale, mon offre d’infogérance serveur peut justement t’aider à remettre ce genre de sujet à plat.

Comment je structure le Cloudflare Terraform provider

Je préfère garder un modèle très explicite plutôt qu’un Terraform trop “magique”. Quand je reviens sur un dépôt plusieurs semaines plus tard, je veux comprendre en quelques minutes où sont les zones, quels enregistrements sont déclarés et ce qui va réellement être créé.

Voici un exemple simplifié inspiré du dépôt, avec les valeurs sensibles remplacées par des placeholders :

variable "dns_zones" {
  type = map(list(object({
    fieldtype = string
    subdomain = string
    ttl       = number
    target    = string
    proxied   = bool
  })))
}

locals {
  dns_records = flatten([
    for zone, records in var.dns_zones : [
      for idx, record in records : {
        zone_id = data.cloudflare_zone.zones[zone].id
        type    = record.fieldtype
        name    = record.subdomain
        ttl     = record.ttl
        content = record.target
        proxied = record.proxied
        index   = idx
      }
    ]
  ])
}

resource "cloudflare_record" "dns_records" {
  for_each = { for record in local.dns_records : "${record.zone_id}-${record.name}-${record.type}-${record.index}" => record }

  zone_id = each.value.zone_id
  name    = each.value.name
  type    = each.value.type
  ttl     = each.value.ttl
  content = each.value.content
  proxied = each.value.proxied
}

Ce que j’aime dans cette approche, c’est qu’elle garde un bon équilibre entre simplicité et réutilisabilité. Tu peux décrire plusieurs enregistrements A, CNAME ou TXT dans une même structure, tout en gardant un rendu final lisible au moment du plan.

Concrètement, ma séquence de travail ressemble souvent à ça :

terraform init
terraform fmt
terraform validate
terraform plan
terraform apply

Je ne saute jamais la phase plan. Sur du DNS, une mauvaise valeur peut avoir un impact immédiat. Le plan permet de relire les changements avant qu’ils ne deviennent effectifs, surtout quand une zone contient déjà des entrées critiques pour le web, le mail ou des validations externes.

Comment j’organise les enregistrements

Quand une zone grossit, je préfère une structure logique par domaine plutôt qu’un grand fichier désordonné. L’idée n’est pas de multiplier les fichiers pour le plaisir. L’idée est d’aider la relecture. Un changement doit être compréhensible sans devoir recoder mentalement tout le dépôt.

Par exemple, je garde généralement les points suivants :

- une convention de nommage claire pour les sous-domaines
- des TTL cohérents selon l’usage
- des valeurs proxied explicites
- un dépôt dédié ou au moins un dossier dédié au DNS
- une revue avant application sur les zones sensibles

Cette discipline paraît basique, mais elle évite beaucoup d’erreurs. Le DNS n’est pas spectaculaire tant qu’il fonctionne. Dès qu’il casse, en revanche, tout le monde s’en souvient très vite.

Les points de sécurité à garder en tête

Gérer du DNS avec Terraform impose aussi de traiter sérieusement les accès API. Celui qui peut modifier tes zones peut rediriger du trafic, casser des validations ou perturber plusieurs services d’un coup. Il faut donc considérer le provider Cloudflare comme un point sensible de ton infrastructure.

Mes garde-fous habituels sont simples :

- utiliser un jeton Cloudflare avec les droits minimum nécessaires
- ne jamais committer de secret dans les fichiers Terraform
- protéger les variables sensibles dans le CI/CD si Terraform est lancé en automatisé
- relire le plan avant application
- séparer les validations de test et les zones réellement critiques

Je fais aussi attention aux valeurs d’exemple. Même dans de la documentation interne ou dans un dépôt public, une adresse IP, une cible DNS ou un identifiant trop précis peuvent devenir des informations inutiles à exposer. Quand je montre des extraits, je préfère les anonymiser sans casser la compréhension.

Si tu as besoin d’un avis sur la manière de reprendre un DNS devenu brouillon, ou de sécuriser les changements avant une migration, le plus simple reste souvent de me contacter via cette page de contact.

Cas d’usage où cette approche fait gagner du temps

Je recommande particulièrement cette approche dans quatre situations :

À l’inverse, si tu as un seul domaine vitrine avec très peu de changements, un dépôt Terraform dédié n’est pas forcément prioritaire. L’idée n’est pas de complexifier. L’idée est de fiabiliser quand le contexte le justifie réellement.

Erreurs fréquentes

Checklist de mise en place

FAQ

Conclusion

Versionner son DNS avec Terraform n’a rien d’un luxe réservé aux grosses équipes. C’est souvent une mesure pragmatique pour mieux relire les changements, garder un historique propre et réduire les manipulations Cloudflare faites dans l’urgence. Sur les environnements où plusieurs services dépendent du DNS, le gain de fiabilité est réel.

Si tu veux reprendre une zone Cloudflare mal documentée, industrialiser proprement tes changements DNS ou sécuriser la gestion de plusieurs domaines, je peux t’aider à remettre tout ça au carré sans transformer le sujet en usine à gaz.