Skip to Content
Serveur LinuxPartie 6 — Réseau, DNS & domaine6.3 — Pointer un domaine

Chapitre 6.3 — Pointer un domaine

⏱️ TL;DR — C’est le geste de cette partie : faire pointer un vrai domaine vers ton VPS. Tu achètes le nom chez un registrar, tu ouvres sa zone DNS, et tu crées les enregistrements : un A sur l’apex (@, c’est-à-dire formacampus.fr nu) vers l’IP du VPS, un enregistrement pour www, puis des sous-domaines (api., staging.) selon tes besoins. Tu apprends au passage un piège classique — le CNAME est interdit sur l’apex (d’où les alternatives ALIAS/ANAME) — puis tu attends le TTL et tu vérifies avec dig. Une fois le nom qui résout vers ton IP, le trafic arrive à la porte du VPS : il ne reste qu’à l’accueillir avec Nginx (Partie 7) et à le chiffrer (Partie 8).

🎯 Objectifs

  • Acheter un domaine et accéder à son interface de zone DNS.
  • Créer un enregistrement A sur l’apex (@) vers l’IP du VPS.
  • Gérer www (A ou CNAME) et créer des sous-domaines (api., staging.).
  • Comprendre pourquoi le CNAME est interdit sur l’apex et ce que sont ALIAS/ANAME.
  • Attendre la propagation intelligemment (TTL) et vérifier avec dig / nslookup.
  • Savoir où ces noms se rebrancheront ensuite : server_name de Nginx et le certificat HTTPS.

Étape 1 — Acheter le domaine

Tout commence chez un registrar (OVH, Gandi, Namecheap, Cloudflare Registrar…). Tu cherches formacampus.fr, tu vérifies qu’il est libre, tu le paies (quelques euros à quelques dizaines d’euros par an selon le TLD). En quelques minutes, le nom est à toi.

Deux réflexes dès l’achat :

  • Active la protection de la vie privée (WHOIS privacy) si le registrar la propose : sans elle, tes coordonnées peuvent apparaître dans l’annuaire public WHOIS.
  • Note la date d’expiration et active le renouvellement automatique. Un domaine qui expire, c’est un site hors ligne du jour au lendemain — et parfois un nom racheté par un tiers dans la foulée.

⚠️ Piège — Laisser expirer un domaine est l’une des pannes les plus bêtes et les plus coûteuses. Le site tombe, les mails ne partent plus, et récupérer un nom expiré peut coûter cher ou être impossible s’il est repris. Renouvellement automatique activé, carte de paiement à jour, et une alerte agenda quelques semaines avant l’échéance.

Étape 2 — Ouvrir la zone DNS

Dans l’interface du registrar (ou de ton hébergeur DNS si tu as délégué la zone, voir chapitre 6.2), tu cherches la section « Zone DNS », « DNS » ou « Enregistrements ». Tu y verras déjà quelques enregistrements par défaut (souvent des NS et parfois un A « parking »). C’est ta table : chaque ligne est un enregistrement (type, nom, valeur, TTL).

Avant de toucher quoi que ce soit, récupère l’IP publique de ton VPS. Depuis le VPS :

ip -brief a        # affiche l'IP de l'interface (souvent eth0)
# ou, pour l'IP publique vue de l'exterieur :
curl -4 ifconfig.co   # renvoie ton IPv4 publique
curl -6 ifconfig.co   # renvoie ton IPv6 publique, si tu en as une

Note l’IPv4 (pour le A) et, si tu en as une, l’IPv6 (pour le AAAA).

Étape 3 — L’enregistrement A sur l’apex

L’apex (aussi appelé root domain, zone apex ou domaine nu) est le domaine sans sous-partie : formacampus.fr tout court, sans www. Dans l’interface, il se désigne par @ (ou parfois un champ « nom » laissé vide).

Tu crées donc l’enregistrement principal :

Type   Nom   Valeur          TTL
A      @     203.0.113.10    3600

Traduction : « formacampus.fr mène à 203.0.113.10 ». Si ton VPS a une IPv6, tu ajoutes en parallèle :

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

C’est le geste central : à partir de là, formacampus.fr pointe vers ta machine (une fois le TTL écoulé). Le reste n’est que déclinaisons.

🐚 Au terminal — Pour vérifier, depuis n’importe où, que l’apex pointe bien où tu veux :

dig formacampus.fr A +short       # doit renvoyer 203.0.113.10
dig formacampus.fr AAAA +short    # doit renvoyer 2001:db8::10

Étape 4 — Le cas www

Historiquement, on tape autant formacampus.fr que www.formacampus.fr — les deux doivent mener au même site. Deux façons de faire pour www :

  • Un CNAME www → formacampus.fr : www devient un alias de l’apex. Avantage : si l’IP change, tu ne la modifies qu’à un seul endroit (le A de l’apex), et www suit automatiquement. C’est la méthode recommandée quand c’est possible.
  • Un A www → 203.0.113.10 : tu répètes l’IP. Simple, mais si l’IP change, tu as deux enregistrements à mettre à jour.
