DNS sécurisé : DNSSEC et DNS sur HTTPS (DoH)

Le système de noms de domaine (DNS) traduit les noms de domaine lisibles par l'être humain en adresses IP. Conçu dans les années 1980, le DNS a été créé sans mécanismes de sécurité : les requêtes et les réponses circulent en clair sur les ports UDP/TCP 53, sans authentification. Cela crée deux vulnérabilités majeures : l'empoisonnement du cache DNS (injection de réponses DNS falsifiées pour rediriger les utilisateurs vers des serveurs malveillants) et l'écoute du DNS (observer les domaines qu'un utilisateur interroge révèle son activité de navigation). Deux normes répondent à ces problèmes : DNSSEC empêche la falsification et le DNS sur HTTPS (DoH) empêche l'écoute.

L'empoisonnement du cache DNS (attaque de Kaminsky) exploite l'absence d'authentification du protocole DNS. Un résolveur envoie une requête à un serveur DNS faisant autorité et met la réponse en cache pendant la durée du TTL. Un attaquant capable de deviner l'identifiant de transaction (16 bits, prévisible) et le port source (utilisé comme entropie supplémentaire depuis la RFC 5452) peut envoyer des réponses falsifiées que le résolveur met en cache, redirigeant ainsi vers le serveur de l'attaquant tous les utilisateurs qui interrogent ce résolveur. Une fois le cache empoisonné, les utilisateurs sont dirigés vers de faux serveurs même s'ils ont saisi le domaine correct. DNSSEC empêche cela en signant numériquement les réponses DNS.

