Résumé

  • La RFC 2845 faisait inclure au MAC d’une réponse DNS signée le MAC de la requête qui l’avait provoquée.
  • Dans un échange DNS/TCP à plusieurs messages, un MAC cumulatif couvrait le MAC précédent et les messages intermédiaires, avec des TSIG au début, à la fin et au moins tous les cent messages.
  • La RFC 8945 a ensuite imposé TSIG sur chaque message de réponse émis, tout en gardant une tolérance de compatibilité limitée pour les messages intermédiaires non signés. Ni l’une ni l’autre ne transforme l’authentification de transaction en confidentialité, vérité des données ou autorisation locale.

Une réponse n’était pas un paquet isolé

Les identifiants et codes de réponse DNS décrivaient un échange sans authentifier le pair ni protéger la transaction contre une modification. Publiée en mai 2000, la RFC 2845 a ajouté TSIG : un enregistrement de métadonnées placé dans le message DNS et vérifié avec un secret partagé. La portée était volontairement point à point. Les deux interlocuteurs devaient déjà avoir configuré la même clé ; sa distribution restait hors du périmètre.

Le choix déterminant se trouvait dans l’entrée du calcul MAC. Le client authentifiait d’abord sa requête. Pour répondre par un message signé, le serveur intégrait le MAC de cette requête, le message de réponse et les paramètres TSIG de la réponse. Le vérificateur ne traitait donc pas la réponse comme un objet neuf, détaché de son contexte : la vérification cryptographique remontait jusqu’à la requête. L’heure signée et la marge temporelle, elles aussi couvertes, ne pouvaient pas être modifiées par un intermédiaire sans invalider le MAC.

Cette liaison portait sur des octets couverts et une relation de clé. Comme les deux pairs partageaient le secret, une vérification réussie indiquait que le message correspondait à la clé configurée ; elle ne révélait pas quelle personne ou quel processus la détenait. TSIG ne chiffrait pas le DNS et ne décidait pas si le serveur devait autoriser une mise à jour. La RFC 2136 définissait DNS UPDATE ; la politique locale devait encore dire si ce pair authentifié pouvait modifier la zone.

Le transfert formait une suite

Le cas plus délicat était une réponse répartie sur plusieurs messages, comme un transfert de zone par TCP. Si chaque message était vérifié isolément, le vérificateur perdait l’ordre et la relation entre les paquets. La RFC 2845 exigeait donc TSIG sur le premier et le dernier message, puis au moins un point de contrôle signé tous les cent messages. Entre deux contrôles, chaque message DNS s’ajoutait au calcul MAC suivant dans l’ordre, avec le MAC précédent et les paramètres temporels concernés.

Le contrôle portait ainsi sur la continuité d’un segment borné du flux, non sur la signature indépendante de chaque message intermédiaire. En cas d’échec, la RFC imposait de fermer la connexion TCP et de traiter le transfert comme interrompu ; elle ne fixait pas une procédure précise de reprise. Un contrôle valide couvre une partie du flux reçu, pas ce que le serveur a ensuite enregistré ni ce qu’un serveur secondaire a servi.

La règle a évolué, pas la limite

La RFC 4635 a ajouté des identifiants d’algorithmes HMAC-SHA au-delà du HMAC-MD5 d’origine. En 2020, la RFC 8945 a remplacé les RFC 2845 et 4635 comme norme Internet STD 93. La règle d’émission est devenue plus stricte : un émetteur conforme signe chaque message de la réponse. La règle de compatibilité du vérificateur est différente : il doit accepter jusqu’à 99 messages intermédiaires non signés, tout en exigeant que le premier et le dernier soient signés. Cette tolérance de 99 messages n’autorise pas un émetteur moderne à omettre TSIG.

La RFC 8945 énonce aussi la limite de preuve : TSIG authentifie la transmission entre deux pairs partageant un secret, pas l’origine ni l’exactitude des données sources. Ce n’est pas DNSSEC, qui authentifie les données selon un autre modèle de confiance. TKEY peut établir des clés dans certains déploiements, mais la distribution des secrets n’est pas une propriété de TSIG. Les normes décrivent un mécanisme précis, non un sceau universel de confiance.

Sources : RFC 1035 ; RFC 2104 ; RFC 2845 ; RFC 8945 ; RFC 4635 ; RFC 2136 ; RFC 2930.