Entre la barre d’adresse et le serveur, une question part vers un annuaire mondial. Ce qu’elle traverse, qui la lit, pourquoi elle est le premier suspect d’une panne et le premier levier de blocage en France.
Le DNS convertit un nom de domaine en adresse IP. Votre appareil ne parcourt pas l’annuaire mondial lui-même : il pose la question à un résolveur, généralement celui de votre opérateur, qui interroge à sa place les serveurs racines, ceux de l’extension puis ceux du domaine, et garde la réponse en mémoire pendant la durée fixée par le propriétaire du domaine. Ce résolveur voit donc la liste des sites que vous demandez, et c’est sur lui que reposent la plupart des blocages ordonnés en France.
Le message est identique sur toutes les machines : « Ce site est inaccessible », suivi d’un sigle obscur du genre DNS_PROBE_FINISHED_NXDOMAIN. Les autres onglets continuent de fonctionner, la box clignote normalement, le même site s’ouvre en une seconde depuis le téléphone en 4G. Rien n’est cassé sur la ligne. Ce qui a échoué, c’est une question posée à un annuaire.
Cet annuaire, c’est le DNS. Il travaille des dizaines de fois par page affichée, en quelques millisecondes, et personne ne le remarque. Il concentre pourtant trois choses qu’on lui prête rarement : la trace de tous les sites que vous demandez, l’essentiel du filtrage ordonné par la justice française, et la panne la plus fréquente derrière un « internet ne marche plus ».
Un nom de domaine se lit de droite à gauche, et le DNS le résout dans cet ordre. Pour www.service-public.fr, la hiérarchie est la suivante : la racine, puis l’extension .fr, puis le domaine service-public.fr, puis le sous-domaine www. Chaque niveau ne connaît que le suivant, et se contente d’indiquer où poser la question d’après.
Votre appareil ne fait pas ce parcours. Il délègue à un résolveur, une machine qui accepte les questions récursives et se charge d’aller au bout. Par défaut, ce résolveur est celui de votre opérateur, transmis par la box en même temps que l’adresse locale de votre appareil.
Comptez de l’ordre de 100 à 300 millisecondes pour ce parcours complet, et 0 à 30 millisecondes pour les milliers de résolutions suivantes servies depuis un cache. L’écart explique pourquoi la première visite d’un site paraît toujours plus lente que la seconde, à débit strictement identique.
Sans cache, la racine recevrait chaque requête de la planète et le système aurait cessé de fonctionner dans les années 1990. Le cache n’est donc pas une optimisation ajoutée après coup : c’est le mécanisme central, et il est réglé par le propriétaire du domaine lui-même à travers le TTL (durée de vie), exprimé en secondes et attaché à chaque enregistrement.
Un TTL de 300 signifie « gardez cette réponse cinq minutes ». Un TTL de 86 400 signifie « gardez-la une journée ». Les valeurs courantes vont de 5 minutes pour un service qui bascule souvent d’un serveur à l’autre, à 24 ou 48 heures pour des enregistrements stables. Les réponses négatives sont mises en cache elles aussi : un nom qui n’existe pas est mémorisé comme inexistant, avec sa propre durée.
Le cache existe à quatre endroits au moins : dans le navigateur, dans le système, dans la box pour certains modèles, et chez le résolveur de l’opérateur, qui mutualise les demandes de millions d’abonnés. Cette dernière couche est la plus efficace : pour un site français très fréquenté, la réponse est presque toujours déjà en mémoire quand vous la demandez.
C’est la phrase que tout hébergeur sert à un client qui déménage son site : « attendez 24 à 48 heures, le temps de la propagation ». Le mot est faux et la conséquence pratique aussi.
Rien ne se propage. Les serveurs faisant autorité changent instantanément, à la seconde où l’enregistrement est modifié. Ce qui prend du temps, c’est l’expiration des copies déjà distribuées, et cette durée n’est pas une propriété d’internet : c’est le TTL que vous aviez publié avant la modification. Si ce TTL valait 86 400, certains résolveurs serviront l’ancienne adresse pendant encore vingt-quatre heures. S’il valait 300, l’affaire est réglée en cinq minutes.
Une idée fausse tenace veut que le passage général au chiffrement ait rendu la navigation invisible. Le chiffrement d’un site en HTTPS protège le contenu échangé avec ce site, pas la question posée pour le trouver. Or cette question contient exactement l’information la plus sensible : le nom du domaine.
Un résolveur enregistre donc, requête par requête, l’adresse IP qui demande, l’horodatage et le nom demandé. Cela dessine une chronologie précise : le site de votre banque à 8 h 12, un forum médical à 12 h 40, un site de rencontres à 23 h. Aucun contenu, mais une liste d’intentions. C’est la raison pour laquelle le choix du résolveur est une décision de vie privée avant d’être une décision technique, au même titre que ce que révèle votre adresse IP publique.
| Résolveur de l’opérateur | Résolveur public tiers | DoH activé dans le navigateur | Résolveur installé chez soi | |
|---|---|---|---|---|
| Qui voit vos requêtes | Votre opérateur | L’exploitant du service, souvent hors de France | L’éditeur du navigateur ou son partenaire | Vous, puis les serveurs interrogés |
| Blocages judiciaires français | Appliqués | Partiellement, selon les décisions visant l’exploitant | Partiellement | Non appliqués |
| Filtrage parental de la box | Fonctionne | Contourné | Contourné | Contourné |
| Latence typique | Très faible, le résolveur est dans le réseau | Faible à moyenne selon la présence en France | Idem, plus le coût du chiffrement | Plus lente au premier appel, optimale ensuite |
| Choix du serveur le plus proche par les réseaux de diffusion | Optimal | Correct si le service est présent en France | Correct | Optimal |
| Effort d’installation | Aucun | Deux champs à remplir | Une case à cocher | Réel, matériel dédié |
DNS over HTTPS enveloppe la requête dans une session HTTPS ordinaire, sur le port 443, indiscernable du reste du trafic web. DNS over TLS fait la même chose sur un port dédié, le 853, plus facile à repérer donc à bloquer. Les deux empêchent le wifi du café ou l’opérateur de lire la question.
Ce qu’ils n’empêchent pas mérite d’être posé clairement. Une fois le nom résolu, votre appareil ouvre une connexion vers une adresse IP, visible de tout le chemin. Pour les grands hébergeurs mutualisés, une adresse ne dit pas grand-chose, mais pour un site hébergé seul, elle désigne le site aussi sûrement que son nom. S’ajoute le champ SNI de la poignée de main TLS, qui transporte le nom du site en clair au moment de l’ouverture de connexion, tant que le chiffrement de ce champ, appelé ECH, n’est pas généralisé.
Le bilan honnête : DoH déplace la confiance plutôt qu’il ne la supprime, exactement comme ce qu’un VPN déplace. Il a une vraie valeur sur un réseau inconnu, une valeur discutable chez soi, et il casse silencieusement les filtrages locaux, à commencer par le contrôle parental installé sur la box.
Quand une décision impose de rendre un site inaccessible depuis la France, les opérateurs ne coupent pas de câble : ils configurent leurs résolveurs pour renvoyer une réponse fausse, soit une page d’avertissement, soit une erreur. C’est simple, réversible, et sans effet sur le reste du réseau.
Trois grandes familles de blocage coexistent. Le blocage judiciaire, ordonné par un juge sur le fondement de l’article 6 de la loi pour la confiance dans l’économie numérique, vise notamment les sites de contrefaçon et de vente illicite. Le blocage administratif, sans juge, est réservé par la loi à des catégories étroites, terrorisme et pédopornographie principalement, sous le contrôle d’une personnalité qualifiée. Le blocage dit dynamique, prévu par le code du sport et suivi par l’Arcom, permet d’ajouter en cours de saison les nouveaux miroirs des sites qui diffusent illégalement des compétitions sportives.
La conséquence technique est connue de tous : puisque le blocage vit dans le résolveur, changer de résolveur le contourne. Les ayants droit l’ont compris, et les tribunaux français ont depuis étendu certaines injonctions aux exploitants de résolveurs publics étrangers, pour qu’ils appliquent les mêmes listes aux requêtes venant de France. La discussion sur le rôle des résolveurs comme point de contrôle du réseau est ouverte, et elle ne se refermera pas.
La couche racine est solide : treize identités de serveurs, exploitées par douze organisations, dupliquées par la technique de l’anycast en plus d’un millier de machines réparties dans le monde. Une même adresse est annoncée depuis des dizaines de lieux, et le réseau achemine chaque requête vers l’instance la plus proche. Faire tomber cette couche est hors de portée.
Les incidents viennent d’ailleurs, presque toujours d’une erreur de configuration. L’exemple le plus spectaculaire reste la panne mondiale des services de Meta, le 4 octobre 2021 : les routes annoncées par le réseau de l’entreprise ont disparu, rendant ses propres serveurs faisant autorité injoignables. Les noms sont alors devenus irrésolubles pour la planète entière pendant plusieurs heures, et les équipes internes se sont retrouvées bloquées par leurs propres outils, qui dépendaient des mêmes noms.
À l’échelle d’un petit site, le scénario ordinaire est plus banal : un nom de domaine non renouvelé à l’échéance, un enregistrement supprimé par erreur, ou un unique serveur faisant autorité hébergé chez le même prestataire que le site. L’ANSSI recommande pour cette raison de répartir les serveurs faisant autorité sur au moins deux infrastructures indépendantes, et de surveiller la date d’expiration du domaine autant que celle du certificat.
Le symptôme est trompeur, parce qu’une résolution qui échoue ressemble à une coupure générale. Quelques vérifications suffisent à trancher, dans l’ordre du plus rapide au plus lent.
Cette séquence évite l’erreur classique qui consiste à changer de résolveur pour tout et n’importe quoi. Un résolveur public réglera une panne du résolveur de l’opérateur, mais ne réparera ni un wifi saturé, ni une ligne coupée, ni un serveur distant en surcharge. Il ne changera pas davantage le débit mesuré, question distincte que traite le calculateur de débit nécessaire.
Le DNS ne sert pas qu’à trouver des sites. Chaque zone contient plusieurs types d’enregistrements, et deux d’entre eux gouvernent le courrier électronique.
| Type | Ce qu’il contient | À quoi il sert au quotidien |
|---|---|---|
| A | Une adresse IPv4 | Trouver le serveur web d’un nom |
| AAAA | Une adresse IPv6 | Le même rôle sur le réseau de nouvelle génération |
| CNAME | Un renvoi vers un autre nom | Faire pointer un sous-domaine vers un service hébergé ailleurs |
| MX | Le nom du serveur de courrier | Indiquer où livrer les messages d’un domaine |
| TXT | Du texte libre | Porter les enregistrements SPF et DMARC, et prouver qu’on possède le domaine |
| NS | Les serveurs faisant autorité | Déléguer la gestion d’une zone |
C’est dans les enregistrements TXT que vivent les politiques d’authentification des expéditeurs, ce qui fait du DNS le socle de SPF, DKIM et DMARC. Un domaine dont la zone est mal tenue voit ses messages partir en indésirable sans que personne ne comprenne pourquoi, mécanisme détaillé dans le trajet d’un courriel.
Cette même hiérarchie de noms est ce que vous lisez, sans y penser, dans chaque lien reçu : savoir quel morceau d’une adresse correspond au domaine réellement déclaré au registre est la compétence décisive pour repérer un hameçonnage, et elle se travaille à part, dans la lecture d’une URL.
Deux questions suffisent à ranger presque tous les cas. La première : est-ce que la ligne transporte encore des paquets, ce que prouve n’importe quel accès par adresse IP ou n’importe quelle application qui continue de fonctionner. La seconde : est-ce que le nom échoue partout, ou seulement chez moi, ce que prouve un essai depuis le réseau mobile.
Si la ligne fonctionne et que le nom échoue uniquement chez vous, le suspect est le résolveur ou un cache. Si le nom échoue partout, le problème appartient au propriétaire du domaine, et aucune manipulation locale n’y changera rien. La recommandation de la rédaction tient dans cette discipline : diagnostiquer avant de changer de réglage, parce qu’un résolveur modifié à l’aveugle masque la panne sans la corriger, et emporte au passage le filtrage familial que vous aviez mis en place.
Que votre appareil n’a pas obtenu de réponse du résolveur configuré, ce qui arrive quand la box a redémarré à moitié, quand le résolveur de l’opérateur est saturé, ou quand un logiciel de filtrage local intercepte le port 53. Le test qui tranche en dix secondes : ouvrez un service en tapant directement son adresse IP. Si la page apparaît, la connexion est intacte et seul l’annuaire est en cause. La méthode de diagnostic en couches détaille la suite.
C’est un résolveur qui renvoie sciemment une réponse fausse ou vide pour un nom donné : soit l’adresse d’une page d’avertissement, soit une erreur. Le procédé sert au blocage judiciaire et administratif, au contrôle parental des opérateurs et au filtrage antihameçonnage. Le terme est technique, pas péjoratif : la réponse est fausse par rapport à la zone d’origine, ce qui est exactement l’effet recherché.
Non, les deux fonctions n’ont rien à voir. DNSSEC signe les réponses pour prouver qu’elles n’ont pas été falsifiées en chemin, mais elles circulent toujours en clair : n’importe quel intermédiaire lit le nom demandé. Chiffrer la requête relève de DNS over HTTPS ou DNS over TLS. L’extension .fr est signée depuis longtemps, mais la validation dépend du résolveur que vous utilisez.
Les liens ci-dessus renvoient vers les textes et les organismes cités. Les dates de consultation sont celles de la dernière relecture, le 13 septembre 2026.
Dans ce thème
Dans la rubrique
Adresse IP, DNS, wifi, fibre, 5G, cookies : le réseau démonté pièce par pièce.