DNSSEC en Afrique : signer les ccTLD ne suffit pas, il faut sécuriser toute la chaîne de confiance

La progression de DNSSEC dans les extensions nationales africaines est réelle et doit être saluée. Mais un ccTLD signé ne protège pas automatiquement les domaines enregistrés sous cette extension. Entre la racine du DNS et l’utilisateur final subsistent plusieurs maillons décisifs : registres, registrars, titulaires, hébergeurs DNS, résolveurs et procédures opérationnelles.

Au 25 février 2026, 32 des 54 extensions nationales africaines étaient actives avec DNSSEC. Vingt-deux restaient encore à signer, contre seulement deux ccTLD actifs en 2010.

Cette progression traduit des années de formation, d’assistance technique et de coopération entre registres, organisations techniques et institutions.

La Coalition pour une Afrique numérique accompagne plusieurs ccTLD, organise des ateliers pratiques et suit les 54 extensions nationales du continent. Son programme prévoit également des formations et des « déployathons » dans au moins vingt autres pays africains sur une période de trois ans.

Mais la prochaine étape exige une lecture plus rigoureuse.

Une extension peut être signée. Une chaîne de confiance peut exister entre la racine et le ccTLD. Et pourtant, l’immense majorité des entreprises, administrations et citoyens utilisant cette extension peuvent ne bénéficier d’aucune validation DNSSEC pour leur propre nom de domaine.

Le vrai sujet n’est donc plus seulement : « Le ccTLD est-il signé ? »

Il devient :

« Jusqu’où la confiance cryptographique descend-elle réellement, et combien d’utilisateurs la vérifient ? »

Signer une extension nationale est un acte d’infrastructure. Sécuriser les domaines qui en dépendent est un acte d’écosystème.

Pourquoi DNSSEC revient au cœur de la sécurité Internet africaine

Le DNS permet à un utilisateur, une application ou un service de trouver la ressource associée à un nom : site web, messagerie, API, plateforme publique ou infrastructure bancaire.

Le problème historique du DNS est simple : il n’a pas été conçu, à l’origine, pour permettre au destinataire de vérifier cryptographiquement qu’une réponse reçue est authentique et n’a pas été modifiée.

DNSSEC ajoute cette capacité grâce à des signatures numériques.

Il permet de vérifier l’origine des données, leur intégrité et la continuité de la confiance jusqu’à l’ancre de la racine. Il répond ainsi aux risques de falsification des réponses et d’empoisonnement de cache pouvant rediriger un utilisateur vers une destination malveillante.

Mais il faut également comprendre ce que DNSSEC ne fait pas.

DNSSEC ne chiffre pas les requêtes. Il ne rend pas un serveur disponible face à une attaque par déni de service. Il ne protège pas un compte registrar mal sécurisé. Il ne remplace ni TLS, ni la protection des messageries, ni la surveillance des changements DNS, ni les procédures de récupération d’un domaine.

DNSSEC constitue une brique de confiance. Pas une sécurité complète à lui seul.

Ce que signifie réellement « signer un ccTLD »

Le tableau de bord de la Coalition distingue trois situations :

• DNSSEC actif : la zone du ccTLD publie ses clés DNSKEY et un enregistrement DS est présent dans la racine,
• signé mais non actif : les clés existent dans la zone, mais aucun DS ne relie encore l’extension à la racine,
• non signé : aucune chaîne DNSSEC n’est déployée.

Cette distinction est fondamentale.

Publier des signatures dans une zone ne suffit pas. Pour que les résolveurs puissent remonter la chaîne de confiance, la zone parente doit publier l’empreinte cryptographique correspondante sous la forme d’un enregistrement DS.

Lorsqu’un ccTLD devient actif, il crée donc la possibilité technique de sécuriser les noms situés sous son extension.

Il ne les sécurise pas automatiquement.

Prenons un domaine fictif : institution.xx.

Pour qu’il soit réellement protégé par DNSSEC :

