DNSSEC expliqué : comment authentifier les réponses DNS

Les extensions de sécurité DNS, ou DNSSEC, ajoutent une authentification cryptographique aux données DNS. Elles aident un résolveur validant à vérifier qu'une réponse provient bien de la zone attendue et n'a pas été altérée en transit. DNSSEC ne chiffre pas les requêtes DNS, ne masque pas le domaine demandé et ne rend pas un site web sûr à utiliser. Il fournit une chaîne de signatures et de clés qui permet à un résolveur de valider les données signées en remontant jusqu'à une racine de confiance. Lorsque la chaîne est correctement configurée, le résolveur dispose d'une preuve plus solide que la réponse est authentique ; lorsqu'elle est rompue, la validation peut faire échouer des résolutions par ailleurs ordinaires.

Les enregistrements d'une chaîne DNSSEC

Une zone signée publie des enregistrements DNSKEY contenant les clés publiques servant à valider les signatures. Les enregistrements RRSIG portent les signatures des ensembles d'enregistrements, et les enregistrements DS de la zone parente relient la clé d'une zone enfant à la chaîne de confiance du parent. Les données NSEC ou NSEC3 permettent de prouver de façon authentifiée qu'un nom ou un enregistrement n'existe pas. Les exploitants s'en remettent généralement à leur fournisseur DNS ou à leur registraire pour créer et maintenir ces valeurs, mais les responsabilités peuvent être partagées : la zone enfant est signée par l'hébergeur DNS, tandis que l'enregistrement DS du parent est publié via le registraire. Un désaccord entre les deux est une cause fréquente de problèmes de validation.

Un résolveur validant suit la chaîne de confiance à partir d'une ancre de confiance configurée, généralement la racine, en passant par les zones parentes et enfants. Il vérifie que les signatures sont valides et que les enregistrements correspondent aux clés et aux données de délégation. Les utilisateurs ordinaires ne voient peut-être jamais ces étapes, mais l'effet se lit dans le résultat : une réponse signée valide est acceptée, tandis qu'une chaîne de signatures rompue peut provoquer un SERVFAIL. Un résolveur non validant peut renvoyer une valeur qu'un résolveur validant rejette, ce qui explique pourquoi les échecs DNSSEC peuvent sembler propres à un réseau. Comparer les résolveurs et vérifier l'état de la validation est plus instructif que de supposer que le nom d'hôte n'a simplement aucun enregistrement.

Comment surviennent les échecs DNSSEC

Les cas d'échec courants comprennent : laisser un enregistrement DS obsolète chez le registraire après un changement de fournisseur DNS, publier des clés qui ne correspondent pas à la zone signée, laisser expirer les signatures parce que la signature s'est arrêtée, ou modifier la délégation sans coordonner le parent et l'enfant. Un déploiement DNSSEC ou un renouvellement de clé doit suivre la procédure documentée du fournisseur et être vérifié depuis un résolveur validant indépendant. Si DNSSEC est désactivé, des données DS périmées peuvent être plus nuisibles que l'absence d'enregistrement DS, car les validateurs peuvent continuer d'attendre une chaîne que l'enfant ne fournit plus. Considérez le registraire et l'hébergeur DNS comme les deux maillons d'un même processus.

• Demandez si le fournisseur DNS signe la zone et gère la rotation des clés.
• Vérifiez que la valeur DS chez le registraire correspond aux instructions actuelles du fournisseur.
• Testez via un résolveur validant après avoir activé, désactivé ou migré DNSSEC.
• Planifiez soigneusement les changements de clés et conservez une voie de retour arrière.
• Ne confondez pas l'authentification DNSSEC avec le transport DNS chiffré.

Diagnostiquer un échec de validation

Si un domaine renvoie SERVFAIL depuis des résolveurs validants, vérifiez la chaîne DNSSEC avant de modifier des enregistrements A ou MX sans rapport. Confirmez les DNSKEY et les signatures de la zone faisant autorité, puis comparez avec le DS publié par le parent. Examinez les périodes de validité des signatures et les changements récents chez le fournisseur. Une recherche générique de domaine vers IP peut vous dire que la résolution a échoué, mais n'expliquera pas forcément quel maillon DNSSEC est cassé ; pour cette question plus fine, utilisez un outil de diagnostic compatible DNSSEC. Conservez une note d'incident indiquant le résolveur, le résultat de la validation et l'heure de la requête, afin que le fournisseur puisse enquêter sur un cas reproductible.

DNSSEC renforce l'authenticité des données, mais la rigueur opérationnelle reste essentielle. Il ne peut pas empêcher la compromission du compte d'un propriétaire de domaine ni corriger un enregistrement erroné : il authentifie les données publiées selon les clés configurées. Pour le contexte de base, voyez la résolution DNS expliquée et les types d'enregistrement DNS. Activez DNSSEC lorsque vous pouvez maintenir la chaîne et la surveiller lors des renouvellements et des migrations, plutôt que de le traiter comme un interrupteur à activer une fois pour toutes dont on présumerait la justesse indéfiniment.

Traiter les renouvellements de clés comme des changements coordonnés

Un renouvellement de clé DNSSEC modifie le matériel cryptographique dont dépendent les résolveurs validants. La séquence sûre exacte dépend du fournisseur de signature et du caractère géré ou manuel du renouvellement. Suivez le processus documenté afin que les anciennes et nouvelles clés se chevauchent comme il convient, que les signatures restent valides et que les données DS du parent correspondent aux clés publiées à la bonne étape. Ne copiez pas une valeur DS depuis une capture d'écran périmée d'un tableau de bord et ne la supprimez pas simplement parce qu'une recherche sans rapport a expiré. Après un renouvellement, vérifiez avec plusieurs résolveurs validant DNSSEC et conservez les journaux d'événements du fournisseur. Si la validation échoue, relevez le domaine, le résolveur, le code de réponse et l'heure, puis contrôlez les signatures et le lien avec le DS avant de toucher aux enregistrements applicatifs. Un renouvellement maîtrisé et surveillé est bien plus sûr qu'une tentative d'urgence pour réparer la chaîne une fois que les navigateurs et les systèmes de messagerie commencent à échouer.