Resumo

  • A revisão pública da ZARC afirma que domínios comerciais de segundo nível sob .ZA sofreram indisponibilidade e degradação de DNS entre 6 e 14 de março de 2025 [1].
  • A ZADNA descreveu uma interrupção que afetou o namespace .za, especificamente nomes co.za, e identificou a ZARC como operadora de co.za, org.za, net.za e web.za [2][3].
  • A ZADNA mencionou tráfego inesperado para servidores de nomes, medidas automatizadas de segurança, relatos envolvendo o Google Public DNS, mitigação e acompanhamento de capacidade e resiliência [2][3].
  • A base raiz da IANA e a RFC 1034 situam o mecanismo na camada de DNS, registro e delegação, mas não comprovam o incidente [4][5].
  • A questão de responsabilidade é se operadora e autoridade conseguem delimitar a falha, explicar a mitigação, preservar incertezas e demonstrar quais controles mudaram.

O que aconteceu

A ZARC publicou depois uma revisão sobre indisponibilidade e degradação de DNS em março de 2025 que afetou domínios comerciais de segundo nível sob .ZA. A organização disse ter analisado telemetria operacional e implementado melhorias em infraestrutura, operações, arquitetura DNS, procedimentos e resiliência [1].

O comunicado da ZADNA de 14 de março traz a perspectiva da autoridade pública. Ele descreveu uma interrupção do serviço do namespace .za, especificamente em nomes co.za, e identificou a ZARC como operadora dos domínios comerciais co.za, org.za, net.za e web.za [2][3].

A ZADNA também indicou a forma operacional do evento: tráfego inesperado para servidores de nomes, medidas automatizadas de segurança, trabalho de mitigação e relatos envolvendo o Google Public DNS que podem ter afetado a resolução [2][3]. Isso sustenta a classificação como continuidade DNS de registro. Não sustenta dizer que o Google causou o incidente, que todos os nomes .za falharam ou que a causa raiz completa já é pública.

A linguagem estreita importa. Um incidente de DNS do registro não é uma queda nacional total da internet. Ele atinge a infraestrutura de consulta que permite a usuários e softwares encontrar um serviço. Para um titular cujo domínio depende dessa camada, o efeito continua concreto: o nome não resolve de forma confiável e o serviço parece inacessível.

Por que importa

Um registro mantém dados, mas também opera infraestrutura em execução. Usuários não chegam a um domínio lendo uma política; seus dispositivos consultam o DNS. Se o caminho autoritativo de resposta degrada, os controles de continuidade do registro viram dependência pública.

Essa é a superfície Heng.lu deste artigo: DNS, registro e delegação. Dados corretos não bastam se o serviço de resolução não continua sob pressão de tráfego, durante decisões de mitigação ou diante de efeitos visíveis em resolvedores. A pergunta não é se o registro é soberano. É se código, registros, servidores de nomes, monitoramento e recuperação mantêm usuários dependentes alcançáveis.

O incidente também mostra por que transparência precisa separar observação de inferência. A ZARC pode relatar análise de telemetria e melhorias [1]. A ZADNA pode relatar tráfego inesperado, medidas automatizadas e acompanhamento [2][3]. Leitores ainda precisam distinguir comportamento DNS autoritativo, sintomas vistos por resolvedores, limites de capacidade, respostas defensivas e fatos não publicados.

A camada técnica

DNS resolve nomes em uma hierarquia delegada. A IANA lista .za no banco da raiz, estabelecendo a superfície de delegação [4]. A RFC 1034 descreve um sistema distribuído no qual servidores respondem sobre nomes e delegam autoridade entre zonas [5]. Essas fontes explicam o mecanismo; não provam os fatos de março.

Em termos simples, um resolvedor procura informação autoritativa para obter uma resposta. Servidores de nomes do registro integram essa cadeia. Se o tratamento de tráfego, a política de mitigação ou a arquitetura DNS se degradam, o usuário pode ver uma falha de resolução mesmo com a hospedagem saudável.

Os materiais da ZARC e da ZADNA convergem sobre a mesma família operacional: indisponibilidade ou degradação de domínios comerciais de segundo nível, tráfego inesperado, medidas automatizadas, mitigação e trabalho de resiliência [1][2][3]. Eles não publicam todos os logs, limites, regras ou caminhos de resolvedores. O limite de evidência termina ali.

Quem foi afetado

O grupo mais seguramente sustentado inclui usuários, registrantes e organizações dependentes dos domínios comerciais afetados. A ZADNA nomeou co.za e descreveu o conjunto comercial operado pela ZARC [2][3].

Também foram afetados operadores cujo serviço pareceu indisponível porque a resolução estava degradada. Aplicativo, provedor de hospedagem ou rede de acesso podem estar saudáveis enquanto o DNS do registro cria o sintoma visto pelo cliente.

As fontes não autorizam um número de usuários, uma estimativa de perda ou a afirmação de que todo nome .za reagiu igual. Elas sustentam uma conclusão mais precisa: a camada DNS do registro ficou visível como dependência de continuidade.

O dever de evidência do registro

O primeiro dever é definir a fronteira do serviço: zonas, rótulos, conjuntos de servidores ou domínios comerciais afetados. Dizer apenas «.za caiu» apaga a superfície operacional que os documentos permitem delimitar.

O segundo é uma linha do tempo separando primeiro sintoma, alerta interno, ação automatizada, mitigação manual, recuperação vista por resolvedores e estado final estável. A ZARC informa uma janela e categorias de melhoria [1], mas não todos os horários internos. O artigo não deve inventá-los.

O terceiro é classificar a telemetria. «Tráfego inesperado» pode ser pico de consultas, mistura anormal, repetições, bots ou interação entre limites defensivos e carga legítima. A ZADNA sustenta a descrição geral [2][3], não um rótulo final de DDoS nem diagnóstico regra por regra.

O quarto é a perspectiva do resolvedor. A referência ao Google Public DNS delimita um sintoma possível, não atribui causa [2][3]. Um fechamento útil separaria respostas autoritativas, caches, respostas negativas e diferenças entre resolvedores.

O quinto é ligar mitigação a uma classe de controle: capacidade, distribuição de servidores, filtros, limites, escalonamento, monitoramento ou arquitetura. «Serviço restaurado» não demonstra sozinho que o próximo evento será menor.

O que acompanhar

Revisões futuras devem separar tráfego para servidores, comportamento autoritativo, sintomas de resolvedores e alcançabilidade do cliente. Devem mostrar diversidade de servidores, reserva de capacidade, segurança de regras automatizadas, retenção de telemetria e validação pública após o reparo.

A avaliação fica mais grave com recorrência, falha mais longa, controles que bloqueiem consultas legítimas ou ausência de fechamento delimitado. Fica menos grave com escopo preciso, cronologia clara, mitigação ligada ao controle e melhorias verificáveis de arquitetura ou capacidade.

Fontes

  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