Relier un nom de domaine à un VPS : le guide DNS complet

Vous avez un nom de domaine d'un côté, un VPS de l'autre, et rien ne se passe quand vous tapez l'adresse. C'est normal : les deux ne se connaissent pas encore. Ce tutoriel détaille les enregistrements DNS à créer, comment vérifier qu'ils sont pris en compte, et comment poser un certificat HTTPS une fois le domaine joignable.

Ce que fait le DNS, en une minute

Votre VPS est joignable par une adresse IP, du type 203.0.113.10. Les visiteurs tapent un nom. Le DNS est l'annuaire mondial qui traduit l'un en l'autre.

Cette traduction se fait en cascade : le navigateur interroge un résolveur, qui demande au registre de l'extension quels serveurs de noms gèrent votre domaine, puis interroge ces serveurs pour obtenir l'adresse. Vous intervenez à la dernière étape : la zone DNS de votre domaine, c'est-à-dire la liste de ses enregistrements.

Chez OmegaCloud, cette zone s'édite depuis l'espace client, et elle est incluse avec chaque nom de domaine. Si votre domaine est ailleurs, l'interface change mais les enregistrements sont les mêmes partout.

Étape 1 : relever les adresses du VPS

Les adresses IPv4 et IPv6 de votre serveur sont affichées dans le panel. Depuis le serveur lui-même, vous pouvez les confirmer :

ip -4 addr show | grep inet
ip -6 addr show | grep inet6

Notez l'IPv4 publique et l'IPv6 globale — celle qui ne commence ni par fe80: ni par ::1.

Étape 2 : créer les enregistrements

L'enregistrement A — le site

C'est l'enregistrement essentiel : il associe votre domaine à l'IPv4 du serveur.

Type	Nom	Valeur	TTL
A	@	203.0.113.10	3600

Le @ désigne le domaine nu, exemple.fr sans sous-domaine. Certaines interfaces demandent de laisser le champ vide plutôt que d'écrire @ : les deux veulent dire la même chose.

L'enregistrement AAAA — l'IPv6

Même rôle, pour les visiteurs qui arrivent en IPv6. Ne le négligez pas : une part croissante du trafic mobile français est en IPv6, et un site qui n'y répond pas force un repli en IPv4, plus lent.

Type	Nom	Valeur	TTL
AAAA	@	2001:db8::10	3600

Le CNAME — le sous-domaine www

Pour que www.exemple.fr réponde aussi, créez un alias vers le domaine nu :

Type	Nom	Valeur	TTL
CNAME	www	exemple.fr.	3600

Le point final n'est pas une faute de frappe : il indique un nom absolu. Sans lui, certains serveurs DNS interprètent la valeur comme exemple.fr.exemple.fr.

Règle à connaître : on ne met pas de CNAME sur le domaine nu (@). La norme l'interdit, parce que le domaine nu porte déjà d'autres enregistrements — NS, SOA, souvent MX — et qu'un CNAME est exclusif. Pour le domaine nu, utilisez un A et un AAAA.

Les MX — le courrier

Les e-mails ne suivent pas l'enregistrement A. Sans MX, une adresse à votre domaine ne recevra rien, même si le site fonctionne parfaitement. Les valeurs sont fournies par votre service de messagerie :

Type	Nom	Valeur	Priorité
MX	@	mail.monservice.fr.	10

La priorité la plus basse est essayée en premier. Un second MX à priorité 20 sert de secours.

Les TXT — l'anti-usurpation

Si vous envoyez des e-mails depuis votre domaine, trois enregistrements TXT évitent que vos messages partent en indésirables et empêchent un tiers d'écrire en votre nom : SPF, DKIM et DMARC. Le SPF, par exemple :

v=spf1 include:monservice.fr -all

Si vous n'envoyez aucun e-mail depuis le domaine, publiez un SPF qui le dit — c'est la meilleure protection contre l'usurpation :

v=spf1 -all

Étape 3 : la propagation, sans les mythes

On lit partout « comptez 24 à 48 heures ». C'est faux dans la grande majorité des cas, et le vrai mécanisme est simple.

Chaque enregistrement porte un TTL, en secondes : la durée pendant laquelle les résolveurs ont le droit de garder la réponse en mémoire. Quand vous modifiez un enregistrement, les résolveurs qui l'avaient déjà en cache continuent de servir l'ancienne valeur jusqu'à l'expiration du TTL qui était en place avant votre modification. Un enregistrement créé de zéro, lui, est visible presque immédiatement : il n'y a pas d'ancienne valeur en cache.

• Première mise en service d'un domaine neuf : quelques minutes.
• Changement d'IP sur un enregistrement existant : le TTL précédent, souvent une heure.
• Changement de serveurs de noms : là, c'est plus long, les registres utilisant des TTL de 24 à 48 heures. C'est de ce cas que vient le chiffre répété partout.

Avant une migration prévue, abaissez le TTL à 300 secondes 24 heures à l'avance. Le jour J, le basculement se fait en cinq minutes. Remontez le TTL ensuite : un TTL très court multiplie les requêtes.

Étape 4 : vérifier

Deux commandes suffisent.

dig exemple.fr A +short
dig www.exemple.fr CNAME +short

La première doit renvoyer l'IP de votre VPS. Si elle ne renvoie rien, l'enregistrement n'est pas encore publié ou le domaine n'est pas délégué.

Pour contourner votre propre cache et interroger un résolveur public :

dig @1.1.1.1 exemple.fr A +short

Et pour voir le TTL restant, qui vous dit combien de temps l'ancienne valeur circule encore :

dig exemple.fr A

Le chiffre de la section ANSWER SECTION, entre le nom et IN, décompte en secondes.

Étape 5 : le serveur doit répondre au nom

Le DNS pointe vers le serveur, mais le serveur web doit encore savoir quoi servir pour ce nom. Sur Nginx :

server {
    listen 80;
    listen [::]:80;
    server_name exemple.fr www.exemple.fr;
    root /var/www/exemple;
    index index.html;
}

Testez la configuration puis rechargez :

sudo nginx -t
sudo systemctl reload nginx

Le certificat HTTPS

Une fois le domaine joignable en HTTP, Let's Encrypt peut émettre un certificat gratuit. La validation passe par une requête HTTP sur votre domaine : elle échouera tant que le DNS ne pointe pas correctement, ce qui en fait aussi un bon test.

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d exemple.fr -d www.exemple.fr

Certbot modifie la configuration Nginx, met en place la redirection vers HTTPS et installe un renouvellement automatique. Vérifiez-le :

sudo certbot renew --dry-run

Les erreurs les plus fréquentes

Symptôme	Cause habituelle	Correction
Le domaine nu marche, pas le www	CNAME www absent	Créer le CNAME vers le domaine nu
Le www marche, pas le domaine nu	CNAME posé sur @	Remplacer par un A (et un AAAA)
Le site répond, pas les e-mails	Aucun MX	Ajouter les MX du service de messagerie
L'ancienne IP répond encore	TTL précédent non expiré	Attendre, ou vérifier via dig @1.1.1.1
Certbot échoue en validation	DNS pas encore propagé, ou port 80 fermé	Vérifier avec dig, puis le pare-feu
Boucle de redirection en HTTPS	Double redirection Nginx et application	N'en garder qu'une

Pour aller plus loin

• Si votre serveur est sous Windows Server, le volet client et le rôle DNS sont traités dans notre tutoriel configurer le DNS sur un VPS Windows.
• Pour gérer plusieurs zones depuis une interface, voir notre comparatif des panels de gestion DNS.
• Pas encore de serveur ? Nos VPS Linux et VPS Windows sont déployés en moins de 60 secondes, avec une IPv4 et une IPv6 dédiées.

À retenir

• A et AAAA sur @, CNAME sur www : c'est le minimum pour qu'un site réponde.
• Jamais de CNAME sur le domaine nu.
• Le point final dans une valeur CNAME ou MX n'est pas optionnel.
• Les 48 heures de propagation sont un mythe : c'est le TTL de l'ancienne valeur qui commande.
• Abaissez le TTL 24 heures avant une migration, remontez-le après.
• Sans MX, pas d'e-mail — même si le site fonctionne.