Le système de noms de domaine (DNS) constitue la structure d'adressage essentielle d'Internet, convertissant les noms d'hôtes en adresses IP de destination. Depuis plusieurs décennies, le protocole de transport privilégié pour les requêtes DNS est l'UDP sur le port 53. Si l'UDP réduit la latence des transactions en évitant la poignée de main en trois étapes, son fonctionnement sans connexion induit une faille architecturale majeure : l'usurpation d'adresse IP source (IP spoofing). Les acteurs malveillants exploitent fréquemment les résolveurs récursifs et les serveurs autoritaires pour déclencher des attaques par déni de service distribué (DDoS) par amplification et réflexion, ainsi que des empoisonnements de cache hors chemin. La RFC 7873 (« Domain Name System (DNS) Cookies ») et sa mise à jour de standardisation RFC 9018 (« Interoperable Domain Name System (DNS) Server Cookies ») introduisent un mécanisme cryptographique sans état au sein de l'extension EDNS(0) pour attester la légitimité réciproque des échanges entre clients et serveurs DNS.

Requête UDP classique sans authentification (vulnérable à l'usurpation) :
Attaquant (usurpe l'IP cible) ──── Requête ────> Résolveur DNS
Cible victime <────── Réponse amplifiée ─────── Résolveur DNS

Transaction protégée par DNS Cookie (RFC 7873 / RFC 9018) :
Client ──────── Requête + Client Cookie (8 octets) ─────> Serveur DNS
Client <── Réponse + Client Cookie + Server Cookie ───── Serveur DNS
(Identité validée dans les deux sens ; paquets falsifiés rejetés)

La crise de l'amplification UDP : la vulnérabilité du DNS classique

Les requêtes DNS standards transmises sur UDP ne possèdent aucun moyen intrinsèque de prouver l'identité de l'émetteur. Lorsqu'un serveur de noms reçoit une requête, il se contente d'examiner le champ d'adresse source de l'en-tête IP. Puisque l'UDP ne valide pas l'accessibilité bidirectionnelle avant d'expédier les données, un attaquant distant peut injecter des requêtes UDP contenant l'adresse IP falsifiée d'une victime désignée.

Transport sans état et usurpation d'adresses IP sources

La disproportion entre une requête DNS compacte et une réponse cryptographique volumineuse engendre des facteurs d'amplification considérables. Une requête de 64 octets demandant des enregistrements ANY, des jeux de clés et de signatures DNSSEC (RRSIG et DNSKEY) ou d'imposants enregistrements TXT renvoie couramment des paquets dépassant 3 000 octets. Lorsque les réseaux intermédiaires n'appliquent pas la validation de l'adresse source (BCP 38 / RFC 2827), les attaquants saturent la bande passante descendante de la cible en canalisant des flux réfléchis par des milliers de résolveurs ouverts.

L'absence d'authentification facilite également les attaques d'empoisonnement de cache (cache poisoning). En anticipant les identifiants de transaction (Transaction ID) et les ports sources UDP, l'attaquant injecte des enregistrements forgés dans la mémoire du résolveur avant l'arrivée de la réponse du serveur autoritaire légitime. Si DNSSEC garantit l'intégrité du contenu des enregistrements, il ne vérifie pas l'émetteur de la requête et n'empêche pas l'infrastructure d'être utilisée pour des attaques par amplification.

Les limites et la fragilité du Response Rate Limiting (RRL)

Pour freiner les vagues d'attaques par réflexion, les administrateurs ont mis en œuvre le mécanisme de limitation de débit des réponses (Response Rate Limiting ou RRL). Le RRL comptabilise les flux par préfixe IP (/24 en IPv4 ou /56 en IPv6) et rejette ou tronque (en activant le drapeau TC=1) les réponses dépassant un seuil défini.

Bien que le RRL modère le volume global des attaques, il engendre des contraintes techniques notables :

  • Les postes situés derrière des passerelles de traduction d'adresses d'opérateurs (CGNAT) partagent un même préfixe public avec des terminaux infectés et subissent des pertes de requêtes légitimes.
  • La troncature force les résolveurs à basculer vers TCP, imposant le délai d'une négociation en trois étapes et une allocation accrue de descripteurs de sockets noyau.
  • Les résolveurs récursifs à fort volume rencontrent des déclenchements intempestifs lors de pointes normales d'activité, dégradant la réactivité perçue par les applications.

Les DNS Cookies éliminent ces approximations en établissant une preuve d'accessibilité mutuelle sans exiger de stockage d'état de session sur le serveur.

Architecture RFC 7873 : double négociation de cookies via EDNS(0)

La RFC 7873 normalise l'insertion de jetons cryptographiques dans les mécanismes d'extension pour DNS (EDNS(0), RFC 6891) sous le code d'option Option Code 10.

+-------------------------------+-------------------------------+
|       OPTION-CODE (10)        |     OPTION-LENGTH (16-40)     |
+-------------------------------+-------------------------------+
|                    Client Cookie (8 octets)                   |
+---------------------------------------------------------------+
|                    Server Cookie (8-32 octets)                |
+---------------------------------------------------------------+

Le protocole repose sur une négociation en deux phases entre un client DNS (résolveur stub ou résolveur récursif) et un serveur DNS (serveur récursif ou autoritaire).

Le Client Cookie est un jeton de 8 octets généré par le client émetteur. Il doit s'avérer imprévisible pour un tiers distant, tout en restant recalculable par le client pour une destination serveur donnée sur une fenêtre temporelle précise :

$$\text{Client Cookie} = \text{PRF-64}(\text{Client IP}, \text{Server IP}, \text{Client Secret})$$

Le secret du client se compose de 128 bits d'entropie cryptographique conservés en mémoire vive. Une rotation périodique de cette clé (généralement toutes les 24 heures) invalide les anciens jetons sans solliciter le stockage sur disque. Le fait d'associer conjointement l'IP du client et l'IP du serveur interdit le rejeu d'un cookie intercepté vers un autre serveur.

Lorsqu'un serveur de noms intercepte une requête comportant un Client Cookie, la logique d'authentification s'articule ainsi :

  1. Requête initiale : Le client transmet uniquement son Client Cookie de 8 octets. La longueur de l'option vaut 8.
  2. Calcul côté serveur : Constatant une initialisation, le serveur calcule son propre Server Cookie dérivé du Client Cookie, de l'IP du client et de son secret interne.
  3. Réponse à double jeton : Le serveur encapsule le Client Cookie initial et le Server Cookie nouvellement généré dans l'enregistrement EDNS(0) OPT renvoyé au client.
  4. Mise en cache locale : Le client vérifie la conformité du Client Cookie reçu, puis enregistre le Server Cookie dans sa table de correspondance indexée par l'IP du serveur.
  5. Requêtes ultérieures : Les messages suivants transmettent systématiquement les deux jetons (taille comprise entre 16 et 40 octets). Le serveur authentifie immédiatement le client en recalculant le condensat cryptographique.

L'attaquant ayant usurpé une adresse IP étant incapable d'intercepter la réponse du serveur, il ne peut prendre connaissance du Server Cookie, ce qui neutralise le potentiel d'amplification.

Bien que la RFC 7873 ait fixé le protocole fonctionnel, elle laissait la structure binaire interne du Server Cookie à la discrétion de chaque éditeur. Au sein des architectures Anycast exploitant conjointement plusieurs moteurs DNS (comme BIND, NSD, Knot DNS et PowerDNS), les nœuds étaient incapables de vérifier les jetons créés par les autres logiciels.

La RFC 9018 a comblé ce manque en instaurant un format binaire standardisé de 16 octets pour le Server Cookie.

+---------------+---------------+-------------------------------+
| Version (0x01)|       Reserved (0x000000)                     |
+---------------+---------------+-------------------------------+
|                      Timestamp (4 octets)                     |
+---------------------------------------------------------------+
|                      Hash (8 octets)                          |
+---------------------------------------------------------------+

La structure comprend les champs suivants :

  • Version (1 octet) : Indicateur de version de calcul, fixé à la valeur 0x01.
  • Reserved (3 octets) : Champ réservé, transmis à 0x000000 et ignoré à la réception.
  • Timestamp (4 octets) : Entier non signé de 32 bits consignant l'horodatage UNIX en secondes.
  • Hash (8 octets) : Code d'authentification cryptographique tronqué sur 64 bits.

Construction SipHash-2-4 et hachage tronqué sur 64 bits

La RFC 9018 impose la fonction pseudo-aléatoire SipHash-2-4 pour générer le champ Hash de 8 octets. Cet algorithme offre une exécution véloce et efficace sur des entrées courtes, une résistance éprouvée aux collisions et une grande efficacité sur les processeurs 64 bits.

Le condensat est produit selon la formule :

$$\text{Hash} = \text{SipHash-2-4}(\text{Server Secret}, \text{Client Cookie} ,|, \text{Version} ,|, \text{Reserved} ,|, \text{Timestamp} ,|, \text{Client IP})$$

Le serveur vérifie deux critères successifs :

  1. Validité de l'horodatage : Vérification de $|T_{\text{actuel}} - T_{\text{cookie}}| \le 3600 \text{ secondes}$. Cet écart admissible d'une heure tolère les variations de transit et les dérives d'horloge tout en restreignant les attaques par rejeu.
  2. Conformité cryptographique : Recalcul de la fonction SipHash-2-4 avec la clé secrète active et comparaison sur 64 bits en temps constant afin d'écarter toute attaque temporelle.

Une fois validée, la requête est formellement authentifiée : le serveur de noms lève les restrictions de débit RRL et dessert les réponses jusqu'à la limite du tampon EDNS négocié.

Topologies de résolveurs Anycast et rotation planifiée des clés

Les infrastructures DNS d'envergure reposent sur BGP Anycast pour diffuser des adresses IP identiques depuis de multiples points de présence (PoP). Au gré des modifications d'acheminement réseau ou d'équilibrage ECMP, des paquets consécutifs émis par un même client peuvent atteindre des nœuds physiques distincts.

Afin de préserver la validité de la vérification, tous les nœuds de la grappe Anycast doivent obligatoirement partager les mêmes clés secrètes. L'exploitation préconise une gestion à deux clés symétriques :

  • Clé active ($K_{\text{active}}$) : Utilisée pour forger les nouveaux Server Cookies sortants et contrôler les jetons entrants.
  • Clé précédente ($K_{\text{previous}}$) : Maintenue active pendant la période de transition (2 à 24 heures) pour valider les jetons issus de la génération précédente.

Lors du renouvellement, la nouvelle clé est introduite comme future, puis promue au rang d'active tandis que l'ancienne bascule au statut de précédente, avant d'être retirée une fois le cache des clients renouvelé. Ce cycle écarte toute perte de requête lors de migrations d'itinéraires Anycast.

Gestion des erreurs BADCOOKIE et boucle de repli des boîtiers intermédiaires

Lorsqu'un serveur intercepte une requête comportant un Server Cookie périmé, tronqué ou incorrect, la procédure de récupération de la RFC 7873 s'exécute automatiquement :

  1. Blocage de l'amplification : Le serveur refuse de restituer le bloc complet des enregistrements sollicités.
  2. Notification d'erreur : Émission d'une réponse vide affichant le code d'erreur RCODE=9 (BADCOOKIE) en conservant l'identifiant de transaction d'origine.
  3. Fourniture d'un nouveau jeton : Inclusion dans l'enregistrement EDNS(0) OPT du Client Cookie d'origine et d'un Server Cookie fraîchement calculé.
  4. Nouvelle tentative du client : Le client interprète le code BADCOOKIE, enregistre le nouveau jeton dans sa table et renvoie immédiatement sa requête.

Si un pare-feu intermédiaire corrompu supprime purement et simplement les en-têtes EDNS(0), le client constate l'absence de cookies en retour et bascule sur des requêtes DNS traditionnelles, garantissant la continuité du service.

Intégration avec RiceGuard : DNS Zero-Trust et protection du trafic sortant

Le moteur réseau RiceGuard intégré à l'application VPNRice incorpore la technologie des DNS Cookies au niveau des liaisons clients comme des passerelles récursives, structurant un environnement DNS Zero-Trust étanche.

Architecture DNS Zero-Trust de RiceGuard :
Appareil client (Application VPNRice)
  │
  ├── Tunnel chiffré WireGuard / IPsec (ChaCha20-Poly1305 / AES-256-GCM)
  ▼
Nœud d'entrée Anycast RiceGuard
  │  - Contrôle strict des Server Cookies RFC 9018 sur tout trafic UDP
  │  - Rejet des sondes d'amplification frauduleuses dès le périmètre
  │  - Synchronisation globale des clés de chiffrement SipHash-2-4
  ▼
Moteur récursif sécurisé
  │  - Émission de Client Cookies EDNS(0) vers les serveurs racine et TLD
  │  - Contrôle systématique des Server Cookies dans les réponses externes
  │  - Validation cryptographique stricte de la chaîne DNSSEC
  ▼
Infrastructure DNS autoritaire globale
  1. Isolation cryptographique en tunnel : L'ensemble des résolutions de noms transite dans les tunnels WireGuard ou IPsec jusqu'aux résolveurs Anycast dédiés de RiceGuard, prévenant toute surveillance sur les réseaux Wi-Fi et les fournisseurs d'accès.
  2. Défense de bordure Anycast : Les interfaces publiques vérifient les Server Cookies RFC 9018 sur chaque flux UDP. Les paquets contrefaits sont limités ou rejetés par le mécanisme BADCOOKIE, empêchant les nœuds d'être instrumentalisés pour des attaques par réflexion.
  3. Sécurisation des requêtes itératives : Lors de l'interrogation des zones racines et des domaines de premier niveau, les résolveurs RiceGuard adjoignent des Client Cookies et contrôlent les réponses, préservant le cache contre les attaques par injection même sur les zones dépourvues de DNSSEC.

L'association du chiffrement par tunnel et de la vérification de transport par DNS Cookies garantit des transactions fiables et sécurisées sur l'ensemble des parcours réseau.

Vérification opérationnelle : tester les DNS Cookies avec Dig

Les administrateurs d'infrastructure peuvent inspecter le bon fonctionnement des DNS Cookies sur leurs serveurs à l'aide de la commande dig.

Émission d'une requête avec négociation de cookies

Les versions récentes de l'outil dig intègrent nativement la négociation de cookies :

# Interrogation d'un résolveur Anycast avec négociation de cookies
dig @1.1.1.1 vpnrice.com +cookie

La section OPT PSEUDOSECTION met en évidence la présence du bloc COOKIE :

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 5a8e2b109c3d4f8a 01000000672c8410d9f82e14a7c3b901 (good)
;; QUESTION SECTION:
;vpnrice.com.			IN	A

;; ANSWER SECTION:
vpnrice.com.		300	IN	A	104.21.48.12

Détail des informations :

  • 5a8e2b109c3d4f8a : Client Cookie de 8 octets généré par dig.
  • 01000000672c8410d9f82e14a7c3b901 : Server Cookie de 16 octets au format RFC 9018 :
    • Version : 01
    • Réservé : 000000
    • Horodatage : 672c8410 (valeur hexadécimale de l'époque UNIX)
    • Hachage : d9f82e14a7c3b901 (condensat SipHash-2-4)
  • La mention (good) confirme que la vérification cryptographique a réussi.

Simulation d'une anomalie et renouvellement de session

Pour analyser le comportement face à un jeton erroné, on peut transmettre une valeur corrompue :

# Transmission d'un Server Cookie falsifié de 16 octets
dig @1.1.1.1 vpnrice.com +cookie=5a8e2b109c3d4f8a0100000000000000ffffffffffffffff

Le serveur conforme renvoie l'état status: BADCOOKIE, ne délivre aucun enregistrement de réponse et fournit un Server Cookie actualisé dans l'option OPT pour réinitialiser la communication.

Les DNS Cookies réconcilient avec brio la rapidité de transport de l'UDP et les exigences d'une authentification rigoureuse des échanges. La généralisation des RFC 7873 et RFC 9018 au sein des architectures récursives et autoritaires élimine les risques d'amplification par réflexion tout en maintenant des temps de réponse inférieurs à la milliseconde.

Pour sécuriser vos connexions et router vos requêtes DNS à travers des résolveurs Anycast hautement protégés, vous pouvez Télécharger VPNRice.