Zone Walking DNSSEC : Failles NSEC, Craquage GPU NSEC3 et Défense NSEC5

Les extensions de sécurité du système de noms de domaine (DNSSEC) ont apporté l'intégrité cryptographique et l'authentification de l'origine au protocole DNS, conçu à l'origine sans mécanismes de protection. En joignant des signatures numériques (RRSIG) aux ensembles d'enregistrements de ressources, DNSSEC garantit que les résolveurs détectent les falsifications et l'empoisonnement de cache en transit.

Cependant, concevoir une authentification cryptographique pour les réponses négatives — prouver qu'un nom de domaine n'existe pas (NXDOMAIN) ou qu'un type d'enregistrement donné est absent (NODATA) — a introduit un dilemme architectural complexe. Pour protéger les clés privées de signature de zone (ZSK) contre le risque de compromission des serveurs faisant autorité, les spécifications initiales imposaient une signature hors ligne. L'administrateur signe l'intégralité de la zone sur un système isolé et transmet les signatures statiques aux serveurs publics.

Ce modèle opérationnel rendait impossible la signature dynamique en temps réel des requêtes sans conserver une clé privée en ligne. Pour prouver l'inexistence de manière statique, l'IETF a conçu l'enregistrement Next Secure (NSEC) dans le RFC 4034. Bien que mathématiquement rigoureux, NSEC a créé un canal auxiliaire imprévu : le parcours de zone DNSSEC (Zone Walking), permettant à des tiers d'énumérer l'intégralité de la topologie d'un réseau d'entreprise en quelques instants.

Le dilemme du déni authentifié : pourquoi les réponses négatives exposent le DNS

Dans le DNS standard sans authentification, un serveur faisant autorité renvoie simplement un en-tête avec le code de réponse 3 (NXDOMAIN) lorsqu'un nom est introuvable. Les résolveurs récursifs effectuant la validation ont toutefois besoin d'une preuve mathématique établissant qu'un attaquant n'a pas falsifié cette réponse pour masquer un service légitime.

Générer dynamiquement une signature pour chaque requête négative exigerait la présence permanente de la clé ZSK sur chaque serveur en bordure de réseau. Lors des premiers déploiements de DNSSEC, les équipes d'ingénierie ont rejeté cette éventualité en raison des risques de vol de clés. Le RFC 4034 s'est donc appuyé sur des preuves d'intervalles pré-signées.

Au lieu d'affirmer qu'un nom spécifique n'existe pas, le serveur émet une déclaration signée certifiant qu'aucun enregistrement valide n'existe entre deux noms canoniques A et B triés alphabétiquement. Si cet intervalle prouve l'inexistence, il révèle en clair le nom des deux bornes au demandeur.

Anatomie du RFC 4034 : comment les enregistrements NSEC forment une liste liée

Un enregistrement NSEC réalise le déni authentifié en pointant directement vers le nom canonique suivant dans le fichier de zone. Sa charge utile comprend deux champs majeurs : le nom suivant (Next Domain Name) et un champ de masques de bits (Type Bit Maps) détaillant les types d'enregistrements existants pour ce nom.

;; Exemple d'ordre canonique dans un fichier de zone d'entreprise
alpha.example.com.     3600 IN NSEC  billing.example.com.   A RRSIG NSEC
billing.example.com.   3600 IN NSEC  db-cluster.example.com. A RRSIG NSEC
db-cluster.example.com. 3600 IN NSEC  example.com.           A RRSIG NSEC

Ces enregistrements constituent une liste chaînée circulaire fermée. Le dernier enregistrement NSEC dans l'ordre alphabétique pointe vers le sommet de la zone (example.com.). Chaque nom d'hôte interne se trouve ainsi lié dans une chaîne déterministe.

Ordre canonique et mécanique du parcours standard de zone

Les outils d'audit automatisés exploitent cette structure par des requêtes récursives courantes :

1. Requête initiale : Le scanner demande un enregistrement A situé immédiatement avant le sommet de zone, par exemple 0.example.com.
2. Extraction d'intervalle : Le serveur renvoie NXDOMAIN avec l'enregistrement NSEC liant le sommet au premier enregistrement : example.com. NSEC admin.example.com.
3. Avancement : Le scanner enregistre admin.example.com et construit la requête suivante : admin0.example.com.
4. Progression itérative : Le serveur renvoie l'intervalle suivant : admin.example.com NSEC api-gateway.example.com.
5. Fermeture du cycle : L'opération se poursuit jusqu'à ce qu'un enregistrement NSEC pointe à nouveau vers example.com., attestant de l'extraction de l'ensemble de la zone.

Énumération de sous-domaines : cartographie du périmètre d'attaque en minutes

Le parcours de zone outrepasse les défenses de reconnaissance traditionnelles. Les outils usuels de découverte s'appuient sur des listes de dictionnaires, les journaux Certificate Transparency ou les moteurs de recherche, laissant souvent échapper les sous-domaines internes.

