DNSSEC et filtrage DNS

Le DNS classique n'offre aucune garantie d'authenticité. Deux défenses complémentaires répondent à ce problème : DNSSEC prouve que les réponses sont authentiques et intactes, tandis que le filtrage DNS bloque la résolution des noms connus comme malveillants. Ensemble, ils protègent l'intégrité et réduisent la surface d'attaque.

Cette leçon explique le fonctionnement de chacune de ces défenses et leur place dans une stratégie de sécurité DNS en couches.

DNSSEC (extensions de sécurité du DNS) ajoute des signatures cryptographiques aux données DNS. Il garantit :

• Authenticité de l'origine — la réponse provient du véritable propriétaire de la zone.
• Intégrité des données — la réponse n'a pas été modifiée pendant son transport.

Point important, DNSSEC ne fournit pas de confidentialité. Les requêtes et les réponses restent en texte clair ; pour préserver la confidentialité, vous avez toujours besoin de DNS via TLS ou de DNS via HTTPS.

Chaque ensemble d'enregistrements d'une zone signée reçoit un enregistrement RRSIG : une signature numérique couvrant ces données. La clé publique correspondante est publiée dans un enregistrement DNSKEY.

Un résolveur validant récupère le RRSIG et le DNSKEY, puis vérifie la signature. Si la vérification échoue, la réponse est rejetée comme invalide au lieu d'être transmise au client.

La confiance descend dans la hiérarchie. Une zone parente publie un enregistrement DS (signataire de délégation) qui contient le hachage du DNSKEY de la zone enfant. La chaîne suit le parcours : racine → TLD → votre domaine.

Un résolveur validant part de l'ancre de confiance de la racine codée en dur et suit les enregistrements DS vers le bas. Si un lien est absent ou incorrect, la validation échoue. La publication du DS auprès de votre bureau d'enregistrement active DNSSEC pour votre domaine.

Les zones utilisent deux rôles de clé :

• ZSK (clé de signature de zone) — signe les enregistrements réels ; elle est renouvelée fréquemment.
• KSK (clé de signature de clé) — signe l'ensemble DNSKEY ; sa durée de vie est plus longue et elle est référencée par le DS parent.

La séparation des rôles permet de renouveler la ZSK sans toucher à la délégation parente, ce qui simplifie la gestion des clés.

DNSSEC doit également prouver qu'un nom n'existe pas. Les enregistrements NSEC signent les intervalles entre les noms existants, mais permettent aux attaquants de parcourir et d'énumérer toute la zone.

NSEC3 résout ce problème en signant des noms hachés plutôt que du texte en clair, ce qui complique l'énumération de la zone. Préférez NSEC3 (ou NSEC3 avec exclusion facultative) pour les zones que vous ne souhaitez pas rendre entièrement explorables.

Soyez réaliste quant à la portée :

• Aucune confidentialité, seulement l'intégrité et l'authenticité.
• La validation doit avoir lieu sur un résolveur de confiance ; le dernier segment jusqu'au résolveur local reste non protégé sans DNS via TLS ou DNS via HTTPS.
• Des signatures mal configurées ou expirées provoquent des interruptions de service ; surveillez donc leur validité.
• Des réponses plus volumineuses augmentent le potentiel d'amplification si la récursion ouverte reste activée.

Le filtrage DNS utilise le résolveur comme point d'application des règles. Lorsqu'un client recherche un domaine malveillant ou indésirable, le résolveur refuse la réponse ou la réécrit, souvent vers un puits de détournement ou une page de blocage.

Cette méthode est économique, rapide et indépendante du protocole : bloquer la recherche empêche le C2 de logiciels malveillants, l'hameçonnage et les catégories indésirables avant même qu'une connexion ne soit tentée.

RPZ est une méthode standard pour appliquer une règle de pare-feu DNS. Le résolveur charge des zones de règles, locales ou provenant de flux de renseignements sur les menaces, et peut :

• Renvoyer NXDOMAIN (le nom n'existe pas).
• Renvoyer NODATA.
• Rediriger vers un puits de détournement ou une adresse IP de jardin clos.
• Laisser passer en journalisant.

Le détournement vers un puits est très utile pour la réponse aux incidents : redirigez les domaines C2 connus et observez quels hôtes tentent de les contacter.

L'efficacité du filtrage dépend de la qualité des données. Alimentez le résolveur avec :

• Des listes sélectionnées d'indicateurs de logiciels malveillants, d'hameçonnage et de C2.
• Des flux de domaines récemment enregistrés et à faible réputation, souvent malveillants.
• Des règles par catégorie, par exemple pour bloquer les outils d'anonymisation connus sur les appareils d'entreprise.

Associez le filtrage à la journalisation afin que les recherches bloquées deviennent des signaux de détection plutôt que de simples refus silencieux.

Ces deux défenses sont complémentaires et non concurrentes :

• DNSSEC garantit que les réponses obtenues sont authentiques et intactes.
• Filtrage/RPZ garantit que vous ne résolvez jamais les noms connus comme malveillants.

Déployez les deux sur des résolveurs internes validants, ajoutez DNS via TLS ou DNS via HTTPS pour la confidentialité du dernier segment, imposez des contrôles du trafic sortant et vous disposerez d'une solide posture de sécurité DNS en couches.

Vérifiez ce que DNSSEC garantit réellement.

DNSSEC authentifie les réponses DNS grâce aux signatures RRSIG, à la chaîne de confiance DNSKEY/DS partant de l'ancre racine et à NSEC/NSEC3 pour le déni authentifié, mais ne fournit aucune confidentialité. Le filtrage DNS (RPZ, détournement vers un puits, flux de renseignements sur les menaces) empêche la résolution des noms connus comme malveillants et transforme les blocages en détections.

Utilisés ensemble sur des résolveurs internes validants, avec DNS via TLS ou DNS via HTTPS et des contrôles du trafic sortant, ils constituent une défense en couches contre les attaques DNS étudiées dans ce cours.