Sécuriser le DNS : DNSSEC, DNS over HTTPS et DNS over TLS

DNSSEC ajoute des signatures numériques aux enregistrements DNS : un résolveur qui valide peut prouver qu'une réponse vient bien du propriétaire de la zone et n'a pas été modifiée. DNS over TLS (DoT) et DNS over HTTPS (DoH) chiffrent, eux, le trajet entre le poste et son résolveur, pour que personne ne lise ni ne modifie les questions en route. Les deux approches se complètent : DNSSEC protège l'authenticité des données, DoT et DoH la confidentialité du trajet. Ce chapitre explique les deux, leur mise en œuvre sur BIND, pfSense et Windows, et la politique à tenir en entreprise.

Ce que chaque technique protège

DNSSEC : les nouveaux enregistrements

DNSSEC utilise la cryptographie asymétrique : le propriétaire de la zone signe avec sa clé privée, n'importe quel résolveur vérifie avec la clé publique publiée dans la zone (signature numérique).

Les zones utilisent souvent deux rôles de clés : une KSK (Key Signing Key), qui signe seulement les DNSKEY et dont l'empreinte est publiée en DS chez le parent, et une ZSK (Zone Signing Key), qui signe le reste et peut changer souvent sans toucher au parent. Une clé unique qui tient les deux rôles s'appelle une CSK (Combined Signing Key) : c'est le choix par défaut de BIND 9.20.

La chaîne de confiance

Un résolveur ne peut pas faire confiance à une clé publiée dans la zone elle-même : un attaquant capable de falsifier la zone falsifierait aussi la clé. La confiance descend donc de la racine.

1. Le résolveur connaît une seule clé à l'avance : la clé de la racine, son ancre de confiance (trust anchor), livrée avec le logiciel et mise à jour automatiquement (RFC 5011).
2. Avec elle, il vérifie le DNSKEY de la racine, qui signe le DS de .example.
3. Ce DS est l'empreinte de la clé de .example : il vérifie le DNSKEY de .example, qui signe le DS de sorbier.example.
4. Le DS de sorbier.example valide son DNSKEY, qui signe (RRSIG) l'enregistrement A de www.sorbier.example.

Si une seule signature est fausse ou expirée, la validation échoue et le résolveur répond SERVFAIL : il préfère ne rien répondre plutôt qu'une réponse douteuse. Si tout est valide, il positionne le drapeau ad (Authenticated Data) dans sa réponse.

Valider DNSSEC sur tes résolveurs

La validation se fait sur le résolveur, pas sur le poste : les postes font confiance au drapeau ad de leur résolveur. Il faut donc valider partout où tu résous.

Pour tester un résolveur, demande un domaine signé et regarde le drapeau ad :

dig @192.168.10.238 www.afnic.fr A +dnssec
# ;; flags: qr rd ra ad; ...           <- ad : réponse validée
# www.afnic.fr.  ...  IN A      ...
# www.afnic.fr.  ...  IN RRSIG  A 13 3 ...

delv (fourni par bind9-dnsutils) fait la validation lui-même et explique pourquoi elle échoue : delv @192.168.10.238 www.afnic.fr affiche ; fully validated quand tout va bien.

Le test inverse compte autant : le domaine dnssec-failed.org, volontairement mal signé, doit renvoyer SERVFAIL sur un résolveur qui valide. S'il donne une adresse, ton résolveur ne valide pas.

Signer une zone avec BIND 9.20

Depuis BIND 9.16, la signature est automatique avec dnssec-policy : BIND crée les clés, signe la zone, renouvelle les signatures avant leur expiration et gère les changements de clés. Sur ns1, il suffit d'ajouter une ligne à la zone :

zone "sorbier.example" {
    type primary;
    file "/var/lib/bind/db.sorbier.example";
    allow-transfer { key "transfert-sorbier"; };
    dnssec-policy default;
};

La politique default utilise une CSK unique en ECDSA P-256 avec SHA-256 (algorithme 13). En BIND 9.20, une zone soumise à dnssec-policy est signée en ligne (inline signing) : ton fichier de zone reste lisible et modifiable comme avant, BIND en tient une version signée à côté (db.sorbier.example.signed), d'où la nécessité de ranger la zone dans /var/lib/bind/.

