Zone DNS OVHcloud : propagation, TTL et bonnes pratiques de configuration

Table des matières :

1. Zone DNS OVHcloud : ce que vous manipulez réellement (et ce qui peut casser)
2. Propagation DNS : comprendre la chaîne autorité → résolveur → cache
3. TTL et SOA : régler le cache sans se tirer une balle dans le pied
4. Bonnes pratiques de configuration sur OVHcloud : web, CDN, mail, TLS
5. Changements contrôlés et diagnostic : plan de bascule, commandes dig, monitoring

Zone DNS OVHcloud : ce que vous manipulez réellement (et ce qui peut casser)

La zone DNS OVHcloud n’est pas « un réglage de domaine », c’est un jeu d’enregistrements (RRsets) servi par des serveurs de noms autoritatifs (NS) pour un nom de domaine. Quand vous modifiez un A, un AAAA, un CNAME ou un TXT dans l’interface OVHcloud, vous changez le contenu d’une zone (un fichier logique) qui sera ensuite publié par les NS autoritatifs. Le reste (résolveurs récursifs, caches opérateurs, caches navigateur via DoH, etc.) n’appartient plus à OVHcloud, et c’est précisément là que naissent les incompréhensions sur la « propagation ».

Concrètement, vous manipulez deux plans distincts :

• Le plan “autorité” (OVHcloud DNS) : ce que renvoient les serveurs autoritatifs pour votre domaine quand on les interroge directement.
• Le plan “résolution” (Internet réel) : ce que voient vos utilisateurs selon leur résolveur récursif (FAI, entreprise, DNS public, DoH/DoT), ses caches, et parfois des politiques locales (plancher TTL, “serve stale”, filtrage, etc.).

Prérequis réalistes côté prod : (1) vous devez contrôler la délégation NS au niveau du registrar (OVHcloud ou non), (2) avoir une machine pour tester (dig sur Linux/macOS/WSL, ou kdig), (3) savoir où est hébergé le service cible (mutualisé, VPS, LB/CDN). Sur un hébergement mutualisé, la surface d’erreur est souvent plus grande (mélange mail/web, IP partagée, contraintes d’accès) : si vous n’êtes pas sûr du socle, commencez par clarifier l’hébergement et les responsabilités (voir aussi : Hébergement mutualisé : critères techniques pour choisir une offre fiable).

Ajoutez une nuance “gouvernance” : la délégation NS dépend d’un registre (TLD) et d’un bureau d’enregistrement (registrar). C’est particulièrement visible quand vous changez de NS : la zone peut être parfaite chez OVHcloud, mais si la délégation au niveau du registrar est erronée (NS manquants, faute de frappe, DS DNSSEC incohérent), l’autorité ne sera pas atteignable de façon fiable.

Côté sécurité et gouvernance, la zone DNS est un point de contrôle critique : un accès non maîtrisé permet un takeover de trafic (A/AAAA), un détournement d’emails (MX), ou des validations de certificats frauduleuses (TXT/CAA). Dans OVHcloud, évitez le partage d’identifiants et utilisez des droits minimaux via IAM ; pour industrialiser, passez par des comptes de service et une traçabilité d’actions (référence interne : Comptes de service OVHcloud : création et gestion IAM via espace client).

Checklist “ce qui casse le plus souvent” (et qui ressemble à de la propagation) :

• Vous modifiez le bon domaine… mais pas la bonne zone (ex : zone DNS OVHcloud inactive car domaine délégué vers un autre DNS).
• Vous changez un A mais oubliez le AAAA : certains clients préfèrent IPv6 et continueront à “aller ailleurs”.
• Vous corrigez un record, mais un NXDOMAIN a été mis en cache (negative caching).
• Vous basculez le web, mais le mail (MX/SPF/DKIM/DMARC) restait sur l’ancien fournisseur.
• Vous changez les NS sans avoir abaissé les TTL et sans période de recouvrement (ancienne et nouvelle zone en parallèle).

