Résumé

  • DNSSEC a transformé une réponse DNS négative en preuve vérifiable en signant les bornes ordonnées qui entourent les noms et types d’enregistrements absents.
  • NSEC3, Opt-Out et l’exploitation du cache validé répartissent divulgation, calcul, assurance des délégations et délai d’activation d’un nouveau nom.

Imaginez des archives où chaque dossier présent porte une signature authentique. Ces signatures ne prouvent pas que le dossier demandé n’a pas été dissimulé. Pour démontrer une absence, il faut aussi un catalogue signé dont l’ordre rende le vide visible.

C’est le déplacement conceptuel opéré par le déni d’existence de DNSSEC.

Le DNS ordinaire renvoie NXDOMAIN lorsqu’un nom n’existe pas, ou une réponse sans données lorsque le nom existe mais pas le type demandé. Sans validation DNSSEC, ce refus dépend de la fiabilité du trajet de réponse. Un adversaire placé sur ce trajet n’a même pas besoin de détourner un service : le faire disparaître peut suffire.

La RFC 4034 donne à une zone signée un moyen de décrire ses intervalles vides. Un enregistrement NSEC indique le propriétaire faisant autorité suivant dans l’ordre canonique de la zone et les types présents au nom courant. La RFC 4035 explique ensuite la validation. Si le nom demandé tombe entre deux bornes signées, l’intervalle établit qu’aucun nom exact ne s’y trouve. Si le nom existe mais que le type manque dans la table de bits signée, la preuve porte sur ce type. Une erreur de nom doit aussi exclure le joker qui aurait pu fournir une réponse.

Il n’existe donc pas un enregistrement négatif pour chaque question imaginable. Ce serait impossible. La preuve est l’intervalle ordonné : deux faits authentifiés délimitent un vide.

La première preuve révélait le catalogue

Cette clarté avait un prix. Chaque NSEC pointant vers le nom suivant, un observateur patient pouvait parcourir la chaîne et reconstituer la zone.

Ce « parcours de zone » ne dévoile pas des données que le DNS aurait été conçu pour chiffrer. Les noms sont publiés pour être utilisés. Mais une liste facile à énumérer peut révéler des habitudes de nommage, des services à apparence interne ou une carte de reconnaissance auparavant coûteuse à dresser. Le validateur exige une preuve assez précise pour borner l’absence, tandis que l’opérateur ne souhaite pas toujours livrer un index en clair.

La RFC 5155 a introduit NSEC3. Le principe de chaîne demeure, mais les noms directement lisibles sont remplacés par des empreintes. Le validateur peut encore constater que l’empreinte de la requête appartient à un intervalle signé ; l’observateur doit deviner les libellés hors ligne.

Il s’agit d’un obstacle, pas du secret. Les libellés usuels sont prévisibles et apparaissent dans les certificats, journaux ou liens. La RFC 9276 souligne le rendement décroissant : multiplier les itérations impose du travail aux serveurs faisant autorité et aux validateurs sans rendre confidentiels des noms devinables.

Opt-Out inscrit le coût d’échelle dans la preuve

Les grandes zones remplies de délégations ont rencontré un autre coût. Lorsque la plupart des zones filles ne sont pas signées, créer et entretenir un NSEC3 pour chacune peut peser sur la signature et la mémoire. Opt-Out permet à un intervalle de couvrir des délégations non sécurisées sans enregistrement haché propre à chacune.

L’économie est réelle, mais la concession sémantique aussi. Selon la RFC 5155, un intervalle Opt-Out n’affirme pas si une délégation non sécurisée qu’il couvre existe ou non. Les autres données faisant autorité restent protégées, mais la preuve est volontairement moins complète à cette frontière. La zone accélère les changements de délégation en renonçant au même niveau d’affirmation cryptographique pour chaque enfant non signé.

Opt-Out est donc une décision de gouvernance, pas un simple réglage. Il détermine les absences que l’opérateur accepte de garantir. La RFC 9276 le déconseille aux petites zones et ne lui reconnaît une justification plausible que dans des zones de délégation très vastes, dynamiques et faiblement signées.

Un intervalle en cache peut répondre plus tard

La RFC 8198 permet à un résolveur validant de réutiliser agressivement des intervalles NSEC ou NSEC3 en cache. Si une requête ultérieure tombe dans un espace déjà prouvé vide, il peut fabriquer la réponse négative sans interroger de nouveau le serveur faisant autorité.

Cela réduit latence, charge et divulgation de requêtes inutiles, et peut absorber une partie d’une attaque par libellés aléatoires. Mais le cache applique un énoncé signé à des questions futures : sa durée devient une donnée d’exploitation.

La RFC 8198 précise que les TTL de NSEC ou NSEC3, combinés aux valeurs de cache négatif de la zone, déterminent la rapidité avec laquelle un nouveau nom peut commencer à fonctionner. Publier un nom juste après une preuve d’absence à longue durée peut laisser des résolveurs validants répondre correctement « non » depuis leur cache. Le protocole n’est pas fautif ; le calendrier de changement a ignoré la validité de la preuve négative.

La pratique actuelle privilégie la retenue

La RFC 9276 recommande NSEC lorsque les fonctions de NSEC3 ne sont pas nécessaires. Si NSEC3 s’impose, elle exige zéro itération supplémentaire et recommande un sel vide. Les itérations additionnelles augmentent le calcul, le risque d’épuisement CPU et les défauts d’interopérabilité ; un sel statique apporte peu, car le nom pleinement qualifié rend déjà le travail propre à chaque zone.

Après un changement de paramètres, le texte recommande aussi d’interroger les secondaires avec des noms connus comme inexistants. Ce test détecte une chaîne négative périmée, incohérente ou trop coûteuse alors que les enregistrements positifs paraissent sains.

Ces RFC définissent un mécanisme et une pratique actuelle ; elles ne prouvent pas la qualité d’un déploiement particulier. Celle-ci doit être mesurée aux frontières faisant autorité et validantes réelles.

Sources