Découvrez comment Paul Mockapetris a créé le DNS, remplaçant les listes d'hôtes peu pratiques par un système de noms évolutif. Comprenez le fonctionnement du DNS, pourquoi la mise en cache est importante et les bases de la sécurité.
Chaque fois que vous tapez une adresse web, cliquez sur un lien ou envoyez un e‑mail, vous comptez sur une idée simple : les humains doivent pouvoir utiliser des noms mémorables, tandis que les ordinateurs se chargent de trouver la bonne machine.
Le DNS résout un problème quotidien : les ordinateurs communiquent avec des adresses numériques (adresses IP) comme 203.0.113.42, mais les gens ne veulent pas mémoriser des suites de chiffres. Vous voulez retenir example.com, pas l'adresse numérique que ce site utilise aujourd'hui.
Le Domain Name System (DNS) est le « carnet d'adresses » d'Internet qui traduit des noms de domaine lisibles par l'humain en adresses IP que les ordinateurs utilisent pour se connecter.
Cette traduction semble mineure, mais c'est la différence entre un Internet utilisable et un annuaire téléphonique entièrement composé de chiffres.
Ceci est une visite non technique — aucun bagage réseau requis. Nous verrons :
En chemin, vous rencontrerez Paul Mockapetris, l'ingénieur qui a conçu le DNS au début des années 1980. Son travail importe parce qu'il n'a pas seulement créé un nouveau format de nommage : il a conçu un système capable de s'étendre quand Internet est passé d'un petit réseau de recherche à quelque chose utilisé par des milliards de personnes.
Si votre site est déjà « tombé », si vous avez déjà attendu qu'un changement de domaine « se propage » ou si vous vous êtes demandé pourquoi les réglages d'e‑mail demandent des entrées DNS mystérieuses, vous avez déjà rencontré le DNS côté utilisateur. Le reste de cet article explique ce qui se passe en coulisses — clairement et sans jargon.
Bien avant que quelqu'un tape une adresse web familière, les réseaux initiaux avaient un problème plus simple : comment atteindre une machine précise ? Les ordinateurs pouvaient communiquer via des adresses IP (des nombres comme 10.0.0.5), mais les humains préféraient des noms d'hôte — des étiquettes courtes comme MIT-MC ou SRI-NIC plus faciles à retenir et partager.
Pour l'ARPANET, la solution fut un fichier partagé unique appelé HOSTS.TXT. C'était essentiellement une table de correspondance : une liste de noms d'hôte associés à leurs adresses IP.
Chaque ordinateur conservait une copie locale de ce fichier. Si vous vouliez vous connecter à une machine par son nom, votre système vérifiait HOSTS.TXT et trouvait l'adresse IP correspondante.
Cela fonctionnait au départ parce que le réseau était petit, les changements relativement rares et il existait un endroit clair pour récupérer les mises à jour.
À mesure que davantage d'organisations rejoignirent le réseau, l'approche commença à fléchir sous la croissance normale :
Le problème central était la coordination. HOSTS.TXT ressemblait à un carnet d'adresses partagé pour le monde entier. Si tout le monde dépend d'un même carnet, chaque correction implique une édition globale, et tout le monde doit télécharger la version la plus récente rapidement. Une fois le réseau arrivé à une certaine taille, ce modèle « un fichier pour tout » devint trop lent, trop centralisé et trop sujet aux erreurs.
Le DNS n'a pas remplacé l'idée d'associer des noms à des numéros — il a remplacé la façon fragile dont cette association était maintenue et distribuée.
Au début des années 1980, l'Internet passait d'un petit réseau de recherche à quelque chose de plus large, désordonné et partagé. De plus en plus de machines arrivaient, les organisations voulaient l'autonomie, et les gens avaient besoin d'un moyen plus simple d'atteindre des services que de mémoriser des adresses numériques.
Paul Mockapetris, travaillant dans ce contexte, est largement reconnu comme le concepteur du DNS. Sa contribution n'était pas un produit flamboyant : c'était une réponse d'ingénierie à une question très pragmatique : comment garder les noms utilisables quand le réseau continue de grandir ?
Un système de nommage paraît simple jusqu'à ce que vous vous représentiez ce que « simple » signifiait alors : une liste partagée unique de noms que tout le monde devait télécharger et tenir à jour. Cette approche casse dès que le changement devient constant. Chaque nouvel hôte, renommage ou correction se transforme en travail de coordination pour tout le monde.
L'intuition clé de Mockapetris fut que les noms ne sont pas que des données ; ce sont des accords partagés. Si le réseau s'étend, le système pour établir et distribuer ces accords doit s'étendre lui aussi — sans exiger que chaque ordinateur récupère constamment une liste maîtresse.
Le DNS a remplacé l'idée d'« un fichier autoritatif » par une conception distribuée :
C'est la finesse discrète : le DNS n'a pas été conçu pour être astucieux, il a été conçu pour continuer à fonctionner sous des contraintes réelles — bande passante limitée, changements fréquents, de nombreux administrateurs indépendants et un réseau qui refusait d'arrêter de croître.
Le DNS n'a pas été inventé comme un raccourci ingénieux — il a été conçu pour résoudre des problèmes pratiques très concrets qui apparaissaient à mesure que l'Internet grandissait. L'approche de Mockapetris fut de définir des objectifs clairs d'abord, puis de bâtir un système de nommage capable de tenir la distance pendant des décennies.
Le concept clé est la délégation : différents groupes gèrent différentes parties de l'arbre des noms.
Par exemple, une organisation gère ce qui se trouve sous .com, un registrar vous aide à réserver example.com, puis vous (ou votre fournisseur DNS) contrôlez les enregistrements pour www.example.com, mail.example.com, etc. Cela répartit clairement la responsabilité, de sorte que la croissance ne crée pas de goulot d'étranglement.
Le DNS part du principe que des problèmes surviendront — serveurs plantent, réseaux se partitionnent, routages changent. Il s'appuie donc sur plusieurs serveurs autoritatifs pour un domaine et sur la mise en cache dans les résolveurs, de sorte qu'une panne temporaire ne casse pas immédiatement toutes les requêtes.
Le DNS traduit des noms conviviaux en données techniques, le plus célèbre étant les adresses IP. Il n'est pas « l'Internet lui‑même » — c'est un service de nommage et de recherche qui aide vos appareils à trouver où se connecter.
Le DNS rend les noms gérables en les organisant comme un arbre. Plutôt que d'avoir une liste gigantesque où chaque nom doit être unique au niveau mondial (et quelqu'un doit la contrôler), le DNS casse le nommage en niveaux et délègue la responsabilité.
Un nom DNS se lit de droite à gauche :
www.example.com. se termine techniquement par un ..com, .org, .net, codes pays comme .ukexample dans example.comwww dans www.example.comAinsi www.example.com se décompose en :
com (le TLD)example (le domaine enregistré sous .com)www (un label créé et contrôlé par le propriétaire du domaine)Cette structure réduit les conflits parce que les noms n'ont besoin d'être uniques que dans leur parent. De nombreuses organisations peuvent avoir un www parce que www.example.com et www.another-example.com ne se chevauchent pas.
Elle répartit aussi la charge de travail. Les opérateurs de .com n'ont pas à gérer les enregistrements de chaque site ; ils indiquent seulement qui est responsable de example.com, et ensuite le propriétaire de example.com gère les détails.
Une zone est simplement une partie gérable de cet arbre — les données DNS qu'une entité a la responsabilité de publier. Pour beaucoup d'équipes, « notre zone » signifie « les enregistrements DNS pour example.com et les sous‑domaines que nous hébergeons », stockés chez leur fournisseur DNS autoritatif.
Quand vous tapez le nom d'un site dans un navigateur, vous ne demandez pas « à Internet » directement. Quelques acteurs spécialisés partagent le travail pour que la réponse soit trouvée rapidement et de façon fiable.
Vous (votre appareil et votre navigateur) débutez avec une demande simple : « Quelle adresse IP correspond à example.com ? » Votre appareil ne connaît généralement pas encore la réponse et ne veut pas interroger une douzaine de serveurs pour l'obtenir.
Un résolveur récursif fait la recherche à votre place. Il est généralement fourni par votre FAI, votre service informatique ou un résolveur public. Le principal avantage : il peut réutiliser des réponses mises en cache d'interrogations précédentes, ce qui accélère les choses pour tous ceux qui l'utilisent.
Les serveurs DNS autoritatifs sont la source de vérité pour un domaine. Ils ne « cherchent » pas sur Internet ; ils détiennent les enregistrements officiels qui indiquent quelles IP, quels serveurs mail ou quels jetons de vérification appartiennent à ce domaine.
example.com.Pensez au résolveur récursif comme à un bibliothécaire qui peut chercher pour vous (et se souvient des réponses populaires), tandis qu'un serveur autoritatif est le catalogue officiel de l'éditeur : il ne consulte pas d'autres catalogues — il affirme ce qui est vrai pour ses propres livres.
Quand vous tapez example.com dans votre navigateur, votre navigateur ne cherche pas un nom — il a besoin d'une adresse IP (un nombre comme 93.184.216.34) pour savoir où se connecter. Le DNS est le système « trouve‑moi le numéro pour ce nom ».
Votre navigateur demande d'abord à l'ordinateur/téléphone : « Connaissons‑nous déjà l'adresse IP de example.com ? » Le système vérifie sa propre mémoire à court terme (cache). S'il trouve une réponse fraîche, la recherche s'arrête là.
Si le système d'exploitation ne l'a pas, il transmet la question à un résolveur DNS — généralement fourni par votre FAI, votre entreprise ou un fournisseur public. Pensez au résolveur comme à votre « concierge DNS » : il fait le travail pour que votre appareil n'ait pas à le faire.
Si le résolveur n'a pas la réponse en cache, il démarre une recherche guidée :
.com). Le serveur racine ne donne pas l'IP finale — il fournit des renvois, des directions : « Interrogez ces serveurs .com ensuite. ».com) : le résolveur demande aux serveurs .com où example.com est géré. Encore une fois, pas l'IP finale — plus de directions : « Interrogez ce serveur autoritatif pour example.com. »A ou AAAA) contenant l'adresse IP.Le résolveur renvoie l'IP à votre système d'exploitation, puis au navigateur, qui peut enfin se connecter. La plupart des recherches semblent instantanées parce que les résolveurs et les appareils mettent les réponses en cache pendant une durée fixée par le propriétaire du domaine (TTL).
Un flux facile à retenir est : Navigateur → cache OS → cache du résolveur → Racine (renvoi) → TLD (renvoi) → Autoritatif (réponse) → retour au Navigateur.
Le DNS serait lent si chaque visite nécessitait de repartir de zéro et d'interroger plusieurs serveurs pour la même réponse. Au lieu de cela, le DNS repose sur la mise en cache — une « mémoire » temporaire des recherches récentes — de sorte que la plupart des utilisateurs obtiennent des réponses en millisecondes.
Quand votre appareil demande à un résolveur DNS example.com, ce résolveur peut devoir travailler la première fois. Après avoir appris la réponse, il la stocke dans un cache. La prochaine personne qui demande le même nom peut ainsi être servie immédiatement.
La mise en cache existe pour deux raisons :
Chaque enregistrement DNS est servi avec une valeur TTL (Time To Live). Pensez au TTL comme à une instruction : garder cette réponse pendant X secondes, puis la jeter et redemander.
Si un enregistrement a un TTL de 300, les résolveurs peuvent le réutiliser jusqu'à 5 minutes avant de le vérifier à nouveau.
Le TTL est un compromis :
Si vous migrez un site vers un nouvel hôte, changez de CDN ou réalisez une bascule d'e‑mail (modification des enregistrements MX), le TTL détermine la rapidité à laquelle les utilisateurs cessent d'aller vers l'ancien endroit.
Une approche courante consiste à baisser les TTL à l'avance d'un changement planifié, effectuer la bascule, puis remonter les TTL une fois que tout est stable. C'est pourquoi le DNS peut être rapide au quotidien — et « têtu » juste après une mise à jour.
Quand vous ouvrez un tableau de bord DNS, vous modifiez principalement une poignée de types d'enregistrements. Chaque enregistrement est une petite instruction qui indique où envoyer les gens (web), où livrer le courrier, ou comment vérifier la propriété.
| Record | Ce que ça fait | Exemple simple |
|---|---|---|
| A | Pointe un nom vers une adresse IPv4 | example.com → 203.0.113.10 (votre serveur web) |
| AAAA | Pointe un nom vers une adresse IPv6 | example.com → 2001:db8::10 (même idée, adressage plus récent) |
| CNAME | Fait d'un nom un alias d'un autre nom | www.example.com → example.com (les deux vont au même endroit) |
| MX | Indique où le courrier du domaine doit être livré | example.com → mail.provider.com (priorité 10) |
| TXT | Stocke des « notes » lisibles par les machines (vérification, politique e‑mail) | example.com a un SPF comme v=spf1 include:mailgun.org ~all |
| NS | Indique quels serveurs autoritatifs hébergent le DNS pour un domaine/zone | example.com → ns1.dns-host.com |
| SOA | L'en‑tête de la zone : NS primaire, contact admin et valeurs de temporisation | la SOA de example.com inclut ns1.dns-host.com et des timers retry/expire |
Quelques erreurs DNS reviennent souvent :
example.com). Beaucoup de fournisseurs DNS ne le permettent pas car le nom racine doit aussi porter des enregistrements tels que NS et SOA. Si vous avez besoin que le root pointe vers un nom d'hôte, utilisez un enregistrement A/AAAA ou une fonctionnalité « ALIAS/ANAME » si votre fournisseur la propose.www). Choisissez une méthode.mail.provider.com peut casser l'e‑mail ; les points manquants/en trop et la copie du mauvais champ d'hôte (par ex. @ vs www) sont des causes fréquentes de pannes.Si vous partagez des consignes DNS avec une équipe, une petite table comme celle ci‑dessus dans votre doc (ou une page runbook) accélère les revues et le dépannage.
Le DNS fonctionne parce que la responsabilité est répartie entre de nombreuses organisations. Cette répartition explique aussi pourquoi vous pouvez changer de fournisseur, modifier des paramètres et garder votre nom en ligne sans demander la permission de « l'Internet ».
Enregistrer un domaine revient à acheter le droit d'utiliser un nom (comme example.com) pour une période donnée. Pensez‑y comme réserver une étiquette pour que personne d'autre ne puisse la réclamer.
Héberger le DNS consiste à exécuter les paramètres qui disent au monde où ce nom doit pointer — votre site web, fournisseur d'e‑mail, enregistrements de vérification, etc. Vous pouvez enregistrer un domaine chez une entreprise et héberger le DNS chez une autre.
.com, .org ou .uk). Elle maintient la base officielle des détenteurs de nom sous ce TLD et quels serveurs de noms en sont responsables.Les serveurs racine se situent au sommet du DNS. Ils ne connaissent pas l'adresse IP de votre site et ne stockent pas les enregistrements de votre domaine. Leur rôle est plus limité : ils disent aux résolveurs où trouver les serveurs autoritatifs pour chaque TLD (par ex. où .com est géré).
Quand vous définissez des « serveurs de noms » pour votre domaine chez votre registrar, vous créez une délégation. Le registre .com (via ses serveurs autoritatifs) indiquera alors aux requêtes pour example.com les serveurs de noms que vous avez choisis.
À partir de ce moment, ces serveurs de noms contrôlent les réponses que le reste d'Internet reçoit — jusqu'à ce que vous changiez à nouveau la délégation.
Le DNS repose sur la confiance : quand vous tapez un nom, vous supposez que la réponse pointe vers le vrai service. La plupart du temps c'est le cas — mais le DNS est aussi une cible d'attaque, car un petit changement dans « où pointe ce nom » peut rediriger beaucoup de monde.
Un problème classique est le spoofing ou l'empoisonnement du cache. Si un attaquant parvient à tromper un résolveur pour qu'il stocke une fausse réponse, les utilisateurs peuvent être envoyés vers une mauvaise IP même s'ils ont tapé le bon domaine. Cela peut conduire à des pages de phishing, des téléchargements malveillants ou une interception du trafic.
Un autre risque est le détournement de domaine au niveau du registrar. Si quelqu'un compromet votre compte registrar, il peut changer les serveurs de noms ou les enregistrements DNS et prendre le contrôle de votre domaine sans toucher à l'hébergement.
Enfin, il y a le danger quotidien : les mauvaises configurations. Un CNAME mal placé, un TXT ancien ou un MX incorrect peut casser des flux de connexion, la livraison d'e‑mails ou des vérifications. Ces pannes ressemblent souvent à « Internet est en panne », alors que la cause est une petite édition DNS.
DNSSEC ajoute des signatures cryptographiques aux données DNS. En clair : la réponse DNS peut être validée pour confirmer qu'elle n'a pas été altérée en transit et qu'elle provient bien du DNS autoritatif du domaine. DNSSEC n'encrypte pas les requêtes et ne rend pas les recherches anonymes, mais il peut empêcher que des réponses forgées soient acceptées.
Les requêtes DNS traditionnelles sont faciles à observer pour les réseaux. DNS-over-HTTPS (DoH) et DNS-over-TLS (DoT) chiffrent la connexion entre votre appareil et un résolveur, réduisant l'espionnage et certaines manipulations en cours de route. Elles ne rendent pas le DNS totalement anonyme, mais elles changent qui peut voir et manipuler les requêtes.
Activez la MFA sur votre registrar, mettez des verrous de transfert, et limitez qui peut modifier le DNS. Traitez les changements DNS comme des déploiements en production : exigez une revue, conservez un journal des modifications et configurez des alertes/monitoring pour les changements d'enregistrements ou de serveurs de noms afin d'être informé rapidement des surprises.
Le DNS peut sembler « configuré et oublié », jusqu'à ce qu'un petit changement fasse tomber votre site ou vos e‑mails. La bonne nouvelle : quelques habitudes rendent la gestion du DNS prévisible — même pour les petites équipes.
Commencez par un processus léger et répétable :
La plupart des problèmes DNS ne sont pas compliqués — ils sont juste difficiles à remarquer rapidement.
Si vous déployez des applications fréquemment, le DNS fait partie de votre processus de release. Par exemple, les équipes qui publient des apps depuis des plateformes comme Koder.ai (où l'on peut construire et déployer via chat puis attacher des domaines personnalisés) reposent sur les mêmes fondamentaux : cibles A/AAAA/CNAME correctes, TTL judicieux lors des bascules et un chemin de retour clair si quelque chose pointe au mauvais endroit.
Si vous envoyez des e‑mails depuis votre domaine, le DNS affecte directement la capacité des messages à atteindre les boîtes de réception.
Les noms conviviaux ont permis à l'Internet de s'étendre au‑delà d'une petite communauté de recherche. Traitez le DNS comme une infrastructure partagée : un peu d'attention en amont garde votre site joignable et vos e‑mails dignes de confiance à mesure que vous grandissez.
Le DNS (Domain Name System) traduit des noms lisibles par l'humain comme example.com en adresses IP comme 93.184.216.34 afin que votre appareil sache où se connecter.
Sans DNS, il faudrait retenir des adresses numériques pour chaque site et service que vous utilisez.
Les réseaux initiaux utilisaient un seul fichier partagé (HOSTS.TXT) qui associait des noms à des adresses IP.
À mesure que le réseau s'est développé, ce système est devenu ingérable : mises à jour constantes, conflits de noms et pannes causées par des copies obsolètes. Le DNS a remplacé l'approche du « fichier mondial unique » par un système distribué.
Paul Mockapetris a conçu le DNS au début des années 1980 pour résoudre le problème d'évolutivité des noms sur un réseau en rapide croissance.
L'idée clé était la délégation : répartir la responsabilité sur de nombreuses organisations afin qu'une liste maîtresse (ou un administrateur unique) ne devienne pas un goulot d'étranglement.
Les noms DNS sont hiérarchiques et se lisent de droite à gauche :
www.example.com..comexample.comwww.example.comCette hiérarchie facilite la délégation et la gestion à l'échelle mondiale.
Un résolveur récursif recherche les réponses pour votre compte et les met en cache (souvent fourni par un FAI, une entreprise ou un fournisseur public).
Un serveur DNS autoritatif est la source de vérité pour les enregistrements d'un domaine ; il ne « cherche » pas ailleurs, il répond pour sa zone.
Un flux typique se déroule ainsi :
.com) → serveurs autoritatifs du domaine.TTL (Time To Live) indique aux résolveurs combien de temps ils peuvent mettre en cache une réponse DNS avant de la redemander.
La « propagation » correspond surtout aux caches qui expirent à des moments différents.
Les enregistrements les plus courants sont :
Un registrar est l'endroit où vous enregistrez/renouvelez le nom de domaine (le droit d'utiliser example.com).
Un hébergeur DNS/fournisseur DNS exécute les serveurs de noms autoritatifs et stocke vos enregistrements DNS.
Vous pouvez enregistrer chez un prestataire et héberger le DNS chez un autre en modifiant les NS au niveau du registrar.
Les défaillances DNS courantes incluent :
Moyens de défense pratiques :
AAAAAA / AAAA : pointent un nom vers une adresse IPv4/IPv6 (sites web, serveurs).CNAME : fait d'un nom un alias d'un autre nom (courant pour www).MX : indique où le courrier du domaine doit être livré.TXT : vérification et authentification d'email (SPF, DKIM, DMARC).NS : quels serveurs de noms sont autoritatifs pour le domaine.Règle pratique : ne placez pas à la fois un CNAME et un A sur le même nom d'hôte.