DNS sécurisé : DNSSEC, DoT, DoH, filtrage et bonnes pratiques

Le DNS a été conçu à une époque où la confiance entre les acteurs d'Internet était présumée. Les requêtes et réponses circulent en clair, sans garantie d'authenticité. Or presque toute communication commence par une résolution DNS : la détourner, c'est rediriger l'utilisateur ; l'observer, c'est connaître son activité ; l'abuser, c'est exfiltrer des données.

Objectif : comprendre les menaces visant le DNS et savoir combiner les mécanismes de protection : DNSSEC, DoT, DoH, résolveurs maîtrisés, filtrage et journalisation. Les bases du protocole sont rappelées dans DNS : résolution de noms et dépannage.

Les menaces

Menace	Description	Protection principale
Empoisonnement de cache	Injection de fausses réponses dans un résolveur	DNSSEC, ports source aléatoires, résolveurs à jour
Usurpation sur le chemin	Réponses falsifiées entre client et résolveur	DoT/DoH, DNSSEC validé jusqu'au client
Écoute	Observation des noms consultés	DoT/DoH
Détournement de domaine	Modification des enregistrements chez le bureau d'enregistrement ou l'hébergeur DNS	MFA sur les comptes, verrouillage de registre, DNSSEC, supervision
Résolveur ouvert	Résolveur répondant à tout Internet, utilisé pour l'amplification	Restreindre la récursivité aux clients internes
Tunnel DNS et exfiltration	Données encodées dans des requêtes DNS	Résolveurs imposés, journalisation, détection d'anomalies
Domaines malveillants	Hameçonnage, serveurs de commande	Filtrage DNS (RPZ, renseignement sur les menaces)

DNSSEC : l'authenticité des réponses

DNSSEC (RFC 4033 à 4035) ajoute des signatures cryptographiques aux enregistrements DNS. Un résolveur validant peut vérifier que la réponse provient bien du détenteur de la zone et n'a pas été modifiée.

Les enregistrements clés

DNSKEY : clés publiques de la zone. On distingue souvent la KSK (Key Signing Key), qui signe les clés, et la ZSK (Zone Signing Key), qui signe les enregistrements.
RRSIG : signature d'un ensemble d'enregistrements.
DS : empreinte de la KSK d'une zone, publiée dans la zone parente. C'est le maillon de la chaîne de confiance.
NSEC / NSEC3 : preuve authentifiée de non-existence d'un nom.

La chaîne part de la racine, dont la clé est connue des résolveurs validants (trust anchor), passe par le TLD (.fr) via son enregistrement DS, jusqu'à votre zone.

Ce que DNSSEC ne fait pas

Il ne chiffre pas : les requêtes restent visibles.
Il protège l'authenticité, à condition que la validation soit effectuée (par le résolveur, et que le chemin entre le client et le résolveur soit de confiance).

Vérifier

dig +dnssec exemple.fr SOA          # présence d'enregistrements RRSIG
dig DS exemple.fr +short            # enregistrement DS publié dans la zone parente
dig @1.1.1.1 www.exemple.fr +dnssec | grep flags   # le drapeau "ad" indique une réponse validée

Attention : une erreur DNSSEC (signature expirée, rotation de clé mal faite, DS incohérent) rend la zone injoignable pour les résolveurs validants, qui renvoient SERVFAIL. Automatisez la signature et la rotation des clés, et supervisez la validité des signatures.

DoT et DoH : la confidentialité des requêtes

Ces deux protocoles chiffrent les échanges entre le client et le résolveur :

Protocole	Transport	Port	Caractéristique
DNS over TLS (DoT, RFC 7858)	TLS	TCP 853	Port dédié, facile à identifier et à filtrer
DNS over HTTPS (DoH, RFC 8484)	HTTPS	TCP 443 (ou HTTP/3 sur UDP 443)	Se fond dans le trafic web
DNS over QUIC (DoQ, RFC 9250)	QUIC	UDP 853	Plus récent, moins répandu

L'enjeu pour l'entreprise

