Chaque fois qu'une application établit une connexion HTTPS chiffrée ou déclenche un appel API, la pile réseau dépend d'un protocole de conversion conçu en 1987. Le système de noms de domaine (DNS), normalisé par Paul Mockapetris dans la RFC 1035, traduit les noms d'hôtes textuels en coordonnées IPv4 32 bits ou IPv6 128 bits. Afin d'optimiser la rapidité et d'alléger la charge réseau à l'époque d'ARPANET, le DNS fonctionne principalement sur le protocole sans état UDP via le port 53.

Cette conception initiale ne comporte aucun mécanisme cryptographique de validation d'origine. Un adversaire capable d'anticiper ou d'injecter des réponses réseau vers un résolveur récursif peut insérer de fausses correspondances d'adresses dans la mémoire temporaire de ce dernier. Connue sous le nom d'empoisonnement de cache DNS (DNS Cache Poisoning), cette manipulation redirige silencieusement les internautes vers des serveurs malveillants, facilitant le vol d'identifiants et l'interception de communications.

[Poste Client] ─── (1) Requête : bank.example.com ───> [Résolveur Récursif]
                                                             │
                                             (2) Requête externe : bank.example.com
                                                 (TXID : 0x4A2F, Port : 53)
                                                             ▼
                                             [Serveur Faisant Autorité]
                                                             ▲
                                                             │
                                             (3) Flux de paquets falsifiés émis
                                                 (Test massif de TXID : 0x0000 - 0xFFFF)
                                                 (IP Malveillante : 198.51.100.25)
                                                             │
                                             [Attaquant Réseau / Nœud MitM]

Fonctionnement et limites de l'empoisonnement de cache classique