DNSSEC ajoute des signatures cryptographiques aux enregistrements DNS, ce qui permet aux résolveurs de vérifier que les réponses proviennent bien de l'autorité légitime de la zone et qu'elles n'ont pas été altérées. DNSSEC introduit de nouveaux types d'enregistrements : RRSIG (signature d'enregistrement de ressource, c'est-à-dire la signature réelle d'un ensemble d'enregistrements), DNSKEY (clé publique utilisée pour vérifier les signatures), DS (signataire de délégation, qui relie les clés des zones parente et enfant) et NSEC/NSEC3 (déni authentifié d'existence : prouve qu'un nom n'existe pas). DNSSEC crée une chaîne de confiance depuis la zone racine (signée par ICANN) jusqu'aux zones de TLD et aux zones faisant autorité.

DNSSEC utilise deux types de clés de signature. La clé de signature de zone (ZSK) signe les ensembles d'enregistrements DNS individuels (RRSIG) et est renouvelée fréquemment (chaque mois ou chaque trimestre) pour faciliter l'exploitation. La clé de signature de clé (KSK) signe l'ensemble d'enregistrements DNSKEY et fournit l'ancre de confiance de la zone. La KSK est renouvelée moins fréquemment (une fois par an), car la zone parente doit être mise à jour avec le nouvel enregistrement DS chaque fois que la KSK change, ce qui nécessite une coordination. La KSK vérifie la ZSK ; la ZSK signe les données. Cette structure à deux niveaux équilibre la sécurité (renouvellement fréquent de la ZSK) et la charge opérationnelle (renouvellement peu fréquent de la KSK).

DNSSEC présente des limites importantes. Il ne chiffre pas les requêtes DNS : il signe uniquement les réponses pour en garantir l'intégrité. Un espion peut toujours voir toutes les requêtes DNS, mais ne peut pas falsifier les réponses. Énumération de zone : les enregistrements NSEC (qui prouvent la non-existence) permettent aux attaquants de parcourir la zone et d'énumérer tous les noms de domaine qu'elle contient ; NSEC3 atténue ce problème grâce aux noms hachés, mais n'est pas parfait. Complexité opérationnelle : la gestion des clés, l'expiration des signatures et la coordination avec la zone parente créent une charge opérationnelle importante. L'adoption de DNSSEC reste incomplète : de nombreux TLD et bureaux d'enregistrement la prennent en charge, mais beaucoup d'organisations ne l'ont pas déployée.

DNS sur HTTPS (DoH) chiffre les requêtes DNS à l’intérieur de HTTPS (RFC 8484), masquant leur contenu aux observateurs du réseau. Les requêtes sont envoyées à un résolveur compatible avec DoH via une URL HTTPS standard, ce qui rend le trafic DNS indiscernable des autres trafics HTTPS. Cela empêche les fournisseurs d’accès à Internet, les employeurs et les attaquants capables d’intercepter le trafic de voir quels domaines un utilisateur interroge — comblant ainsi la faille de confidentialité laissée par DNSSEC. Toutefois, DoH transfère la relation de confiance du résolveur DNS du réseau vers le fournisseur DoH (généralement Google 8.8.8.8, Cloudflare 1.1.1.1 ou le propre résolveur DoH de l’organisation). DoH est désormais pris en charge nativement par la plupart des navigateurs majeurs.

DNS sur TLS (DoT) (RFC 7858) chiffre les requêtes DNS à l’aide de TLS sur un port TCP dédié, le 853, plutôt que de les faire transiter par HTTPS. DoT offre les mêmes avantages en matière de confidentialité que DoH — il masque le contenu des requêtes aux personnes qui les espionnent — mais il est plus facile à identifier et à filtrer pour les administrateurs réseau (port 853 contre port 443). C’est une arme à double tranchant : DoT est visible et peut être bloqué par les pare-feu d’entreprise, tandis que DoH est plus difficile à bloquer sans affecter le trafic HTTPS général. Les résolveurs Stub (au niveau de l’OS) utilisent plus souvent DoT ; les navigateurs utilisent plus souvent DoH.

Le DNS chiffré pose un problème aux environnements d’entreprise qui dépendent du filtrage fondé sur le DNS et des sinkholes. Lorsque les navigateurs utilisent des résolveurs DoH externes, les contrôles DNS internes sont contournés. Contremesures pour l’entreprise : déployer un résolveur DoH/DoT interne (Cisco Umbrella, Pi-hole avec DoH) et configurer tous les appareils pour l’utiliser ; bloquer les adresses IP des résolveurs DoH externes au niveau du pare-feu (Google 8.8.8.8, Cloudflare 1.1.1.1) sur le port 443 ; utiliser la Group Policy pour désactiver DoH au niveau du navigateur sur les points de terminaison gérés ; et appliquer des règles de proxy transparent qui interceptent le DNS sur TLS sur le port 853. L’objectif est d’acheminer tout le DNS via le résolveur contrôlé sans bloquer entièrement le DNS chiffré.

Une stratégie complète de sécurité DNS combine plusieurs contrôles. DNSSEC protège vos zones faisant autorité contre l’empoisonnement du cache de votre domaine. Le filtrage fondé sur le DNS (Cisco Umbrella, Cloudflare Gateway) bloque les domaines malveillants au niveau du résolveur. DoH/DoT vers un résolveur contrôlé garantit la confidentialité des requêtes sans perdre la visibilité nécessaire au filtrage. La journalisation DNS vers le SIEM capture toutes les requêtes à des fins de recherche de menaces — les journaux DNS révèlent le trafic C2, l’exfiltration de données par tunneling DNS et l’activité liée aux algorithmes de génération de domaines (DGA) des logiciels malveillants. La télémétrie DNS est l’une des sources de données de Security les plus précieuses disponibles.

Le tunneling DNS encode des données dans les requêtes et les réponses DNS afin d’exfiltrer des données ou d’établir des canaux C2 à travers des réseaux où les autres trafics sortants sont bloqués. Des outils comme iodine, DNScat et dnscat2 encodent les charges utiles dans les labels de sous-domaines (requête pour EXFILTRATEDDATA.evil.com) ou dans des enregistrements TXT. Détection : noms de requête DNS anormalement longs (>100 caractères), volume élevé de requêtes provenant d’un même hôte, requêtes portant sur des domaines parents inexistants, types d’enregistrements inhabituels (TXT, NULL) et analyse de l’entropie des labels de domaine (les données encodées présentent une entropie de Shannon élevée). Les plateformes d’analyse de Security DNS signalent automatiquement les schémas de tunneling.

Les zones de stratégie de réponse DNS (RPZ) permettent aux résolveurs DNS d’appliquer des stratégies locales de substitution aux réponses DNS — ce qui revient à créer un sinkhole local au niveau du résolveur sans modifier l’infrastructure DNS globale. Lorsqu’un client interroge un domaine connu pour être malveillant, la stratégie RPZ renvoie NXDOMAIN, redirige vers une adresse IP de sinkhole ou laisse passer la réponse. Des flux RPZ sont disponibles auprès de fournisseurs de Threat Intelligence (Spamhaus, SURBL) et peuvent être importés directement dans les résolveurs BIND ou Unbound. RPZ est un outil défensif puissant, car il applique le filtrage au niveau DNS à tous les appareils du réseau, sans configuration côté client.

Test de votre compréhension des concepts de CompTIA Security+ (SY0-701) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : DNSSEC ajoute des signatures cryptographiques aux enregistrements DNS à l’aide de paires de clés KSK/ZSK pour empêcher l’empoisonnement du cache, mais ne chiffre pas les requêtes ; DNS sur HTTPS (DoH) chiffre les requêtes DNS à l’intérieur de HTTPS pour empêcher leur interception, mais crée des risques de contournement du filtrage d’entreprise ; et le tunneling DNS encode des données dans les requêtes DNS et peut être détecté grâce à l’analyse de la longueur, du volume et de l’entropie des requêtes. Nous allons ensuite étudier IPsec, les protocoles VPN et la Security des accès à distance.