1. la zone .xx doit être active avec DNSSEC,
2. la zone institution.xx doit être signée par son opérateur DNS,
3. son enregistrement DS doit être transmis au registre, souvent par l’intermédiaire du registrar,
4. les signatures et les clés doivent rester valides dans le temps,
5. le résolveur utilisé par l’internaute doit effectuer la validation.

Si l’un de ces maillons manque, la protection s’interrompt.

Le maillon souvent oublié : les registrars et les enregistrements DS

Entre le titulaire du domaine et le registre national se trouve souvent le registrar, ou bureau d’enregistrement.

Son rôle dans DNSSEC est déterminant.

Le guide de déploiement de l’ICANN pour les ccTLD identifie deux responsabilités majeures : fournir une interface sûre et fiable pour recueillir les enregistrements DS des titulaires, puis les transmettre correctement au registre.

En pratique, le registrar peut ne proposer aucune fonction DNSSEC, mal accepter certains formats de DS, dépendre de procédures manuelles ou ne pas maîtriser les rotations de clés. Le registre peut alors être prêt tandis que son réseau de distribution ne l’est pas.

C’est ici que la mesure « ccTLD signé » atteint sa limite.

Un registre peut avoir accompli un travail technique remarquable, tandis que les titulaires restent incapables d’activer simplement DNSSEC sur leurs domaines.

La maturité doit donc aussi mesurer la disponibilité du service chez les registrars, la qualité des interfaces, l’automatisation, la documentation et le niveau d’assistance.

Activation réelle, validation et surveillance des erreurs

La chaîne ne produit un bénéfice que si elle est utilisée aux deux extrémités.

D’un côté, les titulaires doivent signer leurs domaines et publier les bons enregistrements DS. De l’autre, les opérateurs télécoms, fournisseurs d’accès, entreprises et administrations doivent activer la validation sur leurs résolveurs récursifs.

KINDNS considère cette validation comme une pratique obligatoire pour les opérateurs de résolveurs engagés dans son cadre de bonnes pratiques.

La différence est essentielle :

• signer permet de publier une preuve cryptographique,
• valider permet de vérifier cette preuve et de rejeter une réponse incorrecte.

Une signature que personne ne vérifie améliore l’infrastructure, mais ne délivre pas tout son potentiel de sécurité à l’utilisateur final.

Les indicateurs de l’Internet Society montrent d’ailleurs un contraste important : la part des ccTLD africains actifs progresse, tandis que la couverture DNSSEC des domaines enregistrés reste faible et que les taux de validation varient fortement selon les pays et les réseaux.

Il faut également surveiller les erreurs.

Les signatures DNSSEC expirent. Les clés doivent être renouvelées. Les enregistrements DS doivent rester cohérents avec les clés publiées. Une rotation mal préparée peut transformer un domaine légitime en domaine considéré comme invalide par les résolveurs.

Le résultat n’est alors pas une sécurité réduite, mais une panne visible : site inaccessible, messagerie perturbée, API indisponible. KINDNS recommande une gestion formalisée des clés, leur rotation régulière, la surveillance des signatures, le contrôle de l’intégrité des zones, la diversité des serveurs et une documentation opérationnelle.

DNSSEC n’est donc pas une case à cocher une fois. C’est une discipline opérationnelle continue.

Les enseignements des programmes africains actuels

Les déploiements du Burkina Faso et du Cameroun montrent que la réussite ne dépend pas uniquement du choix d’un algorithme ou de la génération de clés.

Au Burkina Faso, il a d’abord fallu renforcer les structures internes, formaliser les responsabilités, améliorer l’infrastructure, construire un environnement de test et former les équipes. Au Cameroun, une équipe dédiée disposant déjà de compétences en DNS, sécurité des systèmes, infrastructure à clés publiques et réponse aux incidents a pu avancer plus rapidement.

Les deux pays ont atteint une chaîne de confiance opérationnelle, mais par des trajectoires différentes.

