DNSSEC NSEC3 : mythes, bénéfices et impacts sur les performances

NSEC3 en un écran : ce que c’est et ce que ce n’est pas

DNSSEC ne se contente pas de signer les enregistrements que vous possédez. Il doit aussi fournir une preuve cryptographique pour les enregistrements que vous n’avez pas.
Si un résolveur demande does-not-exist.example, vous ne pouvez pas simplement répondre « non ». Sans preuve, un attaquant pourrait forger des réponses négatives
et faire disparaître des noms entiers.

C’est le rôle de NSEC et NSEC3 : le déni d’existence authentifié. Ils permettent à un serveur faisant autorité de prouver — cryptographiquement — qu’un nom (ou un type)
demandé n’existe pas dans la zone.

NSEC (le simple)

Avec NSEC, la zone contient des pointeurs « suivant » dans l’ordre lexicographique clair des noms. Une réponse négative inclut un enregistrement NSEC qui prouve :
« le nom demandé se situe entre ces deux noms existants, donc il n’existe pas. » Simple, efficace et favorable au cache.

L’inconvénient : NSEC permet une énumération triviale de la zone (« zone walking »). N’importe qui peut interroger des noms successifs et récupérer l’ensemble
des noms propriétaires de la zone, même si AXFR est bloqué.

NSEC3 (le haché)

NSEC3 remplace les noms en clair par des noms hachés. Au lieu de lier a.example → b.example, il lie HASH(a) → HASH(b).
Les réponses négatives incluent des enregistrements NSEC3 contenant les noms propriétaires hachés. L’idée est de rendre la marche de la zone plus difficile en forçant
l’attaquant à deviner des noms puis à les hacher (peut-être avec plusieurs itérations et un sel) pour correspondre à ce qui se trouve dans la zone.

Notez ce qu’il ne fait pas : il ne cache pas votre zone contre le devin ciblé. Si vos noms sont prévisibles, NSEC3 transforme l’énumération en attaque par dictionnaire,
pas en cape d’invisibilité.

Le modèle mental le plus court et utile : NSEC est plus rapide et fuit des informations ; NSEC3 est plus lent et fuit moins, mais n’est pas secret.

Les mythes persistants autour de NSEC3

Mythe 1 : « NSEC3 empêche le zone walking, donc il empêche la reconnaissance. »

NSEC3 empêche l’énumération triviale. Il n’empêche pas la devinette de noms. Si votre organisation utilise
vpn, mail, autodiscover, api, dev, stage, prod,
et que vous pensez qu’un hash va arrêter la reconnaissance… j’ai une mauvaise nouvelle.

Les attaquants n’ont pas besoin de parcourir votre zone quand vous avez déjà nommé les services comme un humain. Ils devineront. Ils forceront. Ils utiliseront des listes de mots.
Ils consulteront les logs de certificate transparency et le DNS passif. NSEC3 ne fait qu’augmenter le coût d’une énumération aveugle.

Mythe 2 : « Plus d’itérations NSEC3 signifie toujours plus de sécurité. »

NSEC3 prend en charge le hachage avec itérations. Plus d’itérations augmentent le coût de la devinette. Elles augmentent aussi le coût de signature et, selon l’implémentation
et la pré-calcul, peuvent augmenter la charge CPU autoritaire et la friction opérationnelle.

L’industrie s’est tournée vers des itérations plus basses parce que le bénéfice réel est mince et les coûts réels. Des itérations élevées ne vous protègent pas contre
les noms évidents. Elles protègent contre… quelqu’un devinant des labels aléatoires de 20 caractères de votre zone. Si c’est votre modèle de menace principal, parfait. Sinon,
vous payez un loyer pour un appartement vide.

Mythe 3 : « NSEC3 est toujours « plus sûr » que NSEC. »

La sécurité n’est pas un axe unique. NSEC3 réduit la divulgation des noms propriétaires, mais augmente la complexité et la taille des réponses.
Il élargit aussi le rayon d’impact d’une mauvaise configuration parce que déboguer un déni d’existence haché est plus difficile que lire une chaîne NSEC.

En termes de fiabilité : NSEC3 est un compromis. Vous ne devriez l’adopter que si vous voulez ce qu’il propose.

Mythe 4 : « NSEC3 résoudra les problèmes de SERVFAIL après l’activation de DNSSEC. »

Si vous obtenez SERVFAIL après avoir activé DNSSEC, vous avez probablement des signatures cassées, des enregistrements DS manquants, des RRSIG expirés,
un mauvais choix d’algorithme, un roll de clé brisé, ou des problèmes de MTU/fragmentation. Passer de NSEC à NSEC3 n’est pas une réparation ; c’est changer les pneus
parce que le voyant moteur est allumé.

Blague #1 (court, pertinent) : NSEC3, c’est comme mettre des vitres teintées sur une voiture sans freins. Ça change ce que voient les étrangers, pas si vous vous arrêtez.

Mythe 5 : « Si nous n’utilisons pas NSEC3, nous ne sommes pas conformes. »

