Resumo

  • Nas notas de 19 de agosto, a AFRINIC transforma uma verificação IPv6 dos servidores do ccTLD em uma afirmação sobre todos os sites abaixo dele. O transporte da consulta DNS não determina a família dos endereços retornados.
  • Um resolvedor recursivo de pilha dupla oferece um contraexemplo. A recursão exclusivamente por IPv6, sem alternativa útil para alcançar uma autoridade necessária, pode sofrer uma limitação real. Não fizemos medições de DNS ou de falhas de aplicações.

A pergunta chega por IPv6. A busca da resposta pode seguir por IPv4. Esse desvio é perfeitamente possível quando um resolvedor recursivo trabalha em nome do usuário — e muda a conclusão que a AFRINIC tira de uma de suas novas verificações.

O monitor de implantação IPv6 e DNSSEC passou a examinar também os domínios de topo de código de país. As notas da versão 2.14.0, datadas de 19 de agosto de 2026, separam três perguntas sobre os servidores do registro: possuem endereço IPv6, respondem por esse transporte e conseguem responder efetivamente a consultas DNS? É uma separação importante.

A explicação acrescenta uma conclusão bem mais ampla: se os servidores do registro não forem alcançáveis por IPv6, nada abaixo deles poderá ser, por melhor que esteja configurado. Mesmo para um nome realmente delegado sob esse ccTLD, a consequência não é necessária. A hierarquia do DNS organiza a procura pelas autoridades. Ela não obriga todas as consultas, a conversa do usuário com o resolvedor e a conexão final ao site a usar a mesma versão de IP.

O endereço retornado não precisa seguir a família da consulta

A RFC 3596, publicada em outubro de 2003, explicita a independência entre o transporte DNS e a versão dos endereços descritos pelos registros. Uma consulta por IPv4 pode recuperar dados AAAA; uma consulta por IPv6 pode recuperar registros de endereços IPv4.

É preciso respeitar também o papel do servidor pai. O ccTLD não entrega necessariamente o AAAA final do site. O resolvedor pode pedir a delegação ao pai por IPv4, seguir para o serviço autoritativo do domínio filho por um caminho disponível e buscar ali o endereço. A resposta volta ao usuário por IPv6, e a conexão ao serviço pode igualmente usar IPv6.

Esse contraexemplo depende de condições explícitas: as etapas autoritativas necessárias são acessíveis, os dados são válidos e existe um caminho IPv6 funcional até a aplicação. Não é um teste de uma rede ou de um país. Tampouco precisa de uma resposta previamente em cache. Ele mostra por que o transporte IPv4 em uma etapa de autoridade não determina, sozinho, o transporte da conexão final.

A RFC 4472, documento informativo de abril de 2006, reafirma a separação entre transporte e dados consultados. Muitas vezes, quem pergunta ao servidor autoritativo não é quem usará o endereço. O resolvedor intermediário tem interfaces e conectividade próprias.

A cautela vale nos dois sentidos. Obter um AAAA não prova que o serviço responde por IPv6. Roteamento, filtros, a escuta da aplicação e o caminho até ela continuam sendo questões independentes. Uma resposta DNS bem-sucedida do pai não substitui o teste desse serviço.

A restrição que não deve desaparecer do relato

O argumento mais forte a favor da preocupação da AFRINIC é uma configuração que faz iteração somente por IPv6 e encontra uma autoridade necessária alcançável apenas por IPv4. Sem encaminhamento funcional para um resolvedor de pilha dupla, tradução ou outro caminho utilizável, aquela etapa pode realmente impedir a resolução. A condição é específica, não uma consequência automática para todo cliente IPv6.

A RFC 3901, orientação sobre transporte DNS IPv6 de setembro de 2004, distingue a resolução direta do encaminhamento a um serviço recursivo de pilha dupla. Não se deve transformar seu conselho histórico em uma nova proibição de clientes exclusivamente IPv6 em 2026. Atender o usuário por IPv6 e usar apenas IPv6 na recursão para as autoridades são escolhas distintas.

As notas do próprio monitor ajudam a conter a interpretação. As verificações partem de um único lugar na África; respostas DNS têm mais peso que respostas a ping. A versão 2.15.0 acrescenta perguntas sobre respostas assinadas grandes e consistência de delegações. São melhorias úteis, não uma verificação mundial de todas as aplicações.

Esta é uma análise feita em setembro de um texto publicado em agosto. Os números antigos do histórico não são medições atuais produzidas aqui. Não executamos consultas DNS, testes de aplicação ou mudanças de resolvedor, e não estabelecemos uma queda nacional ou um defeito presente nos servidores. O teste do ccTLD merece continuar. A explicação precisa parar onde termina sua evidência.