Accueil / Nommage
Le DNS de bout en bout
Chaque page web commence par une question posée au système de noms de domaine. Ce trajet mobilise quatre types de serveurs, plusieurs organisations distinctes et des mécanismes de cache qui expliquent à la fois la performance du système et la difficulté de le corriger vite.
Qui fait quoi dans le nommage
Quatre types de serveurs
Le mot « serveur DNS » recouvre des rôles très différents, et les confondre rend toute discussion de sécurité impossible.
Le résolveur de votre appareil
Minuscule, il ne sait rien faire seul. Il transmet la question au résolveur configuré — celui de votre fournisseur d'accès, de votre entreprise, ou un service public.
Le résolveur récursif
C'est lui qui fait le travail : il interroge la racine, puis l'extension, puis le domaine, et conserve les réponses en cache. C'est aussi lui qui valide DNSSEC — ou non. C'est le maillon le plus déterminant pour la sécurité de l'utilisateur.
Les serveurs faisant autorité
Ils détiennent les données réelles d'une zone. La racine, les registres d'extensions, et les hébergeurs DNS des domaines en font partie.
Les relais
Une box ou un pare-feu d'entreprise qui transmet les requêtes sans résoudre lui-même. Point aveugle fréquent : beaucoup de relais ne transmettent pas correctement les données DNSSEC.
Quatre organisations pour un nom
Derrière exemple.be il y a au minimum quatre entités, et une compromission chez n'importe laquelle suffit à détourner le nom.
| Rôle | Fonction | Risque propre |
|---|---|---|
| Registre | Tient l'extension et publie les délégations. DNS Belgium pour .be. | Compromission au niveau d'une extension entière |
| Bureau d'enregistrement | Vend et gère le nom pour le compte du titulaire. | Détournement de compte, transfert frauduleux |
| Titulaire | Vous. Détient les droits sur le nom. | Expiration oubliée, hameçonnage |
| Hébergeur DNS | Sert les enregistrements du domaine. | Panne, prise de contrôle de sous-domaine |
Le maillon le plus faible est souvent administratif
Les détournements de domaines les plus coûteux ne passent pas par une faille de protocole mais par le compte du bureau d'enregistrement : mot de passe réutilisé, absence de double authentification, ingénierie sociale au support. Le verrouillage au registre — registry lock — bloque toute modification sans procédure hors ligne. C'est la mesure la plus rentable pour un domaine critique.
Ce qui se passe réellement quand vous tapez un nom
Avancez étape par étape. Le parcours ci-dessous est celui d'une première requête, sans aucune donnée en cache.
L'application demande l'adresse de exemple.be. Le système vérifie d'abord son propre cache et son fichier hosts.
La question part vers le résolveur configuré. Si la liaison utilise DoT, DoH ou DoQ, elle est chiffrée à partir d'ici.
« Qui gère .be ? » La racine ne connaît pas exemple.be : elle renvoie les serveurs de l'extension, et le DS qui amorce DNSSEC. Avec la minimisation du nom demandé, elle n'apprend même pas le nom complet.
« Qui gère exemple.be ? » Le registre renvoie les serveurs du domaine et le DS correspondant. Toujours pas l'adresse.
« Quelle est l'adresse de exemple.be ? » Cette fois la réponse contient l'enregistrement A, accompagné de sa signature RRSIG.
Le résolveur remonte les signatures jusqu'à l'ancre de confiance qu'il détient. Si tout concorde, il marque la réponse comme authentifiée.
Le résolveur conserve chaque réponse pour la durée indiquée par son TTL, puis renvoie l'adresse. Les requêtes suivantes sauteront la plupart des étapes précédentes.
Ce que chaque serveur apprend de vous
Sans précaution, chaque serveur interrogé voit le nom complet recherché. La minimisation du nom demandé, décrite par le RFC 9156, corrige cela : à la racine on ne demande que be., au registre que exemple.be.. Chaque niveau n'apprend que ce dont il a besoin. C'est aujourd'hui le comportement par défaut des principaux logiciels résolveurs.
La première requête seulement
Le parcours complet est rare. Sur un résolveur actif, les délégations racines et d'extension sont presque toujours en cache. Ce qui explique qu'une indisponibilité de quelques minutes d'un serveur racine reste invisible — et qu'à l'inverse une donnée erronée mise en cache reste nuisible jusqu'à son expiration.
Le cache, atout et handicap
Chaque enregistrement DNS porte une durée de vie, le TTL, qui indique combien de temps il peut être conservé. Cette valeur est un arbitrage permanent entre performance et capacité de correction.
| TTL typique | Usage | Conséquence en cas d'erreur |
|---|---|---|
| 86 400 s (24 h) | Délégations d'extensions, enregistrements stables | Une erreur reste visible une journée entière |
| 3 600 s (1 h) | Enregistrements A et AAAA classiques | Correction propagée en une heure |
| 300 s (5 min) | Services en bascule rapide, répartition de charge | Correction quasi immédiate, charge accrue |
| 60 s | Pendant une migration ou un changement de clé | Réversibilité maximale, coût maximal |
La règle qui sauve des migrations
Avant tout changement structurant — changement d'hébergeur DNS, rotation de clé DNSSEC, modification d'un enregistrement DS — on abaisse le TTL plusieurs jours à l'avance, on effectue le changement, on observe, puis on remonte le TTL. Sans cela, une erreur reste figée dans les caches du monde entier pendant la durée de l'ancien TTL, et aucune correction ne peut aller plus vite.
Une recommandation de bonne pratique en cours de discussion à l'APNIC suggère un TTL de cinq à quinze minutes sur les enregistrements DS pendant une modification, puis un retour aux valeurs normales quelques jours plus tard.
Chiffrer les requêtes
Le DNS a été conçu en clair. Pendant trente ans, chaque requête était lisible par tout équipement sur le chemin. Trois protocoles corrigent cela, avec des compromis différents.
| Protocole | Transport | Avantage | Limite |
|---|---|---|---|
| DoT | TLS, port 853 | Trafic identifiable et gérable par les administrateurs réseau | Le port dédié se bloque facilement |
| DoH | HTTPS, port 443 | Indistinguable du trafic web ordinaire | Contourne les politiques réseau, y compris légitimes |
| DoQ | QUIC, port 853 | Latence réduite, résiste mieux aux pertes de paquets | Déploiement encore partiel |
Chiffrer n'est pas authentifier
C'est la confusion la plus fréquente. DoH et DoT protègent le trajet entre votre appareil et votre résolveur : personne sur le chemin ne peut lire ni modifier la requête. Mais ils ne disent rien de la véracité de la réponse. Si le résolveur ment, ou s'il a été trompé en amont, la réponse arrive chiffrée et fausse.
DNSSEC fait l'inverse : il ne cache rien, mais il prouve l'origine et l'intégrité de la donnée. Les deux sont complémentaires, pas substituables.
L'effet de concentration
Le chiffrement du DNS s'est accompagné d'un déplacement massif vers quelques résolveurs publics mondiaux. Le gain de confidentialité vis-à-vis du fournisseur d'accès se paie en concentration : quelques opérateurs voient désormais une part considérable des requêtes mondiales. C'est le raisonnement derrière DNS4EU, service de résolution européen lancé en juin 2025 par un consortium de dix pays, qui vise à offrir une alternative hébergée dans l'Union et soumise au droit européen.
Les attaques qui visent le nommage
Huit familles, de la plus ancienne à la plus récente. Chaque fiche indique la parade correspondante.
Empoisonnement de cache
L'attaquant fait accepter une fausse réponse par un résolveur, qui la sert ensuite à tous ses utilisateurs jusqu'à expiration du TTL. La méthode publiée par Dan Kaminsky en 2008 rendait l'opération faisable en quelques secondes.
Parades : aléa sur le port source, variation de casse dans le nom demandé, cookies DNS (RFC 7873), et surtout DNSSEC, qui rend la falsification détectable par construction.
Amplification et réflexion
L'attaquant envoie de petites requêtes à des serveurs DNS ouverts en usurpant l'adresse source de sa victime. Les réponses, bien plus volumineuses, convergent vers elle. Le DNS a longtemps été le vecteur d'amplification le plus utilisé.
Parades : le filtrage d'adresses source en bordure de réseau (BCP 38), la limitation du débit de réponse, et la fermeture des résolveurs ouverts.
Sous-domaines aléatoires, ou « supplice de la goutte d'eau »
Un botnet interroge en masse des noms inexistants sous un domaine cible. Aucune réponse n'étant en cache, chaque requête traverse jusqu'aux serveurs faisant autorité et les sature. Le cache, d'habitude protecteur, est contourné par construction.
Parades : limitation par client, cache des réponses négatives, anycast sur les serveurs faisant autorité.
Détournement de domaine
Prise de contrôle du compte chez le bureau d'enregistrement, puis modification des serveurs de noms. Le domaine pointe alors vers une infrastructure contrôlée par l'attaquant, avec un certificat TLS valide obtenu au passage. Aucune faille de protocole n'est nécessaire.
Parades : double authentification, verrouillage au registre, surveillance des journaux Certificate Transparency, alertes sur toute modification des serveurs de noms.
Prise de contrôle de sous-domaine
Un enregistrement CNAME pointe vers un service tiers — hébergement, CDN, plateforme SaaS — qui a été résilié. N'importe qui peut alors réclamer ce nom chez le prestataire et servir du contenu sous votre domaine, avec un certificat valide.
Parades : inventaire régulier des enregistrements, suppression des CNAME orphelins, analyse automatisée.
Délégations orphelines
Variante plus insidieuse : le domaine délègue à un hébergeur DNS chez qui la zone n'existe plus. Un attaquant crée la zone chez ce même hébergeur et prend le contrôle de la résolution sans jamais toucher au compte du titulaire. Des dizaines de milliers de domaines ont été identifiés comme vulnérables à ce schéma.
Parades : vérifier que chaque serveur de noms délégué répond bien avec autorité pour la zone, et supprimer les délégations vers des services abandonnés.
Tunnel DNS
Le DNS étant presque toujours autorisé à sortir, on peut y encoder un canal de données : exfiltration ou commande et contrôle. Le trafic ressemble à des requêtes ordinaires.
Parades : analyse comportementale, longueur et entropie des noms demandés, résolution DNS filtrée en sortie.
Réattachement DNS
Un nom contrôlé par l'attaquant répond d'abord une adresse publique, puis une adresse interne. Le navigateur, croyant rester sur la même origine, atteint des services du réseau local.
Parades : refus des adresses privées dans les réponses publiques au niveau du résolveur, contrôle de l'en-tête Host côté serveur.
Quatre lignes de défense
Valider et limiter
Activer la validation DNSSEC, la minimisation du nom demandé, les cookies DNS et la limitation du débit de réponse. Refuser la récursion aux clients extérieurs. Surveiller le taux de SERVFAIL, qui est le premier signal visible d'un problème de validation.
Signer et verrouiller
Signer la zone et publier le DS. Répartir les serveurs de noms sur au moins deux opérateurs indépendants. Activer le verrouillage au registre. Contrôler les autorités de certification autorisées avec un enregistrement CAA.
Filtrer et observer
Le DNS protecteur consiste à bloquer au niveau de la résolution les domaines associés à des campagnes malveillantes. Efficace et peu coûteux, mais dépendant de la qualité des listes employées : le NIST a publié en mars 2026 une révision de ses recommandations sur ce point.
Ne pas dépendre d'un seul
La panne de 2016 chez un opérateur DNS majeur et celle de 2021 chez un grand réseau social ont la même leçon : un fournisseur unique pour la résolution d'un nom critique est un point unique de défaillance, indépendamment de sa qualité.