Comment securiser votre infrastructure DNS en entreprise en 7 etapes

Le DNS (Domain Name System) est le composant le plus utilise et le moins surveille de la majorite des reseaux d'entreprise. Chaque courriel envoye, chaque page web ouverte, chaque appel API, chaque synchronisation cloud commence par une requete DNS. Et dans la grande majorite des PME francaises, ce trafic circule en clair, sans validation, sans filtrage, et sans aucune forme de surveillance.

Le resultat est previsible. Selon les donnees du secteur, 91 % des malwares utilisent le DNS a un moment de leur chaine d'execution — pour contacter un serveur de commande et controle (C2), pour exfiltrer des donnees, ou pour tunneliser du trafic a travers un canal que personne ne surveille. Le DNS est la porte d'entree la plus ouverte du reseau, parce que c'est la seule que personne ne pense a fermer.

Ce guide presente sept etapes concretes pour securiser votre infrastructure DNS, de l'audit initial au test continu. Chaque etape est independante et produit des resultats en elle-meme. L'ordre est celui qui maximise les gains par rapport a l'effort, en commencant par ce qui se fait en une journee.

Etape 1 — Auditer votre infrastructure DNS actuelle

Avant de securiser quoi que ce soit, il faut savoir ce qui existe. Et dans la plupart des PME, la reponse a « qui gere notre DNS ? » est un silence gene suivi d'un « le prestataire, je crois ».

L'audit DNS initial couvre quatre questions :

• Ou sont heberges vos enregistrements DNS autoritaires ? Chez le registrar, chez l'hebergeur, chez un tiers ? Qui a acces au panneau de gestion, et avec quelle authentification ?
• Quel resolveur DNS utilisent vos postes de travail et serveurs ? Le resolveur du FAI, celui du DHCP, un resolveur public (8.8.8.8, 1.1.1.1), un resolveur interne ? La reponse varie souvent d'un site a l'autre, voire d'un poste a l'autre.
• Le transfert de zone est-il restreint ? Un transfert de zone (AXFR) non restreint expose l'integralite de vos enregistrements DNS a quiconque le demande. C'est le premier test de tout attaquant, et il fonctionne dans un nombre surprenant de cas.
• Les enregistrements SPF, DKIM et DMARC sont-ils configures ? Ce sont des mecanismes DNS qui protegent votre domaine contre l'usurpation de courriel. Leur absence est une faille exploitee quotidiennement dans les attaques par hameconnage.

Cette etape se realise en une demi-journee avec des outils gratuits : dig, nslookup, host pour les requetes, et des services en ligne comme MXToolbox ou DNSViz pour la validation. Notre guide sur les attaques DNS en entreprise detaille les vecteurs a rechercher.

Etape 2 — Deployer DNSSEC sur vos domaines

DNSSEC (Domain Name System Security Extensions) est le mecanisme qui garantit que la reponse DNS que vous recevez vient bien du serveur autoritaire et n'a pas ete alteree en transit. Sans DNSSEC, un attaquant positionne sur le reseau peut modifier les reponses DNS pour rediriger vos utilisateurs vers un serveur malveillant — c'est l'empoisonnement de cache, ou DNS cache poisoning.

Le principe est simple : le serveur DNS autoritaire signe chaque enregistrement avec une cle cryptographique. Le resolveur verifie la signature avant de transmettre la reponse au client. Si la signature est invalide ou absente, la reponse est rejetee.

Comment le deployer :

• Activez DNSSEC aupres de votre registrar. La plupart des registrars francais (OVH, Gandi, Scaleway) proposent l'activation en un clic. C'est gratuit et immediat.
• Configurez la validation DNSSEC sur votre resolveur interne. Si vous utilisez Unbound, BIND ou PowerDNS, activez le parametre de validation. Les requetes vers des domaines DNSSEC invalides seront rejetees.
• Testez avec DNSViz. Entrez votre domaine sur dnsviz.net et verifiez que la chaine de confiance est complete, du root jusqu'a votre zone.

