Qu'est-ce que DNSSEC ? Un guide simple sur la securite DNS

DNSSEC — abreviation de DNS Security Extensions — est la seule defense largement deployee contre l'empoisonnement de cache DNS, l'attaque qui permet a un adversaire reseau de mentir aux resolveurs sur la destination de votre domaine. C'est un standard depuis 2005, chaque grand TLD signe maintenant sa zone, et chaque grand fournisseur DNS manage le prend en charge. Si DNSSEC n'est pas active sur votre domaine public, vous faites confiance au fait que personne entre vos utilisateurs et votre serveur autoritaire n'a les moyens ou la motivation de les rediriger vers un endroit malveillant. Ce pari n'est plus raisonnable.

Ce guide est le point d'entree simple : ce que DNSSEC fait reellement, pourquoi il existe, comment fonctionne la chaine de confiance a haut niveau, et ce que vous devez attendre de votre fournisseur DNS. Pour la mecanique operationnelle — roles KSK vs ZSK, rotations de cles, choix d'algorithmes — lisez le guide Gestion des cles DNSSEC une fois les bases comprises.

Ce que DNSSEC fait (et ne fait pas)

DNSSEC ajoute des signatures numeriques aux enregistrements DNS. Lorsque votre serveur autoritaire renvoie un enregistrement A indiquant que example.com se trouve a 192.0.2.1, il renvoie egalement une signature cryptographique sur cet enregistrement. Un resolveur qui prend en charge la validation DNSSEC peut verifier la signature contre la cle publique de votre zone — et verifier cette cle publique contre une chaine remontant jusqu'a un point d'ancrage de confiance code en dur — et refuser la reponse si les signatures ne sont pas valides.

C'est tout son travail. DNSSEC :

• ✅ Prouve que la reponse vient du bon serveur autoritaire. Un attaquant en man-in-the-middle ne peut pas falsifier un enregistrement sans casser la signature.
• ✅ Detecte l'alteration sur le reseau ou dans un cache. Meme si le cache d'un resolveur est empoisonne, les signatures ne sont pas valides.
• ✅ Prouve qu'un enregistrement n'existe pas (les reponses negatives sont aussi signees, via les enregistrements NSEC/NSEC3).

DNSSEC ne fait pas :

• ❌ Chiffrer les requetes ou reponses DNS. Quiconque observe le reseau voit toujours ce que vous recherchez. Utilisez DNS over HTTPS ou DNS over TLS pour cela.
• ❌ Cacher la structure de votre zone. Les signatures DNSSEC sont publiques ; n'importe qui peut les recuperer.
• ❌ Remplacer TLS ou HTTPS. DNSSEC protege le DNS lui-meme ; une fois que vous avez une adresse IP, la securite de la connexion releve du protocole applicatif.
• ❌ Defendre contre des serveurs autoritaires compromis. Si un attaquant controle votre serveur de noms, il peut signer ce qu'il veut avec les cles privees de votre zone. DNSSEC fait confiance au detenteur de la cle.

Pourquoi DNSSEC existe — Le probleme d'empoisonnement de cache

Le protocole DNS original des annees 1980 a ete concu pour un reseau ou personne n'essayait activement de tricher. Les resolveurs demandaient des reponses aux serveurs autoritaires en UDP en clair, et faisaient confiance a tout ce qui revenait tant que l'IP source et un identifiant de transaction sur 16 bits correspondaient.

Ce modele de confiance a tenu jusqu'en 2008, quand Dan Kaminsky a demontre l'empoisonnement de cache pratique a grande echelle. L'attaque fonctionne ainsi :

1. L'attaquant declenche un resolveur recursif a chercher un nom qu'il controle (anything.example.com).
2. Pendant que le resolveur attend une reponse du serveur autoritaire, l'attaquant le bombarde de reponses falsifiees en devinant l'identifiant de transaction sur 16 bits.
3. Si une reponse falsifiee gagne la course, le resolveur met en cache la reponse de l'attaquant — un faux enregistrement A pour example.com — et la sert a chaque requete suivante pendant toute la TTL.

