Le DNS est l’aiguillage discret de presque toute activité en ligne : il associe les noms de domaine aux serveurs qui les hébergent. Lorsqu’il est détourné ou simplement mal configuré, les conséquences dépassent la navigation. DNSSEC, DNS over HTTPS et DNS over TLS répondent chacun à une partie du problème, mais aucun ne remplace une stratégie de sécurité complète.
L’article en bref
Protéger le DNS, c’est sécuriser à la fois les réponses reçues et les décisions prises autour de l’infrastructure. Comprendre les rôles de chaque protocole permet de bâtir une protection adaptée, sans confondre chiffrement et authentification.
- Authenticité : DNSSEC authentifie les réponses, sans chiffrer les requêtes.
- Confidentialité : DoH et DoT protègent le transport, avec des compromis opérationnels.
- Contrôle : Un DNS sécurisé exige aussi contrôle des comptes et surveillance.
- Vérification : Des tests réguliers vérifient fuite, validation DNSSEC et résilience.
Une protection efficace combine protocoles, gestion des accès et contrôles réguliers.
Pourquoi la sécurité DNS est essentielle à la protection de la navigation
Un résolveur DNS fonctionne comme un annuaire : lorsqu’un appareil demande l’adresse d’un domaine, il cherche la correspondance nécessaire pour joindre le bon serveur. Cette étape concerne les sites Web, les messageries, les applications métier et de nombreux services internes.
Dans une PME fictive, la compromission du compte chez le registraire pourrait permettre de modifier les serveurs DNS du domaine. Les courriels entrants ou le trafic Web pourraient alors être redirigés ; selon le type de contrôle utilisé pour délivrer un certificat, l’attaquant pourrait aussi tenter d’en obtenir un pour le domaine. La cybersécurité DNS commence donc autant par la protection des comptes et des délégations que par le choix d’un protocole.
Des risques qui touchent l’infrastructure et les utilisateurs
Les attaques ne poursuivent pas toutes le même objectif. L’empoisonnement du cache cherche à faire accepter une réponse falsifiée, tandis que le détournement DNS peut s’appuyer sur un compte de gestion ou une modification de délégation. Le DNS tunneling, lui, dissimule parfois des échanges dans des requêtes DNS afin de contourner des contrôles réseau.
D’autres attaques, comme les requêtes vers des sous-domaines aléatoires ou les réponses NXDOMAIN répétées, visent plutôt à saturer un résolveur ou un serveur faisant autorité. Le premier enjeu est de distinguer une tentative de redirection d’une attaque sur la disponibilité : les signaux observés et les mesures de réponse ne sont pas les mêmes.
Le DNS est également une source précieuse pour la détection. Des changements inhabituels de configuration, des volumes de requêtes anormaux ou des connexions à des domaines rares peuvent compléter les alertes d’autres outils de sécurité.
DNSSEC, DNS over HTTPS et DNS over TLS : des protections différentes
Il faut distinguer l’authenticité des données DNS de la confidentialité des échanges. DNSSEC aide à vérifier qu’une réponse signée n’a pas été falsifiée ; DoH et DoT chiffrent le trajet entre un appareil et son résolveur. Ces mécanismes sont complémentaires, pas interchangeables.
| Technologie | Protection principale | Limite à connaître |
|---|---|---|
| DNSSEC | Vérifie l’authenticité et l’intégrité des réponses signées. | Ne chiffre pas les requêtes ni les réponses. |
| DNS over TLS (DoT) | Chiffre les échanges DNS entre le client et le résolveur. | Le trafic DNS reste identifiable comme tel sur le réseau. |
| DNS over HTTPS (DoH) | Transporte les requêtes DNS dans une connexion HTTPS chiffrée. | Peut compliquer le filtrage et la visibilité côté entreprise. |
DNSSEC authentifie les données, mais ne masque pas les domaines consultés
Avec DNSSEC, les enregistrements d’une zone sont signés cryptographiquement. Le résolveur validant suit une chaîne de confiance, depuis la racine DNS jusqu’à la zone concernée, pour vérifier les signatures et détecter une réponse altérée. Si une validation échoue, il peut refuser la réponse plutôt que de transmettre une information douteuse.
Cette vérification ne rend pas les requêtes confidentielles : un observateur réseau peut encore voir les domaines demandés si le transport n’est pas chiffré. La mise en œuvre exige aussi une configuration correcte des clés et de leur renouvellement ; une erreur de signature peut rendre un domaine inaccessible pour les résolveurs qui valident DNSSEC.
DoT et DoH chiffrent les requêtes, avec des effets différents sur le contrôle
DNS over TLS établit un canal chiffré entre l’appareil et le résolveur DNS, généralement sur le port 853. DNS over HTTPS encapsule la résolution dans HTTPS, souvent sur le port 443, ce qui la rend plus difficile à distinguer du trafic Web ordinaire.
Pour un particulier, ces protocoles peuvent renforcer la confidentialité en ligne face à l’observation locale du réseau, sans cacher pour autant toute activité : le fournisseur du résolveur voit les requêtes, et d’autres métadonnées peuvent rester accessibles. En entreprise, un DoH configuré séparément dans chaque navigateur peut contourner le résolveur central et son filtrage DNS. Il faut donc définir les résolveurs autorisés et adapter les politiques de gestion des appareils.
Pour replacer la résolution DNS dans le parcours d’une connexion, le modèle OSI et ses sept couches offre un repère utile. Le choix du canal sécurisé doit s’intégrer à l’architecture réseau, et non être traité comme un simple réglage de navigateur.
Mettre en place un DNS sécurisé : protocoles et contrôles complémentaires
Un protocole ne protège pas un compte administrateur mal sécurisé ni un serveur exposé sans nécessité. Dans le cas de l’entreprise fictive, une approche solide associerait DNSSEC sur les zones pertinentes, un résolveur contrôlé pour les postes gérés et une protection renforcée du compte chez le registraire.
Les mesures suivantes réduisent les risques sans supposer qu’une technologie unique puisse tout résoudre :
- Protéger la gestion du domaine : activer l’authentification multifacteur, limiter les comptes autorisés et verrouiller les transferts lorsque c’est possible.
- Durcir les serveurs : maintenir les logiciels à jour, restreindre l’administration et prévoir une configuration de secours testée.
- Définir le transport DNS : choisir des résolveurs de confiance, chiffrer les échanges et encadrer DoH sur les appareils de l’organisation.
- Préserver la visibilité : centraliser les journaux utiles dans un outil de supervision et corréler les événements avec les alertes de sécurité.
- Préparer la réponse : documenter les contacts du registraire et les étapes de restauration des enregistrements.
Un service VPN peut compléter la protection d’une connexion, mais ne remplace ni DNSSEC ni la maîtrise du résolveur. Les critères de choix et les limites sont détaillés dans ce guide consacré à Proton VPN et à la confidentialité.
Tests de sécurité DNS : vérifier la configuration et détecter les fuites
Les tests de sécurité DNS doivent couvrir plusieurs scénarios : une réponse peut être correctement signée sans être chiffrée, et une connexion chiffrée peut tout de même utiliser un résolveur inattendu. Une vérification utile commence par identifier le résolveur réellement utilisé, puis contrôle la validation DNSSEC et le comportement du réseau en cas d’échec.
- Identifier le résolveur : comparer la configuration du système, du navigateur et du routeur pour repérer une source DNS non prévue.
- Vérifier DNSSEC : utiliser un outil de diagnostic reconnu ou interroger un domaine de test conçu pour révéler une validation défaillante.
- Contrôler les fuites : vérifier, sur les réseaux concernés, si les requêtes passent par le résolveur attendu plutôt que par un service tiers.
- Tester la résilience : simuler l’indisponibilité d’un serveur secondaire en environnement maîtrisé et confirmer que la résolution reprend correctement.
- Examiner les journaux : rechercher des hausses de NXDOMAIN, des noms inhabituels et des changements de configuration non planifiés.
Un test isolé donne une photographie ; des contrôles récurrents révèlent les dérives. Les équipes doivent aussi vérifier que les politiques de filtrage DNS restent actives lorsque DoH est disponible sur les postes gérés.
Lire les résultats sans confondre chiffrement et sécurité complète
Si un test confirme l’usage de DoH ou de DoT, cela indique que le transport vers un résolveur est chiffré, pas que ce résolveur est digne de confiance. De même, la validation DNSSEC protège contre certaines falsifications, mais ne protège pas un domaine dont les paramètres ont été modifiés depuis un compte compromis.
La vraie question n’est pas seulement « le DNS est-il chiffré ? », mais « qui contrôle la résolution, quelles réponses sont validées et comment les anomalies sont-elles détectées ? ». À l’échelle d’un réseau, ces réponses déterminent si les protections améliorent réellement la protection de la navigation.
Questions fréquentes sur DNSSEC, DoH et la sécurité DNS
DNSSEC chiffre-t-il les requêtes DNS ?
Non. DNSSEC permet de vérifier l’authenticité et l’intégrité des réponses signées, mais ne chiffre pas les échanges. DoH ou DoT peuvent chiffrer le transport entre l’appareil et son résolveur.
Quelle différence entre DNS over HTTPS et DNS over TLS ?
Les deux protocoles chiffrent les requêtes vers un résolveur. DoT les transporte dans une connexion TLS dédiée, tandis que DoH les encapsule dans HTTPS, ce qui peut compliquer leur identification et le filtrage sur un réseau administré.
Un résolveur DNS sécurisé suffit-il à protéger la navigation ?
Non. Il faut aussi protéger les comptes du registraire, surveiller les changements de zones, maintenir les serveurs et vérifier que les appareils utilisent les résolveurs prévus.
Comment effectuer des tests de sécurité DNS ?
Commencez par identifier le résolveur utilisé, vérifier la validation DNSSEC, rechercher d’éventuelles fuites et examiner les journaux. Répétez les contrôles après toute modification du réseau ou de la configuration des appareils.