Point d'attention : DNSSEC protege l'integrite des reponses. Il ne chiffre pas le trafic. Un observateur sur le reseau voit toujours quels domaines vous interrogez. C'est l'objet de l'etape suivante.

Etape 3 — Chiffrer les requetes DNS (DoH / DoT)

Le DNS traditionnel fonctionne en UDP sur le port 53, en clair. Chaque requete et chaque reponse est lisible par quiconque se trouve entre le client et le resolveur : le FAI, un attaquant sur le reseau local, un proxy compromis. DNS over TLS (DoT, port 853) et DNS over HTTPS (DoH, port 443) chiffrent ce canal.

En entreprise, le choix entre DoH et DoT n'est pas esthetique. Il a des consequences directes sur votre securite perimetrique :

Notre recommandation : deployez un resolveur interne compatible DoT (Unbound est le plus simple a configurer), forcez les postes a l'utiliser via DHCP ou GPO, et bloquez le port 853 et les requetes DNS (port 53) vers l'exterieur sur votre pare-feu. Si des postes utilisent DoH vers un resolveur externe, vous perdez toute visibilite sur leur trafic DNS.

Etape 4 — Segmenter et durcir vos serveurs DNS

Un serveur DNS interne mal positionne dans le reseau est une aubaine pour un attaquant qui a obtenu un premier acces. S'il peut interroger votre resolveur interne, il cartographie l'integralite de votre reseau. S'il peut modifier vos enregistrements, il redirige le trafic ou qu'il veut.

Les regles de durcissement :

• Separez les roles. Le serveur DNS autoritaire (qui detient vos enregistrements) ne doit pas etre le meme que le resolveur (qui repond aux requetes des postes). Deux instances, deux machines ou deux conteneurs, deux politiques d'acces.
• Restreignez l'acces reseau. Le resolveur interne n'accepte les requetes que du VLAN bureautique. Le serveur autoritaire n'accepte les transferts de zone que depuis le resolveur secondaire, identifie par IP.
• Desactivez la recursion sur le serveur autoritaire. Un serveur autoritaire qui fait aussi de la recursion elargit inutilement sa surface d'attaque.
• Limitez le rate. Configurez la limitation de debit (RRL, Response Rate Limiting) sur le serveur autoritaire pour reduire l'impact d'un DDoS par amplification DNS.
• Mettez a jour. BIND, Unbound, PowerDNS : chaque version corrige des vulnerabilites. Un serveur DNS non patche est une cible prioritaire. Integrez-le dans votre cycle de patch management.

Si votre infrastructure est hebergee en cloud, les memes principes s'appliquent : un resolveur prive dans le VPC, pas de resolveur ouvert sur Internet, et des regles de securite group qui n'autorisent le port 53 que depuis les sous-reseaux clients.

Etape 5 — Mettre en place la surveillance DNS

La surveillance DNS est le point ou la securite DNS cesse d'etre preventive et devient detective. Un resolveur bien configure empeche certaines attaques. La surveillance des requetes detecte celles qui passent.

Ce qu'il faut surveiller :

• Volume de requetes par domaine. Un pic soudain de requetes vers un meme domaine peut indiquer un beaconing C2 ou une exfiltration en cours.
• Longueur des sous-domaines. Un sous-domaine de plus de 50 caracteres est statistiquement suspect. C'est le mecanisme de base du tunneling DNS : les donnees sont encodees dans le sous-domaine de la requete.
• Enregistrements TXT de grande taille. Les reponses TXT volumineuses sont un canal classique de retour pour le tunneling DNS.
• Requetes vers des domaines nouvellement enregistres (NRD). Les domaines crees dans les dernieres 24 a 72 heures sont statistiquement plus souvent malveillants. Certains resolveurs filtrants integrent cette detection.
• Requetes a intervalles reguliers. Un malware qui contacte son C2 toutes les 60 secondes via DNS produit un pattern reconnaissable, appele beaconing.

