Resumo

  • O mapa atual carrega 27 linhas de um CSV e marca todas como hospedadas; somente 24 delegações incluem afrinic no nome de um servidor.
  • As três restantes — .so, .ng e .ml — têm endereços IPv4 e IPv6 dentro dos prefixos NS2 que a AFRINIC publica, de modo que o total se sustenta no nível de endereço.
  • Um recibo datado de zona hospedada deveria mostrar a ligação entre nome, endereço e prefixo, sem alegar que ela prova contrato, local físico, disponibilidade ou controle do conteúdo.

Há duas maneiras de ler o número 27. Como peça de comunicação, ele resume o alcance regional de um serviço DNS. Como afirmação operacional, ele precisa de uma trilha que outra pessoa consiga percorrer.

A página do programa DNS da AFRINIC informa que hospeda DNS autoritativo para mais de 25 ccTLDs africanos. O mapa vinculado transforma “mais de 25” em 27: seu CSV contém 27 pares únicos de país e domínio. No código da interface, cada entrada recebe isHosted: true e o tamanho da lista vira a estatística exibida.

O caminho mais óbvio para conferir a lista é procurar AFRINIC nos hostnames delegados. Ele encontra 24. Nomes como ns-bw.afrinic.net tornam a relação explícita. Já as delegações de .so, .ng e .ml não contêm afrinic em nenhum nome. Um auditor que pare aí concluirá, erradamente, que três linhas não têm suporte.

A segunda metade da identificação

Em .so, d.nic.so resolvia para 196.216.168.54 e 2001:43f8:120::54 no retrato DNS congelado em 12 de setembro. O registro de delegação da IANA mostra o mesmo par.

No caso de .ng, ns5.nic.net.ng apontava para 196.216.168.41 e 2001:43f8:120::41. Em .ml, d.nic.ml usava 196.216.168.37 e 2001:43f8:120::37. As páginas atuais da IANA confirmam os quatro endereços.

O guia de implantação da AFRINIC fecha a cadeia. Ele associa o NS2 ao AS37177 e publica 196.216.168.0/24 e 2001:43f8:120::/48 como prefixos anycast do serviço. Cada endereço das três zonas pertence à faixa correspondente. Aplicado às 27 linhas, o teste encontrou pelo menos um endereço de servidor em cada prefixo para todas elas.

O mapa não inflou o número. O que ele omitiu foi a ligação necessária para demonstrá-lo.

Identidade local, infraestrutura comum

Não há defeito em um ccTLD manter um nome de servidor local enquanto recebe DNS secundário por uma rede compartilhada. O hostname serve à delegação; não é uma ficha societária do operador. Obrigar a marca do provedor em cada nome tornaria a atribuição mais fácil aos olhos, mas não tornaria o DNS mais resiliente.

O endereço melhora a atribuição técnica, ainda que não responda a tudo. Uma faixa anycast não revela qual instância física atendeu um usuário, nem em qual cidade. Não mede latência, não prova uptime, não publica um SLA e não expõe o contrato entre as partes. A origem BGP em um instante específico também exigiria seu próprio registro.

Também é preciso proteger a fronteira de autoridade. A AFRINIC descreve o programa como DNS escravo ou secundário. Os dados são replicados do servidor mestre ou primário do operador; a AFRINIC afirma que não administra a zona nem seu conteúdo. Hospedar respostas não equivale a governar o domínio nacional.

Um inventário sem relógio

O CSV oferece país, ccTLD e bandeira. Não informa, linha por linha, quando a relação foi observada, qual hostname a sustenta, quais endereços foram resolvidos ou qual prefixo foi usado no vínculo. Não há histórico. O código tampouco diferencia ativo, pendente, encerrado ou temporariamente indisponível.

Isso favorece uma visualização rápida, mas dificulta mudanças. Se um servidor for renomeado sem troca de serviço, um monitor de palavras pode acusar saída. Se o endereço mudar, o leitor não saberá se houve migração, encerramento ou atraso de atualização. A contagem pode continuar certa e, mesmo assim, perder sua explicação.

Um recibo de zona hospedada resolveria o problema com poucas linhas. Ele mostraria ccTLD, hostname delegado, IPv4 e IPv6 observados, prefixo de serviço correspondente, fonte, horário e estado. Datas de primeira observação, última confirmação e alteração de estado formariam uma história mínima.

O recibo deve incluir um canal de correção e uma advertência sobre o que não prova. Não precisa revelar coordenadas, contatos internos ou termos comerciais. Seu objetivo é permitir que qualquer leitor entenda por que uma zona foi incluída no total naquele momento.

A melhor defesa da tela atual é válida: um mapa público deve ser simples, e o total de 27 resistiu à verificação congelada. A solução não é despejar detalhes técnicos na página principal. É oferecer uma camada expansível de evidência. Simplicidade editorial e auditabilidade podem coexistir.

.so, .ng e .ml tornam essa necessidade concreta. Os nomes continuam pertencendo ao contexto local, enquanto os endereços entram na malha comum. O fato de a relação não carregar uma marca visível não a torna secreta. Apenas mostra por que uma contagem responsável precisa publicar a união, não só o resultado.

Fontes