Le DNS expliqué simplement

Par La rédaction de Mon-Adresse-IP.net·Publié le 22 mai 2026·Mis à jour le 21 août 2026·

Chaque page ouverte, chaque courriel envoyé, chaque application lancée commence par la même opération invisible : transformer un nom en adresse IP. Ce guide suit une requête DNS de bout en bout, explique pourquoi un changement met des heures à se voir, ce qu'est exactement une fuite DNS, comment un résolveur peut mentir, et quelles commandes utilisent réellement les administrateurs pour diagnostiquer une panne.

Ce qu'est réellement le DNS

Le DNS, pour Domain Name System, est le service qui traduit des noms lisibles par un humain en adresses IP exploitables par les machines. Spécifié en 1987 par les RFC 1034 et 1035, il fonctionne par défaut sur le port 53, en UDP pour la rapidité et en TCP lorsque la réponse est trop volumineuse.

La comparaison avec l'annuaire téléphonique est commode mais incomplète : un annuaire est un document unique, alors que le DNS est une base de données distribuée et hiérarchique. Aucune machine au monde ne connaît tous les noms de domaine. Chaque niveau délègue au suivant la responsabilité d'une portion de l'espace de noms.

Cette hiérarchie se lit de droite à gauche. Dans www.mon-adresse-ip.net, il existe un point final implicite qui représente la racine ; vient ensuite net, l'extension ou TLD ; puis mon-adresse-ip, le domaine enregistré ; enfin www, un sous-domaine choisi librement par le titulaire. La racine délègue .net à son registre, qui délègue mon-adresse-ip.net aux serveurs désignés par le titulaire. Chaque délégation est matérialisée par des enregistrements NS.

Deux malentendus méritent d'être levés dès maintenant. D'abord, le DNS ne sert pas qu'au web : il achemine aussi le courrier électronique via les enregistrements MX, publie des politiques d'authentification de messagerie et localise des services. Ensuite, et c'est le point le plus souvent confondu, le DNS ne transporte aucune donnée. Il indique où aller ; votre connexion, elle, part directement de votre machine vers l'adresse obtenue. C'est pourquoi un résolveur situé à l'autre bout du monde ne déplace pas votre trafic pour autant. Le vocabulaire de ce guide est repris dans notre glossaire du réseau.

Une résolution DNS pas à pas

Voici ce qui se produit réellement entre le moment où vous appuyez sur Entrée et celui où la première requête HTTP part. Dans le meilleur des cas, tout s'arrête à l'étape 1 ; dans le pire, les huit étapes s'enchaînent en quelques centaines de millisecondes.

1. Le cache du navigateur Les navigateurs modernes conservent leur propre table de correspondances, indépendante du système, avec des durées de rétention parfois plus courtes que le TTL annoncé. Chrome l'expose sur chrome://net-internals/#dns, Firefox sur about:networking#dns. Si le nom s'y trouve, aucun paquet DNS n'est émis.
2. Le cache du système d'exploitation En dessous, le système entretient son propre cache : service « Client DNS » sous Windows, systemd-resolved sur la plupart des distributions Linux, mDNSResponder sous macOS. Un même nom peut donc être connu du système et inconnu du navigateur, ou l'inverse : c'est une source classique de diagnostics contradictoires.
3. Le fichier hosts Avant d'émettre la moindre requête réseau, le résolveur du système consulte ce fichier texte local. Une correspondance qui s'y trouve l'emporte sur tout le reste : ni le résolveur, ni le serveur faisant autorité ne seront interrogés. Nous y revenons plus bas, car c'est autant un outil qu'un point faible.
4. Le résolveur récursif Faute de réponse locale, votre machine envoie la question au résolveur configuré sur l'interface réseau : le plus souvent celui de votre opérateur, annoncé par le DHCP. Ce résolveur accepte une question récursive : il s'engage à mener l'enquête complète à votre place et à ne revenir qu'avec une réponse finale. C'est lui qui détient le plus gros cache et qui, pour un domaine populaire, répond immédiatement.
5. Les serveurs racine Si le résolveur ne sait rien, il repart du sommet. La racine est servie par treize identités nommées de A à M, exploitées par douze organisations distinctes, mais ces identités correspondent à plusieurs centaines d'instances physiques réparties dans le monde grâce à l'anycast. Un serveur racine ne connaît pas votre site : il répond « je ne sais pas, mais voici qui gère .net ».
6. Le serveur du TLD Le résolveur interroge alors le registre de l'extension concernée. Là encore, la réponse est une délégation et non une adresse : le registre indique les serveurs de noms déclarés pour le domaine, accompagnés le cas échéant de leurs adresses IP, appelées glue records lorsque ces serveurs appartiennent au domaine lui-même.
7. Le serveur faisant autorité Dernière étape de l'enquête : le serveur qui détient réellement la zone répond avec l'enregistrement demandé, assorti du drapeau « autoritatif ». Il ne consulte personne d'autre : sa copie de la zone est la référence.
8. La réponse et la mise en cache Le résolveur renvoie le résultat à votre machine, puis le conserve pour la durée du TTL, tout comme les délégations obtenues en chemin. Votre système et votre navigateur en font autant. La requête suivante vers le même nom ne coûtera donc plus rien, et c'est précisément ce cache en cascade qui rend le DNS mondial supportable.

