Résumé

  • GSS-TSIG négocie un contexte GSS au moyen de TKEY puis protège les messages DNS avec TSIG ; il n’établit pas la permission de modifier une zone.
  • La preuve complète doit relier séparément principal authentifié, politique locale, action autorisée, écriture exécutée, propagation et observation DNS.

Le piège commence par une phrase exacte mais incomplète : « la signature est valide ». Elle signifie qu’un message a été vérifié dans un contexte déterminé. Elle ne signifie pas encore que le signataire pouvait supprimer cet enregistrement, que le serveur primaire a conservé la modification ni qu’un résolveur l’a ensuite observée.

RFC 3645 organise le mécanisme en deux temps. Le client et le serveur échangent d’abord des jetons opaques GSS-API dans des enregistrements TKEY, via GSS_Init_sec_context et GSS_Accept_sec_context. Après établissement du contexte, GSS_GetMIC et GSS_VerifyMIC produisent et contrôlent les signatures placées dans TSIG. L’édition texte formule la limite sans détour : le document décrit l’authentification, pas un mécanisme d’autorisation.

Cette réserve n’est pas un détail juridique. Authentifier consiste à déterminer quel principal a protégé la requête. Autoriser consiste à comparer ce principal, l’action demandée, le nom et le type d’enregistrement à la politique du gestionnaire de zone. Exécuter consiste à modifier l’état. Publier et observer consistent à faire parvenir cet état aux serveurs et caches pertinents. Chacune de ces étapes peut réussir ou échouer indépendamment.

L’architecture elle-même impose cette modestie. RFC 2743 définit l’abstraction GSS-API. RFC 2930 fait de TKEY un véhicule d’établissement de clé. RFC 2845 a défini TSIG pour l’authentification des transactions, puis RFC 8945 l’a modernisé. RFC 4121 décrit le mécanisme Kerberos v5 pour GSS. Aucun de ces composants ne décide seul de la politique administrative d’une zone.

Le contexte est un état vivant, non un sceau perpétuel. RFC 3645 le fait passer d’« initialisé » à « en négociation », puis « établi » ; il possède une durée de vie finie et une identité liée au couple client-serveur. Plusieurs allers-retours peuvent être nécessaires, avec une limite de dix tentatives dans les boucles décrites. Le client ne doit avancer vers l’état établi qu’après avoir vérifié la réponse finale signée. Une erreur de contexte ou de signature ne doit jamais être recyclée en présomption d’autorité.

Le profil d’interopérabilité recommande SPNEGO et exige la prise en charge de Kerberos v5, sans interdire d’autres mécanismes. La protection dépend donc du mécanisme sous-jacent. Un journal qui ne conserve que le mot gss-tsig perd le mécanisme négocié, le nom cible, la provenance des identifiants, le nom de clé, la durée du contexte, l’état anti-rejeu et le résultat précis de la vérification.

L’autorisation se trouve ailleurs. RFC 3007 confie la politique au gestionnaire de zone et son application au serveur ; elle dépend du principal authentifié et de l’action souhaitée, avec un refus par défaut en l’absence de permission. RFC 2136 décrit les prérequis et opérations de mise à jour dynamique. La signature fournit donc une identité exploitable par le contrôle, non un laissez-passer universel.

Il faut encore distinguer l’écriture de la lecture. RFC 4033 présente DNSSEC comme une protection de l’origine et de l’intégrité des données DNS. Valider une réponse DNSSEC ne reconstitue pas l’autorisation d’une ancienne mise à jour ; vérifier une transaction ne garantit pas non plus sa propagation. Ce sont des preuves complémentaires, non interchangeables.

Les registres IANA matérialisent le même principe. Le registre des algorithmes TSIG répertorie gss-tsig, et le registre des paramètres DNS, encadré notamment par RFC 6895, coordonne des valeurs communes. Une inscription confirme un vocabulaire partagé ; elle ne prouve ni contexte actif, ni permission, ni changement exécuté.

La provenance du standard demeure contrôlable dans la notice RFC Editor, la fiche Datatracker, son historique et la recherche d’errata. Elle borne les affirmations possibles sans inventer un taux de déploiement ou le comportement d’un produit.

Les textes de Heng Lu sur les couches de réalité, la spécification commune minimale et la primauté du code en service donnent la lecture institutionnelle. La norme rend l’interopérabilité possible ; la politique locale attribue des droits ; le serveur en fonctionnement et l’observation ultérieure attestent le résultat. Confondre ces niveaux transforme une preuve technique limitée en pouvoir administratif imaginaire.