DNSSEC et SERVFAIL après un changement de serveurs de noms : diagnostic et migration sans risque

Une migration de serveurs de noms peut sembler réussie dans tous les panneaux de configuration et rendre pourtant un site inaccessible. Le domaine est actif, ses nouveaux serveurs DNS faisant autorité renvoient l’adresse attendue et rien n’a changé sur le serveur web. Pourtant, les résolveurs DNS qui effectuent la validation DNSSEC répondent SERVFAIL. Il manque souvent un élément : la délégation DNSSEC continue de faire confiance à la clé de signature de l’ancien opérateur DNS.

Dans l’incident étudié ici, les requêtes DNS ordinaires échouaient, alors que les mêmes requêtes aboutissaient lorsque la validation DNSSEC était contournée. La zone parente publiait toujours un ancien enregistrement DS, tandis que la nouvelle zone faisant autorité n’était pas signée au départ. La publication d’une clé correspondante et la signature de la nouvelle zone ont rétabli les réponses validées sur les résolveurs testés. La leçon n’est pas qu’il faut désactiver DNSSEC, mais que le changement de serveurs de noms et la migration de la chaîne de confiance DNSSEC sont deux opérations distinctes.

Pourquoi des enregistrements A corrects peuvent tout de même provoquer SERVFAIL

Le DNS répond à deux questions différentes. Un enregistrement A indique l’adresse IPv4 associée à un nom. DNSSEC permet à un résolveur validant de déterminer si la réponse est digne de confiance. Des données d’adressage correctes ne garantissent pas, à elles seules, une chaîne de confiance DNSSEC valide.

Pour un domaine signé, cette chaîne part d’une zone parente de confiance, passe par un enregistrement DS (Delegation Signer) et aboutit à une clé DNSKEY dans la zone enfant. Celle-ci publie des signatures (enregistrements RRSIG) couvrant ses données DNS. L’enregistrement DS contient une empreinte permettant d’identifier une DNSKEY autorisée : ce n’est ni un enregistrement A, ni une copie de la clé privée, ni un paramètre d’un éditeur de fichier de zone classique.

Après un changement de serveurs DNS faisant autorité, la zone parente peut continuer de publier un enregistrement DS lié à l’ancien signataire. Si la nouvelle zone ne dispose pas de la DNSKEY correspondante ni des signatures nécessaires, un résolveur validant ne peut pas reconstituer la chaîne de confiance. Il considère normalement la réponse comme invalide et renvoie SERVFAIL plutôt qu’une adresse non vérifiée.

Il ne s’agit pas d’une panne HTTP : la requête peut ne jamais atteindre le serveur web. Ce n’est pas non plus la même chose qu’un certificat TLS expiré. DNSSEC valide les données DNS, tandis que HTTPS sécurise la connexion qui s’établit ensuite entre le navigateur et le serveur.

Le diagnostic qui distingue une erreur DNSSEC d’un enregistrement manquant

Le test le plus révélateur consiste à interroger deux fois le même nom via le même résolveur. Commencez par une requête ordinaire et examinez le statut, pas seulement la réponse :

dig example.com A +noall +comments +answer

Répétez ensuite la requête en activant le bit CD (Checking Disabled, désactivation du contrôle DNSSEC) :

dig example.com A +cdflag +noall +comments +answer

Dans l’incident observé, la requête ordinaire renvoyait SERVFAIL, tandis que la requête avec CD renvoyait l’enregistrement A attendu. Ce contraste désignait fortement la validation DNSSEC comme cause probable, plutôt qu’un enregistrement DNS manquant ou une application qui ne répondait pas. L’option +cdflag demande à un résolveur récursif compatible de ne pas effectuer sa validation DNSSEC habituelle pour cette requête. C’est un outil de diagnostic, pas une correction côté navigateur ni un moyen de désactiver DNSSEC pour les visiteurs.

Ne tirez pas de conclusions hâtives d’une réponse vide avec +short. L’absence de réponse et un statut SERVFAIL peuvent tous deux apparaître comme une sortie vide avec ce format. Conservez +comments pendant le diagnostic afin de voir les statuts status: SERVFAIL et status: NOERROR.

La comparaison avec CD ne permet pas, à elle seule, d’identifier l’élément DNSSEC défaillant : elle indique où poursuivre l’enquête. Un résolveur peut aussi subir un incident transitoire en amont. Répétez donc le test si nécessaire et examinez la délégation dans la zone parente.

Examiner l’enregistrement DS de la zone parente, pas seulement l’éditeur DNS

Recherchez les enregistrements DS du domaine :

dig example.com DS +noall +comments +answer

Pour voir plus précisément le chemin de délégation, interrogez directement la hiérarchie DNS :

dig +trace example.com DS

