Résumé

  • DNS Cookies ajoute à DNS sur UDP un indice léger et sans état côté serveur. Le couple de cookies relie faiblement un échange antérieur à une adresse IP ; il n’identifie pas une personne, n’authentifie pas les données DNS et ne protège pas contre un observateur sur le chemin.
  • La RFC 9018 fixe une méthode interopérable : Server Cookie version 1 de 16 octets, SipHash-2-4, horodatage et secret configurable. Dans un ensemble anycast, la distribution et la rotation de ce secret deviennent une surface de pouvoir opérationnel.
  • Une preuve défendable relie les octets reçus, la cause de validation, le nœud, l’époque du secret, BADCOOKIE, la défense effectivement assouplie, la taille de réponse et le résultat du nouvel essai.

Un client connu, mais seulement au sens du paquet

Un service DNS autoritatif anycast subit une vague de requêtes UDP visant une réponse volumineuse. Pour les sources inconnues, il limite la réponse afin de ne pas devenir amplificateur. Un résolveur revient avec le Client Cookie choisi lors du premier échange et le Server Cookie renvoyé par le service. La vérification réussit ; la politique permet alors une réponse plus complète.

La phrase « client connu » paraît naturelle et devient vite dangereuse. L’adresse peut être partagée par des milliers d’abonnés derrière un CGNAT. Elle peut avoir été réattribuée. Un observateur situé sur le chemin peut recopier le cookie pendant sa durée de validité. Un nœud anycast peut accepter une ancienne clé que les autres ont déjà retirée. Les mêmes octets n’impliquent donc pas la même histoire organisationnelle.

Le mécanisme n’a pas échoué. Il répond à une question plus modeste : l’émetteur apparent a-t-il pu recevoir récemment une valeur produite par le serveur pour ce Client Cookie et cette adresse ? Il ne dit pas qui contrôle le résolveur, si la requête est bienveillante, si les données demandées sont authentiques ou si toutes les autres protections peuvent être désactivées.

La véritable autorité réside dans la règle qui consomme ce résultat. Le validateur fournit un fait. La limitation de débit, le contrôle de taille ou la politique anti-abus décide de l’effet accordé à ce fait.

Deux cookies, deux fonctions asymétriques

L’IANA attribue le code d’option EDNS 10 à COOKIE. Lorsque le client ne connaît pas encore la valeur du serveur, la RFC 7873 prévoit une option de huit octets contenant seulement le Client Cookie. La réponse ajoute un Server Cookie. Les requêtes suivantes renvoient le couple, sans obliger le serveur à conserver une table par client.

Le Client Cookie n’est pas un certificat. La RFC 9018 recommande 64 bits d’entropie, une valeur différente pour chaque adresse de serveur, un renouvellement lorsque l’adresse du client change et aucune persistance après redémarrage du programme. Le client reconnaît sa propre valeur ; le serveur n’y découvre aucun nom.

Le Server Cookie version 1 comporte 16 octets. L’option complète mesure donc exactement 24 octets. SipHash-2-4 reçoit le Client Cookie, la version, les octets réservés, l’horodatage et l’adresse IP du client, sous une clé secrète. La valeur prouve faiblement un aller-retour antérieur, tout en restant calculable sans état individuel.

Cette économie déplace le risque vers trois objets : le secret, la fenêtre temporelle et l’encodage exact. Une longueur illégale ne doit pas être interprétée généreusement. Une horloge décalée modifie le domaine de validité. Une clé copiée trop largement augmente le nombre de machines capables de fabriquer une valeur acceptable.

Une assurance faible doit produire un privilège faible

Un cookie valide aide contre l’usurpation hors chemin. Un attaquant qui forge seulement l’adresse source ne reçoit pas la réponse contenant le Server Cookie et ne peut normalement pas inventer son MAC. Le serveur peut réserver certaines réponses coûteuses ou volumineuses aux sources ayant démontré ce retour.