La plupart des exigences de conformité exigent que DNSSEC soit déployé correctement et que les clés soient gérées. NSEC3 est rarement imposé. Certaines organisations
le choisissent comme politique pour « réduire l’énumération ». C’est un choix, pas une exigence universelle.

Quand NSEC3 aide véritablement

1) Vos noms de zone sont réellement impossibles à deviner et vous tenez à la confidentialité des noms

Si vous utilisez des labels aléatoires (pensez : jetons par client, noms d’hôtes longs de type UUID, ou structures de délégation préservant la vie privée), NSEC3 peut
augmenter sensiblement le coût d’énumération. Dans ces niches, la chaîne en clair de NSEC est une erreur évitable.

2) Vous êtes dans un environnement hostile à la reconnaissance et votre convention de nommage est rigoureuse

Certaines entreprises parviennent à garder des noms prévisibles hors du DNS public et n’exposent que ce qui doit l’être. Pour elles, NSEC3 peut être un contrôle utile
pour « rendre la tâche pénible ». Pas une solution miracle. Une gêne. La gêne a de la valeur.

3) Vous gérez un TLD signé ou une grande zone publique et vous subissez des pressions de politique

Dans les registres et certaines zones publiques très scrutées, la divulgation de toutes les délégations peut avoir des implications commerciales et d’abus.
Même si l’énumération reste possible par d’autres canaux, NSEC3 peut être adopté pour éviter de fournir une liste claire via DNS seul.

4) Vous pouvez assumer la surcharge opérationnelle

C’est la partie que beaucoup sautent dans la revue de sécurité. NSEC3 exige une paramétrisation correcte, un comportement de signature cohérent entre autorités,
et une surveillance attentive. Si vous ne pouvez pas vous engager là-dessus, mieux vaut exécuter NSEC correctement que NSEC3 mal.

Où NSEC3 nuit aux performances (et pourquoi)

Inflation de la taille des paquets : les réponses négatives grossissent

DNSSEC augmente déjà la taille des réponses à cause des RRSIG et des DNSKEY. Les réponses négatives peuvent être pires parce que la preuve de déni d’existence
requiert des enregistrements additionnels (NSEC/NSEC3 plus leurs signatures). Les réponses NSEC3 contiennent souvent plusieurs enregistrements NSEC3 pour couvrir
les preuves de closest encloser et le déni de wildcard, et chacun porte des noms propriétaires hachés et des paramètres.

De grandes réponses UDP déclenchent la fragmentation, qui entraîne des pertes, qui entraînent des retries, puis un basculement vers TCP. Vous pensez avoir activé
« plus de sécurité » ; vous avez en réalité activé « plus d’état sur les pare-feu et load balancers ».

Coût CPU : hacher et signer ça coûte

NSEC3 utilise du hachage (SHA-1 dans la conception originale). Les serveurs faisant autorité pré-calculent généralement les chaînes NSEC3 au moment de la signature,
mais les zones à mises à jour dynamiques, une re-signature fréquente, ou de mauvais outils peuvent déplacer le travail sur le chemin de service ou augmenter le churn de signature.

Même lorsqu’elles sont pré-calculées, la construction de preuves négatives plus complexes augmente les chemins de code et les patterns d’accès mémoire. Sur un parc autoritaire
chargé, vous le ressentirez comme un CPU par requête plus élevé et des taux de hit-cache plus faibles (car il y a plus de preuves négatives distinctes en circulation).

Douleur côté résolveur : validation et retries deviennent plus laids

Les validateurs n’aiment pas les réponses volumineuses et fragmentées. Ils aiment les réponses cohérentes et cacheables. NSEC tend à offrir des propriétés de cache plus propres
pour la non-existence parce que c’est simple et stable. La nature hachée de NSEC3, plus la sémantique opt-out (dans certains déploiements), peut entraîner plus de travail côté résolveur,
plus de requêtes et plus de temps passé à parcourir les preuves.

Débogage opérationnel : les humains ne lisent pas les hashes

Avec NSEC, vous pouvez regarder une réponse et comprendre ce qui est prouvé. Avec NSEC3, vous plissez les yeux devant des blobs base32 et vous vous demandez si vous avez invoqué un démon.

Blague #2 (court, pertinent) : Déboguer NSEC3 à l’œil, c’est comme analyser un incident de stockage à partir de dumps hex bruts. Techniquement possible. Spirituellement peu avisé.

Middleboxes : la partie d’internet qui vous déteste encore

DNSSEC dépend d’EDNS(0) pour des tampons UDP plus grands. Certains réseaux gèrent encore mal EDNS, l’UDP fragmenté ou les réponses DNS volumineuses. NSEC3 peut
vous pousser plus souvent au-delà des seuils de taille, transformant un « cas rare » en « ticket quotidien ».

Opt-out : pièges de performance et de politique

L’opt-out de NSEC3 a été conçu pour réduire la charge de signature des zones avec beaucoup de délégations non sécurisées (commun dans les registres). Il peut réduire
le nombre d’enregistrements et la taille des réponses dans ces cas. Il peut aussi créer des malentendus sur ce qui est authentifié ou non.
Si votre équipe ne peut pas expliquer clairement l’opt-out, vous ne devriez probablement pas le déployer à la légère.