Propagation DNS : comprendre la chaîne autorité → résolveur → cache

Le chemin de résolution « standard » est : stub resolver (OS / navigateur) → résolveur récursif (FAI, entreprise, 1.1.1.1/8.8.8.8, DoH/DoT) → serveurs autoritatifs (ceux de la délégation NS). Ce qu’on appelle « propagation » correspond majoritairement au fait que des caches existants expirent à des moments différents selon les TTL, et non à une diffusion progressive contrôlée par le fournisseur DNS. En pratique, deux utilisateurs derrière deux récursifs distincts peuvent voir deux réponses différentes pendant toute la durée où l’ancien enregistrement reste en cache.

Le RFC de base est explicite :

“The time to live field of the resource record specifies how long this resource record may be cached.” — RFC 1034

Traduction opérationnelle : tant que le TTL n’est pas écoulé, un récursif peut (et le fait généralement) servir l’ancienne réponse, même si OVHcloud publie déjà la nouvelle valeur sur ses NS.

Mini-scénario (très proche du terrain) : vous migrez www.example.com d’un VPS vers un load balancer.

• À 10:00, vous mettez à jour le A dans OVHcloud (autorité OK immédiatement).
• Un client sur un réseau A interroge un résolveur récursif qui avait déjà la vieille IP en cache à 09:50 : il peut continuer à voir l’ancien site jusqu’à expiration.
• Un client sur un réseau B (autre FAI / autre entreprise / DNS public) n’avait rien en cache : il voit la nouvelle IP tout de suite.

Ce n’est pas “aléatoire” : c’est la conséquence mécanique du cache distribué. Et en France (ou plus largement en Europe), l’effet est souvent accentué par la diversité des résolveurs utilisés (FAI grand public, DNS d’entreprise, DNS publics, et de plus en plus de DoH).

Deux cas sont systématiquement confondus : (1) modifier un RR dans une zone déjà déléguée (A/AAAA/TXT, etc.), et (2) changer la délégation NS (passer de NS OVHcloud à Cloudflare, ou l’inverse). Le second cas dépend des caches en amont (y compris des serveurs TLD) et du TTL des enregistrements NS/DS ; c’est le scénario où on voit encore des résolutions « anciennes » pendant 24–48h sur certains réseaux. Si vous cherchez une bascule rapide, évitez de changer les NS en urgence : faites-le planifié, avec baisse de TTL préalable et fenêtre de monitoring.

Point important si DNSSEC est activé : en cas de changement de NS, la cohérence DS/DNSKEY devient un facteur de panne “non intuitive”. Un DS obsolète au registrar peut produire du SERVFAIL chez des résolveurs validateurs, même si “chez vous” tout semble fonctionner. (C’est aussi une raison pour laquelle les tests doivent être faits depuis plusieurs résolveurs, pas uniquement depuis votre poste.)

Enfin, il faut intégrer le negative caching : si vous créez un sous-domaine qui n’existait pas (staging.example.com), certains résolveurs auront pu mettre en cache un NXDOMAIN et continuer à répondre « n’existe pas » jusqu’à expiration. Là encore, ce n’est pas un bug d’OVHcloud, c’est la spec :

“Negative caching is the storage of knowledge that something does not exist.” — RFC 2308

À retenir pour les environnements agiles (staging/preview) : une “création DNS” peut sembler lente si le nom a été interrogé juste avant sa création et que la réponse négative a été cachée.

TTL et SOA : régler le cache sans se tirer une balle dans le pied

Le TTL (Time To Live) d’un enregistrement est une durée (en secondes) qui gouverne le cache côté récursifs. Un TTL bas accélère les bascules (migration IP, bascule CDN, rollback), mais augmente le volume de requêtes vers les NS autoritatifs et rend votre disponibilité plus sensible à des incidents de résolution (panne récursif local, congestion). Un TTL haut stabilise la résolution mais rend toute correction plus lente. Il n’y a pas de valeur « universelle » : vous ajustez selon le risque métier et la capacité d’observabilité.