La leçon est importante pour l’Afrique : DNSSEC révèle le niveau de maturité de l’organisation qui le déploie.

Une extension durablement sécurisée suppose des responsabilités claires, des équipes formées, des procédures documentées, des environnements de test, une gestion maîtrisée des clés et une coordination avec les registrars et opérateurs de réseau.

Le programme continental a donc raison de ne pas se limiter à des cérémonies d’activation. L’accompagnement, la documentation et le mentorat opérationnel sont les véritables conditions de la continuité.

Comment mesurer la maturité réelle d’un ccTLD

Une carte binaire « signé ou non signé » reste utile, mais elle ne dit pas si les titulaires peuvent activer DNSSEC facilement, si les registrars maintiennent les DS, si les résolveurs nationaux valident les réponses ou si les rotations de clés sont testées et supervisées.

KINDNS offre ici un socle pertinent.

L’initiative soutenue par l’ICANN organise les bonnes pratiques selon les catégories d’opérateurs : zones critiques et TLD, zones de second niveau, résolveurs privés ou publics, résilience et durcissement des plateformes.

Son approche est volontaire et repose notamment sur une auto-évaluation. Elle permet d’établir des normes opérationnelles communes, mais elle n’a pas vocation, à elle seule, à produire un classement souverain et comparatif des 54 écosystèmes nationaux africains.

C’est précisément l’espace qu’un observatoire africain peut occuper.

Vers un Indice NAAM de la chaîne de confiance DNS

NAAM pose ici les bases d’un indicateur plus complet : un Indice de maturité de la chaîne de confiance DNS, appliqué aux ccTLD africains.

Cet indice pourrait être construit sur six dimensions :

1. Activation du ccTLD : DNSKEY, DS dans la racine, algorithmes utilisés et continuité historique,
2. Accès par les registrars : prise en charge des DS, automatisation, documentation et assistance,
3. Adoption par les titulaires : proportion de domaines signés et disponibilité du service chez les hébergeurs DNS,
4. Validation nationale : adoption par les principaux FAI, opérateurs mobiles, administrations et entreprises,
5. Gouvernance opérationnelle : gestion des clés, rotations, supervision, exercices d’incident et documentation,
6. Résilience globale : diversité des serveurs, des réseaux et des localisations, conformité aux pratiques KINDNS et continuité d’activité.

Le résultat ne serait pas un badge DNSSEC supplémentaire.

Il offrirait une lecture stratégique de la capacité d’un pays à maintenir une chaîne de confiance complète, depuis la racine jusqu’aux domaines critiques utilisés par ses administrations, ses entreprises et ses citoyens.

Du niveau « fondation en construction » à celui de « chaîne de confiance mature », cette lecture permettrait de comparer les progrès sans réduire la sécurité nationale à un seul signal technique.

Elle aiderait aussi les registres, gouvernements, opérateurs et entreprises à identifier le prochain maillon à renforcer.

Signer était la première bataille, diffuser la confiance sera la suivante

L’Afrique a franchi une étape importante.

La majorité de ses ccTLD disposent désormais d’une chaîne DNSSEC active. Les programmes de formation et d’assistance produisent des résultats concrets. De nouvelles extensions nationales rejoignent progressivement la chaîne de confiance mondiale.

Mais la valeur réelle de DNSSEC ne se mesure pas uniquement dans la racine. Elle se mesure dans la capacité d’une administration à sécuriser son domaine, d’une entreprise à transmettre un DS, d’un registrar à maintenir la délégation et d’un résolveur à valider les réponses sans interrompre le service.

Le continent doit maintenant passer du déploiement à l’adoption, à la supervision et à la preuve.

La chaîne de confiance du DNS ne vaut que par son maillon le plus faible. Pour l’Afrique, le prochain progrès ne sera pas seulement de signer davantage d’extensions, mais de faire descendre la confiance jusqu’aux services réellement utilisés.