Résumé

  • Le RFC 2065 plaçait la preuve d’origine et d’intégrité dans des enregistrements DNS signés, afin qu’un résolveur puisse vérifier les données sans faire confiance à chaque serveur qui les transportait.
  • Cette compatibilité avait des limites visibles : un ancien serveur pouvait conserver et restituer KEY, SIG et NXT, mais l’envoi automatique des signatures, les alias CNAME et les indicateurs AD/CD exigeaient davantage.
  • Le texte refusait explicitement la confidentialité et le contrôle d’accès ; une adresse authentifiée ne prouvait pas davantage la légitimité de la machine qui l’utilisait.

Un cache DNS reçoit une réponse, la conserve, puis la transmet. Que prouve cette chaîne ? En 1997, le RFC 2065 a répondu en déplaçant la question. La confiance ne devait pas découler du simple fait que le paquet avait franchi un serveur connu. Elle pouvait être établie à partir d’objets signés, vérifiés par le résolveur qui devait ensuite s’appuyer sur le résultat.

Le détail décisif se trouve dans l’attribution de la clé : la clé d’authentification appartenait à la zone, non aux serveurs qui détenaient ses copies. La compromission d’un serveur pouvait supprimer une réponse, en retarder une autre ou rejouer des données. Elle ne donnait pas automatiquement le moyen de fabriquer une signature récente et valide au nom de la zone.

La sécurité fut découpée en trois services

Le RFC distinguait distribution de clés publiques, authentification de l’origine des données, et authentification facultative des transactions ou requêtes. Cette séparation empêchait une réponse « sécurisée » de devenir une formule sans contenu précis.

L’enregistrement KEY liait une clé publique à un nom DNS. Le résolveur devait néanmoins posséder au moins un point de départ obtenu de manière fiable. Il pouvait ensuite lire des clés signées dans l’arbre des zones sécurisées. Le système ne supprimait donc pas l’ancrage de confiance ; il rendait explicite la chaîne qui partait de cet ancrage.

L’enregistrement SIG portait la preuve attachée à un ensemble d’enregistrements. Il nommait notamment le type couvert et le signataire, indiquait l’algorithme, le TTL d’origine ainsi que le début et la fin de la période de signature. Une signature valide disait quelque chose de borné : cet RRset provenait d’une autorité reliée à la clé de départ et n’avait pas été modifié. Elle ne validait pas automatiquement tous les éléments présents dans le même message.

L’enregistrement NXT traitait l’absence d’un nom ou d’un type. Ce mécanisme sera révisé par la suite, mais sa présence révélait déjà une exigence importante : une non-réponse ne valait pas preuve négative. L’absence devait posséder sa propre forme authentifiable.

Enfin, une signature de transaction ne remplaçait pas la signature des RRsets. Le texte soulignait qu’authentifier un message DNS ne rendait pas, par contagion, chacun de ses enregistrements authentique. La provenance du transport et la provenance des données restaient deux questions.

La migration passait par des serveurs imparfaits

Pour l’authentification d’origine, le RFC n’inventait pas un nouveau transport. Il ajoutait des types d’enregistrement au format DNS existant. Un serveur capable de stocker et restituer ces types pouvait participer, même sans exécuter de validation cryptographique.

Cette tolérance avait un prix mesurable. Un serveur conscient de la sécurité essayait de joindre la signature utile à la réponse. Un serveur ordinaire risquait de ne livrer que le type demandé. Le résolveur devait alors demander tous les SIG du nom et choisir ceux qui couvraient l’RRset recherché. Le supplément de requêtes finançait la coexistence ; il ne transformait pas le vieux logiciel en arbitre de confiance.

La coexistence n’était pas magique. Les CNAME constituaient une exception explicite : le traitement traditionnel d’un alias pouvait conduire le serveur à suivre la cible avant que le client n’obtienne les enregistrements de sécurité du nom d’origine. Le RFC définissait donc une conformité minimale — conserver, transférer et servir KEY, SIG et NXT — et une conformité complète, avec création des signatures, inclusion automatique, traitement adapté des alias et délégations, ainsi que prise en charge des bits d’en-tête.

AD signalait qu’un serveur avait vérifié les données qu’il envoyait. CD permettait à un résolveur qui voulait faire lui-même la cryptographie de demander des données avant la vérification en amont. Les anciens serveurs et résolveurs laissaient ces bits à zéro. Ce zéro facilitait la compatibilité, mais il ne constituait pas un verdict d’authenticité.

Le temps faisait partie de la preuve

Le cache DNS fait diminuer le TTL. Or toute modification d’une valeur signée casse la signature. Le RFC 2065 signait donc le TTL d’origine et ajoutait des dates de création et d’expiration. Le cache pouvait réduire sa durée de conservation, jamais l’étendre au-delà de la valeur signée. Une signature expirée cessait de prouver l’RRset, même si celui-ci restait présent en mémoire.

Il fallait également une horloge raisonnablement sûre. Reculer l’heure d’un résolveur pouvait ressusciter des signatures anciennes. Ici encore, le DNSSEC proposé ne se déclarait pas autosuffisant : il dépendait d’une source de temps protégée et de la politique locale du validateur.

Ce montage répartissait le contrôle. La zone choisissait les données, les clés et la fenêtre de signature. Les serveurs assuraient disponibilité et transport. Le résolveur choisissait ses clés initiales, validait et gérait son cache. Le réseau acheminait les paquets. Une réponse réussie ne fusionnait pas ces responsabilités.

Authentique ne voulait dire ni secret ni autorisé

Le chapitre sur les services non fournis est central. Le DNS était présenté comme une base publique donnant les mêmes réponses à tous. Aucun mécanisme de liste d’accès ni de différenciation des demandeurs n’était ajouté. Le protocole ne cachait pas davantage les requêtes ou les réponses ; le chiffrement du canal relevait d’un mécanisme distinct, tel qu’IPsec.

La limite continuait après la résolution. Obtenir de manière authentique l’adresse d’un hôte ne prouvait pas que l’hôte actuellement placé à cette adresse était légitime. Cela n’empêchait ni l’interception du trafic ni une réponse usurpée hors du DNS. Le RFC réduisait une incertitude bien définie, sans promettre une sécurité totale de l’application.

Un jalon révisable

Le RFC 2065 était un Proposed Standard. Les brouillons conservés par l’IETF s’échelonnent de 1994 à 1996, mais cette chronologie n’est pas une mesure d’adoption. En mars 1999, le RFC 2535 l’a remplacé en intégrant l’expérience des premières implémentations et les demandes d’utilisateurs potentiels. En 2005, les RFC 4033, 4034 et 4035 ont à leur tour remplacé cette génération.

Les formats et les mécanismes de délégation ont changé. La division des rôles est restée lisible : les signatures portent une preuve, les validateurs l’évaluent à partir d’ancrages locaux, les intermédiaires assurent le transport et la confidentialité demeure un autre service.

La « spécification initiale minimale » décrite bien plus tard par Lu Heng offre un angle de lecture, non une preuve des intentions des auteurs. Le RFC 2065 a fixé des règles vérifiables communes tout en laissant un ancien serveur transporter des objets qu’il ne savait pas juger. Sa leçon historique n’est donc pas que l’intermédiaire est inutile, mais que son utilité ne lui confère pas automatiquement l’autorité de décider du vrai.

Sources