DNSSEC pour les domaines e-commerce : activation, validation et rotation des clés

DNSSEC authentifie les données DNS sans rendre les requêtes confidentielles

DNSSEC authentifie l’origine et protège l’intégrité des réponses DNS signées. Un résolveur validant peut ainsi rejeter les données dont la signature ne correspond pas. DNSSEC ne chiffre toutefois pas les requêtes, ne masque pas les noms consultés et ne remplace ni TLS, ni la protection du compte du registrar, ni la sécurité des serveurs autoritaires.

Cette validation crée un risque opérationnel. Dès que la zone parente publie un enregistrement DS, les résolveurs validants attendent un chemin vérifiable jusqu’aux DNSKEY de la zone enfant. Un DS qui désigne une clé absente, des signatures expirées ou des données anciennes encore en cache pendant une rotation peuvent rendre la réponse non valide et provoquer un SERVFAIL. L’activation est une séquence contrôlée avec preuves et délais, pas un simple bouton.

Préparer l’inventaire, les responsabilités et la fenêtre de changement

Représenter la véritable chaîne de confiance

Documentez le registrar, le registre, l’opérateur DNS autoritaire, les responsables des comptes, les contacts d’urgence et la procédure d’ajout ou de retrait d’un DS. Relevez les nameservers, zones secondaires, sous-délégations, algorithmes, condensats, TTL des DS et DNSKEY, durée des signatures, fréquence de renouvellement et rotations automatiques. Si le registrar et l’opérateur DNS sont distincts, attribuez chaque transfert à une personne : un outil ne remplace pas une autorisation absente pendant l’incident.

Conservez une référence des réponses DNSSEC et des requêtes directes à chaque serveur autoritaire. Désignez le responsable du changement, la personne autorisée à l’arrêter et les contacts du registrar et de l’opérateur. Le guide ICANN met l’accent sur la politique, les pratiques, les rôles et la supervision ; un document court doit garder des responsabilités explicites.

Signer la zone enfant avant de la relier au DS parent

Phase A : rendre la zone enfant complète

Activez la signature chez l’opérateur autoritaire tout en laissant le DS absent de la zone parente. Vérifiez que tous les nameservers servent le même ensemble DNSKEY, que les réponses comportent des RRSIG valides et que les réponses négatives sont signées. Comparez le tag de clé, l’algorithme et le condensat proposés pour le DS avec la DNSKEY réellement publiée.

À ce stade, le parent n’impose pas encore la validation de la zone. Une erreur se corrige avant de rendre la chaîne contraignante. Stabilisez la signature sur tous les nameservers et retestez les noms critiques. Ne réutilisez aucun ancien DS et ne le déduisez pas du seul identifiant de clé. Utilisez la valeur produite pour la zone actuelle et confrontez-la aux enregistrements DNSKEY publiés.

Phase B : publier le DS dans la zone parente

Soumettez le DS via le registrar ou le processus du registre uniquement après la validation de la zone signée. Interrogez ensuite les serveurs autoritaires du parent pour confirmer le DS attendu, puis testez la chaîne complète. L’activation est terminée lorsque les réponses positives et négatives sont validées du parent à l’enfant, pas quand une interface affiche un statut vert.

Valider depuis plusieurs résolveurs et plusieurs chemins

Les requêtes directes aux serveurs autoritaires distinguent le contenu de zone du comportement des caches. Interrogez ensuite plusieurs résolveurs validants indépendants ainsi que ceux réellement utilisés par les bureaux, sondes synthétiques ou réseaux d’exploitation. Avec dig +dnssec, examinez DS, DNSKEY et RRSIG ; avec un validateur, localisez le maillon défaillant. Comparez les chemins IPv4 et IPv6 et, si plusieurs opérateurs autoritaires existent, chaque nameserver et région disponible.

• Parent : le DS prévu est présent sans valeur obsolète ni doublon imprévu.
• Enfant : toutes les DNSKEY nécessaires sont publiées et leur ensemble est signé.
• Signatures : des RRSIG valides couvrent les enregistrements existants et les réponses négatives.
• Résolveurs : la validation réussit sans SERVFAIL anormal.
• Parcours : storefront, connexion, checkout, API et callbacks passent les tests synthétiques.

