Configurer ses DNS sur Gandi : le guide pas à pas

Où trouver la zone DNS chez Gandi

Gandi est un des rares registrars où la zone DNS n’est pas toujours au même endroit selon l’ancienneté du domaine. Avant d’aller plus loin, vérifie que tu es bien sur le bon système.

Prérequis :

• Un compte Gandi avec un domaine actif
• Les droits d’administration sur ce domaine (pas juste un accès lecture)
• Savoir vers quoi tu veux pointer : hébergeur mutualisé, VPS, ou plateforme comme Vercel/Netlify
• Un client email pro si tu configures aussi les MX (Gmail Workspace, Outlook, etc.)

Connecte-toi sur admin.gandi.net, clique sur ton domaine dans la liste, puis va dans l’onglet DNS Records (parfois affiché “Enregistrements DNS” en français). C’est le système LiveDNS, standard chez Gandi depuis plusieurs années. Si tu vois un message indiquant que ton domaine utilise encore l’ancien serveur DNS Gandi (avant migration LiveDNS), un bouton “Enable LiveDNS” apparaît, clique dessus pour basculer, sinon certaines fonctions récentes (ALIAS, DNSSEC simplifié) ne seront pas disponibles.

Un point qui piège beaucoup de monde : si ton domaine est enregistré chez Gandi mais que les DNS sont délégués ailleurs (Cloudflare par exemple), tu ne verras aucun enregistrement ici, normal, il faut modifier la zone chez le prestataire qui gère réellement le DNS. Vérifie les “Nameservers” dans l’onglet Domain pour savoir qui a la main. C’est le même principe que sur Cloudflare ou o2switch : un seul endroit fait autorité à la fois.

Comprendre les enregistrements existants avant de toucher à quoi que ce soit

Avant toute modification, fais une capture d’écran ou un export de la zone actuelle. Gandi propose un bouton “Export” en haut de la page, utilise-le, ça évite de tout reconstruire à la main si tu casses quelque chose.

Repère les lignes suivantes :

• A : pointe un nom vers une IPv4 (ex : @ → 51.x.x.x)
• AAAA : équivalent en IPv6
• CNAME : redirige un sous-domaine vers un autre nom (souvent www → ton domaine racine, ou vers un CDN)
• MX : indique le serveur qui gère les emails
• TXT : données diverses (vérification de propriété, SPF, DKIM)

Chez Gandi, les noms sont relatifs, pas absolus. Pour la racine du domaine, tape @, jamais le nom complet du domaine. Pour www, tape www, pas www.tondomaine.fr.. C’est une source d’erreur fréquente pour qui vient d’un autre registrar où le nom complet est parfois attendu.

Pointer le domaine racine vers ton hébergeur (A / AAAA)

Pour faire pointer tondomaine.fr vers un serveur (VPS, mutualisé, hébergeur classique) :

1. Clique sur Add a record (ou l’icône +)
2. Type : A
3. Name : @
4. TTL : laisse la valeur par défaut (10800 secondes, soit 3h) sauf si tu prépares une migration, voir plus bas
5. Value : l’adresse IPv4 fournie par ton hébergeur
6. Valide, puis répète pour l’enregistrement AAAA si ton hébergeur fournit une IPv6

Piège spécifique Gandi : impossible de mettre un CNAME sur @ (la racine). C’est une règle du protocole DNS, pas une limitation Gandi, mais Gandi a ajouté un type maison, ALIAS, qui simule un CNAME sur la racine en le résolvant côté serveur. Utile si ton hébergeur (Vercel, Netlify, certains CDN) ne fournit qu’un nom d’hôte et pas d’IP fixe pour la racine. Sélectionne ALIAS au lieu de A dans ce cas.

Si ton site est en train de changer d’hébergeur, consulte d’abord la checklist migration sans coupure, la bascule DNS est souvent le maillon qui casse tout si elle est mal planifiée.

Configurer le sous-domaine www (CNAME)

La majorité des sites veulent que www.tondomaine.fr fonctionne aussi, pas seulement la racine.

