OVH DNS via Terraform : refresh zone auto, MX préservés

J’ajoute le domaine example.com à mon Terraform pour pointer un site Netlify, en gardant les MX OVH pour mes redirections mail. terraform apply réussit (« 2 to add, 0 to change, 0 to destroy » — exactement ce que je veux). Puis :

$ dig example.com
213.186.33.5   # IP parking OVH par défaut

Pas mon 75.2.60.5 Netlify. Et ovhcloud domain-zone refresh example.com → 403 Client::Forbidden: "This call has not been granted".

Premier réflexe : « le scope du consumer_key ne couvre pas POST /refresh, faut en regénérer un ». Fausse piste.

Ce qui se passe réellement

1. Le provider TF `ovh_domain_zone_record` rafraîchit déjà la zone

En interrogeant directement les NS authoritatifs OVH :

$ dig +short example.com @dns110.ovh.net
75.2.60.5   # le record est BIEN actif, juste pas propagé hors-OVH

Le 213.186.33.5 venait du cache de mon resolver local. Le provider TF avait fait son boulot — contrairement à l’UI OVH Manager qui demande un « Apply changes » explicite.

2. Le 403 `ovhcloud refresh` = cosmétique

Mon consumer_key (créé pour ovhcloudcli) avait les scopes sur /domain/zone/*/record/* mais PAS sur POST /domain/zone/*/refresh. D’où l’échec CLI. Sans conséquence : le refresh est déjà fait par le provider. Pour scripts hors-TF, élargir le scope via api.ovh.com/createToken/.

3. MX, SPF, NS, CNAME préservés naturellement

Peur infondée que TF écrase la zone entière. ovh_domain_zone_record gère un record à la fois, par ID OVH. Les records non déclarés dans le .tf (NS, SPF, les 3 MX, CNAME ftp) restent vivants :

$ ovhcloud domain-zone record list example.com --output yaml | grep -E 'fieldType|target'
NS    dns110.ovh.net.
SPF   v=spf1 include:mx.ovh.com -all
MX    1 mx1.mail.ovh.net.   MX 5 mx2...   MX 100 mx3...
A     75.2.60.5            # nouveau, par TF
CNAME example.netlify.app. # nouveau, par TF

Le pattern « TF gère les records web, OVH UI gère le mail » est sûr.

Mémo

Records via TF OVH = auto-refresh. Pas de « Apply changes » comme l’UI.
dig après apply : vise le NS authoritatif (dig X @dns110.ovh.net) pour court-circuiter ton cache local, sinon faux négatif.
MX et records non déclarés en TF survivent — exactement ce qu’on veut en gestion partagée OVH UI / TF.
ovhcloud refresh 403 = cosmétique si tu n’utilises que TF. À fixer (scope token) seulement pour des scripts hors-TF.