Type    Nom    Valeur              TTL
CNAME   www    formacampus.fr      3600

Le choix www vers apex ou apex vers www (lequel est « canonique ») se règle ensuite, côté Nginx, avec une redirection (Partie 7). Côté DNS, l’essentiel est que les deux résolvent vers ton serveur.

Étape 5 — Le piège de l’apex : pas de CNAME dessus

Voici la subtilité que tout le monde découvre un jour. Le standard DNS interdit un CNAME sur l’apex d’un domaine. La raison technique : l’apex porte obligatoirement d’autres enregistrements (les NS, souvent un MX), et un CNAME exige d’être seul sur son nom — les deux sont incompatibles. Donc pas de CNAME @ → autre-chose.

Concrètement, ça pose problème quand un service (un PaaS, un CDN) te demande de pointer ton apex vers un nom (ton-app.exemple-paas.com) plutôt que vers une IP fixe. Sur www, pas de souci : un CNAME suffit. Sur l’apex, c’est interdit. Deux solutions :

  • Un enregistrement A vers l’IP fixe, quand tu en as une (c’est ton cas avec un VPS : ton IP est fixe, donc A @ → ton_IP, et le problème n’existe pas).
  • Un ALIAS / ANAME (parfois appelé CNAME flattening chez certains hébergeurs comme Cloudflare) : un type d’enregistrement non standard proposé par certains hébergeurs DNS, qui se comporte comme un CNAME mais est autorisé sur l’apex (l’hébergeur résout le nom cible et renvoie l’IP à la place). C’est la parade quand la cible n’a pas d’IP fixe.

💡 Réflexe — Avec un VPS, tu as une IP fixe : tu n’as donc presque jamais besoin d’ALIAS/ANAME. Tu poses un simple A sur l’apex vers l’IP du VPS, et un CNAME (ou un A) sur www. Garde l’ALIAS/ANAME en tête uniquement pour le jour où tu devras pointer un apex vers un service sans IP fixe.

Étape 6 — Les sous-domaines

Un sous-domaine est un nom sous ta zone : api.formacampus.fr, staging.formacampus.fr, admin.formacampus.fr. Tu en crées autant que tu veux, chacun avec son propre enregistrement. Le nom de l’enregistrement est juste la partie de gauche.

Type   Nom       Valeur          TTL
A      api       203.0.113.10    3600
A      staging   203.0.113.10    3600

Ici, api et staging pointent vers le même VPS que l’apex. C’est courant : un seul serveur héberge plusieurs services, et c’est Nginx qui, selon le server_name demandé, dirige vers la bonne application (Partie 7). Rien n’empêche, si tu grandis, de faire pointer staging vers un autre VPS avec une autre IP.

🔒 Sécurité — Un sous-domaine comme staging.formacampus.fr résout publiquement dès que tu l’ajoutes : il est visible de quiconque interroge le DNS (et les scanners de sous-domaines existent). Le DNS ne protège rien — il ne fait qu’indiquer où frapper. La protection d’un environnement de préproduction se fait ailleurs : restriction par IP, authentification HTTP (auth_basic côté Nginx), pare-feu. Ne considère jamais un sous-domaine « obscur » comme secret.

Étape 7 — Attendre (intelligemment) et vérifier

Tes enregistrements sont posés. Maintenant, la patience raisonnée : tant que les anciens caches ne sont pas expirés, la résolution peut être incohérente d’un endroit à l’autre. Le facteur, c’est le TTL (chapitre 6.2). Si c’est un premier enregistrement (rien à remplacer), la résolution est souvent visible en quelques minutes. Si tu modifies un enregistrement existant, il faut attendre l’expiration de l’ancien TTL.

Pour vérifier sans attendre le cache de ton propre resolver, interroge un resolver public « frais » :

dig @1.1.1.1 formacampus.fr +short      # interroge le resolver de Cloudflare
dig @8.8.8.8 formacampus.fr +short      # interroge celui de Google
nslookup formacampus.fr 1.1.1.1         # equivalent avec nslookup

Si plusieurs resolvers publics renvoient déjà ta nouvelle IP, c’est bon : ton autoritaire est correct, il ne reste plus qu’à attendre que ton cache local expire. (Détails de la trousse dig / nslookup au chapitre 6.4.)

⚠️ Piège — Ne juge jamais l’état de ton DNS depuis le seul cache de ta machine ou de ton navigateur (qui a son propre cache DNS, à vider séparément). Le navigateur et l’OS peuvent servir une valeur périmée bien après que le DNS « public » soit correct. Vérifie toujours avec dig @un-resolver-public pour trancher.

Étape 8 — Où ces noms se rebrancheront