Chaque utilisateur de ce resolveur — potentiellement des millions de personnes — est maintenant silencieusement redirige vers ou l'attaquant a choisi. Trafic web, email, mises a jour logicielles : tout est redirige vers le serveur de l'attaquant jusqu'a ce que l'entree de cache expire.

La communaute DNS a reagi avec trois couches de mitigation :

1. Randomisation du port source aux resolveurs (RFC 5452, 2009) — a rendu la course bien plus difficile en ajoutant 16 bits d'imprevisibilite.
2. DNS over HTTPS / DNS over TLS sur le saut resolveur-vers-client — a chiffre la conversation pour qu'un attaquant sur le reseau local ne puisse ni voir ni alterer les requetes.
3. DNSSEC sur le saut autoritaire-vers-resolveur — a ajoute des signatures cryptographiques pour qu'un cache empoisonne produise des signatures invalides qu'un resolveur validant rejette.

DNSSEC est le seul des trois qui resout reellement le probleme sous-jacent au niveau autoritaire. La randomisation de port rend l'attaque plus difficile ; DoH/DoT change qui peut voir la requete mais pas qui peut mentir sur la reponse. DNSSEC verifie la reponse elle-meme.

La chaine de confiance — Une vue de haut niveau

Ce qui fait que DNSSEC fonctionne a l'echelle d'Internet, c'est que les resolveurs n'ont pas besoin de connaitre votre cle publique specifique a l'avance. Au lieu de cela, ils suivent une chaine de confiance d'une cle racine code en dur jusqu'a votre zone :

Zone racine (.)
    │  signe avec KSK racine
    │  publie un enregistrement DS pour .com a la racine
    ▼
TLD .com
    │  signe avec KSK .com
    │  publie un enregistrement DS pour example.com dans .com
    ▼
example.com
    │  signe tous les enregistrements avec ses propres cles
    │  signature sur l'enregistrement demande
    ▼
Enregistrement A : example.com → 192.0.2.1

Un resolveur validant suit cette chaine en sens inverse :

1. Il recoit l'enregistrement A signe de votre serveur autoritaire.
2. Il recupere l'enregistrement DS pour example.com chez les serveurs .com et verifie que le hash correspond a la KSK de votre zone.
3. Il recupere l'enregistrement DS pour .com aux serveurs racine et verifie le hash contre la KSK de la zone .com.
4. Il verifie la signature de la zone racine contre le point d'ancrage de confiance code en dur (la KSK racine, egalement publiee par l'IANA a https://data.iana.org/root-anchors/).

Si un maillon de la chaine echoue, la reponse est traitee comme non fiable. La plupart des resolveurs validants renverront SERVFAIL plutot que de servir une reponse potentiellement alteree.

Vous n'avez pas besoin de comprendre la mecanique pour utiliser DNSSEC. Votre fournisseur DNS genere et fait tourner les cles pour vous ; votre seul travail est de publier une piece — l'enregistrement DS — chez votre registrar pour que la chaine atteigne votre zone.

Pour le decoupage mecanique complet — roles KSK vs ZSK, enregistrements RRSIG, NSEC/NSEC3 pour la negation authentifiee — voir Comment fonctionne DNSSEC.

Comment savoir si un domaine a DNSSEC

Lancez dig avec le drapeau +dnssec contre un resolveur validant :

dig +dnssec example.com @1.1.1.1

Cherchez deux choses :

1. Les enregistrements RRSIG dans la section reponse, associes a chaque set d'enregistrements interroge. Ce sont les signatures.
2. Le drapeau AD (Authenticated Data) dans l'en-tete de reponse, indiquant que le resolveur a valide la chaine avec succes.

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
                                ^^
                                 │
                          drapeau AD positionne = validation reussie
 
;; ANSWER SECTION:
example.com.         300  IN  A      192.0.2.1
example.com.         300  IN  RRSIG  A 13 2 300 20260601000000 ...
                                         ^^
                                          │
                                   enregistrement de signature