Deux précisions techniques éclairent bien des comportements observés. La première : les questions posées par le résolveur aux serveurs racine, TLD et autoritaires sont itératives, jamais récursives ; ces serveurs ne travaillent pas pour vous, ils orientent. La seconde : pour limiter la quantité d'information divulguée, un résolveur moderne applique la minimisation du nom demandé, normalisée par la RFC 9156. Il ne révèle à la racine que net, et au registre que mon-adresse-ip.net, sans jamais lui transmettre le sous-domaine complet. C'est une amélioration réelle de confidentialité, indépendante de tout chiffrement.

Les acteurs du DNS et leur rôle

Le mot « serveur DNS » désigne dans la conversation courante des machines aux fonctions totalement différentes. Cette confusion est la source de la plupart des malentendus lorsqu'on cherche à qui s'adresser en cas de problème.

La distinction entre registre et bureau d'enregistrement est celle qu'on comprend le plus tard, et souvent au mauvais moment. Le registre gère l'extension et n'a pas de relation contractuelle avec vous ; le bureau d'enregistrement est votre interlocuteur, c'est chez lui que se déclarent les serveurs de noms. Quant au serveur faisant autorité, il peut appartenir à un troisième acteur : rien n'oblige à héberger sa zone chez celui qui a vendu le domaine. Ce découplage est la raison pour laquelle une modification effectuée « chez le bon prestataire » reste parfois sans effet : elle a été faite sur une zone que plus personne n'interroge.

Le cache et le TTL

Chaque réponse DNS transporte une durée de vie exprimée en secondes, le TTL (Time To Live). Elle indique combien de temps un cache a le droit de réutiliser cette réponse sans reposer la question. Les valeurs courantes s'échelonnent de 300 secondes pour un service que l'on souhaite pouvoir déplacer rapidement à 86 400 secondes, soit une journée, pour des enregistrements stables.

Cette mécanique explique une expression trompeuse : la « propagation DNS ». Rien ne se propage. La modification est instantanée sur le serveur faisant autorité ; ce qui prend du temps, c'est l'expiration des copies déjà distribuées. Tant qu'un résolveur détient l'ancienne valeur, il continue de la servir en toute légitimité, et aucune action de votre part ne peut l'en empêcher. C'est aussi pourquoi deux internautes voisins peuvent voir deux versions différentes du même site pendant plusieurs heures.

La conséquence pratique est une méthode en trois temps pour préparer un changement d'adresse :

1. Abaisser le TTL à l'avance Passez l'enregistrement concerné à 300 secondes, et faites-le au moins une durée d'ancien TTL avant la bascule. Si le TTL valait 24 heures, abaissez-le 24 heures avant, sinon certains caches ignoreront encore la nouvelle valeur au moment du basculement.
2. Basculer Modifiez l'adresse. À partir de cet instant, la fenêtre de désynchronisation maximale n'est plus que de cinq minutes pour les résolveurs respectueux du TTL.
3. Remonter le TTL Une fois la nouvelle valeur confirmée partout, revenez à une durée longue : cela réduit la charge sur vos serveurs et améliore la résilience en cas de panne de ces derniers.

Il existe aussi un cache des réponses négatives, souvent ignoré : quand un nom n'existe pas, ce « non » est mémorisé lui aussi, pour une durée plafonnée par le champ minimum de l'enregistrement SOA de la zone, conformément à la RFC 2308. Créer un sous-domaine juste après avoir constaté son absence donne donc l'impression que la création n'a pas fonctionné, alors que c'est un souvenir d'échec qui bloque la vue.

Pour vider les caches locaux :

# Windows, invite de commandes ou PowerShell
ipconfig /flushdns
Clear-DnsClientCache

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Linux avec systemd-resolved
resolvectl flush-caches

Sur Android et iOS, aucune commande n'est exposée : activez puis désactivez le mode Avion, ou oubliez le réseau Wi-Fi avant de vous y reconnecter. Et n'oubliez jamais le cache du navigateur : il est distinct de celui du système, et c'est lui qui fausse le plus souvent les vérifications. Le réglage du TTL enregistrement par enregistrement est détaillé dans notre table de référence des enregistrements DNS.

Les enregistrements que l'on rencontre

Une zone DNS n'est pas une simple liste de correspondances nom vers IP. Elle contient des enregistrements typés, chacun répondant à une question différente posée par un logiciel différent.

Type	À quoi il sert
A	Associer un nom à une adresse IPv4
AAAA	Associer un nom à une adresse IPv6
CNAME	Déclarer qu'un nom est l'alias d'un autre nom
MX	Indiquer les serveurs qui reçoivent le courrier du domaine
TXT	Publier du texte libre : SPF, DMARC, preuves de propriété
NS	Désigner les serveurs faisant autorité sur la zone
SOA	Décrire la zone : serveur primaire, numéro de série, TTL négatif
PTR	Résolution inverse : retrouver un nom depuis une adresse IP
CAA	Restreindre les autorités autorisées à émettre un certificat

Deux pièges reviennent constamment. Un CNAME ne peut pas cohabiter avec d'autres enregistrements sur le même nom, ce qui interdit d'en poser un à la racine d'un domaine qui possède déjà un MX. Et un enregistrement PTR n'est pas déclaré dans votre zone mais dans celle de l'opérateur qui détient le bloc d'adresses : c'est pourquoi un serveur de messagerie autohébergé est refusé par de nombreux destinataires tant que ce point n'est pas réglé avec le fournisseur, comme l'explique notre guide sur l'adresse IP et le courrier électronique. La description complète de chaque type, avec sa syntaxe et ses cas d'usage, figure dans notre table des enregistrements DNS.

Le fichier hosts

Antérieur au DNS lui-même, le fichier hosts est la table de correspondances locale du système. Il se trouve dans C:\Windows\System32\drivers\etc\hosts sous Windows et dans /etc/hosts sur macOS et Linux. Sa syntaxe tient en une ligne : une adresse IP, un ou plusieurs noms séparés par des espaces.

127.0.0.1       localhost
192.168.1.50    intranet.exemple.test
203.0.113.10    preprod.exemple.com

# Une ligne commence par # pour etre ignoree

Sa caractéristique décisive est sa priorité absolue : consulté avant toute requête réseau, il court-circuite le résolveur, le cache et le serveur faisant autorité. D'où ses usages légitimes : tester un site sur un nouveau serveur avant de basculer le DNS, atteindre une machine du réseau local sans monter de service de noms interne, ou neutraliser un domaine unique sur un poste précis. Il connaît toutefois trois limites : aucun caractère générique, donc pas de *.exemple.com ; aucun type d'enregistrement autre que A et AAAA, donc aucun effet sur le courrier ; et certaines applications embarquant leur propre résolveur peuvent, selon leur configuration, ne pas le consulter.

Les fuites DNS