Faits & histoire : comment on en est arrivé là

• NSEC est arrivé en premier : le déni d’existence authentifié utilisait initialement NXT, puis NSEC, qui exposait directement l’ordre des noms de la zone.
• Le zone walking n’était pas une surprise : c’était une propriété évidente de NSEC, et la communauté a débattu de son importance pendant des années.
• NSEC3 a été introduit pour contrer l’énumération : il a ajouté le hachage (plus sel et itérations) pour rendre la divulgation en masse plus difficile.
• NSEC3 utilise SHA-1 : pas parce que c’est « moderne », mais parce que la norme date d’une époque où SHA-1 était le choix pragmatique pour ce cas d’usage.
• Les itérations étaient un réglage tardif : l’idée était d’augmenter le coût des attaques hors ligne ; en pratique cela a créé des drames de tuning.
• Les grandes réponses sont devenues le véritable ennemi : à mesure que DNSSEC se déployait, les défaillances opérationnelles venaient souvent de la taille UDP/fragmentation plutôt que du pur crypto.
• Opt-out a été conçu pour les registres : il visait à rendre NSEC3 faisable pour des zones avec d’énormes nombres de délégations non sécurisées.
• Les outils opérationnels ont pris du retard : les premiers déploiements DNSSEC ont souffert parce que la surveillance et les workflows de débogage étaient immatures par rapport à aujourd’hui.
• Beaucoup d’opérateurs préfèrent maintenant la simplicité : pour de nombreuses zones, la leçon de l’industrie a été « utilisez NSEC sauf si vous avez une raison de ne pas le faire. »

Une citation, parce qu’elle appartient à chaque discussion ops. Werner Vogels (CTO d’Amazon) a dit : « Everything fails, all the time. » Cet état d’esprit s’applique ici :
concevez vos choix DNSSEC autour des modes de défaillance que vous pouvez survivre, pas de la perfection théorique.

Playbook de diagnostic rapide

L’objectif n’est pas de devenir un savant DNSSEC pendant que les utilisateurs expirent. L’objectif est de trouver le goulot d’étranglement rapidement : CPU autoritatif,
perte de paquets/fragmentation, échecs de validation du résolveur, ou état de signature cassé.

Première étape : confirmez si la douleur concerne les réponses négatives ou tout le trafic

• Échantillonnez des requêtes pour des noms existants et des noms NXDOMAIN. Si NXDOMAIN est disproportionnellement lent ou déclenche TCP plus souvent, NSEC3 est un suspect principal.
• Regardez les tailles de réponse. Si vous êtes régulièrement au-dessus d’environ ~1232 octets, vous êtes dans la zone de « roulette de fragmentation » pour de nombreux réseaux.

Deuxième étape : vérifiez la fragmentation, les retries et le basculement TCP

• Capturez sur la bordure autoritaire. Si vous voyez des requêtes répétées, des réponses tronquées (TC=1), ou beaucoup de sessions TCP/53, vous payez la taxe de taille.
• Vérifiez le comportement des tampons EDNS depuis de vrais réseaux clients. Ne vous fiez pas à un seul point de vue sur un LAN d’entreprise propre.

Troisième étape : validez la chaîne DNSSEC et les preuves de non-existence

• Utilisez un résolveur validant et des outils qui affichent la preuve de déni d’existence. Confirmez la validité des RRSIG et la couverture correcte NSEC3.
• Cherchez des erreurs de roll de clé ou d’expiration de signature. Elles se déguisent en « problème de performance » car elles déclenchent des retries et des chemins de repli.

Quatrième étape : isolez le coût côté serveur

• Surveillez le CPU autoritatif et le qps sous charge. Si le CPU augmente avec le taux de NXDOMAIN, vous faites peut-être du travail NSEC3 dynamique ou souffrez de caches manqués.
• Vérifiez si votre signer thrash (re-signature trop fréquente, trop de clés, validité des signatures trop courte, ou mauvais changements de paramètres NSEC3).

Tâches pratiques : commandes, sorties et décisions

Ce sont des tâches réelles que vous pouvez exécuter pendant un incident ou un mardi calme. Chaque élément inclut : commande, exemple de sortie, ce que ça signifie, et la décision à prendre.

Task 1: Compare positive vs negative response size and flags

cr0x@server:~$ dig +dnssec +bufsize=1232 www.example.com A @ns1.example.net

; <<>> DiG 9.18.24 <<>> +dnssec +bufsize=1232 www.example.com A @ns1.example.net
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4812
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN RRSIG A 13 3 300 20260204000000 20260114000000 12345 example.com. ...

;; Query time: 18 msec
;; MSG SIZE  rcvd: 412

cr0x@server:~$ dig +dnssec +bufsize=1232 does-not-exist.example.com A @ns1.example.net