Dans une résolution récursive courante, le poste client interroge son résolveur local (fourni par le FAI ou la passerelle d'entreprise). Si l'enregistrement n'est pas présent en cache, le résolveur parcourt la hiérarchie : les serveurs racines (.), les serveurs de domaines de premier niveau (.com), puis les serveurs faisant autorité pour la zone cible (example.com).

Pour associer un paquet UDP entrant à une requête en attente, la RFC 1035 alloue un identifiant de transaction de 16 bits (TXID) dans l'en-tête DNS. À la réception d'une réponse sur le port UDP 53, le résolveur vérifie quatre paramètres :

  1. Adresse IP source : Doit correspondre à l'adresse du serveur faisant autorité.
  2. Port UDP de destination : Doit être identique au port local d'émission (historiquement le port statique 53).
  3. Section Question : Doit reprendre exactement le nom de domaine et le type d'enregistrement (A, AAAA, MX).
  4. Identifiant TXID : Doit coïncider avec l'entier pseudo-aléatoire généré par le résolveur.

Un champ de 16 bits offre exactement 65 536 combinaisons possibles ($2^{16}$). Avant 2008, l'attaque consistait à émettre une requête pour bank.example.com, puis à saturer le résolveur de paquets UDP falsifiés prétendant émaner du serveur faisant autorité en faisant défiler les TXID.

Cette méthode se heurtait toutefois à la durée de vie du cache (TTL, Time-to-Live). Si la véritable réponse faisant autorité parvenait au résolveur avant la réponse frauduleuse, la donnée légitime restait mémorisée pendant toute la période TTL (fréquemment 86 400 secondes, soit 24 heures). L'attaquant devait attendre une journée complète pour disposer d'une nouvelle tentative.

La découverte de Dan Kaminsky : sous-domaines aléatoires et injection NS

En juillet 2008, le chercheur Dan Kaminsky a révélé une faille structurelle permettant de s'affranchir totalement de la contrainte du TTL. Au lieu de cibler directement le nom principal, l'attaquant émet en continu des requêtes portant sur des sous-domaines inexistants générés aléatoirement :

  • x01a9.bank.example.com
  • m47k2.bank.example.com
  • z99p8.bank.example.com

Puisque ces préfixes ne figurent jamais dans le cache, le résolveur émet systématiquement une requête externe vers le serveur faisant autorité. L'attaquant injecte simultanément des réponses UDP forgées pour chaque sous-domaine spécifique. Il insère dans la réponse forgée des enregistrements stratégiques au sein des sections d'autorité (Authority) et additionnelle (Additional) :

;; QUESTION SECTION:
x01a9.bank.example.com.    IN    A

;; ANSWER SECTION:
x01a9.bank.example.com.    IN    A    198.51.100.99

;; AUTHORITY SECTION:
bank.example.com.          IN    NS   ns.attacker-domain.org.

;; ADDITIONAL SECTION:
ns.attacker-domain.org.    IN    A    198.51.100.66

En vertu des règles de traitement des délégations (Bailiwick Rules), une réponse émanant d'une zone est habilitée à redéfinir les serveurs de noms responsables de cette même zone. Si un seul des paquets falsifiés correspond au TXID de 16 bits avant la réponse authentique, le résolveur mémorise le faux sous-domaine et remplace les serveurs faisant autorité de bank.example.com par ns.attacker-domain.org.

À partir de cet instant, l'ensemble des résolutions du domaine principal et de tous ses sous-domaines bascule sous le contrôle de l'attaquant. Sur des liaisons haut débit contemporaines, la compromission ne prend que quelques secondes.

Calcul d'entropie et aléation des ports sources (RFC 5452)

La vulnérabilité Kaminsky s'expliquait par une entropie de validation trop restreinte. Un espace de recherche de 16 bits ($N = 65 536$) cède aisément face à l'attaque des anniversaires (Birthday Attack) combinée à un débit élevé de paquets UDP.

Pour répondre à ce risque, l'IETF a ratifié la RFC 5452 (« Measures for Making DNS More Resilient against Forged Answers »). Cette norme rend obligatoire l'aléation des ports sources (Source Port Randomization, SPR). Le résolveur ne lie plus ses requêtes sortantes au port statique 53, mais choisit un port UDP éphémère de manière aléatoire parmi un ensemble d'environ 50 000 ports disponibles (plages 1024 à 65535 ou 49152 à 65535).

Paramètre de sécurité RFC 1035 Standard (avant 2008) Aléation des ports RFC 5452 Validation cryptographique DNSSEC
Entropie TXID 16 bits ($2^{16} = 65 536$) 16 bits ($2^{16} = 65 536$) 16 bits ($2^{16} = 65 536$)
Entropie des ports 0 bit (Port 53 fixe) ~15,6 bits (~50 000 ports) ~15,6 bits (~50 000 ports)
Espace de recherche global 65 536 combinaisons $pprox 3,27 imes 10^9$ combinaisons $pprox 3,27 imes 10^9$ combinaisons
Paquets pour 50 % de succès ~300 paquets ~2 000 000 paquets Rejet immédiat faute de signature privée
Type de protection Purement statistique Purement statistique Cryptographie asymétrique (RSA/ECDSA)

En combinant le TXID de 16 bits à un port source aléatoire de 15 à 16 bits, l'attaquant est contraint de deviner deux variables indépendantes en même temps :

$$ ext{Combinaisons totales} = 2^{16} imes pprox 50 000 pprox 3 276 800 000$$

La transmission de plus de 3,2 milliards de paquets sature l'infrastructure de l'attaquant et alerte les dispositifs de détection d'anomalies bien avant d'obtenir un résultat concluant.

Garantie structurelle : La chaîne de confiance DNSSEC

Bien que l'aléation des ports selon la RFC 5452 complique l'attaque, elle demeure une barrière probabiliste. Les passerelles de translation d'adresses (NAT), les pare-feu d'inspection et les boîtiers CGNAT des opérateurs réduisent souvent les ports sortants à un groupe restreint et déterministe, affaiblissant l'entropie théorique.

La protection architecturale pérenne réside dans les extensions de sécurité du DNS (DNSSEC), codifiées dans les RFC 4033, 4034 et 4035. DNSSEC adjoint la cryptographie sur clés publiques à la structure arborescente du DNS :

[Zone Racine / Root (.)]
  └─ Clé KSK signe ZSK ──> signe l'enregistrement DS pour .com
                                 │
                                 ▼
[Zone de Premier Niveau .com]
  └─ Clé KSK signe ZSK ──> signe l'enregistrement DS pour example.com
                                 │
                                 ▼
[Zone Faisant Autorité example.com]
  └─ Clé KSK signe ZSK ──> signe RRSIG pour bank.example.com
  1. RRSIG (Resource Record Signature) : Signature numérique associée à chaque ensemble d'enregistrements, générée via des algorithmes RSA ou ECDSA.
  2. DNSKEY : Clé publique permettant de contrôler la signature RRSIG.
  3. DS (Delegation Signer) : Condensat SHA-256 de la clé KSK de la zone enfant, consigné dans la zone parente pour former une chaîne de certification ininterrompue reliée à l'Ancre de Confiance Racine (Root Trust Anchor).

Dès lors qu'un résolveur validant examine la réponse, il vérifie la conformité de la signature. Même si un assaillant réussissait à deviner le TXID et le port UDP, la charge frauduleuse est rejetée en l'absence de signature RRSIG valide.

Vulnérabilités locales et protection par tunnel de Couche 3

Sur un réseau Wi-Fi public ou un réseau d'entreprise partagé, un acteur malveillant situé sur le même sous-réseau n'a pas besoin de calculer des probabilités :

  • Écoute passive : Les requêtes DNS transitant en clair, une capture réseau locale révèle instantanément le TXID et le port d'émission réels.
  • Course aux paquets : Grâce à sa proximité physique avec la cible, l'attaquant diffuse une fausse réponse qui parvient au poste client quelques millisecondes avant la réponse du serveur distant.
[Applications sur l'Équipement]
            │ (Liaison interne locale : 127.0.0.1)
            ▼
[Interface Réseau Virtuelle : wg0 / tun0]
   Chiffrement ChaCha20-Poly1305 (Couche Réseau 3)
            │
            ▼
[Liaison Physique Wi-Fi / Câble Ethernet]
   Seules des données WireGuard / RiceGuard chiffrées sont transmises
   L'attaquant local ne voit aucun nom d'hôte, aucun TXID, aucun port UDP 53
            │
            ▼
[Résolveur Récursif Sécurisé VPNRice]
   Application de la RFC 5452 et validation DNSSEC intégrale
   Aucun enregistrement d'historique de requêtes, résolution directe Anycast

Afin d'endiguer les interceptions sur le segment local, VPNRice encapsule la totalité des requêtes DNS dans un tunnel chiffré de Couche 3. Avec le protocole RiceGuard :

  • Les résolutions de noms sont scellées dans des paquets authentifiés ChaCha20-Poly1305 avec un tag d'intégrité de 128 bits avant d'atteindre la carte réseau physique.
  • L'environnement local ne perçoit que des flux chiffrés à haute entropie, rendant la lecture du TXID ou des noms de domaine techniquement irréalisable.
  • Le traitement s'effectue sur des résolveurs durcis appliquant la répartition aléatoire des ports selon la RFC 5452 et le contrôle strict des signatures DNSSEC.

Vérification technique de la configuration du résolveur

Les administrateurs et spécialistes de la sécurité peuvent auditer le comportement de leur résolveur à l'aide des outils en ligne de commande usuels :

# 1. Interroger un domaine en exigeant la validation des signatures DNSSEC
dig +dnssec bank.example.com @127.0.0.1

# 2. Vérifier la présence du drapeau ad (Authenticated Data) dans l'en-tête
# Observez : flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

# 3. Tester une zone délibérément corrompue (doit retourner le statut SERVFAIL)
dig sigfail.verteiltesysteme.net @127.0.0.1

# 4. Examiner la traçabilité complète de la chaîne via l'outil delv
delv @127.0.0.1 bank.example.com
  • Activer la validation DNSSEC : Vérifiez que le gestionnaire DNS de votre poste (comme systemd-resolved ou Unbound) dispose de l'option DNSSEC=yes.
  • Acheminer les requêtes dans un tunnel VPN : Isolez vos demandes de résolution des écoutes locales en empruntant un tunnel WireGuard ou RiceGuard.
  • Maintenir le rejet des signatures défaillantes : Configurez les services pour traiter les réponses SERVFAIL comme des blocages légitimes plutôt que de revenir à une résolution standard non vérifiée.