sudo named-checkconf
sudo rndc reconfig
sudo rndc dnssec -status sorbier.example     # clés, états, prochaines étapes
dig @127.0.0.1 sorbier.example DNSKEY +multi +norec
dig @127.0.0.1 sorbier.example CDS +short    # l'enregistrement à transmettre au parent

Reste l'étape que BIND ne peut pas faire seul : publier le DS chez le parent, par l'interface du bureau d'enregistrement du domaine. Tant que le DS n'est pas publié, la zone est signée mais pas validable (les résolveurs la traitent comme non signée) : c'est sans danger. L'inverse est dangereux.

DNS over TLS et DNS over HTTPS

Sans chiffrement, toute personne placée sur le trajet (le Wi-Fi d'un hôtel, un fournisseur d'accès) lit la liste des sites que tu consultes, et peut modifier les réponses. DoT et DoH enveloppent les requêtes DNS dans TLS.

Une variante plus récente, DNS over QUIC (DoQ, RFC 9250, UDP 853), suit la même logique.

Le point de vue de l'entreprise : garder la maîtrise du DNS

Pour un particulier sur un Wi-Fi public, DoH est une protection. Pour une entreprise, un navigateur qui envoie ses requêtes en DoH à un résolveur extérieur pose trois problèmes : les noms internes ne se résolvent plus, le filtrage DNS de l'entreprise est contourné, et les journaux DNS (précieux en cas d'incident) ne voient plus rien. La politique de Sorbier :

1. Les postes utilisent le DNS interne, et seulement lui : par DHCP, et par GPO pour les navigateurs. Les modèles d'administration de Chrome et d'Edge ont une stratégie DnsOverHttpsMode, à régler sur off (ou sur un DoH interne). Firefox désactive de lui-même son DoH par défaut si le résolveur du réseau répond « nom inexistant » pour le domaine témoin use-application-dns.net, et se pilote par la stratégie DNSOverHTTPS.
2. Le pare-feu bloque le DNS sortant qui ne vient pas des résolveurs autorisés : UDP et TCP 53, TCP 853. Pour DoH, bloquer le port 443 est impossible ; on bloque les adresses et noms des services DoH publics connus (listes tenues à jour, par exemple avec le paquet pfBlockerNG de pfSense).
3. Le chiffrement se fait vers l'extérieur, sous contrôle : sur pfSense, les cases DNS Query Forwarding et Use SSL/TLS for outgoing DNS Queries to Forwarding Servers chiffrent en DoT les requêtes du pare-feu vers ses redirecteurs. Le fournisseur d'accès ne voit plus les noms demandés, et l'administrateur garde ses journaux.

Côté Windows, Windows 11 sait utiliser DoH pour ses propres requêtes (réglage par carte réseau, ou stratégie Configurer la résolution de noms DNS over HTTPS (DoH) dans Configuration ordinateur > Modèles d'administration > Réseau > Client DNS). Et Microsoft ajoute à Windows Server 2025, avec les mises à jour de 2026, la possibilité pour le serveur DNS de répondre en DoH aux postes (Set-DnsServerEncryptionProtocol) ; le lien entre le serveur et ses redirecteurs reste alors en clair. La fonction a été livrée d'abord en préversion : vérifie son état et ses prérequis (un certificat valide pour le nom du serveur) dans la documentation de Microsoft avant de la déployer.

Filtrer les domaines malveillants

Puisque presque toute connexion commence par une requête DNS, le résolveur est un excellent point de filtrage : refuser de résoudre les domaines d'hameçonnage, de logiciels malveillants ou de serveurs de commande connus coupe une grande partie des attaques avant même la première connexion.

Le filtrage DNS ne remplace ni l'antivirus ni le pare-feu : un programme qui se connecte directement à une adresse IP le contourne. Mais il est simple, peu coûteux, et ses journaux révèlent souvent un poste infecté (un poste qui demande sans arrêt des domaines bloqués). L'analyse de ces journaux dans un SIEM est traitée dans le cours Wazuh.

Exercices

A) ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3310
   ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

B) ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3311
   ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1