Une fuite DNS désigne une situation précise : un tunnel chiffré est actif, votre trafic web emprunte bien ce tunnel, mais vos requêtes de résolution de noms continuent de partir vers le résolveur du réseau local ou de votre opérateur. Le résultat est une protection en trompe-l'œil : les sites que vous visitez voient une adresse IP qui n'est pas la vôtre, tandis que votre opérateur dispose toujours de la liste horodatée des domaines que vous demandez.

Les causes tiennent presque toujours à un désaccord entre couches logicielles :

• Le tunnel ne capture pas la résolution : le client VPN modifie les routes mais laisse les serveurs DNS de l'interface physique en place. Le système continue alors de les interroger, en dehors du tunnel.
• IPv6 laissé de côté : le tunnel ne gère que l'IPv4, tandis que la box annonce des résolveurs en IPv6 que le système préfère. Ce cas de figure est devenu fréquent avec le déploiement de l'IPv6 à la maison.
• La résolution parallèle de Windows : le système peut interroger simultanément les serveurs de plusieurs interfaces et retenir la première réponse ; la question a alors bel et bien été posée à l'opérateur, même si sa réponse est écartée.
• Le tunnel partiel : une configuration en split tunneling exclut certaines applications du tunnel, avec leurs résolutions.
• Le portail captif : sur un réseau public, la résolution utilisée avant l'établissement du tunnel reste parfois active ensuite. Voir nos recommandations sur le Wi-Fi public.

Pour vérifier, gardez en tête que les commandes locales ne suffisent pas : nslookup affiche le serveur configuré, pas nécessairement celui qui traite la requête en bout de chaîne. Le seul point de vue fiable est extérieur : un test de fuite DNS déclenche la résolution de noms uniques et rapporte l'adresse et l'opérateur des résolveurs qui sont réellement venus les chercher. Si l'un d'eux appartient à votre fournisseur d'accès alors que le tunnel est actif, la fuite est confirmée. Notre guide des VPN détaille les réglages qui la corrigent, et le principe se vérifie en parallèle du test de fuite WebRTC, qui concerne un tout autre mécanisme d'exposition, propre au navigateur.

Une nuance honnête pour finir : activer le DNS chiffré du navigateur pendant qu'un VPN est actif ne constitue pas une fuite vers l'opérateur, puisque la requête voyage chiffrée. Elle sort en revanche du périmètre du fournisseur de VPN pour rejoindre celui du service DoH configuré. Ce n'est pas un incident de sécurité, mais un troisième acteur de plus à qui accorder sa confiance.

DNS menteur, filtrage et blocages

Un résolveur récursif n'est pas contraint de restituer fidèlement la réponse du serveur faisant autorité. Il peut la remplacer : renvoyer NXDOMAIN pour un domaine qui existe, substituer l'adresse d'une page d'information à l'adresse réelle, ou rediriger un nom inexistant vers un moteur de recherche. On parle alors de résolveur « menteur ». Le procédé est identique dans tous les cas ; seules changent l'intention et la légitimité.

Quatre usages coexistent : le filtrage légal, ordonné par une autorité ; la protection, quand un résolveur bloque les domaines associés à des logiciels malveillants ou à de l'hameçonnage ; le contrôle parental, activable chez la plupart des opérateurs français et sur les résolveurs publics qui proposent des profils filtrés ; et la captation commerciale, qui consiste à monétiser les fautes de frappe en dirigeant les noms inexistants vers une page publicitaire, pratique aujourd'hui marginale mais qui a laissé des traces durables dans la réputation du DNS.

En France, les blocages s'appuient sur des fondements distincts, qu'il est utile de ne pas confondre :

• Le blocage administratif : prévu à l'article 6-1 de la loi pour la confiance dans l'économie numérique pour les contenus terroristes et pédopornographiques. La demande émane du service compétent du ministère de l'Intérieur et son bien-fondé est contrôlé par une personnalité qualifiée ; les fournisseurs d'accès l'appliquent à leurs résolveurs.
• Le blocage judiciaire : un juge, saisi notamment sur le fondement de la LCEN, peut ordonner aux fournisseurs d'accès d'empêcher l'accès à un service. C'est la voie utilisée dans la plupart des litiges liés à la contrefaçon.
• Les régulateurs sectoriels : l'Autorité nationale des jeux pour les sites de jeux d'argent non autorisés, l'Arcom pour la retransmission illicite de manifestations sportives et pour les sites miroirs de services déjà condamnés.