; <<>> DiG 9.18.24 <<>> +dnssec +bufsize=1232 does-not-exist.example.com A @ns1.example.net
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1129
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2026020401 3600 900 1209600 300
example.com. 300 IN RRSIG SOA 13 2 300 20260204000000 20260114000000 12345 example.com. ...
6JQ2K7...example.com. 300 IN NSEC3 1 0 10 A1B2C3D4 6K5... NS SOA RRSIG DNSKEY NSEC3PARAM
6JQ2K7...example.com. 300 IN RRSIG NSEC3 13 3 300 20260204000000 20260114000000 12345 example.com. ...
9F8P1...example.com. 300 IN NSEC3 1 0 10 A1B2C3D4 B0T... A AAAA RRSIG
9F8P1...example.com. 300 IN RRSIG NSEC3 13 3 300 20260204000000 20260114000000 12345 example.com. ...

;; Query time: 44 msec
;; MSG SIZE  rcvd: 1216

Ce que ça signifie : NXDOMAIN est ~3x plus volumineux et plus lent, et il flirt avec la limite de tampon 1232 octets.

Décision : Traitez les réponses négatives comme le risque principal de performance. Commencez à tester la troncation et la fragmentation ensuite.

Task 2: Check truncation behavior (TC bit) with a smaller EDNS buffer

cr0x@server:~$ dig +dnssec +bufsize=512 does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9001
;; flags: qr aa tc rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message truncated

Ce que ça signifie : Avec un tampon plus petit, le serveur met TC=1 et s’attend à ce que le client réessaie en TCP.

Décision : Si de nombreux clients se comportent effectivement ainsi (EDNS cassé, tampons petits), vous verrez des pics TCP. Prévoyez des atténuations.

Task 3: Confirm TCP fallback works and measure it

cr0x@server:~$ dig +tcp +dnssec does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7711
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; Query time: 96 msec
;; MSG SIZE  rcvd: 1216

Ce que ça signifie : TCP fonctionne mais coûte ~2–5x de latence vs UDP dans de nombreux environnements.

Décision : Si vous poussez fréquemment les clients vers TCP, vous construisez des pannes latentes. Réduisez la taille des réponses ou améliorez le comportement MTU du chemin.

Task 4: Inspect NSEC vs NSEC3 presence in the zone

cr0x@server:~$ dig +dnssec example.com NSEC3PARAM @ns1.example.net

;; ANSWER SECTION:
example.com. 300 IN NSEC3PARAM 1 0 10 A1B2C3D4
example.com. 300 IN RRSIG NSEC3PARAM 13 2 300 20260204000000 20260114000000 12345 example.com. ...

Ce que ça signifie : La zone utilise NSEC3 avec algorithm 1, flags 0, iterations 10, salt A1B2C3D4.

Décision : Si les itérations sont élevées « pour la sécurité », revisitez. Si vous n’avez pas de modèle de menace concret, préférez de faibles itérations ou NSEC.

Task 5: See whether negative answers include multiple NSEC3 records

cr0x@server:~$ dig +dnssec +norecurse nohost.sub.example.com A @ns1.example.net

;; AUTHORITY SECTION:
... NSEC3 ...
... NSEC3 ...

Ce que ça signifie : Vous obtenez des preuves closest-encloser et des preuves de déni de wildcard. C’est normal, et ça augmente la taille.

Décision : Attendez-vous à ce que NXDOMAIN soit plus lourd que les réponses positives. Si c’est un pattern de requêtes à fort volume (typos, scanners), optimisez-le.

Task 6: Check authoritative server QPS and CPU during NXDOMAIN bursts

cr0x@server:~$ sudo rndc stats
cr0x@server:~$ sudo tail -n 12 /var/named/data/named_stats.txt
++ Incoming Requests ++
[View: default]
                17642 QUERY
                 8810 NXDOMAIN
++ Name Server Statistics ++
               1420010 IPv4 requests received
                  9901 TCP requests received

Ce que ça signifie : NXDOMAIN représente une grosse fraction, et les requêtes TCP ne sont pas négligeables.

Décision : Traitez NXDOMAIN comme une charge. Envisagez le rate limiting des requêtes abusives, resserrez l’utilisation des wildcard, et réduisez la taille des réponses négatives.

Task 7: Check for DNS UDP fragmentation on the server interface

cr0x@server:~$ sudo tcpdump -ni eth0 port 53 and udp -vv -c 6
tcpdump: listening on eth0, link-type EN10MB
12:00:01.100000 IP 198.51.100.20.53534 > 203.0.113.53.53: UDP, length 67
12:00:01.100500 IP 203.0.113.53.53 > 198.51.100.20.53534: UDP, length 1492
12:00:01.100520 IP 203.0.113.53 > 198.51.100.20: ip-proto-17 fragment 1492:1480@0+
12:00:01.100540 IP 203.0.113.53 > 198.51.100.20: ip-proto-17 fragment 220@1480

Ce que ça signifie : Vous envoyez des réponses UDP fragmentées. Certains réseaux suppriment les fragments. Cela devient une source d’échecs DNS aléatoires.

Décision : Réduisez la taille des réponses UDP (choix de politique et de signature), ou ajustez la stratégie EDNS/MTU. Ne négligez pas les fragments en 2026.