Poursuivez l’observation pendant les TTL et fenêtres opérationnelles du parent et de l’enfant. N’érigez pas 24 ou 48 heures en règle universelle : la durée dépend des TTL, des caches déjà alimentés et du traitement par le registrar et le registre.

Effectuer la rotation avec chevauchement et critères de passage

Distinguer ZSK, KSK et automatisation du prestataire

La rotation d’une clé signant les enregistrements ordinaires reste interne si la référence de confiance du parent ne change pas. Une rotation modifiant la clé référencée par le parent exige également une coordination du DS. Les services gérés automatisent parfois une partie du travail, mais le propriétaire du domaine doit savoir qui publie les DNSKEY, renouvelle les signatures et gère le rollover. Documentez comment suspendre l’automatisation pendant une migration : deux systèmes autonomes peuvent invalider une séquence préparée.

Le modèle prudent consiste à prépublier la nouvelle clé, attendre sa visibilité là où elle est requise, commencer à l’utiliser, conserver l’ancienne pendant le chevauchement, puis la retirer après expiration des caches pertinents. Pour une KSK ou un modèle équivalent, publiez et validez le nouveau DS avant de supprimer l’ancien. La RFC 6781 décrit plusieurs méthodes, car le calendrier dépend des signatures, TTL et capacités des parties. Réduire les étapes pour tenir une fenêtre arbitraire supprime la marge de sécurité.

Migrer d’opérateur sans rompre la confiance

Une migration DNSSEC n’est pas un changement ordinaire de nameservers. L’ancien opérateur, le nouveau et le registrar doivent maintenir la confiance envers les deux ensembles de clés pendant la transition. La procédure Google s’appuie sur la publication croisée des DNSKEY et plusieurs DS, afin que les résolveurs acceptent les réponses des deux opérateurs pendant la modification des délégations. Elle nécessite l’importation de clés, plusieurs DS, le même algorithme chez les deux opérateurs et une rotation automatique suspendue ; ne changez pas d’algorithme pendant la migration.

Avant de changer les NS, vérifiez que les deux infrastructures servent la zone prévue, que le parent expose les deux DS planifiés et que les TTL du runbook sont écoulés. Après la bascule, gardez l’ancien opérateur disponible tant que ses délégations peuvent rester en cache. Retirez les anciennes clés et les anciens DS uniquement dans l’ordre documenté. Si les plateformes ne prennent pas en charge cette méthode, désactiver temporairement DNSSEC réduit explicitement la protection ; ce n’est pas un raccourci équivalent à une chaîne continue.

Retour arrière : retirer l’exigence parente avant de changer les NS

Si l’activation produit des SERVFAIL et que la zone signée ne peut pas être réparée rapidement, retirez le DS du parent, vérifiez son retrait sur les serveurs autoritaires et attendez l’expiration de son TTL avant de désactiver la signature ou de changer les serveurs de noms. Les instructions Cloudflare demandent de retirer le DS et d’attendre avant le changement de NS. Inverser l’ordre peut laisser des résolveurs attendre une preuve que la nouvelle zone ne fournit pas.

Pendant l’attente, les résolveurs peuvent observer des états différents. Maintenez la zone signée et les clés référencées, poursuivez les tests et communiquez à partir des mesures, non d’une estimation générique de propagation. Le runbook doit contenir les anciennes valeurs DS, les accès, les commandes, les procédures d’escalade et les critères permettant de corriger ou de retirer la confiance. Reliez ce scénario au plan de reprise, sans confondre retour DNSSEC et restauration de l’application ou des données commerciales.

Surveiller expiration, validation et impact commercial

Le tableau de bord doit relier l’état DNS au parcours client : jours avant expiration des signatures, cohérence DNSKEY entre nameservers, DS observé au parent, validation depuis plusieurs résolveurs, SERVFAIL, latence DNS, disponibilité du storefront et du checkout, succès des callbacks et anomalies par réseau ou zone. Chaque changement laisse une trace des anciennes et nouvelles valeurs, du responsable, des critères franchis et de la décision finale.

Une exploitation DNSSEC fiable associe une chaîne documentée, une signature préalable, un DS publié en dernier, une validation distribuée et des rotations avec chevauchement. Découvrez nos services pour domaines e-commerce et infrastructure afin d’aligner le registrar, le DNS autoritaire, la supervision et le runbook. Pour préparer une activation ou revoir une rotation proche, contactez AE Digital Agency pour une vérification opérationnelle avant le changement.