Résumé

  • La revue publique de ZARC indique que des domaines commerciaux de second niveau en .ZA ont subi une panne et une dégradation DNS entre le 6 et le 14 mars 2025 [1].
  • ZADNA a décrit une perturbation touchant l'espace de noms .za, en particulier des noms co.za, et a identifié ZARC comme l'opérateur de co.za, org.za, net.za et web.za [2][3].
  • ZADNA a mentionné un trafic inattendu vers les serveurs de noms, des mesures de sécurité automatisées, des signalements concernant Google Public DNS, des mesures d'atténuation et un suivi de capacité et de résilience [2][3].
  • Les documents IANA et RFC 1034 placent le mécanisme dans la couche DNS, registre et délégation, sans servir de preuve de l'incident lui-même [4][5].
  • La question de responsabilité est de savoir si l'opérateur et l'autorité peuvent délimiter la panne, expliquer l'atténuation, conserver les incertitudes et montrer quels contrôles ont changé.

Ce qui s'est passé

ZARC a publié une revue d'incident concernant une panne et une dégradation DNS de mars 2025 affectant des domaines commerciaux de second niveau en .ZA. ZARC a indiqué avoir analysé sa télémétrie opérationnelle et avoir apporté des améliorations à l'infrastructure, aux opérations, à l'architecture DNS, aux procédures et à la résilience [1].

La déclaration de ZADNA du 14 mars apporte la perspective de l'autorité publique. Elle parle d'une perturbation du service de l'espace de noms .za, plus précisément autour de noms co.za, et rappelle que ZARC opère les domaines commerciaux de second niveau co.za, org.za, net.za et web.za [2][3].

ZADNA a également décrit la forme opérationnelle de l'événement: trafic inattendu vers les serveurs de noms, mesures de sécurité automatisées, travaux d'atténuation et signalements impliquant Google Public DNS qui ont pu affecter la résolution [2][3]. Ces éléments suffisent à qualifier l'événement de problème de continuité DNS du registre. Ils ne permettent pas d'affirmer que Google en est la cause, que tous les noms en .za ont échoué ou qu'une analyse complète de la cause racine est publique.

Cette précision est essentielle. Une perturbation DNS de registre n'est pas une panne nationale totale d'Internet. Elle touche la couche de recherche qui permet aux utilisateurs et aux logiciels de trouver un service. Pour un titulaire dont le domaine dépend de cette couche, la conséquence reste tangible: le nom ne se résout pas de façon fiable et le service paraît inaccessible.

Pourquoi c'est important

Un registre tient des enregistrements, mais il exploite aussi une partie du système en fonctionnement. Les utilisateurs ne joignent pas un domaine en lisant une politique; leurs logiciels interrogent le DNS. Si le chemin de réponse faisant autorité se dégrade, les contrôles de continuité du registre deviennent une dépendance publique.

C'est la surface Heng.lu de cet article: DNS, registre et délégation. Un registre exact ne suffit pas si son service de résolution ne tient pas sous pression de trafic, pendant une décision d'atténuation ou lors d'effets visibles chez les résolveurs. La question n'est pas de traiter le registre comme un souverain. Elle est de vérifier si le code en fonctionnement, les enregistrements, les serveurs de noms, la supervision et la reprise maintiennent la joignabilité.

L'incident montre aussi pourquoi la transparence doit séparer observation et inférence. ZARC peut déclarer une analyse de télémétrie et des améliorations [1]. ZADNA peut confirmer un trafic inattendu, des mesures automatisées et un suivi [2][3]. Le lecteur doit encore distinguer comportement DNS faisant autorité, symptômes vus par les résolveurs, contraintes de capacité, réponses défensives et faits non publiés.

La couche technique

Le DNS organise les noms dans une hiérarchie déléguée. IANA répertorie .za dans la base racine, ce qui établit la surface de délégation [4]. RFC 1034 décrit un système distribué dans lequel des serveurs répondent sur des noms et délèguent l'autorité entre zones [5]. Ces références expliquent le mécanisme; elles ne prouvent pas les faits de mars 2025.

