DNSSEC : ce qu'il protège, et ses limites

Ce qu'une réponse DNS falsifiée permet

Avant chaque visite et chaque email, une machine demande au DNS où se trouve votre domaine. Le protocole d'origine ne donne aucun moyen de vérifier qu'une réponse vient bien du serveur qui fait autorité sur ce domaine.

Une réponse falsifiée, placée dans la mémoire d'un résolveur, envoie ses utilisateurs vers le serveur choisi par celui qui l'a placée, tant qu'elle y reste. Le visiteur a pourtant tapé la bonne adresse. Les emails adressés à votre domaine peuvent de la même façon partir vers un autre serveur de messagerie.

L'agence nationale de la sécurité des systèmes d'information (ANSSI) le dit dans ses bonnes pratiques pour l'acquisition et l'exploitation de noms de domaine : DNSSEC compense la faible sécurité du protocole DNS face aux attaques qui remplacent une réponse pendant son transit, comme la pollution de cache.

Comment la signature se vérifie

Les extensions de sécurité du DNS sont décrites par la RFC 4033 et ses deux compagnes, publiées en 2005. Le gestionnaire de la zone signe ses enregistrements. Une empreinte de sa clé est déposée dans la zone du dessus, le .fr ou le .com, elle-même signée, et ainsi de suite jusqu'à la racine. Le résolveur remonte cette chaîne de confiance.

La protection demande deux acteurs. Votre domaine doit être signé, et le résolveur de votre visiteur (celui de son fournisseur d'accès ou de son entreprise) doit vérifier la signature. L'ICANN le souligne : quand ces deux conditions sont réunies, une réponse falsifiée ne donne aucun résultat, et c'est voulu.

Ce que DNSSEC ne protège pas

La signature répond à une seule question : cette réponse vient-elle de la zone qui fait autorité ? Le reste relève d'autres protections.

• La confidentialité. La RFC 4033 le dit en toutes lettres : DNSSEC n'est pas conçu pour la fournir. Questions et réponses circulent signées, mais lisibles.
• Le site lui-même. Une fois l'adresse obtenue, la connexion au serveur repose sur HTTPS et sur le certificat, que l'en-tête HSTS rend obligatoire aux yeux du navigateur.
• Une modification faite par le bon canal. Si quelqu'un obtient l'accès à votre compte chez le registraire ou l'hébergeur DNS, ses changements sont signés comme les vôtres. L'ANSSI le rappelle dans ses recommandations de 2024 sur les architectures DNS.
• La disponibilité. La RFC 4033 précise que DNSSEC n'offre aucune protection contre le déni de service.

Le compte chez le registraire garde aussi votre domaine renouvelé : le guide sur l'expiration d'un nom de domaine explique pourquoi un renouvellement échoue.

Pourquoi si peu de domaines sont signés

La racine du DNS et le .fr sont signés depuis 2010. En dessous, beaucoup de domaines ne le sont pas. L'Afnic, qui gère le .fr, y voit deux raisons : d'autres chantiers de sécurité passent avant, et une partie des résolveurs ne vérifie toujours pas les signatures.

L'ANSSI, elle, ne recommande pas formellement de déployer DNSSEC. Dans ses recommandations relatives aux architectures des services DNS, publiées en 2024, elle demande à une organisation qui exploite ses propres serveurs DNS de décider sur une analyse de risque : DNSSEC suppose une gestion des clés et une surveillance continues, et une erreur sur la chaîne de confiance peut rendre un domaine injoignable pendant des heures ou des jours.

Pour un site dont le DNS est confié à un prestataire, la question se pose autrement : c'est le prestataire qui gère les clés et leur renouvellement.

Qui l'active, et ce qui peut casser

Deux rôles, parfois tenus par le même prestataire. L'hébergeur DNS, qui répond pour votre zone, la signe. Le registraire, chez qui le domaine est enregistré, transmet l'empreinte de la clé au registre du .fr ou du .com. Quand les deux rôles sont chez le même prestataire, l'activation se fait chez lui ; quand ils sont séparés, l'empreinte doit passer de l'un à l'autre.

L'ANSSI en fait sa recommandation R4 pour les noms de domaine : choisir un registraire qui permet de publier ces informations. Sans lui, le titulaire ne peut pas activer DNSSEC.

Ce qui casse, c'est une chaîne qui ne correspond plus. Le cas typique est un changement d'hébergeur DNS : si l'empreinte déposée au registre désigne encore l'ancienne clé, les résolveurs qui vérifient rejettent les réponses du nouvel hébergeur, et le domaine devient injoignable pour leurs utilisateurs, site et messagerie compris. Une signature qu'on laisse expirer a le même effet. Sur un domaine signé, un changement de prestataire se prépare donc avec les deux prestataires, avant la bascule.

Ce que nous relevons sur les sites audités

Ce pourcentage porte sur une trentaine de sites audités entre le 14 août 2026 et le 24 septembre 2026, ceux où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : le chiffre décrit nos audits, pas l'ensemble des sites.

Ce que l'audit regarde

L'audit interroge le DNS public sur votre domaine principal. Il y cherche l'empreinte de clé publiée dans la zone du dessus et les signatures de votre zone. Le rapport indique DNSSEC actif, absent ou non vérifiable.

Non vérifiable n'est jamais lu comme absent. Si aucun résolveur capable de rendre ces enregistrements ne répond pendant l'audit, le rapport le dit, et la note n'en perd rien.

L'absence retire des points à la note du pilier, moins qu'une messagerie sans protection. Une signature de zone ne remplace pas un enregistrement DMARC, qui empêche un tiers d'écrire à vos clients sous votre nom ; l'ANSSI note d'ailleurs que DNSSEC complète ces mécanismes de messagerie, qui s'appuient sur le DNS.

Ce que cette vérification ne dit pas

Par Quentin Mathis, Z29K · mis à jour le 28 septembre 2026