Avec un utilitaire comme ldns-walk face à une zone RFC 4034, des auditeurs ou des acteurs malveillants obtiennent l'inventaire complet des bases de données internes, consoles d'administration, clusters de développement et passerelles d'accès distant. Ces informations mettent au jour les conventions de nommage et l'architecture logicielle, facilitant des intrusions ciblées.

Le compromis du RFC 5155 : déni d'existence haché avec NSEC3

Face aux risques de divulgation de données, l'IETF a ratifié en 2008 le RFC 5155 introduisant NSEC3 (DNSSEC Hashed Authenticated Denial of Existence).

NSEC3 visait à conserver le déni authentifié tout en masquant les noms de domaine en clair. Plutôt que de trier les chaînes littérales, NSEC3 applique la fonction de hachage SHA-1 à chaque nom, avec un sel (salt) cryptographique optionnel et plusieurs itérations.

;; Syntaxe NSEC3 : [Algorithme] [Indicateurs] [Itérations] [Sel] [Hachage suivant] [Types]
2T8A7...example.com. 3600 IN NSEC3 1 0 10 A1B2C3D4 7K9P2... A RRSIG

Les hachages codés en base32hex forment un anneau ordonné. Lorsqu'une requête vise un nom inexistant, le serveur calcule son hachage et renvoie l'enregistrement NSEC3 englobant cet intervalle. Les noms en clair ne figurent plus dans les paquets échangés sur le réseau.

Briser NSEC3 : attaques par dictionnaire accélérées par GPU et Hashcat

Bien que NSEC3 empêche l'extraction immédiate par ldns-walk, il a déplacé la vulnérabilité vers le calcul hors ligne. L'anneau complet des hachages reste accessible publiquement par requêtes successives.

Une fois les hachages collectés, l'attaquant opère hors ligne. Comme NSEC3 repose sur SHA-1 avec un sel fixe, l'opération devient une attaque par dictionnaire classique :

Candidat ("vpn") -> Sel ("A1B2C3D4") -> SHA-1 itéré -> Comparaison avec l'anneau capturé

Les processeurs graphiques (GPU) modernes calculent des dizaines de milliards d'opérations SHA-1 par seconde. Des suites comme Hashcat intègrent des modules dédiés (Mode 8300 : DNSSEC NSEC3) taillés pour cette tâche.

Des recherches approfondies indiquent que les attaques par dictionnaire contre NSEC3 recouvrent 65 % à 85 % des noms réels en quelques heures, en raison des préfixes prévisibles (mail, vpn, api, auth, jira, dev).

Le piège du DoS computationnel : pourquoi trop d'itérations saturent les résolveurs

Pour ralentir le calcul sur GPU, certains administrateurs ont augmenté le paramètre iterations du RFC 5155 à 500, 1000 voire 2500 passes de SHA-1.

Cette approche a créé une surface d'attaque par déni de service (DoS) asymétrique pénalisant les résolveurs récursifs :

• Asymétrie : Le serveur faisant autorité calcule NSEC3 une seule fois lors de la signature hors ligne.
• Charge du résolveur : Chaque requête client vers un nom inexistant oblige le résolveur à recalculer l'intégralité des 2500 tours de SHA-1 pour valider la preuve.
• Amplification : En envoyant un flux de requêtes NXDOMAIN vers un résolveur validant sur une zone à fortes itérations, un attaquant mobilise la totalité des cœurs CPU dans des calculs futiles.

Sous forte charge, les résolveurs subissent l'épuisement de leurs files de traitement, des latences supérieures à 1500 ms et l'échec des requêtes d'utilisateurs légitimes.

Durcissement moderne avec le RFC 9276 : suppression du sel et itérations nulles

Afin d'éradiquer cette vulnérabilité et de dissiper l'illusion de protection des paramètres NSEC3, l'IETF a publié le RFC 9276 (Recommandations pour la configuration de NSEC3).

Le RFC 9276 définit des règles strictes :

1. Itérations obligatoirement à zéro : Les valeurs supérieures à zéro n'offrent aucun gain réel face aux fermes de GPU et surchargent les résolveurs. Il convient de fixer iterations = 0.
2. Suppression du sel : Le sel dynamique n'empêche pas le recouvrement des mots de dictionnaire et invalide les caches des résolveurs lors des mises à jour. Le standard préconise un sel vide (noté -).
3. Plafonds de validation : Les résolveurs récents appliquent des seuils stricts. Si une zone impose un nombre d'itérations excessif, le résolveur la traite comme non sécurisée ou renvoie SERVFAIL pour préserver ses ressources.

;; Configuration moderne recommandée pour NSEC3 (conforme RFC 9276)
;; Algorithme = 1 (SHA-1), Indicateurs = 0, Itérations = 0, Sel = -
U5G9E...example.com. 3600 IN NSEC3 1 0 0 - 8F3K2... A RRSIG

L'étape cryptographique suivante : NSEC5 et fonctions aléatoires vérifiables