En pratique, un résolveur cherche les informations faisant autorité pour transformer un nom en réponse. Les serveurs de noms du registre font partie de cette chaîne. Une dégradation du traitement de trafic, de la politique d'atténuation ou de l'architecture DNS peut donc apparaître comme un échec de résolution, même si l'hébergement du service reste sain.

Les documents ZARC et ZADNA convergent sur une même famille opérationnelle: panne ou dégradation de domaines commerciaux de second niveau, trafic inattendu vers des serveurs de noms, mesures automatisées, atténuation et améliorations de résilience [1][2][3]. Ils ne publient pas tous les journaux, seuils, règles ou chemins de résolveur. L'analyse doit s'arrêter à cette limite.

Qui a été affecté

Le groupe le plus solidement établi comprend les utilisateurs, titulaires et organisations qui dépendaient des domaines commerciaux de second niveau concernés. ZADNA a nommé co.za et a identifié l'ensemble commercial géré par ZARC [2][3].

Sont également concernés les opérateurs dont le service paraissait indisponible parce que la résolution était dégradée. Une telle panne peut créer des symptômes clients alors que l'application, l'hébergeur ou le réseau d'accès n'est pas la source initiale du problème.

Les sources ne justifient ni un nombre d'utilisateurs, ni un montant de pertes, ni l'affirmation que tous les noms en .za ont réagi de la même manière. Elles montrent que la couche DNS du registre est devenue une dépendance de continuité visible.

Le devoir de preuve du registre

Le premier devoir est de délimiter le service: zones, labels, ensembles de serveurs ou domaines commerciaux affectés. Les termes trop larges comme « tout .za était en panne » masquent la surface opérationnelle réelle.

Le deuxième est une chronologie séparant premier symptôme visible, première alerte interne, action de sécurité automatisée, atténuation manuelle, reprise visible par les résolveurs et état stable. ZARC publie une fenêtre et des catégories d'amélioration [1], mais pas tous les horodatages internes. Cette lacune ne doit pas être comblée par supposition.

Le troisième est la classification de la télémétrie. Un « trafic inattendu » peut être une hausse de requêtes, un mélange anormal, des réessais, des bots ou une interaction entre seuils défensifs et charge légitime. ZADNA confirme la formule générale [2][3], pas une qualification finale de DDoS ni un diagnostic règle par règle.

Le quatrième est la perspective des résolveurs. La référence de ZADNA à Google Public DNS décrit un symptôme possible, pas une causalité [2][3]. Une revue utile distinguerait l'état des serveurs faisant autorité, les caches, les réponses négatives et les différences entre résolveurs.

Enfin, l'atténuation doit être reliée à une classe de contrôle: capacité, distribution des serveurs, filtrage, seuils, procédures d'escalade, supervision ou architecture. Dire que le service est rétabli ne prouve pas que le prochain événement sera contenu plus vite.

Ce qu'il faut surveiller

Il faut suivre si les prochains rapports de ZARC et ZADNA distinguent trafic vers les serveurs, comportement DNS faisant autorité, effets visibles chez les résolveurs et impact utilisateur. Il faut aussi chercher des preuves de capacité, de diversité des serveurs, de sécurité des mesures automatisées, de conservation de télémétrie et de validation publique après réparation.

L'évaluation deviendrait plus sévère en cas de récurrence sur le même service commercial, d'échec plus long que décrit, de mesures bloquant des requêtes légitimes ou d'absence de compte rendu borné. Elle deviendrait moins sévère avec une portée limitée, une chronologie précise, une atténuation explicable et des améliorations d'architecture ou de capacité vérifiables.

Sources

  1. https://zarc.web.za/public-incident-review-march-2025-dns-outage-and-degradation/
  2. https://www.zadna.org.za/za-namespace-experiences
  3. https://www.zadna.org.za/images/za_namespace_disruption.pdf
  4. https://www.iana.org/domains/root/db/za.html
  5. https://www.rfc-editor.org/rfc/rfc1034.txt