Mais un acteur sur le chemin voit la valeur. DNS Cookies ne chiffre ni la question ni la réponse. Il ne signe pas les RRsets. DNSSEC répond à l’authenticité des données ; l’aléa de l’identifiant et du port aide à associer une réponse à la transaction ; TLS, HTTPS ou QUIC ajoutent des propriétés de transport. Aucun de ces mécanismes ne doit être résumé par un unique voyant « DNS sécurisé ».

La règle raisonnable est négative : un cookie ne peut lever que les défenses directement liées à la falsification hors chemin. Il ne doit pas ouvrir la récursion, contourner l’accès, ignorer DNSSEC, supprimer toute limite de débit ni excuser une anomalie. Un résolveur compromis conserve des cookies parfaitement valides.

L’adresse elle-même n’est pas une identité stable. Le NAT agrège, la mobilité déplace, les baux changent. La liaison à l’adresse reste précieuse pour le modèle de menace, mais sa précision ne doit pas être transformée en certitude sociale.

L’anycast transforme la clé en responsabilité commune

Deux requêtes adressées à la même IP anycast peuvent atteindre des nœuds différents. Pour éviter que le second rejette systématiquement le cookie émis par le premier, l’ensemble doit partager une méthode et des époques compatibles. La RFC 9018 rend la construction version 1 interopérable et exige que le Server Secret soit configurable.

La rotation suit trois phases. D’abord, tous les nœuds apprennent la nouvelle clé, continuent à générer avec l’ancienne et vérifient les deux. Ensuite, ils génèrent avec la nouvelle tout en acceptant l’ancienne. Enfin, l’ancienne est retirée après le délai prévu pour le renouvellement des clients. Inverser l’ordre crée des tempêtes de BADCOOKIE dépendantes de la géographie.

Une livraison de configuration n’est pas une preuve d’activation. Chaque nœud doit publier un identifiant d’époque non secret, l’état appris/généré/accepté et son horloge. La clé commune doit être limitée au plus petit ensemble qui a réellement besoin d’interopérer ; partager la même matière entre environnements ou adresses indépendants transformerait une compromission locale en capacité globale de fabrication.

BADCOOKIE raconte plusieurs histoires

Un Server Cookie invalide peut être ancien, lié à une autre adresse ou à un autre Client Cookie, produit par une époque inconnue, mal formé, ou falsifié. BADCOOKIE permet au serveur de fournir une nouvelle valeur ; si le Client Cookie correspond, le client peut recommencer. La boucle doit rester bornée.

Le compteur brut d’échecs ne suffit pas. Une concentration sur un site signale souvent une dérive de secrets. Une hausse après changement d’accès peut venir du NAT ou de la mobilité. Des longueurs invalides sur tous les sites suggèrent plutôt une attaque de parseur. L’équipe doit conserver la catégorie exacte avant de qualifier l’intention.

Mesurer seulement les validations réussies masque la compatibilité réelle. Il faut connaître les premières rencontres, les cookies valides, périmés et mal formés, les réponses BADCOOKIE, les nouveaux essais réussis, les abandons et le repli vers TCP. Un mécanisme qui protège bien mais empêche une population légitime de terminer sa résolution n’est pas déployé correctement.

La norme coordonne ; les paquets établissent la réalité

La Minimum Initial Specification de Heng Lu éclaire ici une architecture sobre. Le code d’option, les longueurs, la méthode cryptographique, l’horodatage et BADCOOKIE forment la couche commune. La taille maximale accordée, la stratégie anti-DDoS, l’organisation de garde des clés et le calendrier de déploiement restent locaux.

Localized Future Decision permet à un serveur de refuser un privilège malgré un cookie valide lorsqu’il manque de capacité, et à un client de continuer avec un serveur sans cookie. Voluntary Adoption signifie que la publication d’une RFC ne crée aucun comportement : seules l’implémentation, l’observation et l’usage en production le font.

Le registre IANA est symbolique. L’option reçue est un état protocolaire. La branche de politique qui augmente une réponse est un pouvoir exécutable. Les octets envoyés et leur facteur d’amplification sont la conséquence. La primauté du code en fonctionnement exige de conserver ces quatre couches, non de déclarer légitime tout ce qu’un programme exécute.

Sources