NSEC3 ne pouvant empêcher le cassage hors ligne, la recherche académique et l'IETF ont développé NSEC5 (Déni d'existence DNSSEC par fonctions aléatoires vérifiables — VRF).

NSEC5 résout le problème du parcours de zone via une primitive asymétrique VRF :

• Le serveur faisant autorité détient une clé secrète VRF (sk_vrf).
• Le résolveur dispose de la clé publique de vérification (pk_vrf).
• Calculer le hachage d'un nom requiert obligatoirement sk_vrf.
• Vérifier la validité du hachage nécessite uniquement pk_vrf.

L'attaquant ne possédant pas la clé secrète, il ne peut rien précalculer hors ligne, ce qui neutralise mathématiquement les attaques par dictionnaire sur GPU.

Synthèse en ligne contre signature hors ligne : l'approche des "White Lies"

Une méthode alternative déployée par les grands réseaux de diffusion de contenu est le NSEC à couverture minimale (Minimal Covering NSEC), dite des "White Lies" (RFC 4470 et RFC 7129).

Plutôt que d'exposer une liste prédéfinie, le serveur génère dynamiquement la réponse en bordure de réseau :

1. Lorsqu'une requête vise charlie.example.com qui n'existe pas, le serveur synthétise un enregistrement NSEC couvrant strictement (charlie\000.example.com NSEC charlie\001.example.com).
2. Cet enregistrement prouve l'inexistence de la requête sans rien dévoiler des domaines voisins.
3. Cette architecture nécessite des clés de signature en ligne aux points de présence (PoP), sécurisées par des modules cryptographiques matériels (HSM).

Garanties mathématiques de confidentialité via l'évaluation VRF asymétrique

NSEC5 conserve la sécurité des signatures hors ligne tout en conférant la discrétion de la synthèse dynamique. Chaque requête réseau ne livre qu'une seule preuve. L'énumération de millions de sous-domaines imposerait des millions de paquets directs, déclenchant aussitôt les systèmes de détection d'intrusion.

Le parcours de zone passe ainsi d'une extraction passive indétectable à un scan réseau visible et facilement bloqué.

Architecture DNS récursive RiceGuard : atténuation de la reconnaissance de zone

Dans les architectures de passerelles professionnelles, les résolveurs récursifs forment une barrière capitale entre les postes clients et l'Internet public. Un traitement non maîtrisé des réponses négatives nuit aux performances globales.

L'infrastructure RiceGuard Couche 3 intègre des mécanismes pour contrer la reconnaissance DNS :

• Minimisation des requêtes (RFC 7816) : Les résolveurs RiceGuard éliminent les labels superflus, ne transmettant en amont que le fragment nécessaire à l'étape d'acheminement courante.
• Mise en cache des réponses négatives : Le résolveur conserve les réponses NXDOMAIN en cache local (RFC 2308) pour répondre immédiatement aux requêtes répétées et préserver l'amont.
• Contrôle de la charge algorithmique : En accord avec le RFC 9276, RiceGuard déclasse les enregistrements NSEC3 affichant des itérations excessives, neutralisant les saturations computationnelles de processeur.
• Protection contre les fuites DNS : Toutes les requêtes sont convoyées par des tunnels chiffrés WireGuard vers des résolveurs dédiés, dissociant les adresses IP clientes. Les paramètres de connexion sont vérifiables sur /what-is-my-ip.

Les utilisateurs recherchant une protection éprouvée peuvent installer les applications depuis /download. Les fondements du chiffrement DNS sont présentés dans /news/dnssec-vs-encrypted-dns-authenticity-privacy-architecture, et la parade aux attaques par mesure de latence est examinée dans /news/dns-cache-snooping-non-recursive-query-timing-defense.

Audit pratique et défense : détection du zone walking et réglage des serveurs

Les administrateurs doivent auditer leurs domaines publics afin de s'assurer qu'aucun enregistrement NSEC obsolète ne dévoile leur infrastructure. Cette démarche implique l'évaluation des paramètres de zone et l'application de règles de signature adaptées.

L'exposition au RFC 4034 se vérifie par la commande dig +dnssec example.com NSEC ou avec ldns-walk @ns1.example.com example.com. Si les noms défilent séquentiellement, une migration vers NSEC3 selon le RFC 9276 est requise.

Dans BIND 9, la configuration se déclare dans named.conf :

dnssec-policy "hardened-nsec3" {
    keys {
        ksk lifetime 365d algorithm ecdsap256sha256;
        zsk lifetime 60d algorithm ecdsap256sha256;
    };
    nsec3param {
        iterations 0;
        optout no;
        salt-length 0;
    };
};

Pour Knot DNS (knot.conf), spécifiez nsec3-iterations: 0 et nsec3-salt-length: 0 dans la section policy. En testant avec dig +dnssec +multiline nonexistent.example.com A, l'enregistrement NSEC3 renvoyé doit attester d'itérations à 0 et d'un sel vide -. L'abandon des itérations inutiles couplé à des résolveurs renforcés écarte toute fuite de topologie tout en préservant l'authenticité de DNSSEC.