Le SOA (Start of Authority) ajoute une seconde couche de contrôle, souvent mal lue. Il porte notamment des timers utilisés par des secondaires (refresh/retry/expire) et une valeur liée au negative caching (selon RFC 2308, le champ “MINIMUM” sert de TTL négatif par défaut). Concrètement : si vous avez tendance à créer/supprimer des noms (staging, preprod, short-lived), surveillez la politique de TTL négatif, sinon vous vous exposez à des “ça marche chez moi / ça ne résout pas ailleurs” pendant des dizaines de minutes (voire plus) après création.

Valeurs pratiques (ordre de grandeur) pour une boutique PrestaShop (8.x/9.x) en prod, PHP 8.2/8.3, derrière un reverse proxy/CDN ou non :

• Régime stable (pas de migration prévue) : A/AAAA à 3600s–14400s, TXT à 3600s (DKIM/validation), MX à 3600s. Le but est de réduire la variabilité.
• Fenêtre de changement planifiée (migration, failover) : abaissez 24h avant les RR critiques (typiquement A/AAAA de l’apex et www) à 60s–300s, puis remontez après stabilisation.
• Ne jouez pas au “TTL = 0” : certains récursifs imposent des planchers, certains providers aussi, et vous augmentez inutilement la charge. Le gain réel face à 60s est marginal, le coût opérationnel ne l’est pas.

Pour rendre la décision plus “opérationnelle”, voici un mémo simple (à adapter) :

Type de record	Si vous changez rarement	Si vous prévoyez des bascules / rollback	Risque typique si TTL trop bas
A / AAAA (web)	3600–14400	60–300 (temporaire)	charge DNS + dépendance accrue à la résolution
CNAME (ex: www)	3600–14400	300–900	chaînes CNAME plus sensibles aux incidents amont
MX	3600–14400	300–900 (si migration mail)	bascules mail “flappantes” si mal planifiées
TXT (SPF/DKIM/DMARC/ACME)	3600–14400	300–900 lors d’une phase de validation	erreurs de validation si changements multiples rapides

Point que beaucoup ratent : baisser le TTL n’a d’effet qu’après expiration des caches existants. Si votre A est à 3600s et que vous le passez à 60s à 10:00, les caches qui ont récupéré l’ancien RR à 09:59 peuvent rester valides jusqu’à ~10:59. D’où la règle : baisse de TTL en amont, puis changement de cible une fois le nouveau TTL « en circulation ».

Autre point utile en incident : distinguez TTL servi par l’autorité vs TTL restant dans le cache. Un dig “normal” vous montrera souvent un TTL qui décroît (valeur restante dans le cache du résolveur interrogé), ce qui est parfait pour comprendre où en est la convergence… mais pas pour savoir si OVHcloud publie bien la valeur attendue.

Bonnes pratiques de configuration sur OVHcloud : web, CDN, mail, TLS

Pour le web, séparez clairement l’apex (example.com) et www. L’apex ne peut pas être un CNAME dans le DNS classique (contrainte de la RFC et des implémentations). Sur OVHcloud, partez sur un apex en A/AAAA vers votre point d’entrée (LB, reverse proxy, CDN si vous avez une IP dédiée), et un www en CNAME vers l’apex ou vers un nom cible. Pattern robuste : apex = A/AAAA, www = CNAME @, puis redirection 301 (HTTP) vers www ou vers l’apex, mais pas les deux. Évitez la cohabitation ambiguë A + CNAME sur le même label : certains outils l’acceptent, beaucoup de résolveurs/validateurs la considèrent incohérente.