1. Add a record, type CNAME
2. Name : www
3. Value : tondomaine.fr., attention au point final, Gandi l’exige pour les FQDN complets dans la valeur d’un CNAME, sinon l’enregistrement est invalide ou mal interprété
4. TTL : par défaut

Erreur classique : créer un CNAME www alors qu’il existe déjà un A ou un AAAA sur www. Un nom ne peut avoir qu’un seul type d’enregistrement à la fois en matière de CNAME (règle DNS stricte). Gandi refuse la sauvegarde et affiche une erreur, supprime l’ancien enregistrement d’abord.

Configurer les emails : enregistrements MX et TXT (SPF/DKIM)

Si tu utilises Google Workspace, Microsoft 365 ou un autre service mail pro, la zone MX doit pointer vers leurs serveurs, pas vers ton hébergeur web.

1. Supprime les MX par défaut de Gandi si tu utilises une messagerie externe (Gandi propose parfois un mail forwarding basique qui entre en conflit)
2. Add a record, type MX, Name @, Value : le serveur fourni par ton prestataire mail (ex : aspmx.l.google.com.), Priority : celle indiquée par le prestataire
3. Ajoute ensuite le TXT SPF en type TXT, Name @, Value : v=spf1 include:_spf.google.com ~all (adapte selon ton fournisseur)
4. Ajoute le DKIM fourni par ton prestataire, généralement en Name du type google._domainkey

Piège important : Gandi n’autorise qu’un seul enregistrement SPF (TXT commençant par v=spf1) par domaine. Si tu en ajoutes un deuxième au lieu de fusionner les include: dans un seul enregistrement, les serveurs de réception ignoreront ou rejetteront le SPF, tes emails finiront en spam. Si tu galères sur ce point précis, le guide sur SPF, DKIM et DMARC détaille la syntaxe exacte à respecter. Et si après configuration tes emails WordPress n’arrivent toujours pas, regarde du côté de la configuration SMTP.

TTL et propagation : ce qui se passe après avoir sauvegardé

Le TTL (Time To Live) définit combien de temps les résolveurs DNS gardent l’info en cache avant de la revérifier. Chez Gandi, la valeur par défaut est 10800 secondes (3h), modifiable enregistrement par enregistrement.

Avant une migration planifiée (changement d’hébergeur, bascule de serveur mail) :

1. 24 à 48h avant, réduis le TTL à 300 secondes sur les enregistrements concernés
2. Attends que ce TTL réduit se propage (le double du TTL précédent est une bonne marge)
3. Effectue la bascule
4. Une fois la nouvelle config stable, remonte le TTL à sa valeur normale pour réduire la charge sur les résolveurs

Un TTL bas ne garantit pas une propagation instantanée partout, certains FAI ou résolveurs publics ignorent les TTL courts. Compte 5 minutes à 2h dans la majorité des cas, jusqu’à 24-48h dans les cas extrêmes. Si le domaine ne pointe toujours pas après ce délai, le guide de diagnostic DNS liste les vérifications à faire (nameservers, cache local, outils dig).

Cas particulier : pointer vers Vercel ou Netlify

Ces plateformes fournissent souvent une IP fixe pour la racine et un nom d’hôte pour les sous-domaines.

• Pour la racine @ : utilise le type A avec l’IP fournie, ou ALIAS si Vercel/Netlify recommande un CNAME sur l’apex
• Pour www : CNAME classique vers le nom d’hôte fourni (ex : cname.vercel-dns.com.)
• Vérifie ensuite le certificat SSL côté plateforme, il se génère automatiquement une fois le DNS propagé, mais peut prendre plusieurs heures

Le détail complet des pièges DNS/SSL sur ces deux plateformes est couvert dans domaine perso sur Vercel/Netlify.

Pièges courants

Une fois la zone stabilisée, garde une copie exportée à jour à chaque modification majeure. Si un jour tu changes de prestataire ou reprends la main sur un domaine mal configuré par une ancienne agence, ce fichier d’export évite de repartir de zéro, le même principe s’applique quand il faut reprendre le contrôle d’un nom de domaine laissé en friche.