Techniquement, ces blocages sont majoritairement mis en œuvre au niveau des résolveurs des opérateurs : c'est simple, réversible, et cela n'inspecte pas le contenu. Cette simplicité fait aussi leur fragilité, puisqu'un changement de résolveur suffit à ne plus les voir. Disons-le sans ambiguïté : contourner un blocage ne rend pas licite l'usage qui le motive, et la responsabilité de l'internaute reste entière. Vous trouverez le détail des pratiques par opérateur dans notre panorama des fournisseurs d'accès français.

Un symptôme permet de reconnaître un blocage DNS : le nom ne résout pas ou résout vers une adresse inattendue, alors que le même nom interrogé auprès d'un autre résolveur renvoie une adresse normale. À l'inverse, une page qui s'affiche avec un message d'erreur du serveur relève d'un tout autre problème ; notre référence des codes de statut HTTP aide à faire la part des choses, et notre guide mon IP est bloquée traite le cas où c'est votre adresse, et non le domaine, qui pose problème.

DNSSEC : signer les réponses

Le DNS d'origine ne comporte aucun mécanisme d'authentification : une réponse arrivant avec le bon identifiant de transaction et le bon port est acceptée. Cette faiblesse a rendu possible l'empoisonnement de cache, qui consiste à faire mémoriser une fausse réponse par un résolveur, laquelle sera ensuite servie à tous ses utilisateurs.

DNSSEC répond à ce problème par la signature cryptographique. Chaque enregistrement signé est accompagné d'une signature RRSIG, vérifiable avec la clé publique publiée dans un enregistrement DNSKEY. Pour éviter de faire confiance à cette clé sans preuve, la zone parente publie un enregistrement DS qui en contient l'empreinte. La chaîne se remonte ainsi de proche en proche : le domaine est validé par son TLD, le TLD par la racine, et la racine par une clé de confiance intégrée aux logiciels résolveurs, gérée selon une cérémonie publique et documentée. La zone racine est signée depuis 2010, et le .fr l'est également.

Ce qu'il faut retenir de ses limites est au moins aussi important que son principe :

Sa mise en œuvre demande de la rigueur : une signature expirée ou un enregistrement DS incohérent avec la clé publiée rend le domaine totalement injoignable pour tous les résolveurs qui valident, avec une erreur SERVFAIL. Une panne DNSSEC n'est jamais partielle. C'est pourquoi le changement de clés et la migration d'un domaine signé se préparent, comme le détaille la section consacrée à DNSSEC dans notre référence des enregistrements.

Le DNS chiffré

DNSSEC traite l'authenticité ; il reste la confidentialité. Une requête DNS classique voyage en clair sur le port 53 : toute personne placée sur le chemin (administrateur du réseau visité, opérateur du Wi-Fi, fournisseur d'accès) peut lire les noms demandés, et un intermédiaire actif peut les modifier.

Trois transports chiffrés répondent à ce problème. DNS over TLS (DoT, RFC 7858) établit un canal TLS dédié sur le port 853 : facile à identifier sur un réseau, donc facile à autoriser comme à bloquer. DNS over HTTPS (DoH, RFC 8484) fait voyager les mêmes requêtes dans du trafic HTTPS ordinaire sur le port 443, où elles se distinguent mal du reste de la navigation. DNS over QUIC (DoQ, RFC 9250) transpose l'approche sur QUIC, avec de meilleurs délais d'établissement.

Le point d'honnêteté indispensable : chiffrer le DNS ne supprime pas l'observation, elle la déplace. Le résolveur choisi, lui, voit toujours l'intégralité de vos requêtes. Par ailleurs, même avec un DNS parfaitement chiffré, l'adresse IP de destination reste visible sur le réseau, et le nom du site demandé apparaît encore souvent en clair dans l'établissement de la connexion TLS. Le choix du prestataire, sa politique de journalisation et sa juridiction comptent donc davantage que le protocole employé. Notre guide dédié au DNS chiffré (DoH et DoT) compare les quatre modes de résolution possibles et indique où activer le chiffrement selon les cas.