Le serveur faisant autorité pour la zone parente dépend du domaine de premier niveau. Ce qui compte, c’est l’ensemble d’enregistrements DS (RRset) publié par cette zone parente, et non simplement le résumé affiché dans le tableau de bord de l’hébergeur DNS. Un transfert de domaine vers un autre bureau d’enregistrement peut se faire sans changer les serveurs de noms ; inversement, on peut changer les serveurs de noms sans changer de bureau d’enregistrement. Dans les deux cas, les DS de la zone parente doivent rester cohérents avec la zone faisant autorité effectivement utilisée.

Un enregistrement DS comporte quatre champs importants : l’identifiant de clé (key tag), l’algorithme, le type d’empreinte et l’empreinte elle-même. L’identifiant de clé est un repère pratique pour le diagnostic, mais il ne prouve pas à lui seul qu’une DNSKEY correspond. L’empreinte et les informations d’algorithme doivent également correspondre à une clé réellement fournie par la zone faisant autorité.

Dans ce cas, le constat décisif était simple : la zone parente continuait de publier les anciennes informations de confiance DNSSEC, tandis que la nouvelle zone faisant autorité indiquait que la signature était désactivée. Les enregistrements A étaient présents et pouvaient être obtenus en contournant la validation. Modifier la configuration de l’application ou retoucher sans cesse le même enregistrement A n’aurait pas corrigé cette incohérence.

Deux façons de rétablir une délégation DNSSEC défaillante

Deux stratégies de rétablissement sont légitimes. Elles corrigent la même incohérence dans la chaîne de confiance, mais leurs conséquences opérationnelles diffèrent. Choisissez-en une délibérément, sans passer de l’une à l’autre au hasard.

Option 1 : supprimer l’ancien DS et laisser temporairement la zone non signée

Demandez au bureau d’enregistrement actuel de supprimer, via son assistance ou son interface de gestion DNSSEC, l’enregistrement DS obsolète de la zone parente. Lorsque celle-ci n’affirme plus que la délégation est sécurisée, les résolveurs validants peuvent considérer une zone enfant non signée comme non sécurisée, plutôt que comme invalide. Le DNS continue de fonctionner, mais l’authentification DNSSEC du domaine est temporairement absente.

C’est souvent l’option d’urgence la plus simple, à condition de disposer d’un moyen fiable de modifier l’ensemble des DS de la zone parente. Gardez la configuration de signature existante inchangée jusqu’à l’expiration des anciens DS présents dans les caches des résolveurs récursifs. La suppression d’un DS dans un panneau de configuration ne constitue pas une preuve suffisante : vérifiez l’enregistrement de la zone parente depuis l’extérieur et tenez compte de son TTL. HTTPS reste indépendant de la configuration DNSSEC. Cette transition temporaire vers une zone non signée est également décrite dans la RFC 8078.

Option 2 : signer la nouvelle zone et publier un DS correspondant

L’autre solution consiste à activer DNSSEC chez le nouvel opérateur DNS faisant autorité, à générer les clés DNSKEY, à signer la zone et à publier l’enregistrement DS correspondant dans la zone parente. Un résolveur validant peut alors établir une chaîne de confiance jusqu’à la nouvelle DNSKEY et valider l’enregistrement A.

C’est la méthode de rétablissement effectivement observée. L’interface de gestion DNS indiquait avoir généré les clés, signé la zone et publié un nouveau DS. Une interrogation ultérieure de la zone parente affichait ce nouveau DS aux côtés de l’ancien. Les requêtes récursives avec validation ont recommencé à renvoyer l’enregistrement A attendu ; un test ultérieur a aussi renvoyé NOERROR avec le drapeau ad, signalant des données authentifiées par ce résolveur.

L’ordre des opérations est déterminant : un DS publié n’est utile que si la DNSKEY correspondante et des signatures valides sont déjà disponibles sur le service DNS faisant autorité. La mention « publié » dans un panneau de configuration ne remplace pas une vérification externe. Les enregistrements DS, DNSKEY, RRSIG et NS en cache peuvent entraîner des délais de rétablissement différents selon les résolveurs.

Pourquoi deux enregistrements DS n’empêchaient pas nécessairement le site de fonctionner

Un résultat surprenant : la zone parente contenait temporairement à la fois un DS obsolète et un nouveau DS valide, mais la validation DNSSEC réussissait. Il n’y a là aucune contradiction. Un ensemble d’enregistrements DS peut comporter plusieurs entrées, comme c’est souvent le cas lors d’une transition de clés. Un validateur n’exige pas que chaque DS désigne une clé encore utilisable ; il lui suffit d’une chaîne d’authentification valide passant par un DS applicable, une DNSKEY et des signatures valides. La RFC 6840 précise que les validateurs devraient accepter une seule chaîne valide.

