DNSSEC

general

Définition

DNSSEC (Domain Name System Security Extensions) est un ensemble d'extensions du protocole DNS qui ajoute la cryptographie à clé publique pour authentifier et garantir l'intégrité des réponses DNS. Il protège contre les attaques d'empoisonnement DNS (DNS Cache Poisoning, comme l'attaque Kaminsky de 2008) qui consistent à injecter des fausses réponses DNS dans le cache d'un résolveur pour rediriger les utilisateurs vers des serveurs malveillants. Le problème fondamental de DNS est qu'il a été conçu pour la disponibilité et l'efficacité, pas pour la sécurité. Les réponses DNS traditionnelles ne sont pas signées — un résolveur ne peut pas distinguer une réponse légitime d'une réponse falsifiée. L'attaque de Dan Kaminsky (2008) a démontré qu'un attaquant pouvait empoisonner le cache DNS d'un résolveur en environ 10 secondes via une attaque par force brute sur le port source et le query ID, redirigeant ainsi potentiellement tous les utilisateurs d'un ISP vers des serveurs malveillants. DNSSEC résout ce problème en ajoutant des enregistrements DNS signés cryptographiquement. Les types d'enregistrements DNSSEC incluent : DNSKEY (contient la clé publique de la zone), RRSIG (signature d'un Resource Record Set), DS (Delegation Signer — hash de la clé de la zone enfant, stocké dans la zone parente), NSEC/NSEC3 (preuve d'inexistence d'enregistrement, pour authentifier les réponses NXDOMAIN). La chaîne de confiance DNSSEC remonte jusqu'à la root zone signée (Root KSK — Key Signing Key, dont la cérémonie de signature est publique et auditée). Les résolveurs DNSSEC-aware vérifient la chaîne de signatures depuis la racine jusqu'au domaine interrogé pour valider l'authenticité de la réponse. Les limitations de DNSSEC sont réelles. DNSSEC ne chiffre pas les requêtes (DNS over TLS/HTTPS est nécessaire pour la confidentialité). DNSSEC augmente la taille des réponses DNS (les signatures et clés ajoutent des octets, causant parfois des problèmes avec UDP 512 octets et nécessitant EDNS0). Le déploiement de DNSSEC est encore partiel : environ 90% des ccTLDs supportent DNSSEC, mais les taux de signature des domaines individuels varient (30-40% en France, 60%+ aux Pays-Bas — champion mondial).

Déploiement DNSSEC pour un domaine

Activer DNSSEC pour un domaine implique plusieurs étapes. (1) Générer une paire de clés ZSK (Zone Signing Key — signe les enregistrements) et KSK (Key Signing Key — signe le DNSKEY) via les outils du registrar ou de la solution DNS (dnssec-keygen pour BIND, pdnsutil pour PowerDNS). (2) Signer la zone avec ces clés (génère les enregistrements RRSIG, NSEC3). (3) Publier les enregistrements DNSKEY dans la zone. (4) Transmettre le DS record (hash de la KSK) au registrar pour qu'il le publie dans la zone TLD parente (.fr, .com). (5) Vérifier avec des outils comme DNSViz (dnsviz.net) qui visualise graphiquement la chaîne de confiance DNSSEC. Les registrars comme Gandi, OVH, et Cloudflare offrent DNSSEC en un clic avec gestion automatique de la rotation des clés.

Rotation des clés DNSSEC — opérations

La rotation périodique des clés DNSSEC (tous les 3-12 mois pour la ZSK, tous les 1-5 ans pour la KSK) est une opération délicate. Une mauvaise rotation peut "casser" le domaine pour les résolveurs DNSSEC-aware — l'erreur la plus courante est de changer la KSK sans mettre à jour le DS record chez le registrar, ou de supprimer les anciennes clés avant que le nouveau DS record ait propagé. La procédure de rollover KSK recommandée par RFC 6781 utilise un "double-KSK" : publier la nouvelle KSK et son DS simultanément avec l'ancienne, attendre la propagation TTL (souvent 24-72h), puis retirer l'ancienne KSK et son DS. Les solutions DNS managées (Cloudflare, AWS Route 53 avec DNSSEC activé, NS1) automatisent cette rotation.

DNSSEC et DAne — DANE (DNS-based Authentication of Named Entities)

DANE (RFC 6698) est un protocole qui utilise DNSSEC pour publier et valider des certificats TLS directement dans le DNS, sans dépendre des CAs traditionnelles. Un enregistrement TLSA dans la zone DNS (sécurisée par DNSSEC) contient le hash du certificat attendu pour un service. Un client DANE-aware vérifie que le certificat présenté par le serveur correspond à l'enregistrement TLSA — si la zone est signée DNSSEC, cette vérification est authentifiée. DANE pour SMTP (SMTP over DANE) est déployé par les registrars email modernes (Orange, SFR, certains ISPs européens) pour authentifier les connexions MTA-to-MTA. DANE pour HTTPS (HTTPS) est moins déployé car il requiert la validation DNSSEC dans les navigateurs — Chrome et Firefox ne valident pas DNSSEC nativement (ils délèguent aux résolveurs).

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis