Resumo

  • A APNIC registrou 18 horas de impacto no RDAP, de 27 de janeiro de 2026 às 15h45 a 28 de janeiro às 9h45, no fuso UTC+10.
  • Uma alteração não intencional na configuração da Cloudflare impôs verificações mais estritas de integridade do navegador e bloqueou aproximadamente 10% das requisições com User-Agent diferente dos navegadores comuns.
  • Proteger o registro de automação abusiva e DDoS é necessário. O limite é usar uma descrição autodeclarada do software como se ela provasse a legitimidade de quem consulta.
  • Quatro consultas de baixa frequência, feitas em setembro com perfis distintos de User-Agent, receberam o mesmo JSON RDAP. O resultado vale para aquele instante e caminho, não para todos os clientes nem para a configuração histórica.
  • Um registro enxuto por classe de cliente pode unir decisão na borda, chegada à origem, resposta de protocolo e linhagem da mudança sem expor a regra de segurança.

O incidente aconteceu antes da resposta

Uma falha de conteúdo deixa rastros dentro do objeto retornado. O episódio descrito pela APNIC ocorreu antes: uma parcela das requisições foi interrompida na camada que antecede o aplicativo RDAP. O dado na origem podia continuar correto; para o cliente classificado de outra forma, ele simplesmente não chegava.

O anúncio de serviço delimita o evento. O início foi na terça-feira, 27 de janeiro de 2026, às 15h45, e o encerramento na quarta-feira, 28 de janeiro, às 9h45, sempre em UTC+10. O serviço afetado foi o RDAP. A duração total foi de 18 horas.

Segundo a APNIC, uma mudança em sua configuração Cloudflare teve o efeito não intencional de executar verificações mais estritas de integridade do navegador. Aproximadamente 10% das requisições ao RDAP que continham cadeias User-Agent incompatíveis com os User-Agent usuais de navegadores foram bloqueadas no período.

A redação não sustenta a frase “10% dos usuários ficaram sem serviço”. A unidade é uma requisição. Um processo pode enviar milhares; um usuário pode executar mais de um processo; uma recusa pode provocar novas tentativas. O anúncio não traz contagem de clientes únicos, nomes de programas, número de operadores nem decisões afetadas.

Também não informa códigos HTTP, corpo da resposta, localidades, pontos de presença, cadeias exatas ou limiares. Não há base para afirmar que todos os clientes de máquina foram bloqueados ou que determinado utilitário falhou. Preservar essas lacunas é parte da precisão: elas não devem ser preenchidas por uma narrativa tecnicamente plausível, mas não documentada.

O melhor argumento da APNIC é a própria disponibilidade

Um serviço público e automatizável precisa resistir a abuso. O RDAP é eficiente para inventários, verificações de recursos e tratamento de incidentes justamente porque programas conseguem consultá-lo. A mesma facilidade pode sustentar coleta excessiva, padrões agressivos e ataques de negação de serviço. A APNIC não cumpriria sua função se aceitasse toda carga sem proteção.

Em 2020, a organização descreveu uma arquitetura na qual a Cloudflare recebe o tráfego destinado a rdap.apnic.net e aos serviços RDAP de registros nacionais, oferece balanceamento e proteção DDoS e encaminha as requisições para infraestrutura no Google Cloud. O ponto de controle na borda faz parte, portanto, do serviço que o usuário experimenta.

A documentação da Cloudflare explica o propósito do Browser Integrity Check: procurar cabeçalhos HTTP comuns em tráfego abusivo e desafiar requisições com User-Agent ausente ou fora do padrão. Como um indício combinado com frequência, reputação e comportamento, isso pode ser útil. A documentação também mostra que o recurso pode ser delimitado por regras, nome de host ou caminho.

Desligar toda proteção não é a conclusão deste incidente. O que precisa ser revisto é o encaixe entre regra e população. Uma heurística criada em torno do visitante de um site interativo pode encontrar, no RDAP, clientes normais que não têm nem deveriam ter aparência de navegador.

O cliente normal do RDAP pode ser um script

A própria APNIC apresentou o RDAP em 2021 como JSON sobre HTTP ou HTTPS, fácil de processar por máquinas. Um único cliente pode interpretar respostas da maioria dos serviços RDAP, e a infraestrutura HTTP oferece cache. Essa uniformidade é uma das diferenças práticas em relação ao WHOIS tradicional.

A RFC 9082 define consultas REST uniformes para domínios, servidores de nomes, entidades, redes IP e sistemas autônomos. A RFC 7480 descreve o uso de HTTP pelo protocolo. Aplicações em navegadores são previstas, inclusive por regras de acesso entre origens, mas não formam uma classe superior. Ferramentas de linha de comando, bibliotecas, plataformas de gestão de endereços e sistemas de atendimento a abuso são igualmente naturais.

Não parecer navegador, nesse contexto, não é sinônimo de não parecer cliente RDAP. Pode ser apenas uma identificação honesta de software especializado. Uma regra que considere isso anômalo por padrão inverte a promessa do protocolo: a máquina precisa fingir ser a interface humana para obter a resposta feita para máquinas.

Isso não torna todo robô legítimo. Velocidade, sequência de consultas, reputação, autenticação e finalidade observável continuam relevantes. A questão é quanto poder decisório cabe a cada indício. O formato do User-Agent é uma evidência fraca de risco e uma evidência ainda mais fraca de autoridade.

Um nome de software não autentica o operador

Na RFC 9110, User-Agent contém informações sobre o software que originou a requisição. O campo pode ajudar na interoperabilidade e na adaptação de respostas. É formado por identificadores de produto e comentários, todos fornecidos pelo próprio cliente.

Ele não autentica quem está por trás do processo. Não prova vínculo com a APNIC, necessidade operacional, direito a determinada capacidade ou finalidade lícita. Uma cadeia semelhante a navegador não transforma um coletor abusivo em usuário autorizado. Uma cadeia curta com o nome de um script não torna suspeito um engenheiro de rede.

O campo pode participar de uma avaliação multicritério. O erro ocorre quando deixa de ser descrição de software e assume o lugar de uma credencial. Como o valor pode ser imitado, o bloqueio baseado em aparência cria um incentivo previsível: clientes legítimos adotam strings de navegador para funcionar; agentes hostis já sabem fazer o mesmo.

O resultado é menos informação. Os painéis passam a mostrar mais “navegadores”, mas não mais pessoas. A automação identificável desaparece da telemetria. A próxima regra é ajustada com dados que a regra anterior ensinou os usuários a falsear.

O termo “não intencional” usado pela APNIC impede uma leitura exagerada. Não há evidência de uma política consciente contra clientes de software. Há evidência de que uma alteração genérica recebeu escopo suficiente para governar uma interface de protocolo. Essa é uma falha de controle de mudança, não uma prova de intenção.

Limitar taxa é diferente de exigir uma fantasia

O RDAP não promete uso sem limites. A RFC 7481 trata disponibilidade e negação de serviço como temas de segurança, reconhece o uso de controle por cliente e admite autenticação HTTP. A RFC 7480 recomenda o status 429 para limitação de taxa: o cliente deve reduzir o ritmo e respeitar Retry-After quando o servidor o fornece.

Essa semântica permite reação automática. O programa distingue uma consulta inválida de uma solicitação excessiva e sabe quando tentar novamente. Se certas utilizações exigirem mais capacidade, a autenticação representa uma relação de autoridade mais verdadeira do que o nome de um navegador.

Não é correto, porém, afirmar que cada bloqueio do Browser Integrity Check em janeiro tinha obrigação de retornar 429. Limite de taxa e desafio antirrobô são mecanismos diferentes, e a APNIC não divulgou os detalhes de resposta. O pedido razoável é que a evidência os separe: o que a borda decidiu, se a origem recebeu a consulta e qual resposta RDAP foi produzida.

Essa separação também impede falsos sucessos. Uma página HTML de desafio, ainda que retorne um status comum, não é application/rdap+json. Uma requisição descartada antes da origem não deve desaparecer de uma métrica construída apenas com logs da aplicação. Medir porta aberta ou status isolado é insuficiente.

A amostra atual mostra convergência

Em 5 de setembro de 2026, quatro GETs de baixa frequência foram enviados a https://rdap.apnic.net/ip/202.12.29.0, todos com Accept: application/rdap+json. Um não definiu User-Agent explicitamente; outro usou um User-Agent de automação que explicitava sua finalidade; o terceiro apresentou curl/8.7.1; o quarto usou uma cadeia de estilo Mozilla/Safari.

As quatro respostas foram HTTP 200, com tipo application/rdap+json, 3.857 bytes e a mesma soma SHA-256: d6983abd9266f7ac6d6a23b8b5cf67c186aae673a64030fc04e4e457837bb853. Os cabeçalhos mostraram passagem pela Cloudflare.

Naquele endpoint, naquele momento, caminho e ritmo, os quatro perfis chegaram ao mesmo resultado. A observação é compatível com a ausência atual da diferença que a APNIC descreveu em janeiro. Ela não é uma reprodução do incidente, nem testa todas as consultas, métodos, redes, regiões, bordas e velocidades. Uma execução correta não garante a seguinte.

O valor do canário está em repetir a comparação e registrar quando ela muda. Se apenas o cliente navegador continuar no painel, a camada que falhou em janeiro ficará novamente fora do campo de visão.

Publicar o resultado, não a receita de evasão

Uma prestação de contas útil não exige abrir a configuração do WAF. A APNIC pode manter em sigilo expressões, limiares e listas de reputação. Precisa tornar observável o contrato externo: que classes de cliente legítimo alcançam uma resposta de protocolo pela cadeia realmente implantada?

Quatro canários controlados pela própria APNIC cobrem o mínimo: ausência de User-Agent, automação com nome explícito, linha de comando comum e navegador. Para cada um, o registro deve conter a decisão da borda, a chegada à origem, a classe de status HTTP, o tipo de conteúdo, a latência e a instrução de nova tentativa quando houver limitação de taxa.

Depois vem a linhagem da mudança: identificador, dono, revisor, escopo, horário de implantação, horário de reversão e validação posterior. É possível mostrar que uma regra orientada a navegador não cobre todo o host ou caminho RDAP sem revelar seus critérios exatos. Percentuais agregados de decisão por classe podem indicar desvio sem entregar o limiar a um atacante.

A APNIC já mede pela perspectiva do usuário. No relatório do segundo trimestre de 2025, um teste RDAP era bem-sucedido quando recebia uma resposta HTTP sem erro em menos de cinco segundos; a disponibilidade era a razão entre sucessos e total. Acrescentar classe de cliente e camada de decisão torna essa mesma lógica mais representativa.

O informe do primeiro trimestre de 2026 afirma que todos os serviços centrais de registro atingiram ou superaram 99,99% de disponibilidade. O resumo não traz o denominador e a metodologia necessários para reconciliar essa frase com o episódio de 18 horas. Não há base para chamá-la de falsa. Há motivo para ligar futuras cifras aos clientes e às camadas que elas de fato observam.

O que permanece fora da conclusão

Não se afirma que o RDAP da APNIC continue com defeito, que todos os clientes de máquina tenham sido bloqueados ou que um número conhecido de operadores tenha sofrido impacto. Não se inventam códigos, páginas, User-Agent ou localidades. As quatro consultas de setembro não completam as lacunas históricas.

O incidente também não demonstra que a APNIC ou a Cloudflare ignoraram uma norma. As RFCs oferecem semântica e princípios; a implantação de segurança exige julgamento local. A própria APNIC reconheceu um efeito não pretendido. A conclusão sustentada é operacional: a borda precisa provar que protege sem converter aparência de navegador em autoridade.

Uma evidência pequena, repetível e versionada é mais forte do que uma promessa genérica de normalidade. Ela mantém separados o participante, o rótulo que ele envia, a decisão do intermediário e a resposta do registro.

Fontes

  1. APNIC, anúncio de serviço de 28 de janeiro de 2026
  2. APNIC Blog, nova infraestrutura para servir RDAP
  3. APNIC Blog, o RDAP está pronto para substituir o whois?
  4. APNIC Blog, disponibilidade dos serviços de registro no segundo trimestre de 2025
  5. APNIC Blog, atualização da Secretaria no primeiro trimestre de 2026
  6. Cloudflare Docs, Browser Integrity Check
  7. RFC 7480, uso de HTTP no RDAP
  8. RFC 7481, serviços de segurança para RDAP
  9. RFC 9082, formato de consultas RDAP
  10. RFC 9110, semântica HTTP