Task 8: Test from a validating resolver to separate “authoritative” from “validator” issues

cr0x@server:~$ dig +dnssec www.example.com A @9.9.9.9

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2
;; ANSWER SECTION:
www.example.com. 300 IN A 203.0.113.10
www.example.com. 300 IN RRSIG A 13 3 300 20260204000000 20260114000000 12345 example.com. ...

Ce que ça signifie : ad indique que le résolveur a validé DNSSEC avec succès.

Décision : Si certains validateurs affichent ad et d’autres renvoient SERVFAIL, suspectez le chemin/fragmentation ou des caches périmés/cassés, pas seulement les signatures.

Task 9: Use delv to validate and show why a name fails

cr0x@server:~$ delv +vtrace does-not-exist.example.com A @9.9.9.9
; fully validated
does-not-exist.example.com. 300 IN A ; negative response, NXDOMAIN

Ce que ça signifie : La preuve négative a été validée de bout en bout.

Décision : Si delv échoue avec une plainte sur la signature ou la preuve de non-existence, arrêtez d’optimiser la performance et corrigez d’abord la justesse.

Task 10: Verify DS at the parent (the classic “why is it SERVFAIL?” check)

cr0x@server:~$ dig +dnssec example.com DS @a.gtld-servers.net

;; ANSWER SECTION:
example.com. 86400 IN DS 12345 13 2 3A1B...C9
example.com. 86400 IN RRSIG DS 13 1 86400 20260204000000 20260114000000 9999 com. ...

Ce que ça signifie : Le parent publie un DS. Les validateurs appliqueront les signatures pour example.com.

Décision : Si le DS est manquant ou incorrect, corrigez la chaîne de délégation avant d’accuser NSEC3. Un DS erroné crée une défaillance de validation universelle.

Task 11: Check RRSIG validity windows (clock skew and expiry)

cr0x@server:~$ dig +dnssec example.com SOA @ns1.example.net | grep RRSIG
example.com. 300 IN RRSIG SOA 13 2 300 20260204000000 20260114000000 12345 example.com. ...

Ce que ça signifie : Les signatures ont une date d’inception et d’expiration. Si l’horloge du signer est fausse ou si vous laissez des signatures expirer, les validateurs échoueront.

Décision : Si vous voyez des expirations proches avec une re-signature lente, allongez la validité ou corrigez la planification du signer. La justesse prime sur l’ingéniosité.

Task 12: Measure authoritative latency distribution under load

cr0x@server:~$ sudo dnstap-read /var/log/dnstap/dnstap.log | head -n 6
2010-01-01 12:00:01.100 CQ example.com/A udp 198.51.100.20:53534
2010-01-01 12:00:01.101 CR example.com/A NOERROR 1ms 412b
2010-01-01 12:00:02.200 CQ does-not-exist.example.com/A udp 198.51.100.21:53535
2010-01-01 12:00:02.260 CR does-not-exist.example.com/A NXDOMAIN 60ms 1216b

Ce que ça signifie : NXDOMAIN est plus lent et plus volumineux. C’est la signature (sans jeu de mots) du surcoût des preuves de non-existence plus des effets réseau.

Décision : Si NXDOMAIN domine la latence tail, traitez-le comme une exigence produit : réduisez le volume de NXDOMAIN (typos, scanners), ou réduisez la taille des preuves.

Task 13: Inspect NSEC3 parameters in BIND (if you’re signing there)

cr0x@server:~$ grep -R "nsec3param" -n /etc/bind
/etc/bind/named.conf.local:42:    auto-dnssec maintain;
/etc/bind/named.conf.local:43:    inline-signing yes;
/etc/bind/named.conf.local:44:    nsec3param 1 0 10 A1B2C3D4;

Ce que ça signifie : L’inline signing est activé et les paramètres NSEC3 sont explicitement définis.

Décision : Si vous avez hérité de cette config, remettez-la en question. Si vous n’avez pas de raison pour NSEC3, supprimez le param et passez à NSEC (changement planifié), ou baissez les itérations.

Task 14: Check for EDNS compliance issues from a “bad path” client network

cr0x@server:~$ dig +dnssec +edns=0 +bufsize=4096 does-not-exist.example.com A @ns1.example.net

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5150
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; MSG SIZE  rcvd: 1216

Ce que ça signifie : Depuis ce point de vue EDNS fonctionne, mais cela ne prouve pas que ça marche pour les opérateurs mobiles, les proxies d’entreprise ou les appareils legacy.

Décision : Si les incidents corrèlent avec certains réseaux, supposez une interférence EDNS/fragmentation et priorisez la réduction des réponses pour qu’elles tiennent dans des tailles sûres.

Trois mini-récits d’entreprise depuis les tranchées DNS

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (« NSEC3 va arrêter la reconnaissance, donc on est safe »)

Une entreprise SaaS de taille moyenne avait une zone publique avec beaucoup de noms utilitaires internes accidentellement publiés : jenkins,
grafana, vpn, staging-api. Rien d’exploitable directement, mais beaucoup d’indices.
Une revue de sécurité a signalé « fuite d’informations via zone walking avec NSEC ».

