Mon module Terraform pour une zone DNS Cloudflare complète (fournisseur v5)

Salut r/cloudflare,

Je gère des zones Cloudflare avec Terraform, et passer au fournisseur v5 a signifié tout refaire. J'ai transformé le résultat en module, et j'aimerais avoir des retours de personnes utilisant DNS en production avant d'aller plus loin.

Registre : `theobs-digital/dns/cloudflare`

GitHub : https://github.com/theobs-digital/terraform-cloudflare-dns

**Ce que ça fait**

Une zone DNS Cloudflare dans un seul bloc : la zone, ses enregistrements, ses paramètres DNS et DNSSEC.

“`hcl

module "dns" {

source = "theobs-digital/dns/cloudflare"

version = "~> 1.2"

account_id = "…"

name = "example.com"

records = {

apex = { name = "@", type = "A", content = "192.0.2.10", proxied = true }

mx = { name = "@", type = "MX", content = "mx1.example.net", priority = 10 }

caa = { name = "@", type = "CAA", data = { flags = 0, tag = "issue", value = "letsencrypt.org" } }

}

dnssec = { status = "active" }

}

“`

**Objectifs**

– **Ne réinventez rien.** Chaque entrée garde le nom de l'attribut du fournisseur. Si vous connaissez `cloudflare/cloudflare`, vous connaissez le module, et la documentation du fournisseur s'applique toujours.

– **Zéro dérive.** Un deuxième plan ne doit montrer aucun changement. Un test quotidien sur une vraie zone (18 enregistrements, 14 types) vérifie cela avec le dernier fournisseur 5.x.

– **Échouer au plan, pas à l'application.** Le fournisseur laisse passer certaines erreurs à l'API. Le module les bloque au plan : un enregistrement sans valeur, avec à la fois `content` et `data`, proxifié avec un TTL fixe, ou proxifié quand ce n'est pas A, AAAA ou CNAME.

– **Créer ou adopter.** Le module crée la zone, ou avec `create_zone = false` gère les enregistrements d'une zone que possède une autre configuration.

– **DNSSEC prêt au registraire.** L'enregistrement DS sort comme une sortie, entier ou champ par champ.

**Contraintes et limites connues**

– Terraform >= 1.3 et fournisseur `~> 5.27`. Pas de support v4.

– Détruire le module supprime la zone et tous les enregistrements qu'elle contient, y compris ceux que Terraform ne gère pas. C'est ainsi que fonctionne Cloudflare. Le README couvre comment cesser de gérer sans supprimer (`removed`, `state rm`).

– Une clé mal orthographiée dans `records` (`proxid = true`) est silencieusement ignorée par la conversion de type de Terraform.

– Cloudflare réécrit certains valeurs (empreintes SSHFP en majuscules, points finaux sur NAPTR et HTTPS, TXT au-delà de 255 caractères). Le module les documente plutôt que de les normaliser.

– Le fournisseur ne peut ni supprimer ni importer les paramètres DNS : retirer `dns_settings` ne réinitialise rien.

– Certaines options nécessitent un plan payant (`soa` sur Entreprise, `tags` et serveurs de noms personnalisés sur Pro ou Business).

**Mes questions**

1. Un module devrait-il normaliser les valeurs que Cloudflare réécrit, ou rester transparent et les documenter ?
2. Pour attraper les fautes de frappe, taperiez-vous `records` comme `any` et valideriez-vous les clés, abandonnant la saisie et les valeurs par défaut `optional()` ? Comment gérez-vous cela ?
3. L'adoption recherche la zone par son nom. Un input direct `zone_id` vous aiderait-il ?
4. Que manque-t-il pour que vous l'utilisiez en production ?

Licence MIT. Les retours francs sont les bienvenus, surtout si vous avez rencontré la dérive du fournisseur v5 que je n'ai pas couverte. Merci !