DNSSEC avec Cloudflare : ce qu'il protège, ce qu'il ne protège pas et comment l'activer sans problème

La confusion la plus courante à propos du DNSSEC est de le décrire comme « Cryptage DNS ». Les équipes qui partent de ce postulat erroné arrivent à deux conclusions tout aussi erronées : soit elles rejettent la fonctionnalité parce que « nous avons déjà TLS », soit elles l'activent sans comprendre la dépendance opérationnelle qu'elles viennent d'introduire. DNSSEC signe les réponses DNS pour prouver leur authenticité – il ne crypte rien. L'attaque qu'il stoppe, conséquence d'une configuration mal gérée, et ce qu'il ne couvre tout simplement pas sont trois sujets distincts qui méritent un traitement séparé.

Ce que fait réellement DNSSEC

Lorsqu'un résolveur récursif interroge un serveur faisant autorité et reçoit une réponse, il n'existe aucun mécanisme dans le DNS traditionnel pour vérifier que cette réponse est légitime. L'attaque par empoisonnement du cache décrite par Dan Kaminsky en 2008 — et ses variantes ultérieures — exploite exactement ceci : un attaquant injecte de faux enregistrements dans le cache d'un résolveur, redirigeant le trafic vers les adresses IP sous son contrôle à l'insu du propriétaire du domaine. Les utilisateurs interrogent le résolveur compromis, reçoivent une adresse IP malveillante avec une réponse apparemment normale et passent à autre chose. TLS ne résout pas ce problème à lui seul : si l'utilisateur a été redirigé vers un serveur disposant d'un certificat valide pour le domaine — obtenu par exemple via DV dans une autre autorité de certification — la chaîne HTTPS apparaît intacte même si la destination est frauduleuse.

DNSSEC résout le problème au niveau de la couche DNS, avant toute connexion TCP. Chaque réponse DNS contient des enregistrements RRSIG – des signatures cryptographiques générées avec la clé privée de la zone. Le résolveur qui prend en charge la validation DNSSEC vérifie la signature à l'aide de la clé publique publiée dans la zone (enregistrement DNSKEY) et vérifie que cette clé publique est légitime en vérifiant l'enregistrement DS dans la zone parent — la chaîne de confiance descend de la racine, passe par la zone TLD (.com, .com.br) et arrive dans votre zone. Un enregistrement avec une signature invalide ou manquante, dans une zone qui déclare le support DNSSEC, entraîne SERVFAIL : le résolveur refuse la réponse plutôt que de transmettre des données potentiellement falsifiées.

Ce que DNSSEC ne couvre pas

DNSSEC ne chiffre pas les requêtes DNS. Un observateur sur le réseau peut toujours voir quels domaines vous interrogez – pour cela, il existe DNS sur HTTPS (DoH) et DNS sur TLS (DoT), des protocoles distincts qui cryptent le transport. DNSSEC ne protège pas non plus le contenu de votre service, n'atténue pas les DDoS contre vos serveurs faisant autorité et n'empêche pas le typosquatting ou le phishing sur des domaines qui ressemblent simplement au vôtre. La garantie est étroite et spécifique : les réponses DNS de votre zone, lorsqu'elles sont correctement signées, arrivent au résolveur sans altération.

Activation sur Cloudflare

Le processus technique dans Cloudflare est simple : un bouton sur le panneau DNS de la zone génère la paire de clés, commence à signer tous les enregistrements de la zone et commence automatiquement à servir les enregistrements RRSIG. La fonctionnalité est disponible sur tous les forfaits, y compris le forfait gratuit. Ce que vous faites ensuite est ce qui détermine si DNSSEC fonctionnera ou interrompra la production.

Après activation dans le tableau de bord, Cloudflare affiche l'enregistrement DS que vous devez enregistrer auprès de votre registraire. Cet enregistrement DS, publié dans la zone TLD par le registraire, est le lien qui relie la confiance du TLD à votre zone. Sans lui, la chaîne de confiance est incomplète et les résolveurs validés par DNSSEC traitent votre zone comme non signée et non invalide. Le processus d'enregistrement DS varie selon le registraire : certains disposent d'une interface graphique sur le panneau de commande, d'autres nécessitent que vous saisissiez manuellement les champs : Key Tag, Algorithm, Digest Type et Digest. Cloudflare affiche toutes ces valeurs formatées après avoir activé DNSSEC.

Le problème de rotation des clés

Le risque opérationnel du DNSSEC ne réside pas dans l'activation, mais dans la maintenance. Cloudflare alterne périodiquement les clés DNSSEC de la zone. Lorsque cela se produit, l'enregistrement DS enregistré auprès du registraire doit être mis à jour pour refléter la nouvelle clé. Si le bureau d'enregistrement prend en charge la mise à jour automatique de DS via l'API — comme c'est le cas avec Cloudflare Registrar, Amazon Route 53 en mode domaine enregistré et Namecheap avec API activée — la rotation s'effectue sans intervention manuelle. Si le registraire ne le prend pas en charge, Cloudflare vous envoie une alerte et vous disposez d'un délai pour mettre à jour manuellement.

Manquer cette fenêtre a une conséquence directe : le DS dans le registre pointe vers une clé que la zone n'utilise plus. Les résolveurs validés DNSSEC commencent à recevoir RRSIG signé par une clé différente de celle du DS publié, concluent qu'une falsification a eu lieu et renvoient SERVFAIL pour toute requête adressée à votre domaine. Du point de vue de l'utilisateur, le domaine cesse tout simplement de se résoudre. Le correctif nécessite de mettre à jour le DS dans le registraire et d'attendre que le TTL de la zone TLD se propage — ce qui est souvent long, de l'ordre de plusieurs heures, car vous ne contrôlez pas ce TTL.

Activer en toute sécurité : ce qu'il faut vérifier avant et après

Avant d'activer DNSSEC, confirmez que votre registraire accepte les enregistrements DS pour le domaine en question. Pour .com.br domaines, Registro.br prend désormais en charge DNSSEC, mais la prise en charge historique a été incohérente : il vaut la peine de vérifier directement dans le tableau de bord si l'option DS est disponible pour votre domaine spécifique avant de l'activer sur Cloudflare. L'activation de Cloudflare sans pouvoir enregistrer le DS auprès du registraire laisse la zone signée mais sans la chaîne de confiance complète, ce qui n'offre aucune protection supplémentaire et crée également un état qui peut générer de la confusion dans les diagnostics futurs.

Après avoir activé et enregistré le DS, testez la validation avec des outils tels que dnssec-analyzer.verisignlabs.com ou dnsviz.net avant de considérer le processus comme terminé. Ces outils affichent chaque maillon de la chaîne de confiance et identifient les enregistrements RRSIG invalides, expirés ou manquants. Configurez des alertes pour la rotation des clés (le tableau de bord de Cloudflare propose des notifications par e-mail) et documentez le processus de mise à jour DS dans votre runbook d'opérations DNS. Une rotation mal gérée à trois heures du matin, avec le domaine principal de l'entreprise renvoyant SERVFAIL, est le type d'incident qui devrait figurer dans le runbook avant qu'il ne se produise, pas après.