Pointer le domaine, c’est amener le trafic à la porte du VPS. La suite du cours l’accueille :

  • Nginx (Partie 7) écoute sur 80/443 et, selon le server_name (formacampus.fr, api.formacampus.fr…), relaie vers la bonne application locale. Les noms que tu viens de créer deviennent les valeurs de server_name.
  • Le certificat HTTPS (Partie 8) est délivré par Let’s Encrypt pour ces noms précis — et Let’s Encrypt vérifie, au moment de la demande, que le nom résout bien vers ton serveur. Autrement dit : le DNS doit être correct AVANT de demander le certificat. C’est pour ça que cette partie vient avant le HTTPS.

🧭 Sur FormaCampus — Concrètement, la zone de formacampus.fr finit ainsi : A @ → 203.0.113.10 et AAAA @ → 2001:db8::10 (l’apex vers le VPS), CNAME www → formacampus.fr (le www suit l’apex), A api → 203.0.113.10 (l’API Symfony, même VPS, distinguée par Nginx via server_name), A staging → 203.0.113.10 (préprod, protégée par auth_basic), un MX vers le fournisseur de messagerie (le mail ne touche pas le VPS) et un TXT SPF. La veille du rapatriement depuis l’ancien PaaS, l’équipe a baissé le TTL du A à 300, puis basculé l’IP le jour J ; la vérification s’est faite d’un dig @1.1.1.1 formacampus.fr +short répété jusqu’à voir la nouvelle IP partout. Une fois le DNS stable, direction la Partie 7 pour brancher Nginx sur ces noms.

✏️ Exercices

Exercice 1 — Écris la zone. Ton VPS est en 198.51.100.7 (pas d’IPv6). Écris les enregistrements pour que exemple.fr, www.exemple.fr et api.exemple.fr mènent tous à ce VPS, www étant un alias de l’apex.

✅ Solution

Type    Nom    Valeur          TTL
A       @      198.51.100.7    3600
CNAME   www    exemple.fr      3600
A       api    198.51.100.7    3600

L’apex (@) et api sont des A vers l’IP (on ne peut pas mettre de CNAME sur l’apex, et api peut être un A direct). www est un CNAME vers l’apex : si l’IP change un jour, seul le A de @ est à modifier, et www suit. On pourrait aussi faire www en A vers l’IP — les deux fonctionnent.

Exercice 2 — Le CNAME refusé. Ton hébergeur DNS refuse de créer un CNAME @ → mon-app.paas.example.com. Pourquoi, et quelles sont tes deux options ?

✅ Solution

Parce que le standard DNS interdit un CNAME sur l’apex : l’apex porte obligatoirement des enregistrements NS (et souvent MX), or un CNAME doit être seul sur son nom. Options : (1) si la cible a une IP fixe, poser un A vers cette IP (c’est ton cas avec un VPS) ; (2) si la cible n’a pas d’IP fixe, utiliser un ALIAS/ANAME (ou CNAME flattening), un enregistrement non standard proposé par certains hébergeurs qui se comporte comme un CNAME mais est autorisé sur l’apex.

🧠 Quiz de révision

1. Comment désigne-t-on l’apex du domaine dans une zone DNS ?

Par @ (ou un champ « nom » laissé vide). L’apex est le domaine nu, sans sous-partie : formacampus.fr sans www. On y pose typiquement le A (et le AAAA) vers l’IP du serveur.

2. Peut-on mettre un CNAME sur l’apex ? Pourquoi ?

Non. L’apex porte obligatoirement d’autres enregistrements (NS, souvent MX), or un CNAME exige d’être seul sur son nom. On utilise donc un A vers une IP fixe, ou un ALIAS/ANAME (non standard) si la cible n’a pas d’IP fixe.

3. Quel est l’intérêt de faire www en CNAME vers l’apex plutôt qu’en A ?

Si l’IP change, tu ne la modifies qu’à un seul endroit (le A de l’apex) : www, étant un alias, suit automatiquement. Avec deux A, tu aurais deux enregistrements à mettre à jour et un risque d’oubli.

4. Comment vérifier qu’un domaine pointe vers la bonne IP sans être trompé par ton cache local ?

En interrogeant un resolver public « frais » : dig @1.1.1.1 formacampus.fr +short (ou @8.8.8.8). Cela contourne le cache de ton propre resolver et du navigateur, et montre la valeur réellement servie publiquement.

5. Pourquoi faut-il que le DNS soit correct AVANT de demander un certificat HTTPS ?

Parce que Let’s Encrypt vérifie, au moment de délivrer le certificat, que le nom résout bien vers ton serveur. Si le DNS ne pointe pas encore correctement, la validation échoue. Le DNS (Partie 6) vient donc avant le HTTPS (Partie 8).

Chapitre suivant : Diagnostic réseau — la trousse à outils (dig, ss, curl, nc…) pour répondre à « ça bloque où ? ».

Last updated on
6.2 — Comment marche le DNS6.4 — Diagnostic réseau