Si vous utilisez plusieurs IP (HA/cluster), assumez-le explicitement : deux A (ou plus) sur le même nom sont une forme de round-robin DNS, pas un load balancing intelligent. Ça peut convenir pour de la tolérance “best effort”, mais ça ne remplace pas un vrai LB avec health checks. En e-commerce, l’approche la plus robuste reste souvent : DNS → point d’entrée unique (LB/reverse proxy/CDN) → pool applicatif.

Si vous introduisez un CDN, ne confondez pas cache DNS et cache HTTP. Le DNS vous amène à l’edge, le CDN cache ensuite au niveau HTTP ; régler un TTL DNS n’améliore pas vos Core Web Vitals par magie. En revanche, une configuration DNS propre conditionne une adoption CDN sans surprises (subdomain, CNAME, validation TLS, records ACME). Pour une stratégie CDN en 2026 (coûts, features, HTTP/3, purge, shielding), vous avez une base comparative ici : CDN en 2026 : comparatif Bunny.net, Cloudflare, Akamai, CloudFront, Fastly. Et côté boutique, l’impact se joue ensuite sur les bons leviers PrestaShop (assets, CCC, cache Smarty, invalidations) : PrestaShop : optimiser performance via cache Smarty, CCC et CDN.

• Les challenges ACME (Let’s Encrypt et autres) passent souvent par des TXT du type _acme-challenge. Si vous avez un TTL très long sur les TXT, vos itérations de validation peuvent devenir pénibles.
• Si votre fournisseur CDN vous demande de pointer un CNAME vers un nom “edge”, vérifiez la cohérence des chaînes de CNAME (un CNAME qui pointe vers un autre CNAME, etc.). Ça marche, mais plus la chaîne est longue, plus vous multipliez les dépendances.

Pour le mail, un DNS « qui marche » ne suffit pas : il faut un DNS « qui délivre ». Vérifiez systématiquement :

• MX cohérents (pas de reliquats si vous avez migré la messagerie), TTL raisonnable.
• SPF (TXT) : une politique qui couvre vos émetteurs réels (serveur applicatif, ESP, CRM). Trop permissif (+all) = inutile. Et gardez en tête la contrainte bien connue : une politique SPF peut devenir fragile si elle déclenche trop de recherches DNS (enchaînements d’include, mécanismes a, mx, etc.).
• DKIM (TXT) : clés par sélecteur, idéalement 2048 bits si votre fournisseur le supporte.
• DMARC (TXT _dmarc) : commencez en p=none pour mesurer, puis durcissez (quarantine/reject) quand vous avez de la visibilité.

Exemple minimal (à adapter, et à déployer avec prudence) :

• SPF : v=spf1 include:... -all
• DMARC (démarrage “observabilité”) : v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Ajoutez aussi un enregistrement CAA pour cadrer l’émission de certificats (réduction de surface de compromission CA) ; c’est un garde-fou simple, souvent absent des zones historiques. Enfin, si vous déléguez des sous-domaines (ex : assets.example.com chez un CDN, mail.example.com chez un provider), documentez-le : une délégation NS partielle non maîtrisée est un classique des incidents « intermittent ».

Une bonne pratique “hygiène” qui s’applique très bien en équipe : gardez un petit inventaire (même un simple tableau) de qui “possède” quoi :

• @ et www : web / CDN
• api : backend
• mail, autodiscover, smtp, imap : messagerie
• _dmarc, selector._domainkey : authentification mail
• _acme-challenge : certificats

Ça réduit les erreurs de manipulation, surtout quand plusieurs prestataires interviennent (hébergeur, infogérant, agence, email provider).

Changements contrôlés et diagnostic : plan de bascule, commandes dig, monitoring

