Nom de domaine et DNS de A à Z
Le DNS est la pièce du web qu'on ne regarde jamais, jusqu'au jour où on la casse. Et quand on la casse, ce n'est presque jamais le site qui tombe : c'est la messagerie, sans message d'erreur, sans que personne s'en rende compte avant plusieurs heures.
Avant d'appliquer ce mémo
Les manipulations décrites ici peuvent entraîner une perte de données ou l'indisponibilité d'un service. Avant d'en appliquer une seule : faites une sauvegarde complète et vérifiez qu'elle se restaure, travaillez d'abord sur un environnement sans enjeu, et n'exécutez aucune commande dont vous ne comprenez pas l'effet.
Ce mémo est un contenu pédagogique de portée générale. Il ne tient pas compte de votre situation, n'a pas valeur de conseil professionnel, et son application relève de votre seule responsabilité. Avertissement et limites d'usage
1. Ce qui se passe quand vous tapez une adresse La chaîne complète, en une minute
Le système de noms de domaine, le DNS, est l'annuaire du réseau : il traduit un nom lisible par un humain en une adresse numérique lisible par une machine. Il ne sert rien, ne stocke aucun site, ne voit passer aucune page. Il répond à une question, et sa réponse décide de tout ce qui suit.
votre box, votre entreprise, 1.1.1.1
Il pose la question à votre place et garde la réponse
13 groupes de serveurs
« Pour du .com, adresse-toi là »
.com, .fr, .ma
« Cette zone est gérée par ces serveurs »
ceux que vous désignez
La réponse officielle : votre zone
Deux conséquences qui expliquent presque tous les incidents
- La seule autorité, c'est vous. Les serveurs qui répondent officiellement pour votre domaine sont ceux que vous avez désignés. Changer de main sur cette désignation, c'est déplacer la vérité entière du domaine d'un coup. C'est le geste le plus lourd de tout ce mémo, et c'est aussi le plus banalisé par les procédures de migration.
- Personne n'interroge la chaîne à chaque fois. Chaque maillon garde les réponses en mémoire pendant une durée que vous fixez. C'est ce qui rend le réseau utilisable, et c'est ce qui fait qu'une correction ne se voit pas immédiatement.
2. Ce que vous achetez vraiment Une location, et à qui elle est faite
Un nom de domaine ne s'achète pas, il se loue, par tranches d'un à dix ans. Trois acteurs interviennent, et savoir lequel fait quoi évite de s'adresser au mauvais le jour où il y a un problème.
Le registre
Il tient la base d'une extension entière : l'AFNIC pour le .fr, Verisign pour le .com. Vous n'avez jamais affaire à lui directement.
Le bureau d'enregistrement
Le revendeur agréé chez qui vous payez. C'est lui qui inscrit votre domaine au registre, et lui seul qui peut le transférer ou le libérer.
Le gestionnaire de zone
Celui qui héberge les enregistrements. Souvent le même que le bureau d'enregistrement, pas toujours, et cette distinction est le sujet de la section 8.
! Le piège du domaine au nom du prestataire
C'est le litige le plus fréquent et le plus destructeur du métier. Une agence achète le domaine « pour simplifier », le déclare à son propre nom, et le client découvre des années plus tard qu'il ne possède pas l'adresse de son entreprise. À la rupture, il perd le site, la messagerie, et le référencement accumulé.
La règle : le domaine appartient au client, déclaré à son nom, sur un compte à lui, avec ses identifiants et son adresse de contact. Un prestataire peut en avoir la gestion déléguée ; il ne doit jamais en être le titulaire. Vérifiez-le sur vos propres domaines dès aujourd'hui, la manœuvre prend deux minutes.
Les quatre réglages à poser une fois
- Le renouvellement automatique, activé, avec un moyen de paiement valide. Une carte expirée est la première cause de perte de domaine.
- Le verrouillage du transfert, activé. Il empêche qu'on déplace le domaine sans votre accord.
- L'adresse de contact du titulaire, qui doit être une adresse que vous lirez encore dans trois ans. Surtout pas une adresse sur le domaine lui-même : le jour où il expire, vous ne recevez plus l'avertissement.
- La protection des coordonnées dans l'annuaire public, presque toujours incluse.
L'expiration, et ce qui vient après
Un domaine qui expire ne redevient pas libre immédiatement. Il passe par une période de grâce où vous pouvez encore le récupérer au tarif normal, puis par une période de rachat où le même domaine coûte souvent dix fois plus, puis il retourne à la vente.
Pendant ce temps, le site est éteint et la messagerie ne reçoit plus rien. Les domaines expirés à valeur commerciale sont surveillés par des robots qui les reprennent à la seconde où ils se libèrent.
3. Anatomie d'un enregistrement Lire une ligne de zone sans hésiter
Une zone DNS est une liste de lignes. Chaque ligne dit la même chose sous une forme différente : pour ce nom, et pour ce type de question, voici la réponse, et voilà combien de temps tu peux la garder.
| Colonne | Ce que c'est | Exemple | Le piège |
|---|---|---|---|
| Nom | Le sous-domaine concerné, relatif au domaine. | www, @, * |
@ désigne le domaine nu. Écrire monsite.com dans un champ qui attend un nom relatif crée monsite.com.monsite.com. |
| Type | La nature de la question à laquelle la ligne répond. | A, MX, TXT |
Deux types différents sur le même nom coexistent sans problème. Deux CNAME sur le même nom, non. |
| Valeur | La réponse renvoyée. | 92.0.2.10 |
Les valeurs qui désignent un nom se terminent par un point dans un fichier de zone. Les interfaces web l'ajoutent seules, ou pas. |
| TTL | La durée de vie de la réponse, en secondes. | 3600 |
Il ne s'applique qu'aux copies faites après sa modification. Voir la section 6. |
| Priorité | Uniquement pour MX et SRV : l'ordre d'essai. | 10 |
Le plus petit nombre passe en premier. C'est contre-intuitif une fois sur deux. |
À quoi ressemble une zone complète et fonctionnelle
; nom TTL type valeur @ 3600 A 92.0.2.10 www 3600 CNAME monsite.com. @ 3600 MX 10 mail1.messagerie.net. @ 3600 MX 20 mail2.messagerie.net. @ 3600 TXT "v=spf1 include:_spf.messagerie.net -all" _dmarc 3600 TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@monsite.com" selecteur._domainkey 3600 TXT "v=DKIM1; k=rsa; p=MIGf..." @ 3600 CAA 0 issue "letsencrypt.org"
4. Les types qui comptent Neuf lignes, et ce que chacune casse
| Type | Répond à la question | Exemple de valeur | Si vous vous trompez |
|---|---|---|---|
| A | Quelle adresse IPv4 sert ce nom ? | 92.0.2.10 |
Le site est injoignable. |
| AAAA | Quelle adresse IPv6 sert ce nom ? | 2001:db8::10 |
Panne intermittente Un AAAA laissé en place après migration envoie une partie des visiteurs sur l'ancien serveur, et seulement eux. |
| CNAME | De quel autre nom celui-ci est-il l'alias ? | www → monsite.com. |
Seule cette adresse-là échoue. Ne peut pas cohabiter avec d'autres types sur le même nom. |
| MX | Quel serveur reçoit les courriels ? | 10 mail.messagerie.net. |
Vous ne recevez plus rien Et l'expéditeur ne reçoit pas toujours d'erreur. |
| TXT | Texte libre : preuves de propriété et protections antispam. | v=spf1 include:... |
Vos courriels partent en indésirable, ou vos services tiers se déconnectent. |
| NS | Quels serveurs font autorité sur cette zone ? | ns1.gestionnaire.net. |
Tout le reste est ignoré Le domaine entier bascule ailleurs. |
| CAA | Quelle autorité a le droit d'émettre un certificat pour ce domaine ? | 0 issue "letsencrypt.org" |
Le renouvellement du certificat SSL échoue et le site passe en alerte de sécurité. |
| SRV | Sur quel hôte et quel port trouve-t-on tel service ? | 10 0 443 sip.monsite.com. |
Téléphonie, messagerie instantanée et clients qui se configurent seuls cessent de fonctionner. |
| ALIAS / ANAME | Comme un CNAME, mais utilisable sur le domaine nu. | @ → app.plateforme.net. |
N'est pas un standard : disponible chez certains gestionnaires seulement. Voir la section 5. |
5. La racine, le www, et le problème du CNAME Un détail technique aux conséquences quotidiennes
! Pourquoi on ne peut pas mettre un CNAME sur le domaine nu
Un CNAME dit « pour ce nom, va voir cet autre nom, entièrement ». Le protocole interdit donc qu'un nom portant un CNAME porte autre chose. Or le domaine nu porte obligatoirement des NS, et presque toujours des MX. Un CNAME à la racine effacerait la messagerie et la désignation des serveurs faisant autorité : c'est pour cela qu'il est interdit.
Le problème est très concret : beaucoup de plateformes d'hébergement modernes ne vous donnent pas d'adresse fixe, seulement un nom. Elles vous demandent un CNAME, que vous ne pouvez pas poser à la racine.
Les trois issues, par ordre de propreté
- Un enregistrement ALIAS chez un gestionnaire qui le propose. Il résout le nom pour vous et répond une adresse, tout en restant compatible avec les MX. C'est la bonne solution.
- Une adresse fixe fournie par la plateforme, posée en A. Simple, mais elle vous oblige à surveiller si elle change.
- Une redirection du domaine nu vers
www, assurée par le gestionnaire. Cela fonctionne, au prix d'un saut supplémentaire pour chaque visiteur.
Choisir sa forme canonique
Avec ou sans www, le choix n'a aucune importance technique. Ce qui compte, c'est qu'une seule des deux serve le contenu et que l'autre redirige vers elle, en permanence et sans exception.
Servir le même site sur deux adresses différentes disperse le SEO entre deux versions, fausse les statistiques et complique les certificats. Ne pas choisir est la seule erreur possible.
*, fait répondre n'importe quel sous-domaine inexistant. Pratique pour une application qui crée des espaces clients à la volée, dangereux partout ailleurs : il masque vos erreurs de saisie, et il rend possible qu'un tiers serve du contenu sur un sous-domaine que vous n'avez jamais créé. Ne le posez que si vous savez précisément pourquoi.6. Le TTL, et pourquoi « propagation » est un mot faux Rien ne se propage, tout expire
On dit couramment qu'un changement DNS « se propage en 24 à 48 heures », comme si une information voyageait de serveur en serveur. Il ne se passe rien de tel. Votre modification est effective immédiatement sur vos serveurs faisant autorité. Ce qui prend du temps, c'est que les copies périmées finissent d'expirer chez ceux qui les avaient prises avant.
Valeur de manœuvre, le temps d'une migration.
Bon compromis courant, hors période de changement.
Pour ce qui ne bouge jamais. Une erreur reste visible une journée.
! La manœuvre d'abaissement, et son piège
Avant une migration prévue, on abaisse le TTL des lignes concernées à 300 secondes pour que la bascule soit quasi immédiate. Le piège tient en une phrase : le nouveau TTL ne s'applique qu'aux copies prises après sa publication. Si l'ancienne valeur était de 24 heures, il faut attendre 24 heures pour que tout le monde ait reçu la nouvelle durée courte.
Autrement dit, l'abaissement doit se faire au moins un TTL complet avant la bascule, soit typiquement la veille ou l'avant-veille. Un abaissement fait le matin même ne sert strictement à rien.
7. La messagerie : SPF, DKIM, DMARC Trois lignes de texte qui décident si vos mails arrivent
Un serveur qui reçoit un courriel se pose une question simple : cet expéditeur a-t-il le droit d'écrire au nom de ce domaine ? Trois enregistrements TXT répondent, et ils se posent dans cet ordre. Sans eux, un message légitime part en indésirable, et n'importe qui peut écrire en votre nom.
1 SPF
Qui a le droit d'envoyer. Une liste des serveurs autorisés à émettre pour votre domaine.
Un seul enregistrement SPF par domaine, jamais deux. Le nombre de renvois vers d'autres domaines est plafonné à dix : au-delà, la vérification échoue en silence, ce qui arrive vite quand on cumule messagerie, service d'infolettre et outil de facturation.
2 DKIM
Que le message n'a pas été modifié. Votre serveur signe chaque message, la clé publique est publiée dans le DNS.
C'est le seul des trois qui survit à une réexpédition. Sa clé est un long texte fourni par la messagerie, et c'est exactement le genre de valeur qu'on ne retrouve pas si on ne l'a pas exportée.
3 DMARC
Ce qu'il faut faire en cas d'échec. Il s'appuie sur les deux précédents et donne la consigne : ne rien faire, mettre en quarantaine, ou rejeter.
Il fournit aussi des rapports, qui révèlent souvent des envois légitimes oubliés depuis des années.
La progression qui ne casse rien
- Poser SPF et DKIM, et vérifier qu'un message de test passe les deux contrôles.
- Publier DMARC en observation seule,
p=none, avec une adresse de rapport. Ne rien changer d'autre. - Lire les rapports pendant deux à quatre semaines. C'est là qu'on découvre l'outil de devis, le formulaire du site ou la boutique qui envoient sans être déclarés.
- Une fois tout le monde en règle, passer en quarantaine, puis en rejet.
Passer directement au rejet fait disparaître des courriels légitimes sans avertissement, et c'est irrattrapable pour les messages déjà refusés.
8. Qui gère quoi, et les trois montages courants Le NS est un aiguillage, pas un réglage
Trois rôles, qui peuvent être tenus par une seule société ou par trois différentes : le bureau d'enregistrement chez qui vous payez le domaine, le gestionnaire de zone où vivent les enregistrements, et l'hébergeur qui sert le site. Les NS déclarés chez le bureau d'enregistrement désignent le gestionnaire de zone. Ils ne désignent pas l'hébergeur.
| Montage | Comment ça se présente | Pour qui | Le risque |
|---|---|---|---|
| Tout au même endroit | Domaine, zone, site et messagerie chez le même hébergeur. | Une seule interface, un seul interlocuteur. Le plus simple. | Tout part ensemble le jour où l'on veut changer, et le rapport de force n'est pas de votre côté. |
| Domaine séparé | Domaine chez un bureau d'enregistrement indépendant, zone déléguée à l'hébergeur. | Le montage recommandé pour la plupart des cas. | Aucun réel. Il faut seulement savoir où l'on modifie quoi. |
| Zone chez un tiers | Un service DNS spécialisé, souvent celui d'un fournisseur cloud, gère la zone. | Sites à fort trafic, plusieurs hébergements, besoin de pilotage par API. | Une couche de plus à comprendre, et un compte de plus à sécuriser. |
9. Migrer sans couper la messagerie La procédure complète, jour par jour
J-7 : Photographier l'existant
Exporter la zone complète. Noter séparément les MX, tous les TXT, et les sous-domaines actifs. Vérifier qui est titulaire du domaine et que vous avez la main sur le compte. Interroger la zone depuis l'extérieur pour comparer plus tard à ce que le nouveau gestionnaire aura recréé.
J-2 : Abaisser les TTL
Passer à 300 secondes les lignes qui vont changer. Cela doit se faire au moins un TTL complet avant la bascule, sans quoi la manœuvre est sans effet. Ne toucher à rien d'autre.
J-1 : Préparer la cible
Le site doit déjà être installé, testé et joignable chez le nouvel hébergeur, par son adresse directe ou par un sous-domaine temporaire. Recréer chez le nouveau gestionnaire toute la zone, MX et TXT compris, avant de basculer quoi que ce soit. Si un CMS écrit sa propre adresse en base de données, préparer la mise à jour de cette valeur.
Jour J, le matin : Basculer
Modifier le A et le AAAA, ou les NS si la zone entière change de main. Un mardi ou un mercredi matin, jamais un vendredi soir. Laisser l'ancien serveur allumé.
Jour J, dans l'heure : Contrôler
Interroger le domaine depuis deux résolveurs publics différents. Envoyer un courriel vers une adresse du domaine depuis l'extérieur et vérifier qu'il arrive. Envoyer un courriel depuis le domaine et vérifier qu'il n'est pas classé en indésirable. Puis le certificat, les redirections, et une page profonde du site.
J+2 : Refermer
Remonter les TTL à leur valeur habituelle. Attendre encore quelques jours avant de résilier l'ancien hébergement, et ne le faire qu'après avoir récupéré une sauvegarde complète.
! Les cinq oublis qui reviennent le plus souvent
- Le AAAA laissé sur l'ancienne adresse, qui casse pour une partie des visiteurs seulement.
- Les TXT de vérification des outils tiers, qui déconnectent silencieusement la console de recherche, la régie publicitaire ou l'outil d'infolettre.
- Les sous-domaines discrets : la préproduction, l'extranet, le suivi de colis, l'agenda partagé.
- L'enregistrement CAA, qui empêche le nouvel hébergeur d'émettre un certificat s'il ne figure pas dans la liste.
- Le renvoi automatique configuré sur l'ancienne messagerie, qui disparaît avec elle.
10. Diagnostiquer au lieu de croire « Chez moi ça marche » ne prouve rien
Votre navigateur garde les réponses, votre système aussi, votre box aussi, et votre fournisseur d'accès encore. Quatre couches de mémoire séparent ce que vous voyez de ce qui est vrai. Interroger directement l'annuaire est le seul moyen de savoir.
Les six commandes qui répondent vraiment
# Où pointe le domaine, vu d'un résolveur public neutre dig +short monsite.com @1.1.1.1 # La même chose en IPv6 : la ligne qu'on oublie dig +short AAAA monsite.com @1.1.1.1 # Qui reçoit les courriels, et dans quel ordre dig +short MX monsite.com # Les protections de la messagerie dig +short TXT monsite.com dig +short TXT _dmarc.monsite.com # Qui fait autorité, tel que le registre le déclare dig +short NS monsite.com # Toute la chaîne, maillon par maillon, depuis la racine dig +trace monsite.com
Lire la réponse
- Aucune réponse alors que la ligne existe : votre modification n'est pas publiée, ou vous interrogez un résolveur qui garde encore l'ancienne.
- Une réponse différente selon le résolveur : c'est normal pendant la durée du TTL, anormal au-delà.
- Le nom n'existe pas : la zone elle-même est absente, ou les NS pointent vers un gestionnaire qui ne la connaît pas.
- Une réponse correcte partout, mais le site ne s'affiche pas : le DNS n'est plus en cause. Le problème est sur le serveur ou dans le certificat.
Vider les mémoires locales
Avant de conclure à une panne, videz le cache du système et du navigateur, et testez depuis une connexion mobile qui ne passe pas par la même box. Trois minutes qui évitent des heures de fausse piste.
Un service de vérification multi-pays complète utilement le tableau : il interroge des résolveurs répartis sur plusieurs continents et montre où l'ancienne valeur traîne encore.
dig +trace est la seule qui montre la chaîne entière de la section 1, maillon par maillon. Quand rien ne s'explique, c'est elle qui révèle qu'un NS pointe vers un ancien gestionnaire, ou que le registre déclare autre chose que ce que vous croyez avoir configuré.11. Protéger le domaine Ce qu'on perd quand on le perd
Un domaine détourné, ce n'est pas seulement un site indisponible. C'est la messagerie de l'entreprise entre des mains tierces, donc les réinitialisations de mot de passe de tous vos autres comptes, la banque comprise. C'est le point de défaillance unique le plus sous-protégé des petites structures.
1 Les cinq protections, par rentabilité
- Double authentification sur le compte du bureau d'enregistrement. C'est la seule serrure qui compte vraiment.
- Verrouillage du transfert, activé en permanence, désactivé seulement le temps d'un transfert voulu.
- Adresse de contact hors du domaine, pour rester joignable quand le domaine ne fonctionne plus.
- Renouvellement automatique et moyen de paiement à jour, avec un rappel dans votre agenda un mois avant l'échéance.
- Enregistrement CAA, qui limite les autorités pouvant délivrer un certificat pour votre domaine.
DNSSEC, et quand l'activer
DNSSEC signe cryptographiquement les réponses de votre zone, ce qui empêche qu'un intermédiaire y substitue les siennes. C'est une vraie protection contre une classe d'attaques réelle mais rare pour un petit site.
La contrepartie : une zone mal signée ne répond plus du tout, et une migration avec DNSSEC actif demande une séquence précise sous peine de rendre le domaine invisible pendant des heures. Activez-le quand le gestionnaire le propose en un clic et le tient à jour tout seul ; désactivez-le avant une migration, puis réactivez-le.
12. La checklist qui referme le sujet À cocher, pas à lire
1 Le domaine
- Titulaire : le client, jamais le prestataire
- Double authentification activée sur le compte
- Verrouillage du transfert activé
- Renouvellement automatique et paiement valide
- Adresse de contact hors du domaine
- Date d'expiration notée dans un agenda
2 La zone
- Zone exportée et rangée avec les sauvegardes
- A et AAAA cohérents entre eux
- Une seule forme canonique, l'autre en redirection
- MX vérifiés par un envoi réel, pas par lecture
- SPF unique, DKIM publié, DMARC au moins en observation
- CAA posé si le certificat se renouvelle tout seul
Les six règles qui résument ce mémo
- Le domaine appartient au client, à son nom, sur son compte.
- On exporte la zone avant de la toucher, jamais après.
- Rien ne se propage : les anciennes copies expirent, et le TTL décide quand.
- Abaisser un TTL doit se faire un TTL complet avant la bascule.
- Basculer les NS abandonne toute la zone, messagerie comprise.
- Une migration se contrôle en envoyant un vrai courriel, pas en lisant une interface.
Mémo publié par NET&PRO à titre pédagogique. Information générale, sans garantie d'exactitude, d'exhaustivité ni d'actualité, et sans valeur de conseil personnalisé. Avertissement et limites d'usage
Dans le glossaire
Les mots croisés au fil de ce mémo, définis en une phrase. Ils sont soulignés dans le texte : un clic y mène directement.
Mémos liés
Mettre un site en ligne de A à Z
Nom de domaine, hébergement, transfert du code, HTTPS, droits, sauvegardes : la mise en ligne expliquée pas à pas.
Lire le mémoChoisir son hébergement de A à Z
Cinq familles d'hébergement, ce qu'elles font tourner vraiment, ce qu'elles coûtent une fois toutes les lignes ajoutées.
Lire le mémoLes sauvegardes de A à Z
Quoi sauvegarder, où, à quelle fréquence, comment automatiser et chiffrer, et le seul contrôle qui prouve que ça marche : restaurer pour de vrai.
Lire le mémoLe faire vous-même
Un nom de domaine et sa zone DNS se gèrent très bien seul, à condition de comprendre ce qu'on modifie. Ce mémo donne chaque type d'enregistrement et son rôle.
- Le temps réel : une heure pour poser une zone propre, dix minutes par changement ensuite.
- Les outils gratuits : l'interface de votre registrar suffit. Pour vérifier, les outils publics de diagnostic DNS répondent en une seconde et ne demandent pas de compte.
- Le piège : changer un enregistrement MX pendant une migration sans avoir baissé la durée de vie la veille. Les messages se perdent pendant des heures, et personne ne le voit tout de suite.
Si vous préférez me le confier
Sur ce sujet, voici ce que je fais pour mes clients. Les formules disent ce qui est compris, ce qui ne l'est pas, et ce que ça coûte au bout de trois ans.