Cela ne signifie pas qu’il soit souhaitable de conserver indéfiniment d’anciens DS. Un DS obsolète accroît l’ambiguïté opérationnelle et devrait, à terme, être supprimé une fois la nouvelle chaîne vérifiée. Mais ce nettoyage relève de la maintenance : ce n’est pas une raison pour relancer une réinitialisation DNSSEC risquée alors que les requêtes validées fonctionnent déjà.

Attention à un piège particulièrement dangereux dans les panneaux de configuration : une action intitulée « emergency unpublish DS » peut supprimer tous les enregistrements DS, y compris le nouveau qui fonctionne. De même, désactiver la signature de la zone alors qu’un DS reste publié peut recréer immédiatement la panne. Aucune de ces actions n’équivaut à supprimer un seul DS obsolète. Si l’interface ne permet pas de cibler un enregistrement précis, demandez une modification sélective prise en charge par le bureau d’enregistrement plutôt qu’une réinitialisation générale.

Comment changer les serveurs DNS faisant autorité en toute sécurité

La séquence la plus sûre dépend de la possibilité, pour l’ancien et le nouvel opérateur DNS, de coordonner leurs clés. Pour une migration classique comportant une période temporaire sans signature, l’ordre suivant évite l’incohérence observée dans cet incident :

1. Préparez d’abord la zone de destination. Recopiez les enregistrements A, AAAA, CNAME, MX, TXT et les autres enregistrements nécessaires. Testez directement les nouveaux serveurs DNS faisant autorité avant de modifier la délégation.
2. Vérifiez DNSSEC dans la zone parente. Recherchez les éventuels DS et identifiez qui peut les modifier. Faites-le même si vous n’avez jamais activé DNSSEC manuellement : certains services DNS signent les zones automatiquement.
3. Supprimez l’ancien DS pendant que l’ancienne zone signée fonctionne encore. Confirmez la modification auprès de la zone parente faisant autorité, puis attendez suffisamment pour que les DS précédemment mis en cache expirent. Cette durée dépend des TTL observés et non d’un nombre fixe de minutes applicable partout.
4. Modifiez la délégation des serveurs de noms. Maintenez l’ancien service faisant autorité disponible tant que des délégations NS en cache peuvent encore y diriger les requêtes. Tenez compte des TTL des NS de la zone parente et vérifiez quels serveurs les différents résolveurs interrogent réellement.
5. Décidez s’il faut réactiver DNSSEC. Si le nouveau service doit rester non signé, ne publiez pas de DS. S’il doit être signé, assurez-vous que la nouvelle DNSKEY et ses signatures sont correctement servies avant de publier le DS correspondant. Coordonnez cette étape avec les caches qui utilisent encore les anciens serveurs NS afin d’éviter une nouvelle incohérence de validation.
6. Effectuez une validation indépendante. Vérifiez les DS de la zone parente, la DNSKEY faisant autorité, la résolution récursive ordinaire et le résultat d’authentification fourni par des résolveurs validants.

Si la protection DNSSEC doit rester continue, mieux vaut un roulement de clés explicitement coordonné ou une transition multisignataire qu’une période sans signature. Cela exige que les deux opérateurs DNS prennent en charge les mécanismes de gestion des clés et de signature nécessaires ; recopier simplement l’empreinte de l’ancien DS chez le nouveau fournisseur ne constitue pas un roulement de clés.

Liste de vérification rapide après la migration

Après toute modification liée à DNSSEC, vérifiez aussi bien les enregistrements DNS que la capacité des résolveurs à en valider l’authenticité :

dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answer

Utilisez un résolveur récursif validant pour contrôler les réponses authentifiées. Dans sa réponse, NOERROR accompagné de l’enregistrement A attendu signifie que la résolution a réussi ; le drapeau ad indique en outre que ce résolveur a authentifié la réponse selon sa politique DNSSEC. L’absence du drapeau ad ne prouve pas, à elle seule, un échec : les capacités, les politiques et les indicateurs de requête varient selon les résolveurs. Si les requêtes DNSKEY échouent via un résolveur validant pendant une panne, interrogez aussi directement le service DNS faisant autorité actif dans le cadre du diagnostic.

Ne vous arrêtez pas à une réponse réussie d’un seul résolveur. Les caches peuvent temporairement conserver des délégations et des clés différentes. Mettez également à jour toute demande d’assistance opérationnelle encore ouverte : une ancienne instruction demandant la suppression de tous les DS devient dangereuse dès lors qu’un nouveau DS fonctionnel a été publié. Le suivi doit indiquer explicitement de conserver la clé active et, si nécessaire, de supprimer uniquement l’enregistrement obsolète.

La panne n’était pas due à une mauvaise adresse de serveur web. Elle résultait du déplacement du service DNS sans alignement préalable des informations de confiance indiquant aux résolveurs quelles réponses accepter. Avant chaque bascule de serveurs de noms, la question pratique à se poser est donc : quels enregistrements DS la zone parente publie-t-elle, et la DNSKEY ainsi que les signatures de la destination permettent-elles de les valider ?