Un changement DNS en production se traite comme un déploiement : préparation, fenêtre, vérification, rollback. La méthode qui évite 80% des pannes : (1) inventaire des RR concernés, (2) baisse de TTL J-1, (3) bascule à heure creuse, (4) monitoring multi-résolveurs, (5) remontée TTL, (6) nettoyage (anciens RR, validations). Pour une migration d’infra e-commerce, vous gagnez à coupler ça avec un plan de bascule applicative (blue/green, tests synthétiques, rollback) plutôt que de “changer l’IP et prier” ; la logique est similaire à une migration PrestaShop sans coupure : Migration PrestaShop 1.6/1.7/8 vers PrestaShop 9 sans coupure.

Pour les changements de délégation NS (cas le plus risqué), ajoutez deux règles :

• Publiez la même zone chez l’ancien et le nouveau fournisseur pendant une période de recouvrement (mêmes A/AAAA/CNAME/TXT/MX, mêmes validations mail). Ça rend la transition tolérante aux caches “en retard”.
• Si DNSSEC est en jeu, traitez DS comme un change séparé : DS incorrect = SERVFAIL chez les validateurs, symptôme typique “ça marche depuis mon réseau, pas depuis un autre”.

Exemple concret (pattern fréquent) : bascule d’un frontal Nginx vers un load balancer, en gardant PrestaShop et la base inchangés. J-1, vous passez A @ et CNAME www à 120s. J0, vous basculez l’IP vers le LB, vous vérifiez l’état TLS (SNI, cert), puis vous gardez l’ancienne IP disponible pendant au moins 2×TTL. Si vous devez rollback, vous réécrivez le A et vous retrouvez une convergence en quelques minutes (selon caches). Ce workflow est banal, mais il impose d’accepter une contrainte : il faut une double capacité temporaire (ancien et nouveau point d’entrée) pendant la fenêtre.

Pour diagnostiquer proprement, arrêtez d’utiliser uniquement “vider le cache DNS Windows”. Utilisez des requêtes ciblées :

# Vérifier la réponse vue par un récursif précis
$ dig @1.1.1.1 www.example.com A +noall +answer

# Voir les TTL et comparer plusieurs résolveurs
$ dig @8.8.8.8 www.example.com A +noall +answer
$ dig @9.9.9.9 www.example.com A +noall +answer

# Comprendre la chaîne complète (utile en cas de délégation cassée)
$ dig +trace www.example.com A

# Inspecter SOA (utile pour TTL négatif / cohérence)
$ dig example.com SOA +noall +answer

Deux commandes supplémentaires, très utiles pour séparer “OVHcloud publie-t-il bien ?” de “les caches ont-ils expiré ?” :

# Interroger directement un serveur autoritatif (réponse "source")
# (remplacez nsX par un NS listé dans la délégation)
$ dig @ns1.example-dns.tld www.example.com A +norecurse +noall +answer

# Vérifier les NS vus publiquement (utile après un changement de délégation)
$ dig example.com NS +noall +answer

Si l’incident est “ça ne résout pas” : cherchez d’abord NXDOMAIN (negative cache), SERVFAIL (souvent DNSSEC/autorité injoignable), ou un conflit AAAA (IPv6) pointant vers une infra non prête. Pour objectiver, utilisez une sonde externe type RIPE Atlas ou un check depuis plusieurs régions, pas uniquement depuis votre poste. Et si vous automatisez des changements (API OVHcloud, CI/CD infra), traitez la zone DNS comme du code : diff, review, historique, et droits minimaux (au passage, les principes IAM et traçabilité s’appliquent très bien à la gestion DNS : voir aussi créer un compte de service OVHcloud et déléguer finement les permissions).

Dernier point, terre-à-terre : une « bonne » configuration DNS est celle qui réduit l’entropie. Peu de RR, des TTL cohérents, pas de doublons, des sous-domaines explicites pour séparer web/assets/api, et une politique mail complète (SPF/DKIM/DMARC). Quand ça casse, vous voulez pouvoir répondre à deux questions en 5 minutes : qui fait autorité ? et qui a encore l’ancienne valeur en cache ? Le reste n’est que de l’exécution.