La réponse de l’équipe a été rapide et propre : activer NSEC3, augmenter les itérations « par sécurité », déployer. Ils se sont déclarés vainqueurs et sont passés à autre chose.
Personne n’a posé la question gênante : « Si quelqu’un peut deviner nos noms, qu’avons-nous réellement accompli ? »

Quelques semaines plus tard, ils ont subi une vague de password spraying ciblée contre les services mêmes que la zone « cachait ». L’attaquant n’a rien parcouru.
Il a deviné les noms, vérifié via DNS, puis essayé des identifiants courants. NSEC3 a fait son travail — empêché une liste propre d’être récoltée — tout en n’apportant rien
contre la menace réelle, qui était banale et prévisible.

Le postmortem a été douloureux car la correction n’était pas de « régler les itérations ». La correction était l’hygiène de nommage et le contrôle d’exposition : retirer les
noms de service internes du DNS public, mettre les points d’administration derrière un VPN, et cesser de publier des CNAME de commodité pointant vers des UIs de gestion.
NSEC3 n’avait pas tort ; l’hypothèse avait tort.

L’élément opérationnel : l’entreprise a gardé NSEC3 de toute façon, parce que le retirer aurait ressemblé à « réduire la sécurité ». Pendant ce temps, l’on-call a appris en secret
que l’effet mesurable principal du projet était une augmentation des tailles de réponse DNS et un basculement TCP occasionnel.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux (« on pousse les itérations NSEC3 à fond »)

Une grande entreprise avec un cluster DNS autoritatif mondial a décidé de standardiser NSEC3 partout. Elle craignait sincèrement l’énumération en masse des sous-domaines délégués
et avait un récit de conformité pour le soutenir.

Quelqu’un a proposé d’augmenter fortement le nombre d’itérations NSEC3 « pour ralentir les attaquants ». Ça semblait raisonnable. Le hachage, c’est peu coûteux, non ? Et leur cluster
autoritatif avait beaucoup de marge en état stable.

Puis est venu un événement de signature : un rollover coordonné de clés plus un changement de contenu de zone touchant beaucoup de noms. La charge du signer a bondi.
Les signatures ont mis plus de temps à être régénérées. Le délai de propagation a augmenté. L’équipe a commencé à observer des échecs de validation intermittents depuis certains résolveurs
parce que la zone était dans un état moitié mis à jour plus longtemps que prévu. Les utilisateurs ont vu : des SERVFAIL aléatoires.

La réponse à l’incident s’est concentrée sur « bugs des résolveurs » et « l’internet est instable », jusqu’à ce que quelqu’un corrèle la timeline avec le changement de paramètre NSEC3.
Des itérations élevées n’avaient pas seulement « ralenti les attaquants » — elles avaient ralenti la capacité de l’organisation à récupérer et à compléter les opérations de signature sous churn.

Ils ont rétabli des paramètres plus raisonnables et introduit une règle : ne jamais changer les paramètres NSEC3 en même temps qu’un événement de clé. Aussi : tester le débit du signer comme vous testez
le temps de rebuild d’un stockage — sous conditions pires cas, pas en happy-path.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (monitoring strict et discipline « tenir dans UDP »)

Une société de services financiers exploitait DNSSEC depuis des années avec un minimum de drame. Leur secret n’était pas un crypto exotique. C’était la discipline :
monitoring de la taille des réponses, gestion prévisible des clés, et un playbook écrit pour valider les échecs.

Ils ont choisi NSEC pour la plupart des zones. Pour les quelques zones qui bénéficiaient réellement de NSEC3, ils ont gardé des paramètres conservateurs et évité des itérations inutiles.
Plus important : ils avaient un SLO : « Les réponses DNSSEC doivent rentrer dans un budget UDP choisi pour la majorité des réponses négatives. » Si un changement augmentait les réponses,
c’était traité comme une régression.

Un jour, une campagne DDoS a changé de tactique pour inonder la zone publique d’un flot de NXDOMAIN. L’attaque n’était pas sophistiquée ; elle envoyait un haut débit de requêtes inutiles
visant à forcer des réponses négatives coûteuses.

Parce qu’ils disposaient de métriques de base, ils ont reconnu le pattern en quelques minutes : pic du ratio NXDOMAIN, augmentation de la taille des réponses en tail, basculement TCP en hausse,
CPU autoritatif en hausse. Ils ont activé le rate limiting des réponses pour sources abusives, ajusté le caching et le filtrage frontal, et sont revenus à la stabilité. Pas d’exploits héroïques.
Pas de threads Slack à minuit « pourquoi le DNS est cassé ? ».

L’avantage : l’équipe a pu justifier ses décisions « ennuyeuses » antérieures avec des données concrètes. NSEC n’était pas une idéologie ; c’était un choix de fiabilité conscient qui maintenait
les réponses négatives plus petites et plus faciles à mettre en cache.

Erreurs fréquentes : symptômes → cause racine → correction

1) Symptom: random timeouts, especially on mobile networks