DoH protège la vie privée de l'utilisateur sur un réseau non maîtrisé. Mais dans une entreprise, un navigateur ou une application qui envoie ses requêtes en DoH vers un résolveur public contourne le résolveur interne : filtrage, journalisation, résolution des noms internes. Stratégie recommandée :

Fournir un résolveur interne de qualité, éventuellement accessible en DoT/DoH ;
Configurer les navigateurs gérés par stratégie (les principaux navigateurs proposent des politiques pour désactiver le DoH ou imposer un fournisseur) ;
Bloquer en sortie les accès DNS (53, 853) vers l'extérieur, sauf depuis les résolveurs autorisés ;
Bloquer les résolveurs DoH publics connus au niveau du proxy ou du pare-feu, en sachant que cette liste n'est jamais exhaustive.

Windows 11 et les distributions Linux récentes (systemd-resolved) permettent aussi de configurer DoH ou DoT au niveau du système vers votre résolveur.

Des résolveurs maîtrisés

Récursivité réservée aux clients internes : un résolveur ouvert sur Internet participe aux attaques par amplification.
Séparation des rôles : les serveurs faisant autorité pour vos zones publiques ne doivent pas être des résolveurs récursifs.
Mises à jour régulières du logiciel (BIND, Unbound, PowerDNS, DNS Windows).
Validation DNSSEC activée sur les résolveurs (c'est le cas par défaut sur Unbound et sur les versions récentes de BIND).

Exemple avec Unbound (extrait) :

server:
    interface: 10.10.20.53
    access-control: 10.10.0.0/16 allow
    access-control: 0.0.0.0/0 refuse
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
    hide-identity: yes
    hide-version: yes
    qname-minimisation: yes

La minimisation des requêtes (RFC 9156) limite les informations envoyées aux serveurs intermédiaires : le résolveur ne demande à la racine que ce qui est nécessaire pour trouver le serveur de .fr, et non le nom complet.

Le filtrage DNS

Un résolveur peut refuser de résoudre les domaines connus pour être malveillants, grâce aux zones de politique de réponse (RPZ) ou à des listes de renseignement sur les menaces. C'est une protection simple et efficace contre une partie de l'hameçonnage et des communications de logiciels malveillants. Elle ne remplace pas les autres mesures : un logiciel malveillant peut utiliser directement des adresses IP.

Journaliser et détecter

Les journaux DNS sont une source de détection précieuse :

requêtes vers des domaines récemment enregistrés ou de réputation douteuse ;
volume anormal de requêtes depuis un poste ;
noms très longs et aléatoires, typiques d'un tunnel DNS ;
requêtes NXDOMAIN en rafale, caractéristiques de certains algorithmes de génération de domaines.

Centralisez ces journaux dans votre plateforme d'analyse. Voir Journalisation et supervision des événements de sécurité.

Protéger vos domaines publics

MFA sur les comptes du bureau d'enregistrement et de l'hébergeur DNS.
Verrouillage de registre (registry lock) pour les domaines critiques, lorsque proposé.
Supervision des enregistrements NS, MX et des enregistrements critiques.
Enregistrements CAA (RFC 8659) pour restreindre les autorités autorisées à émettre des certificats pour votre domaine.
DNSSEC sur les zones publiques, avec des procédures de rotation documentées.

Erreurs courantes

Résolveur récursif accessible depuis Internet.
DNSSEC déployé sans automatisation, puis signatures expirées.
Ignorer le DoH des navigateurs, qui contourne silencieusement le résolveur interne.
Autoriser le port 53 en sortie pour tous les postes.
Ne pas journaliser les requêtes DNS.

Conclusion

Aucun mécanisme ne couvre à lui seul toutes les menaces : DNSSEC garantit l'authenticité, DoT/DoH la confidentialité, des résolveurs maîtrisés et filtrants réduisent les abus, la journalisation permet la détection. Pour un domaine Active Directory, consultez aussi DNS sous Windows Server et intégration à Active Directory.

DNS sécurisé et mécanismes de protection

Les menaces