Pourquoi une erreur de DS est une panne, pas un défaut
DNSSEC fait confiance en chaîne : la zone parente (par exemple celle de l'extension) publie un enregistrement DS, empreinte de la clé de signature de la zone du client, et les résolveurs validants comparent cette empreinte aux clés réellement publiées par la zone. Si l'empreinte ne correspond plus à aucune clé, le résolveur ne peut pas prouver que les réponses sont authentiques et il refuse de répondre : le client reçoit un SERVFAIL.
C'est ce qui rend l'erreur traître. Le domaine continue de répondre chez un résolveur qui ne valide pas, donc un test rapide depuis un poste ou un réseau d'entreprise peut sembler correct, pendant que les utilisateurs derrière un résolveur public validant ne résolvent plus rien. Un DS orphelin n'abaisse pas la sécurité : il coupe le domaine. Le reste du guide sert à ne jamais en fabriquer un, et à savoir en sortir.
Qui fait quoi : opérateur DNS, registrar, registre
Trois acteurs interviennent, et la confusion entre eux cause la plupart des incidents. L'opérateur DNS héberge la zone et détient les clés : c'est lui qui signe et qui publie les DNSKEY et les signatures RRSIG. Le registrar est l'interface commerciale où le titulaire gère son nom, et il transmet au registre l'enregistrement DS. Le registre tient la zone parente et publie le DS.
Le DS ne se crée donc jamais côté registrar seul : il copie une information produite par l'opérateur DNS. Si le domaine est chez un registrar mais que ses serveurs de noms pointent vers un autre opérateur, la signature se demande à l'opérateur DNS, et le DS se saisit chez le registrar. La définition générale de DNSSEC et son rôle contre l'empoisonnement de cache sont supposés connus ici ; l'article sur le changement de clé racine du 11 octobre 2026, côté résolveur, traite l'autre extrémité de la chaîne.
Activer DNSSEC dans le bon ordre
Vérifier que l'extension et le registrar acceptent le DS
Avant de toucher à la zone, confirmez que le registrar propose un champ DS pour cette extension et que le registre accepte l'algorithme prévu. Tous les registres n'acceptent pas tous les algorithmes : la liste de l'extension fait foi, pas celle de l'opérateur DNS. Certaines extensions n'offrent pas DNSSEC du tout, par règle du registre.
Écrire le plan de retour arrière avant de commencer
Notez l'état actuel : serveurs de noms, TTL de la zone, absence de DS. Relevez-le avec
dig NS votre-domaine.com +shortetdig DS votre-domaine.com +short. Écrivez aussi qui peut supprimer le DS chez le registrar, et par quel canal, en cas de problème. Un retour arrière qui dépend d'une personne injoignable n'en est pas un.Signer la zone chez l'opérateur DNS
Activez la signature dans l'interface de l'opérateur, ou avec ses outils si vous gérez vous-même le serveur. L'opérateur génère la clé de signature de clé (KSK) et la clé de signature de zone (ZSK), puis publie les DNSKEY et les RRSIG. À ce stade, rien ne change pour les résolveurs : sans DS dans la zone parente, la zone est signée mais non validée, donc sans risque.
Attendre la propagation des DNSKEY et des signatures
Les résolveurs gardent en cache les anciennes réponses jusqu'à la fin de leur TTL. Attendez au moins le TTL le plus long de la zone avant de passer à la suite, et vérifiez que
dig +dnssec votre-domaine.com DNSKEYrenvoie bien les clés et leur signature depuis chacun des serveurs de noms.Relever les paramètres du DS
L'opérateur DNS fournit quatre valeurs : le key tag, l'algorithme, le type de digest et l'empreinte. Vérifiez qu'elles correspondent à la KSK publiée (le champ flags vaut 257) et choisissez le digest SHA-256, type 2. Copiez-les par copier-coller et non à la main : une erreur d'un caractère produit un DS orphelin.
Publier le DS chez le registrar
Saisissez les quatre valeurs dans le champ DS du registrar. Le registre publie ensuite le DS dans la zone parente, avec un délai propre à l'extension. Tant que ce délai n'est pas écoulé, certains résolveurs voient encore l'ancien état : ne conclure qu'après vérification.
Vérifier la chaîne de bout en bout
Interrogez le serveur du parent, puis un résolveur validant, puis
delv, comme détaillé dans la section suivante. Gardez le plan de retour arrière ouvert jusqu'à ce que les trois contrôles soient bons depuis au moins deux résolveurs publics validants différents.
Algorithmes et digests : ce que la RFC 8624 impose
Faites défiler le tableau
| Paramètre | Valeur | Statut dans la RFC 8624 |
|---|---|---|
| Signature ECDSAP256SHA256 | 13 | MUST, choix courant |
| Signature RSASHA256 | 8 | MUST |
| Signature ED25519 | 15 | RECOMMENDED |
| Signature ED448 et ECDSAP384SHA384 | 16 et 14 | MAY |
| Signatures RSASHA1 et variantes | 5, 7 et 10 | NOT RECOMMENDED |
| Digest du DS : SHA-256 | 2 | MUST |
| Digest du DS : SHA-1 et GOST | 1 et 3 | MUST NOT pour la délégation |
Vérifier avec dig et delv, sorties à l'appui
Quatre contrôles suffisent. Le premier, dig +dnssec votre-domaine.com DNSKEY, doit renvoyer deux DNSKEY avec les flags 256 (ZSK) et 257 (KSK) et un RRSIG. Le deuxième, dig DS votre-domaine.com @<serveur du parent>, interroge directement la zone parente et doit renvoyer une ligne de la forme <key tag> <algorithme> <type de digest> <empreinte>, par exemple 2371 13 2 <empreinte> (valeurs illustratives) : le key tag doit être celui de la KSK publiée par l'opérateur.
Le troisième, dig +dnssec votre-domaine.com A @1.1.1.1, doit afficher le drapeau ad (authenticated data) dans la ligne flags, par exemple flags: qr rd ra ad. Le quatrième, delv votre-domaine.com A @1.1.1.1, doit afficher ; fully validated avant la réponse. Un échec ressemble à ceci : dig renvoie status: SERVFAIL, souvent avec EDE 9 DNSKEY Missing, et delv signale resolution failed.
Ce qui peut bloquer chez le registrar ou le registre
- Aucun champ DS — le registrar ne propose pas la saisie pour cette extension, ou seulement par ticket : demandez-le avant de signer la zone.
- Algorithme refusé — le registre n'accepte qu'une partie des algorithmes de la RFC 8624 ; lisez la liste de l'extension et non celle de l'opérateur DNS.
- Digest limité — certains formulaires n'acceptent que le SHA-256 ; c'est le bon choix, mais il faut le savoir avant de générer le DS.
- Délai de publication — la zone parente n'est pas mise à jour instantanément ; ce délai dépend de l'extension : ne testez pas trop tôt.
- Extension sans DNSSEC — certaines extensions n'offrent pas la fonction ; le domaine reste valide mais ne peut pas être signé.
- Validation manuelle — la demande passe par un ticket du registrar ou un contact, ce qui allonge le retour arrière : à intégrer au plan.
Changer d'hébergeur DNS sans laisser de DS orphelin
C'est le cas qui produit le plus de pannes. Le DS reste chez le registrar, tandis que les serveurs de noms changent : si le nouvel opérateur ne signe pas, ou signe avec d'autres clés, l'ancien DS ne correspond plus à rien et les résolveurs validants répondent SERVFAIL. Le même incident survient lors d'une migration de zone où l'ancien DS est conservé.
La RFC 6781 distingue deux cas, selon que l'ancien opérateur coopère ou non. S'il coopère, le nouvel opérateur et lui échangent leurs clés publiques et publient les deux jeux pendant la bascule, ce qui évite toute période non signée. S'il ne coopère pas, la RFC conclut que la seule opération viable est de laisser la zone passer à l'état non signé : retirer le DS, changer les serveurs de noms, puis réinsérer un DS pointant vers la zone nouvellement signée. Dans le doute, appliquez la version prudente ci-dessous, qui marche dans les deux cas.
Procédure prudente de changement d'hébergeur DNS
Préparer la zone chez le nouvel opérateur
Recréez tous les enregistrements, sans signer ni changer de serveurs de noms. Comparez les deux zones enregistrement par enregistrement, par exemple avec
dig @<ancien serveur> votre-domaine.com MX +shortpuisdig @<nouveau serveur> votre-domaine.com MX +short, et de même pour A et TXT.Relever le TTL du DS
Interrogez
dig DS votre-domaine.com @<serveur du parent>et notez le TTL affiché : c'est le temps pendant lequel les résolveurs peuvent encore croire à l'ancien DS.Supprimer le DS chez le registrar
Faites supprimer le DS, puis constatez sa disparition avec la même commande sur le serveur du parent. La zone devient non signée pour les résolveurs, ce qui est un état valide et sans panne.
Attendre l'expiration du TTL du DS
Patientez au moins la durée relevée avant de toucher aux serveurs de noms. Retirer les clés avant que le DS ait expiré des caches recrée exactement le DS orphelin que l'on cherche à éviter.
Changer les serveurs de noms
Modifiez les NS chez le registrar. Vérifiez la bascule avec
dig NS votre-domaine.com @<serveur du parent>puis testez la résolution depuis un résolveur validant. Le guide sur le changement de serveurs de noms détaille l'opération dans l'espace client.Signer chez le nouvel opérateur puis republier le DS
Activez la signature, attendez la propagation des DNSKEY, relevez les nouveaux paramètres et publiez le DS comme à l'activation initiale. Terminez par les quatre contrôles dig et delv.
Rollover de clés, CDS et CDNSKEY
Deux opérations de maintenance se ressemblent mais n'ont pas le même effet sur le registrar. Un rollover de ZSK ne demande aucune action chez le registrar, car le DS ne porte que sur la KSK. Un rollover de KSK impose un nouveau DS : la RFC 6781 décrit la double signature en quatre phases, avec une attente d'au moins le TTL du DS avant de retirer l'ancienne clé. Lors d'un changement d'algorithme, la même RFC demande de retirer d'abord le DS du parent, puis le DNSKEY et les signatures.
Pour éviter la saisie manuelle, la RFC 7344 définit les enregistrements CDS et CDNSKEY : l'opérateur DNS publie dans la zone le DS souhaité et l'agent du parent peut le consommer, après validation DNSSEC. La RFC 8078 y ajoute la suppression, par CDS 0 0 0 0 ou CDNSKEY 0 3 0 0. Reste que le registre ou le registrar décide de les consommer ou non, et que leur support dépend de l'extension. Le 13 octobre 2026, l'ICANN a ouvert une consultation publique sur l'évaluation de sécurité et de stabilité de l'automatisation des DS, ouverte jusqu'au 23 novembre 2026. L'annonce ne mentionne pas CDS ni CDNSKEY : l'automatisation n'est ni adoptée ni imminente à ce stade.
Symptômes, causes et remèdes
Faites défiler le tableau
| Symptôme | Cause probable | Remède |
|---|---|---|
| SERVFAIL chez 1.1.1.1 ou 8.8.8.8, réponse normale ailleurs | DS orphelin ou clé absente de la zone | Retirer le DS, attendre son TTL, republier un DS correct |
| `EDE: 9 (DNSKEY Missing)` dans la sortie de dig | Aucune DNSKEY ne correspond au DS | Comparer le key tag du DS à la KSK publiée |
| `delv` répond `resolution failed` | Chaîne de confiance rompue | Tester avec `dig +cd` pour confirmer que la zone répond sans validation |
| Pas de drapeau `ad` mais pas d'erreur | Résolveur non validant ou DS pas encore publié | Interroger un autre résolveur, attendre le délai du registre |
| Panne après changement de serveurs de noms | Nouvel opérateur non signé, ancien DS conservé | Suivre la procédure prudente, en commençant par retirer le DS |
| Signatures expirées | Signature automatique arrêtée chez l'opérateur | Relancer la signature, comparer les dates du RRSIG |
Le plan de retour arrière se rédige avant, pas pendant
Notez par écrit l'état de départ, la commande qui prouve chaque étape et la personne qui peut supprimer le DS en urgence. En cas de doute, la sortie la plus courte est toujours la même : supprimer le DS chez le registrar, puis attendre son TTL. La zone redevient non signée mais joignable, et l'on diagnostique ensuite sans pression avec dig +cd.
Ce que fait ServOrbit.com et ce qu'il ne fait pas
DNSSEC ne s'active pas en libre-service depuis l'espace client. Pour en faire la demande, ouvrez un ticket depuis votre espace client ou écrivez à [email protected]. La prise en charge dépend de l'extension et de son registre, notamment pour les domaines .ma. ServOrbit.com ne signe pas les zones à votre place et n'expose pas de champ DS dans l'espace client : ce guide décrit la méthode, pas une fonction automatique. Le DNS managé Cloudflare, présenté dans le guide d'activation correspondant, n'est mentionné ici que sur un point : changer de serveurs de noms sur un domaine déjà signé expose au DS orphelin. Pour ajouter ou modifier des enregistrements pendant la préparation, le guide sur les enregistrements DNS reste la référence, et celui sur le transfert sortant couvre le cas d'un changement de registrar. Guide fourni, pas de prise en charge.
La documentation officielle
RFC 6781, pratiques opérationnelles DNSSEC : https://www.rfc-editor.org/rfc/rfc6781.html
RFC 8624, algorithmes et digests : https://www.rfc-editor.org/rfc/rfc8624.html
RFC 7344, CDS et CDNSKEY : https://www.rfc-editor.org/rfc/rfc7344.html
RFC 8078, gestion du DS par l'enfant : https://www.rfc-editor.org/rfc/rfc8078.html
Consultation ICANN sur l'automatisation du DS : https://www.icann.org/en/announcements/details/icann-seeks-input-on-security-stability-assessment-of-dnssec-ds-automation-13-10-2026-en
Changement de KSK de la racine : https://www.icann.org/resources/pages/ksk-rollover-en