Choisir et changer son résolveur

Le résolveur par défaut est celui que votre box annonce, c'est-à-dire presque toujours celui de votre opérateur. Le remplacer est un réglage réversible, pas un acte technique lourd. Encore faut-il savoir sur quels critères arbitrer :

• La proximité réseau : un résolveur situé sur le réseau de votre opérateur répond généralement en quelques millisecondes, ce qu'un service mondial n'égale pas toujours.
• La localisation des réponses : les grands sites servent des contenus depuis le point de présence le plus proche. Un résolveur mal placé, ou qui ne transmet pas d'indication de localisation approximative, peut vous orienter vers un serveur plus lointain.
• La politique de journalisation : durée de conservation, granularité, existence d'un audit externe. À évaluer pour ce qui est écrit et vérifiable, pas pour ce qui est promis.
• La validation DNSSEC : un résolveur qui valide vous protège des réponses falsifiées, à condition d'accepter les échecs qu'elle provoque parfois.
• Le transport chiffré : la prise en charge de DoT et DoH conditionne la confidentialité de vos requêtes vis-à-vis du réseau local.
• Le filtrage : présent ou absent, choisi ou subi. Un résolveur filtrant est un bon choix familial, un mauvais choix pour un poste de développement.
• La robustesse : le DNS est un point de défaillance unique : sans résolution, plus rien ne fonctionne. Configurez toujours deux adresses du même service, et non deux services aux politiques divergentes.

Les chemins de configuration exacts pour Windows, macOS, Linux, Android, iOS et les principales box, ainsi que les pièges qui annulent silencieusement un réglage, figurent dans notre guide pas à pas pour changer de serveur DNS.

Diagnostiquer un problème DNS

Le premier réflexe utile consiste à séparer deux pannes que tout oppose : la résolution de noms et la connectivité. Contactez une adresse IP directement, puis un nom. Si l'adresse répond et que le nom échoue, le problème est dans le DNS ; si les deux échouent, c'est la connectivité qu'il faut examiner, et notre guide ping et traceroute prend alors le relais.

# 1. La connectivite brute fonctionne-t-elle ?
ping 1.1.1.1

# 2. La resolution de noms fonctionne-t-elle ?
ping mon-adresse-ip.net

Si le diagnostic pointe vers le DNS, trois outils suffisent. dig sous Linux et macOS, nslookup partout, et Resolve-DnsName sous Windows PowerShell.

# Linux, macOS : reponse courte, puis reponse complete
dig +short mon-adresse-ip.net A
dig mon-adresse-ip.net AAAA

# Comparer deux resolveurs : le sien, puis un resolveur public
dig @9.9.9.9 mon-adresse-ip.net

# Suivre toute la delegation, de la racine au serveur faisant autorite
dig +trace mon-adresse-ip.net

# Interroger un type precis, ici les serveurs de courrier
dig MX exemple.fr
nslookup -type=MX exemple.fr

# Windows PowerShell
Resolve-DnsName mon-adresse-ip.net
Resolve-DnsName mon-adresse-ip.net -Server 9.9.9.9
Get-DnsClientServerAddress

La commande dig +trace mérite une mention particulière : elle rejoue devant vous les étapes 5 à 7 décrites plus haut, en montrant successivement la réponse de la racine, celle du registre de TLD puis celle du serveur faisant autorité. C'est le moyen le plus direct de savoir si une délégation est cassée et, le cas échéant, à quel niveau.

Reste à lire le code de retour, qui vaut à lui seul un diagnostic :

Trois réflexes complètent utilement cette lecture. Interrogez toujours un second résolveur avant de conclure : si lui répond correctement, le problème est local et non global. Videz les caches avant de retester, faute de quoi vous mesurez le passé. Enfin, méfiez-vous des noms internes : un suffixe de recherche configuré sur le réseau peut transformer intranet en intranet.exemple.local et produire des résultats déroutants sur une machine nomade.

Questions fréquentes