L’audit de sécurité commandité par le client, dans le cadre d’une certification imposée à son secteur d’activité, listait DNSSEC parmi les points à corriger sous trente jours. Le développeur en charge du site WordPress n’avait, jusque-là, jamais eu à toucher à ce mécanisme : DNSSEC ne concerne pas la sécurisation du site lui-même, mais celle de la résolution de son nom de domaine, une couche entièrement différente et rarement manipulée au quotidien.
DNSSEC (Domain Name System Security Extensions) ajoute une signature cryptographique à chaque réponse DNS, permettant à un résolveur de vérifier qu’elle n’a pas été falsifiée en chemin, par exemple lors d’une attaque de type empoisonnement de cache DNS. Le principe est solide, mais son activation comporte un piège bien connu : mal la configurer peut rendre un domaine entièrement injoignable, un risque suffisamment sérieux pour mériter une procédure précise plutôt qu’une case cochée à la va-vite.
Comprendre la chaîne de confiance avant d’y toucher
DNSSEC repose sur une chaîne de signatures qui remonte jusqu’à la racine du DNS. Concrètement, la zone DNS du domaine est signée avec une paire de clés, et un enregistrement appelé DS (Delegation Signer) est ensuite publié chez le registrar du domaine, qui le transmet au registre de l’extension (.fr, .com, etc.). C’est cet enregistrement DS qui referme la chaîne de confiance : sans lui, la signature de la zone existe mais personne ne peut la valider, et selon la configuration du résolveur, la résolution peut soit ignorer DNSSEC (dégradation silencieuse), soit être purement et simplement rejetée si le résolveur impose une validation stricte.
Étape par étape : signer la zone puis publier le DS
L’ordre des opérations est ce qui fait la différence entre une activation sans incident et une coupure de plusieurs heures :
- Activer la signature DNSSEC côté hébergeur de la zone DNS (le registrar lui-même, ou un service DNS tiers comme Cloudflare) : cette étape génère les clés et commence à signer chaque enregistrement de la zone, sans encore rien publier vers le registre.
- Vérifier que la signature est effective et cohérente avant de publier le DS, avec un outil de contrôle externe :
dig +dnssec exemple.fr delv exemple.fr - Une fois la signature confirmée stable, publier l’enregistrement DS correspondant dans l’interface du registrar, qui le transmet au registre de l’extension.
- Attendre la propagation complète avant de considérer l’opération terminée, en tenant compte du TTL des enregistrements DNSKEY et DS.
Publier le DS avant que la signature de zone ne soit stable et correctement propagée est l’erreur la plus fréquente : le registre affirme alors qu’un DS existe pour ce domaine, mais les signatures qu’il est censé valider ne correspondent pas encore, ou pas correctement, ce qui casse la résolution pour tout résolveur validant strictement DNSSEC (Google Public DNS et Cloudflare 1.1.1.1 valident tous les deux par défaut).
Le piège du rollover de clé
Un autre moment sensible survient bien après l’activation initiale : le renouvellement périodique des clés de signature, appelé rollover. Si l’ancienne clé est retirée avant que le nouveau DS ne soit propagé et pris en compte par tous les résolveurs en cache, une fenêtre d’incohérence apparaît, pendant laquelle certains résolveurs valident encore avec l’ancienne clé pendant que la zone signe déjà avec la nouvelle.
- Toujours publier le nouveau DS avant de retirer l’ancienne clé de signature, jamais l’inverse.
- Respecter un délai de chevauchement au moins égal au TTL le plus long de la zone avant tout retrait de clé.
- Surveiller la résolution du domaine depuis plusieurs résolveurs publics distincts (Google, Cloudflare, OpenDNS) pendant toute la fenêtre de rollover, pas seulement depuis son propre poste.
Ce que DNSSEC ne couvre pas
DNSSEC garantit l’intégrité et l’authenticité des réponses DNS : il empêche un attaquant de falsifier une résolution DNS pour rediriger le trafic vers un serveur pirate. Il ne chiffre rien : les requêtes DNS restent lisibles en clair sur le réseau (ce rôle revient à des mécanismes distincts comme DNS over HTTPS). Il ne sécurise pas non plus le site WordPress lui-même : un domaine parfaitement signé en DNSSEC peut tout à fait héberger un site vulnérable si les correctifs de sécurité applicatifs ne sont pas suivis par ailleurs.
DNSSEC est une case d’audit qui se coche une fois, proprement, puis s’oublie presque : sa seule vraie exigence récurrente est la vigilance au moment des rollovers de clés, un rendez-vous qu’il ne faut jamais rater.
En résumé
Activer DNSSEC sur un domaine WordPress est une opération sûre à condition de respecter l’ordre des étapes : signer la zone, vérifier, puis seulement publier le DS chez le registrar. La rigueur s’applique aussi longtemps après l’activation initiale, à chaque rollover de clé. Ce chantier reste distinct de la sécurisation du site lui-même, qui continue de se jouer sur d’autres fronts : mises à jour, permissions de fichiers, authentification.