Si vous voyez les RRSIG mais pas le drapeau AD, le resolveur ne valide pas — essayez 1.1.1.1 ou 9.9.9.9, qui valident tous deux par defaut. Si vous ne voyez pas de RRSIG, la zone n'est pas signee.

Pour la visualisation, DNSViz et le DNSSEC Debugger de Verisign dessinent la chaine de confiance complete et signalent les ruptures.

Quand activer DNSSEC

En bref : toujours, pour tout domaine public.

Cas particulierement importants :

• Services a forte confiance — banque, e-commerce, fournisseurs d'identite, gouvernement — ou un empoisonnement de cache reussi a des consequences directes.
• Email — DNSSEC est un prerequis pour DANE/TLSA, qui protege le TLS SMTP contre les attaques de retrogradation. MTA-STS est une alternative partielle pour les organisations pas encore pretes pour DANE.
• Entites UE regulees sous NIS2 — l'article 21(2)(h) exige des "politiques et procedures concernant l'usage de la cryptographie". Un fournisseur DNS qui n'offre pas DNSSEC, ou un deploiement qui ne l'a pas active, risque d'etre juge non conforme. Voir le guide NIS2 et DNS pour la cartographie complete.
• Environnements pilotes par la conformite — PCI DSS, HIPAA, ISO 27001 et divers cadres nationaux listent DNSSEC comme un controle recommande ou attendu.

Il n'y a essentiellement aucune situation ou DNSSEC est une mauvaise idee pour une zone publique. Les objections historiques — complexite operationnelle, risque de gestion de cles, compatibilite resolveur — sont largement resolues par les fournisseurs DNS manages qui gerent la generation, la rotation et la publication DS automatiquement.

Que rechercher chez un fournisseur DNS compatible DNSSEC

Lors de l'evaluation du support DNSSEC d'un fournisseur DNS, demandez :

Activer DNSSEC sur DNScale

DNScale active DNSSEC en un clic par zone :

1. Depuis le tableau de bord, ouvrez la zone.
2. Cliquez sur Activer DNSSEC. DNScale genere une CSK (Combined Signing Key) en utilisant ECDSA P-256.
3. Copiez l'enregistrement DS affiche chez votre registrar. Certains registrars l'acceptent directement ; d'autres via API ; certains exigent encore une saisie manuelle.
4. Attendez 24–48 heures pour que le DS se propage au TLD.
5. Verifiez avec dig +dnssec votredomaine @1.1.1.1 et confirmez le drapeau AD.

La rotation des cles, le rafraichissement des signatures et la synchronisation avec la zone parente se font automatiquement. Les mises a niveau d'algorithme sont des rolls coordonnes que DNScale execute sans interruption visible cote client.

Pour le pas-a-pas complet incluant les instructions specifiques au registrar, voir Guide d'installation DNSSEC pour DNScale. Pour la mecanique sous-jacente, voir Comment fonctionne DNSSEC et Gestion des cles DNSSEC.

References

• RFC 4033 — Introduction et exigences DNS Security
• RFC 4034 — Resource Records pour les DNS Security Extensions
• RFC 4035 — Modifications de protocole pour les DNS Security Extensions
• RFC 5155 — DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 8901 — Modeles DNSSEC multi-signataires
• Points d'ancrage de confiance racine IANA
• DNSViz — visualiseur de chaines de confiance DNSSEC
• DNSSEC Debugger de Verisign

Lectures complementaires

• Comment fonctionne DNSSEC — mecanique KSK/ZSK/DS/DNSKEY
• Gestion des cles DNSSEC — procedures operationnelles de rotation
• Guide d'installation DNSSEC pour DNScale — pas-a-pas produit
• DNSSEC vs DNS over HTTPS — integrite vs confidentialite
• NIS2 et conformite DNS — cartographie reglementaire
• Empoisonnement de cache DNS — l'attaque que DNSSEC contre