Pourquoi automatiser DNS Cloudflare avec Terraform en entreprise ?

Quand une entreprise multiplie les services (site vitrine, app SaaS, monitoring, emailing, environnements de test), la zone DNS devient rapidement un point de fragilité. Une simple modification manuelle dans Cloudflare peut casser un sous-domaine, interrompre une validation TLS, ou créer un écart entre ce qui est documenté et ce qui est réellement en production.

J’utilise Terraform pour gérer cette couche DNS comme du code : modifications versionnées, revue Git, rollback propre, et exécution reproductible. C’est la méthode la plus fiable que j’applique pour éviter les erreurs humaines et garder un socle infra cohérent.

Si tu veux industrialiser cette logique avec supervision, sauvegardes et exploitation continue, tu peux voir l’approche infogérance serveurs Linux en entreprise utilisée chez Linux-Man.

Réponse rapide

Pour automatiser DNS Cloudflare avec Terraform en entreprise : structure les enregistrements dans des variables typées, applique une convention de nommage stable, valide avec terraform plan, puis déploie via pipeline GitLab. Résultat : changements tracés, risques réduits, et reprise plus simple après incident.

Le problème concret rencontré en production

Dans beaucoup d’équipes, les enregistrements DNS sont gérés “au fil de l’eau” depuis l’interface web. Cette approche fonctionne au début, puis devient coûteuse :

• pas d’historique central fiable des changements,
• dépendance à une seule personne qui “sait où cliquer”,
• erreurs de copier-coller sur les CNAME/TXT critiques,
• difficulté à reproduire un environnement préprod identique à la prod.

Le sujet n’est pas seulement technique. C’est aussi un sujet business : un mauvais enregistrement DNS, c’est des formulaires indisponibles, des emails qui n’arrivent plus, voire une perte de leads.

Le repo GitLab utilisé comme preuve technique

Pour cet article, je m’appuie sur le repo linux-man/cloudflare-dns-terraform (source interne Linux-Man), avec un pattern simple et robuste :

• déclaration typée des zones et records dans variables.tf,
• données de zones dans un fichier dns_records.auto.tfvars,
• flatten + for_each dans main.tf pour générer les ressources DNS.

Extrait réel de la variable (structure map/list/object) :

variable "dns_zones" {
  description = "Liste des zones DNS et leurs enregistrements"
  type = map(list(object({
    fieldtype = string
    subdomain = string
    ttl       = number
    target    = string
  })))
  default = {}
}

Extrait réel du moteur Terraform (flatten + for_each) :

locals {
  dns_records = flatten([
    for zone, records in var.dns_zones : [
      for idx, record in records : {
        zone      = zone
        fieldtype = record.fieldtype
        subdomain = record.subdomain
        ttl       = record.ttl
        target    = record.target
        index     = idx
      }
    ]
  ])
}

resource "cloudflare_domain_zone_record" "dns_records" {
  for_each = { for idx, record in local.dns_records : "${record.zone}-${record.subdomain}-${record.fieldtype}-${record.index}" => record }
  zone      = each.value.zone
  fieldtype = each.value.fieldtype
  subdomain = each.value.subdomain
  ttl       = each.value.ttl
  target    = each.value.target
}

Exemple de fichier dns_records.auto.tfvars

Exemple cohérent avec la variable dns_zones du repo :

dns_zones = {
  "example-infra.fr" = [
    {
      fieldtype = "A"
      subdomain = "@"
      ttl       = 300
      target    = "203.0.113.10"
    },
    {
      fieldtype = "CNAME"
      subdomain = "www"
      ttl       = 300
      target    = "example-infra.fr"
    }
  ]

  "example-infra.eu" = [
    {
      fieldtype = "MX"
      subdomain = "@"
      ttl       = 300
      target    = "mx1.mailhost.tld"
    }
  ]
}

Note : adapte les valeurs (zone, IP, cible mail) à ton contexte, et garde les tokens/API keys en dehors des fichiers versionnés.

Ce pattern évite les ressources Terraform répétitives, réduit la dette technique et rend les changements DNS beaucoup plus lisibles en revue Git.

Architecture de travail recommandée (simple et efficace)

1) Déclarer le DNS comme donnée, pas comme code dupliqué

Le meilleur compromis observé : tu décris les enregistrements dans un fichier de variables, et Terraform se charge de matérialiser les ressources. Tu manipules des données métier (zone, type, target), pas des blocs Terraform copiés 40 fois.

2) Standardiser les conventions

• TTL par défaut explicite,
• format de sous-domaines homogène,
• noms des clés stables pour éviter le churn dans le state.

3) Faire un cycle plan/apply propre

terraform fmt -recursive
terraform init
terraform validate
terraform plan -out tfplan
terraform apply tfplan

Avec ce cycle, tu vois précisément ce qui sera ajouté/modifié/supprimé avant impact.

4) Industrialiser dans GitLab CI

L’étape suivante consiste à exécuter terraform validate et terraform plan automatiquement à chaque merge request. L’apply reste manuel (ou protégé) pour garder une validation humaine sur les zones sensibles.

Checklist opérationnelle avant mise en prod

• ✅ Tous les enregistrements critiques (A, CNAME, TXT SPF/DMARC/DKIM) sont versionnés
• ✅ Aucun secret/API key stocké en clair dans les fichiers de variables
• ✅ terraform validate est vert
• ✅ terraform plan relu par un second pair
• ✅ Fenêtre de changement connue (impact DNS possible)
• ✅ Plan de rollback prêt (commit précédent + apply rapide)
• ✅ Monitoring HTTP/TLS post-changement en place

Pour les équipes qui veulent aussi sécuriser la couche hôte (SSH, firewall, durcissement OS), le guide sécurisation VPS en entreprise complète bien cette approche DNS as Code.

Erreurs fréquentes à éviter

Confondre “ça marche” avec “c’est maintenable”

Un DNS manuel peut fonctionner aujourd’hui, mais devenir ingérable dans 6 mois. Le coût apparaît au premier incident.

Modifier plusieurs zones sans lot de validation

Si tu touches plusieurs domaines en même temps sans plan relu, tu augmentes le rayon d’impact d’une erreur.

Utiliser des ressources Terraform non stables

Une clé de for_each mal conçue peut provoquer des suppressions/recréations inutiles. Ici, la clé combine zone, subdomain, type et index, ce qui limite le drift.

Ignorer l’aspect business

Le DNS n’est pas juste un sujet “admin sys”. C’est une pièce critique de disponibilité, de délivrabilité email et d’acquisition commerciale.

Prévention et gouvernance

Une gouvernance DNS pragmatique en entreprise repose sur 4 règles :

1. Tout changement DNS passe par Git (merge request + review).
2. Les environnements sensibles ont un gate manuel avant apply.
3. La documentation vient du code (README + variables commentées).
4. Les changements sont corrélés à des alertes monitoring post-déploiement.

Si ton besoin va au-delà du DNS (sauvegardes, SLA, supervision, astreinte), la page maintenance serveurs Linux détaille le périmètre BOFU typique pour une externalisation maîtrisée.

FAQ

Plan de migration DNS as Code en 4 phases (retour terrain)

Phase 1 — Audit et cartographie

Commence par inventorier toutes les zones et tous les enregistrements réellement utilisés. Dans la pratique, on découvre souvent des entrées “orphelines” : anciens sous-domaines de tests, validations ACME oubliées, redirections marketing périmées, ou CNAME historiques non documentés. Cette phase te donne une base factuelle pour éviter d’automatiser du bruit.

Le bon réflexe : classer chaque record par criticité métier (critique, important, secondaire). Les enregistrements liés aux emails (SPF, DKIM, DMARC), au site principal, aux APIs clients et aux tunnels de supervision doivent être explicitement marqués comme critiques.

Phase 2 — Modélisation Terraform minimale

Ensuite, tu transformes cette cartographie en structure exploitable, avec un schéma simple comme celui du repo (zone, type, sous-domaine, TTL, target). Le but n’est pas de créer une usine à gaz, mais un modèle lisible par toute l’équipe. Cette lisibilité est clé : si seul l’auteur du code le comprend, tu recrées une dépendance humaine.

À ce stade, garde des conventions strictes :

• nommage uniforme des sous-domaines,
• documentation des exceptions (records temporaires, prestataires externes),
• commentaires sur les entrées sensibles.

Phase 3 — Validation contrôlée

Avant le premier apply, exécute plusieurs plans dans un environnement de validation. L’objectif est d’identifier les différences inattendues (drift) et de réduire les suppressions accidentelles. C’est aussi le moment de faire une revue croisée : un second regard détecte souvent des détails invisibles pour l’auteur initial.

Une méthode qui fonctionne bien :

1. plan local + plan CI,
2. comparaison des sorties,
3. validation des records critiques un par un,
4. apply en fenêtre calme,
5. contrôle post-apply (résolution DNS, HTTPS, email auth).

Phase 4 — Exploitation continue

Une fois le DNS géré en code, le vrai gain arrive dans la durée : onboarding plus rapide d’un nouveau client, modifications multi-zones sans stress, et meilleur délai de remise en service après incident. Tu peux ensuite brancher de la gouvernance : règles de review, check automatique de format, et runbook d’urgence.

Exemples d’usages concrets en contexte entreprise

Ouverture d’un nouvel environnement client

Au lieu de cliquer manuellement 10 à 20 enregistrements, tu ajoutes un bloc propre dans le fichier de variables, tu passes la MR, puis apply validé. Temps gagné : significatif. Risque d’oubli : nettement réduit.

Mise à jour rapide après changement d’IP

Quand une migration impose un changement d’IP publique, Terraform permet de visualiser immédiatement les impacts et d’appliquer la modification de façon atomique. C’est particulièrement utile quand plusieurs sous-domaines pointent vers la même cible.

Conformité et auditabilité

Dans un cadre contractuel ou réglementaire, pouvoir répondre “voici le commit exact qui a modifié tel record, validé tel jour par telle personne” change totalement la qualité de l’audit. Tu passes d’une logique déclarative orale à une preuve écrite vérifiable.

KPIs à suivre après adoption

• Nombre d’incidents DNS par mois
• Temps moyen de correction d’un incident DNS
• Taux de changements DNS réussis au premier passage
• Part des changements DNS passés via MR vs changements manuels
• Nombre de records orphelins détectés lors des revues trimestrielles

Ces indicateurs permettent de mesurer l’impact réel du DNS as Code sur la continuité de service, pas juste la propreté technique.

Quand il faut aller plus loin

Si ton entreprise gère plusieurs clouds, plusieurs registrars et des exigences de disponibilité fortes, l’étape suivante est de coupler Terraform DNS avec :

• des tests de résolution automatisés post-déploiement,
• une supervision synthétique multi-région,
• un runbook incident prêt à l’emploi (qui décide, qui rollback, qui communique).

Le DNS devient alors un composant pleinement intégré à ton système de production, et non un point de configuration “à part”.

Conclusion

Automatiser DNS Cloudflare avec Terraform n’est pas un luxe d’équipe “très mature”. C’est une base pragmatique pour fiabiliser ton infra, réduire les erreurs humaines et accélérer les changements sans perdre le contrôle.

Si tu veux, je peux te proposer une trame de migration en 2 semaines (audit des zones, normalisation, IaC, pipeline, runbook de rollback) adaptée à ton contexte entreprise.