Accueil

DNSSEC : Sécuriser les requêtes DNS avec BIND

Security
Difficulte: Advanced
4 min de lecture

Tutoriel pour installer et configurer DNSSEC avec BIND sur Linux pour sécuriser votre infrastructure DNS contre les attaques de type cache poisoning.

Retour aux tutoriels

L'essentiel

  • DNSSEC n'est pas du chiffrement : il ajoute des signatures numériques qui garantissent l'authenticité et l'intégrité des réponses DNS. Les requêtes restent lisibles en clair sur le réseau, mais l'empoisonnement de cache devient détectable.
  • La hiérarchie de clés tient en trois objets : la ZSK signe les enregistrements de la zone, la KSK ne signe que la ZSK, et l'enregistrement DS est une empreinte de la KSK publiée chez le registrar pour raccrocher la zone à la chaîne de confiance mondiale.
  • Côté BIND9, trois directives suffisent dans la déclaration de zone : inline-signing yes, auto-dnssec maintain et key-directory. BIND génère alors les clés et signe la zone tout seul, sans manipulation de fichiers de zone.
  • L'enregistrement DS s'extrait avec dnssec-dsfromkey -2 sur le fichier .key de la KSK. Il faut reporter les quatre valeurs chez le registrar : le key tag, l'algorithme, le type de digest et l'empreinte.
  • La validation se contrôle avec dig +dnssec : le flag ad (Authenticated Data) dans l'en-tête signifie que le résolveur a vérifié la signature. La rotation des ZSK est automatique, celle de la KSK reste manuelle car elle impose un nouveau DS chez le registrar, tous les 1 à 2 ans.
Qu'est-ce que DNSSEC ?
DNSSEC (Domain Name System Security Extensions) est une technologie qui renforce l'authentification dans le DNS en utilisant des signatures numériques. Il permet à un client DNS de vérifier que les réponses qu'il reçoit d'un serveur DNS sont authentiques et n'ont pas été altérées. Il ne chiffre pas les requêtes, mais garantit leur intégrité.

Pourquoi utiliser DNSSEC ?

Le DNS a été conçu sans sécurité. Un attaquant peut intercepter une requête DNS et renvoyer une fausse adresse IP, redirigeant un utilisateur vers un site malveillant. C'est ce qu'on appelle l'empoisonnement de cache DNS (cache poisoning). DNSSEC empêche ce type d'attaque.

Prérequis

  • Un serveur DNS BIND9 fonctionnel, maître pour une zone (ex: `example.com`).
  • Accès root ou privilèges sudo.
  • Votre registrar de nom de domaine doit supporter DNSSEC pour pouvoir publier vos clés.

Contenu Premium

Ce tutoriel avancé est réservé aux membres premium.

9,90€ / mois
  • Tous les tutoriels avancés
  • Nouveaux contenus chaque semaine
  • Suivi de progression
  • Annulation à tout moment
Se connecter Créer un compte
MR

Écrit par

Morgann Riu

Expert en cybersécurité et administration Linux. Je partage mes connaissances à travers des tutoriels gratuits et des formations pour aider les administrateurs systèmes et développeurs à sécuriser leurs infrastructures.

Mon profil LinkedIn GitHub

Questions fréquentes

BIND a signé ma zone mais aucun résolveur ne la valide, pourquoi ?
Tant que l'enregistrement DS n'est pas publié chez le registrar, la zone signée n'est rattachée à rien : les résolveurs la traitent comme une zone non signée et ignorent les signatures. Récupérez le DS avec dnssec-dsfromkey -2, saisissez ses quatre champs dans la section DNSSEC de votre registrar, puis patientez : la propagation va de quelques minutes à 24 heures.
Pourquoi deux clés, une ZSK et une KSK, plutôt qu'une seule ?
La ZSK signe l'intégralité des enregistrements de la zone : elle travaille beaucoup et doit donc pouvoir tourner souvent. La KSK, plus robuste, ne signe que la ZSK. C'est uniquement l'empreinte de la KSK qui part chez le registrar sous forme de DS, ce qui permet de renouveler la ZSK aussi souvent que nécessaire sans jamais retoucher à la configuration du registrar.
DNSSEC chiffre-t-il mes requêtes DNS ?
Non, et c'est la confusion la plus fréquente. DNSSEC apporte de l'authentification et de l'intégrité, pas de la confidentialité : un observateur du réseau voit toujours quels noms vous résolvez. Il garantit en revanche qu'une réponse n'a pas été forgée ou altérée en chemin, ce qui bloque l'empoisonnement de cache. Pour la confidentialité, ce sont d'autres mécanismes, comme le DNS chiffré, qui interviennent.
Dois-je gérer la rotation des clés à la main ?
Avec auto-dnssec maintain, BIND se charge automatiquement de la rotation des ZSK : rien à faire de votre côté. La KSK est un autre sujet, car changer de KSK signifie publier un nouvel enregistrement DS chez le registrar, opération qui ne peut pas être automatisée depuis le serveur. Cette rotation manuelle se planifie généralement tous les 1 à 2 ans.
Comment vérifier concrètement que la validation fonctionne ?
En ligne de commande, lancez dig +dnssec www.example.com @8.8.8.8 et cherchez le flag ad dans les en-têtes de la réponse : sa présence prouve qu'un résolveur tiers a validé votre chaîne de confiance de bout en bout. L'option +dnssec affiche également les enregistrements RRSIG. Pour une vue graphique de toute la chaîne, dnsviz.net et dnssec-analyzer.verisignlabs.com donnent un diagnostic complet à partir du seul nom de domaine.

Partager ce tutoriel

X LinkedIn WhatsApp

Cet article vous a plu ?

Cet article vous a-t-il été utile ?

Merci pour votre retour !

Commentaires

Recommandé pour vous

Sécurité

iptables : Configurer un Pare-feu sur Linux

 Sécurité

UFW : Pare-feu simple pour Linux

 Sécurité

Bastion SSH : Sécuriser l'Accès à Vos Serveurs

 Sécurité

Snort : Détection d'intrusion réseau (NIDS)

Article de fond sur le sujet

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.

← Retour à l'accueil
↑