Ou centraliser les logs : si vous disposez d'un SIEM (Wazuh, ELK, Splunk), alimentez-le avec les logs de votre resolveur interne. Si vous n'avez pas de SIEM, le fichier de log d'Unbound configure en mode verbeux suffit pour commencer — un script qui compte les requetes par domaine et alerte au-dessus d'un seuil est un premier detective DNS fonctionnel.

Etape 6 — Deployer le filtrage DNS

Le filtrage DNS consiste a bloquer la resolution de certains domaines classes comme malveillants, de hameconnage, ou appartenant a des categories non souhaitees (jeux, paris, malware). C'est l'equivalent d'un pare-feu, mais au niveau du nom de domaine : la requete est interceptee avant meme que la connexion TCP ne s'etablisse.

Trois approches, du plus simple au plus complet :

• Listes de blocage sur le resolveur interne. Unbound ou Pi-hole peuvent charger des listes de domaines malveillants (RPZ, Response Policy Zones). Gratuit, efficace pour les menaces connues, mais limite par la fraicheur des listes.
• Resolveur DNS filtre externe. Des services comme Quad9 (9.9.9.9), Cisco Umbrella, ou Cloudflare Gateway filtrent les requetes en temps reel a partir de bases de threat intelligence mises a jour en continu. C'est la solution la plus rapide a deployer pour une PME sans equipe securite dediee.
• Proxy DNS d'entreprise. Des solutions comme dnsdist, Infoblox ou BlueCat permettent de combiner le filtrage, le logging, et la redirection DNS dans un point de controle unique. Plus adapte aux ETI et grands comptes.

Configuration minimale recommandee : un resolveur Unbound interne qui interroge Quad9 en upstream via DoT, avec les listes RPZ du projet abuse.ch chargees localement. Vous obtenez le filtrage de Quad9 plus le blocage des menaces connues, le tout journalise dans vos logs. Cette configuration se deploie en moins de deux heures sur un serveur existant.

Etape 7 — Tester et maintenir en continu

La securite DNS n'est pas un projet ponctuel. C'est un processus continu, parce que la surface d'attaque change chaque fois qu'un enregistrement est ajoute, qu'un sous-domaine est cree, ou qu'un poste est configure avec un nouveau resolveur.

Tests reguliers a planifier :

• Tentative de transfert de zone (AXFR) mensuelle. Depuis l'exterieur et l'interieur du reseau. Si elle reussit, la restriction est mal configuree.
• Test DNSSEC trimestriel. Verifiez sur dnsviz.net que la chaine de confiance est intacte et que les cles n'ont pas expire.
• Simulation de tunneling DNS. Utilisez un outil comme dnscat2 ou iodine depuis un poste interne et verifiez que votre SIEM ou vos regles de filtrage detectent l'activite.
• Revue des enregistrements DNS semestrielle. Supprimez les enregistrements pointant vers des services arretes (sous-domaines pendants, ou dangling DNS). Un sous-domaine qui pointe vers un service cloud resilie peut etre repris par un attaquant.
• Veille sur les CVE DNS. Abonnez-vous aux bulletins de securite de BIND, Unbound, PowerDNS. Integrez les mises a jour DNS dans votre cycle de patch management, au meme titre que l'OS ou le pare-feu.

Recapitulatif des 7 etapes

L'ensemble de ces sept etapes peut etre deploye en une semaine pour une PME de 50 postes, pour un cout inferieur a 3 000 euros par an. L'essentiel de l'investissement est du temps d'administration, pas de l'achat de licence. Et les gains sont cumulatifs : chaque etape ameliore la posture de securite independamment des autres.

Le DNS est le composant le plus critique et le moins protege de votre reseau. C'est aussi celui dont la securisation offre le meilleur rapport effort/resultat, parce qu'il couvre toutes les phases de la chaine d'attaque d'un seul coup. Les sept etapes de ce guide ne demandent ni budget exceptionnel ni equipe dediee. Elles demandent une decision, et une semaine.