Résumé
- Les DNS Cookies offrent une protection volontairement limitée contre l’amplification, la falsification et l’empoisonnement de cache par un attaquant hors chemin, en reliant la requête à une adresse source, un Client Cookie et une réponse antérieure.
- Un Server Cookie valide n’identifie pas une personne ni un appareil durable : plusieurs clients peuvent partager une adresse NAT, un changement d’adresse impose le renouvellement et un observateur sur le chemin peut réutiliser une valeur aperçue pendant sa validité.
- L’exploitation doit conserver la méthode, l’âge, le contexte d’adresse, le domaine de validation anycast et le résultat des reprises, tandis que l’accès, la facturation et les quotas individuels restent liés à un principal authentifié distinct.
Le tableau de bord qualifie la requête d’« authentifiée » parce que son Server Cookie est valide. Une règle aval en déduit l’identité d’un abonné, assouplit une limite ou attribue le volume à un compte. Le raccourci paraît logique : le serveur a produit une valeur difficile à deviner et la requête la rapporte depuis l’adresse attendue. Pourtant cette adresse peut être celle d’un NAT opérateur partagé par des milliers d’utilisateurs, ou celle d’un résolveur récursif qui agit pour toute une organisation.
Le cookie n’est pas inutile pour autant. Il répond simplement à une question plus étroite : la requête apporte-t-elle une preuve qu’un client utilisant ce Client Cookie, à cette adresse source, a reçu auparavant une réponse de ce serveur ou de son ensemble anycast interopérable ? C’est une propriété du chemin de retour et de la transaction. Le nom de l’utilisateur, son compte et ses droits appartiennent à une autre surface de preuve.
La valeur valide étaye un échange antérieur
La RFC 9018 présente les DNS Cookies comme un mécanisme léger de sécurité transactionnelle, capable de fournir une protection limitée contre l’amplification, la falsification et l’empoisonnement de cache provenant d’attaquants hors chemin. L’adjectif « limitée » décrit le modèle : l’attaquant visé ne voit pas l’échange entre la victime supposée et le service DNS et doit donc deviner une valeur qu’il n’a pas reçue.
Les deux champs du mécanisme ne sont pas symétriques. Le client choisit un Client Cookie imprévisible et doit en utiliser un différent pour chaque adresse IP de serveur. La RFC 9018 recommande 64 bits d’entropie. Ce champ n’est pas un justificatif de compte délivré par le serveur ; il s’agit d’une valeur produite côté client, renvoyée ensuite par le serveur. Sa séparation par adresse de serveur aide le client à relier une réponse à la cible qu’il avait interrogée.
Le Server Cookie est la preuve de retour produite par le service. La RFC 9018 le décrit comme l’équivalent d’un code d’authentification de message calculé à partir du Client Cookie, de l’adresse IP cliente, de champs définis de version et de temps, et d’un secret détenu par le serveur ou par l’ensemble de serveurs à la même adresse anycast. Présent et valide dans une nouvelle requête, il donne au serveur une assurance faible : un client à cette adresse, utilisant ce Client Cookie, a reçu une réponse antérieure contenant la valeur.
Cette assurance est suffisante pour modifier certaines défenses contre les requêtes UDP dont l’adresse source aurait été forgée. La RFC 7873 permet au serveur de considérer qu’il a déjà dialogué avec ce contexte client. Elle ne définit pas un protocole général d’authentification. Le cookie ne prouve ni l’appartenance à un compte, ni le droit de consulter une vue protégée, ni l’identité de la personne à laquelle facturer la requête.
Une adresse NAT n’est pas un utilisateur
Le NAT rend la frontière immédiatement visible. Plusieurs foyers, terminaux ou applications peuvent apparaître au serveur DNS sous une même adresse publique. La RFC 9018 note aussi qu’un client placé derrière un équipement NAT peut être incapable de détecter le changement de cette adresse publique. Le serveur, lui, peut suivre l’adresse du dispositif NAT ; empêcher ce suivi sort du champ du document.
Un Server Cookie valide peut donc contribuer à une décision portant sur le chemin de retour vers cette adresse publique sans distinguer les acteurs qui la partagent. Utiliser la valeur comme clé de quota par personne agrège des utilisateurs différents. L’utiliser comme identité de facturation attribue à une propriété réseau temporaire une responsabilité qu’elle ne porte pas.
La mobilité et les adresses de confidentialité posent le problème inverse. Pour éviter le suivi d’un appareil d’un lien à l’autre et ne pas contourner les mécanismes de confidentialité IPv6, la RFC 9018 interdit de réutiliser un Client Cookie ou un Server Cookie après un changement de l’adresse cliente. Le renouvellement du cookie n’indique donc pas forcément un nouvel utilisateur : il peut être le comportement de confidentialité correct. Sa stabilité n’est pas non plus une identité durable ; elle peut seulement refléter un processus et une connexion restés en place.
BADCOOKIE ne rend pas à lui seul un verdict
Un cookie invalide possède plusieurs explications compatibles avec le protocole. La RFC 7873 cite notamment l’âge de la valeur, un changement d’adresse cliente ou de Client Cookie, une configuration incohérente de l’ensemble anycast et une tentative d’usurpation. Le serveur traite alors la requête comme si le Server Cookie invalide n’était pas présent.
La réponse BADCOOKIE organise la récupération, pas l’attribution d’une faute. Le client reprend avec la nouvelle valeur fournie. Si le serveur renvoie encore BADCOOKIE avec ce cookie frais, l’incohérence des secrets ou des méthodes dans la grappe anycast devient une hypothèse, et la RFC prévoit une reprise sur TCP. Un seul événement ne permet donc pas de distinguer mobilité, expiration, dérive de déploiement et trafic hostile.
L’incident utile conserve l’ordre des faits : ancienne valeur et âge, adresse vue de chaque côté, membre anycast ou domaine de validation, nouvelle valeur, résultat de la reprise, puis éventuel passage à TCP. Une alerte intitulée simplement « cookie invalide = attaque » détruit ce chemin de diagnostic et peut masquer une rotation de secret incomplète.
Les autres contrôles DNS restent nécessaires
Les DNS Cookies ne remplacent pas les règles de rapprochement des réponses. La RFC 5452 impose au résolveur de comparer adresses source et destination, port de destination, identifiant de requête, nom, classe et type avant d’appliquer les règles de confiance DNS. Elle impose aussi des ports source et identifiants de requête imprévisibles. Ces contrôles sont complémentaires : chaque élément augmente le coût d’une réponse forgée sans devenir une identité applicative.
Le support du cookie lui-même reste transactionnel. La RFC 6891 définit l’enregistrement OPT comme un porteur d’informations de contrôle pour une séquence question-réponse. Il ne contient pas de données DNS, ne doit pas être mis en cache ni enregistré dans les fichiers maîtres, et EDNS est négocié saut par saut. Le COOKIE est donc une option de l’échange DNS, pas une fiche d’identité destinée à survivre dans un annuaire utilisateur.
La limite face à l’adversaire est également explicite. Un observateur placé sur le chemin et capable de voir le DNS en clair peut observer un Server Cookie et le réutiliser contre ce client tant qu’il reste valide. Le MAC empêche un attaquant hors chemin, privé du secret serveur, de fabriquer librement une valeur. Il ne chiffre pas le cookie et n’authentifie pas tous les acteurs susceptibles d’émettre depuis le chemin observé.
La bonne étiquette opérationnelle suit donc la proposition du protocole : « Server Cookie valide pour cette adresse source, ce Client Cookie, ce domaine de validation et cette heure ». Si une action exige une identité, le reçu DNS doit être relié à un principal authentifié séparément, avec la preuve de cette liaison. Le cookie renforce l’intégrité de la chronologie transactionnelle ; il ne doit pas devenir subrepticement le registre des personnes.
Sources et références
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance