Résumé

  • Les cookies DNS constituent un état transactionnel léger destiné à compliquer certaines attaques hors chemin par amplification, falsification ou empoisonnement de cache.
  • Un Server Cookie valide donne au serveur une assurance limitée : la requête provient de l’adresse source observée et contient un Client Cookie déjà vu lors d’un échange antérieur.
  • Le mécanisme ne résiste pas à un observateur en chemin et ne permet d’identifier ni l’utilisateur, ni l’abonné, ni le propriétaire de l’appareil, ni le compte de service à l’origine d’une requête passée par un résolveur ou un NAT.
  • L’exploitation a donc besoin d’un journal d’audit des requêtes DNS qui distingue validation du cookie, observation réseau, identité du résolveur et autorisation.

Imaginons un contrôle anti-abus sans l’attribuer à un opérateur réel. Un foyer, une entreprise ou un réseau d’accès envoie ses requêtes à travers un résolveur récursif partagé. Celui-ci contacte un service anycast, reçoit un Server Cookie puis en présente un qui reste valide depuis la même adresse publique. Un système en aval en déduit que le même client a produit les deux requêtes. Le protocole affirme moins : la seconde requête contient un état que le serveur peut vérifier à partir du Client Cookie, de l’adresse observée, d’un secret et d’une fenêtre temporelle.

RFC 7873 définit les cookies DNS comme un mécanisme léger de sécurité transactionnelle. Leur objet est d’offrir une protection limitée contre l’amplification, la falsification de réponses et l’empoisonnement de cache lorsqu’un attaquant ne peut pas observer l’échange. Cette condition « hors chemin » constitue la frontière de la preuve.

Une première requête transporte un Client Cookie de huit octets. Après la réponse du serveur, les requêtes suivantes peuvent joindre le Client Cookie au Server Cookie reçu. Le serveur peut alors écarter ou restreindre un trafic incapable de reproduire l’état qu’il a émis. Le dispositif se déploie progressivement, tolère le NAT et fonctionne en anycast sans imposer à chaque internaute un identifiant convenu à l’avance.

Ces qualités expliquent pourquoi le RFC parle d’une forme faible d’authentification et non d’un système d’identité. Un routeur, un pont, un participant à un support partagé ou tout autre observateur en chemin peut lire un trafic DNS en clair et voir le cookie. Pendant sa durée d’utilisation, il peut réemployer ce qu’il a observé. Le cookie augmente donc le coût d’une falsification hors chemin ; il ne transforme pas une valeur porteuse visible en preuve d’une personne ou d’une organisation.

RFC 9018 rend la construction du Server Cookie interopérable. La version 1 combine le Client Cookie, les champs de version et réservés, un horodatage et l’adresse IP source sous un Server Secret. L’adresse intervient dans le calcul sans apparaître dans la valeur du cookie. Le serveur vérifie le résultat avec le même secret.

La construction répond à une question précise : la requête est-elle compatible avec un cookie précédemment produit pour ce Client Cookie et cette adresse observée, sous un secret et une fenêtre encore valides ? Elle ne dit pas qui utilise l’adresse. Plusieurs personnes peuvent partager un résolveur. Plusieurs appareils peuvent sortir par le même NAT. Le processus de résolution peut redémarrer, renouveler son Client Cookie ou changer d’adresse. Inversement, une adresse peut demeurer stable alors que les personnes et leurs droits changent.

Le temps fait partie de la preuve. RFC 9018 impose de vérifier l’horodatage dans une période définie et recommande une tolérance d’environ une heure dans le passé et cinq minutes dans le futur. Le serveur devrait renouveler une valeur reçue vieille de plus d’une demi-heure. Cette borne réduit le rejeu ; elle ne devient pas pour autant l’époque d’autorisation d’un compte.

L’anycast ajoute une autre séparation. Les membres d’un ensemble doivent utiliser une construction compatible et disposer des secrets nécessaires pour valider les cookies produits par leurs pairs. RFC 9018 décrit une rotation en trois étapes : distribuer le nouveau secret tout en générant avec l’ancien ; commencer à générer avec le nouveau tout en validant les deux ; puis retirer l’ancien après le renouvellement des clients. L’acceptation par un autre membre prouve une cohérence de validation de la flotte, non le retour du même serveur physique, du même processus ou du même utilisateur.

Les règles de confidentialité confirment cette limite. Le client doit créer un nouveau Client Cookie lorsque son adresse change, tandis qu’un client derrière un NAT peut ignorer le changement de son adresse publique. La continuité du cookie est donc volontairement liée au contexte réseau et à l’état de l’implémentation. En faire un identifiant durable contredirait les hypothèses de mobilité et de confidentialité du mécanisme.

Le point de comparaison plus fort est RFC 8945, qui normalise TSIG. TSIG authentifie une transaction DNS par un code d’authentification entre des entités qui partagent déjà un secret configuré. Il peut établir qu’une mise à jour ou une réponse vient d’une partie agréée détenant la clé. Cette propriété exige distribution et protection des clés ainsi qu’une relation de confiance nommée que les cookies DNS évitent volontairement.

Même TSIG possède sa frontière : il authentifie la transmission entre deux parties partageant un secret, pas la vérité ni la provenance initiale de chaque donnée DNS. Les cookies DNS ne peuvent hériter de cette authentification plus forte sous prétexte que les deux mécanismes utilisent des calculs à clé. L’un fournit un état anti-falsification léger et largement déployable ; l’autre authentifie des transactions au sein d’une confiance préétablie.

L’erreur opérationnelle consiste à réduire quatre observations à un indicateur d’identité. Le Server Cookie peut être valide. L’adresse source peut correspondre au calcul. Le chemin peut néanmoins être observable. Le résolveur peut représenter de nombreux utilisateurs dotés de droits applicatifs différents. Un limiteur de débit peut employer le cookie comme signal anti-abus sans prétendre avoir authentifié un client.

Un tel journal d’audit conserverait ces éléments. Il enregistrerait le Client Cookie, la version et l’horodatage du Server Cookie, le résultat de validation, l’adresse source observée, le membre anycast répondant, la génération du Server Secret, le transport et son exposition en chemin, l’instance de résolution lorsqu’elle est connue, tout utilisateur ou compte de service authentifié séparément, la politique d’autorisation et l’heure de l’action. Il ne conserverait jamais le secret lui-même.

Cette discipline préserve l’utilité du mécanisme. Les cookies valides peuvent soutenir la limitation de débit, réduire les possibilités de réflexion et filtrer des requêtes manifestement falsifiées avant des contrôles plus coûteux. Ils révèlent aussi des défauts de rotation ou de cohérence anycast. Leur valeur vient de la lisibilité de leur preuve, pas d’une promotion au-delà de leur modèle de menace.

Sources

RFC 7873 — Domain Name System (DNS) Cookies; RFC 9018 — Interoperable DNS Server Cookies; RFC 8945 — Secret Key Transaction Authentication for DNS.