Cause racine : réponses DNSSEC UDP fragmentées (souvent NXDOMAIN avec NSEC3) supprimées par des réseaux ou des middleboxes.

Correction : réduisez la taille des réponses (préférez NSEC quand acceptable ; réduisez la complexité NSEC3 ; évitez les données additionnelles surdimensionnées), et testez avec des tampons EDNS plus petits.

2) Symptom: sudden increase in TCP/53 connections after enabling DNSSEC

Cause racine : troncation TC=1 due à la taille des réponses et retry du résolveur en TCP ; parfois aggravé par des tampons EDNS petits.

Correction : surveillez les taux de bit TC ; ajustez pour garder les réponses typiques sous votre budget UDP ; assurez-vous que le TCP autoritatif est dimensionné et protégé.

3) Symptom: validators return SERVFAIL for non-existent names but existing names work

Cause racine : preuves de déni d’existence cassées (chaîne NSEC3 incorrecte, signature incorrecte, état inline-signed périmé).

Correction : validez avec delv +vtrace ; re-signez proprement ; assurez des transferts de zone cohérents du contenu signé ; évitez les changements partiels de paramètres.

4) Symptom: authoritative CPU spikes correlate with NXDOMAIN floods

Cause racine : construction coûteuse de réponses négatives, mauvais comportement de cache, ou travail de signature qui déborde dans le service.

Correction : rate limit des sources abusives ; augmentez le caching en périphérie ; assurez que les chaînes NSEC3 sont pré-calculées ; envisagez NSEC pour les zones où l’énumération n’est pas un souci.

5) Symptom: “We enabled NSEC3 and security says it’s better, but incidents increased”

Cause racine : contrôle de sécurité choisi sans modèle de menace ; régressions de performance ignorées ; risque de divulgation surestimé.

Correction : documentez pourquoi NSEC3 est nécessaire ; si vous ne pouvez pas, ne l’utilisez pas. Préférez un DNSSEC plus simple quand c’est possible et concentrez-vous sur le contrôle d’exposition.

6) Symptom: intermittent SERVFAIL around key rollovers

Cause racine : débit du signer et délai de propagation ; changement des paramètres NSEC3 pendant des événements de clé ; fenêtres de validité des signatures trop serrées.

Correction : séparez les changements de paramètres des key rolls ; allongez les fenêtres de validité de façon appropriée ; surveillez la file du signer et l’état de publication.

7) Symptom: resolvers behave differently (some validate, some fail)

Cause racine : différences de MTU de chemin, différences de gestion EDNS, ou état cache cassé ; pas toujours des « bugs de résolveur ».

Correction : testez depuis plusieurs réseaux ; capturez la fragmentation ; confirmez la cohérence DS et DNSKEY ; réduisez la taille des réponses pour minimiser la sensibilité au chemin.

8) Symptom: “Zone walking is still possible even with NSEC3”

Cause racine : labels prévisibles permettent des attaques par dictionnaire ; d’autres sources de données fuient les noms de toute façon.

Correction : traitez le DNS public comme public. Retirez les noms sensibles, randomisez si approprié, et n’assumez pas que NSEC3 apporte la confidentialité.

Checklists / plan étape par étape

Checklist de décision : cette zone doit-elle utiliser NSEC3 ?

1. Listez la menace : essayez-vous d’empêcher l’énumération en masse de noms réellement impossibles à deviner, ou cherchez-vous juste à éviter l’embarras ?
2. Évaluez la prévisibilité du nommage : si les labels sont des mots communs, NSEC3 n’empêchera pas la devinette.
3. Estimez le volume NXDOMAIN : les zones à fort NXDOMAIN (typos, scanners, trafic de bots) paient plus cher pour NSEC3.
4. Définissez un budget UDP : choisissez une cible (souvent 1232) et testez les réponses négatives par rapport à ce budget.
5. Confirmez la maturité de la chaîne d’outils : votre équipe peut-elle valider et déboguer rapidement les échecs NSEC3 ?
6. Ayez un plan de rollback : les changements de paramètres et les mécanismes de déni d’existence nécessitent un déploiement par étapes et une surveillance.

Plan de déploiement : basculer NSEC ↔ NSEC3 sans douleur auto-infligée

1. Mesurez la base : mesurez la taille des réponses, le ratio NXDOMAIN, le taux TCP/53 et la latence tail.
2. Testez depuis plusieurs réseaux : incluez les chemins mobiles et « proxy d’entreprise ».
3. Faites un déploiement progressif : canarisez une zone ou un sous-ensemble d’autorités ; surveillez les taux TC=1 et les comptes de fragments.
4. Ne mélangez pas avec des événements de clé : ne changez pas les paramètres NSEC3 pendant des rolls KSK/ZSK. Séparez les variables.
5. Surveillez le comportement du cache négatif : vérifiez les taux de requêtes des résolveurs après le changement ; ne comptez pas sur les caches pour tout sauver.
6. Répétez les scénarios d’échec : entraînez-vous à valider SERVFAIL et les échecs de preuves de non-existence avec votre équipe on-call.

Checklist opérationnelle : garder DNSSEC ennuyeux (le plus grand compliment)

1. Surveillez la taille des réponses DNS (surtout NXDOMAIN) et les percentiles, pas seulement les moyennes.
2. Surveillez les taux TCP/53, le taux du bit TC, et les comptes de fragments UDP.
3. Alertez sur l’horizon d’expiration des signatures (RRSIG proches de l’expiration).
4. Gardez les horloges des signers correctes (NTP) et vérifiez la synchronisation temporelle sur signers et autorités.
5. Documentez les runbooks de key roll et effectuez-les de préférence en heures ouvrables.
6. Gardez des valeurs EDNS tampon par défaut raisonnables ; évitez les gros tampons qui invitent à la fragmentation sur l’internet ouvert.
7. Supposez que des inondations NXDOMAIN arriveront ; ayez le rate limiting et les contrôles anti-abus prêts.

FAQ

1) Is NSEC3 required for DNSSEC?

Non. DNSSEC exige un déni d’existence authentifié, mais cela peut être fourni par NSEC ou NSEC3. Beaucoup de zones fonctionnent avec succès en NSEC.

2) Does NSEC3 make my zone “private”?

Non. Il rend l’énumération en masse plus difficile, pas la découverte ciblée. Si les noms sont devinables, ils sont découverts.

3) Why do NXDOMAIN answers get so big with DNSSEC?

Parce que le serveur doit inclure une preuve. Cette preuve inclut des enregistrements de déni (NSEC/NSEC3) et leurs signatures, plus souvent le SOA et sa signature.
Les preuves NSEC3 peuvent inclure plusieurs enregistrements.

4) Should I increase NSEC3 iterations for better security?

Seulement si vous avez un modèle de menace clair qui en bénéficie et si vous avez testé l’impact opérationnel sur la signature et le service. Sinon, gardez-les conservatrices ou évitez NSEC3.

5) What’s the simplest way to tell if NSEC3 is causing performance issues?

Comparez la taille et la latence des réponses positives vs des requêtes NXDOMAIN, et vérifiez si NXDOMAIN vous pousse vers la troncation, la fragmentation ou le basculement TCP.

6) If I switch from NSEC3 to NSEC, will validators break?

Ils ne devraient pas, tant que la zone est correctement signée et publiée. Mais la transition est sensible opérationnellement : déployez-la prudemment et surveillez la validation et le comportement du cache.

7) Is NSEC always faster than NSEC3?

Souvent, oui — surtout pour les réponses négatives — parce que les preuves sont plus simples et généralement plus petites. Mais votre expérience dépendra du contenu de la zone,
de l’implémentation serveur et des réseaux clients.

8) What about NSEC3 opt-out—should I use it?

L’opt-out existe principalement pour des zones avec beaucoup de délégations non sécurisées (comme certains registres) pour réduire le nombre d’enregistrements et la charge opérationnelle.
Il complique aussi la sémantique d’assurance. Si vous ne pouvez pas expliquer ce que cela fait à un auditeur et à l’on-call, ne l’utilisez pas à la légère.

9) Our security team wants NSEC3 to prevent “attackers learning our subdomains.” What should I tell them?

Dites-leur que NSEC3 réduit l’énumération triviale mais n’empêche pas la devinette, la découverte CT, ou la découverte passive DNS. S’ils insistent, exigez un budget de taille de réponse
et des SLO opérationnels pour éviter que la fiabilité ne soit sacrifiée en silence.

10) What is the most common DNSSEC failure that looks like performance?

La perte et les retries provoquées par la fragmentation. Cela se manifeste par des timeouts intermittents et une latence tail plus élevée, pas par un événement net « en panne ».
DNSSEC (et surtout les réponses négatives volumineuses) peut vous pousser dans ce régime.

Conclusion : quoi faire ensuite (pratique, pas spirituel)

NSEC3 n’est pas « DNSSEC en mieux ». C’est un compromis spécifique : moins de divulgation de noms en échange de plus de complexité, de réponses négatives plus volumineuses,
et d’une chance plus élevée de découvrir que certaines parties d’internet ne transportent pas vos paquets de façon fiable.

Prochaines étapes qui rapportent :

1. Mesurez le comportement NXDOMAIN dans votre zone : taille, latence, taux de basculement TCP, et signaux de fragmentation.
2. Décidez si l’énumération est un vrai problème pour votre zone. Si les noms sont devinables, corrigez l’exposition et le nommage, pas seulement les preuves de déni.
3. Choisissez un budget UDP et appliquez-le comme test de régression pour les changements DNS, en particulier les changements DNSSEC.
4. Si vous utilisez NSEC3, gardez des paramètres conservateurs et séparez les changements de paramètres des key rollovers.
5. Opérationnalisez la validation : runbooks, tests multi-vues, et alertes pour l’expiration des signatures et les pics TCP.

Exécutez DNSSEC comme vous gérez le stockage : supposez les pannes, surveillez la latence tail, et préférez la conception la plus simple qui répond au besoin réel.
NSEC est souvent cette conception. NSEC3 est pour quand vous pouvez nommer l’ennemi et accepter la facture.