Resumo

  • O Whois 1.124 da RIPE passou a oferecer versões históricas em texto simples. O resultado é um objeto histórico filtrado, não um arquivo integral da solicitação de atualização original.
  • No código examinado, o retorno em texto ocorre antes da atribuição explícita do número da revisão ao objeto da resposta estruturada. Guardar a consulta junto com o corpo ajuda a identificar a versão; a análise não demonstra ausência de contexto em todos os cabeçalhos.

Um arquivo de texto pode sobreviver por anos e continuar perfeitamente legível. A chave do objeto está lá, a descrição também. Se a equipe não guardou o endereço da consulta, porém, como o próximo leitor identifica a revisão e as condições em que ela foi obtida? Esse é um cenário de arquivamento, não um caso de uso indevido descoberto nesta apuração. A nova resposta histórica da RIPE torna a pergunta menos abstrata.

A versão 1.124 do Whois incluiu suporte a texto simples na API REST de versões históricas. A página do lançamento no GitHub é de 12 de agosto de 2026. O registro oficial indica 13 de agosto para a versão candidata e 27 de agosto para a implantação em produção. Esta análise, feita em setembro, não transforma a mudança em um lançamento de setembro nem afirma que todas as instalações atuais executam essa versão. Sua base é o código fixado no lançamento e a documentação, não uma consulta de teste ao serviço de produção.

Há boas razões para preferir texto. RPSL é uma linguagem familiar aos profissionais de redes; retirar a embalagem da resposta facilita a leitura, os scripts e a comparação de arquivos. Uma representação útil não precisa ser, sozinha, um pacote completo de evidências. A dificuldade aparece quando quem a guarda presume que ela também desempenha esse segundo papel.

O caminho da consulta ajuda a localizar a revisão. WhoisVersionService monta uma consulta com SELECT_TYPES e SHOW_VERSION, passando a este último o número histórico solicitado. O processamento seleciona o objeto RPSL correspondente. Datas e observações dentro do objeto podem ter importância operacional, mas não são automaticamente equivalentes ao identificador da revisão no envelope da resposta.

Antes de devolver o objeto escolhido, VersionQueryExecutor aplica filtros relativos a e-mail, autenticação, changed e informações pessoais. Portanto, o resultado histórico já passou por regras de apresentação e proteção. Não é uma promessa de reproduzir sem cortes o pedido HTTP, a mensagem de atualização por e-mail ou todos os registros internos daquela transação.

Isso não torna o histórico “corrompido”. Proteger dados pessoais e de autenticação é uma razão legítima para filtrar uma resposta pública. Tampouco se pode concluir que todos os campos necessariamente mudam, ou que um texto devolvido jamais coincidiria com um texto submetido no passado. A distinção é contratual: oferecer uma revisão histórica não equivale a oferecer o arquivo original da transação.

A bifurcação mais relevante vem depois. Quando Accept contém text/plain, o serviço retorna getRpslObject().toString(). Esse retorno ocorre antes do mapeamento estruturado e antes de WhoisObject.setVersion atribuir explicitamente o número da revisão histórica. O corpo em texto segue, assim, um caminho que não executa essa etapa da resposta estruturada.

A conclusão vale para o corpo produzido por esse código. Não é uma auditoria de todos os interceptadores, proxies ou cabeçalhos HTTP. A URI da consulta ainda pode ligar objeto e revisão solicitada. Se o cliente a conserva junto com o corpo, essa ligação não desaparece necessariamente porque a representação é textual.

Na alternativa estruturada, o serviço encaminha o valor interpretado de unformatted ao mapeador de atributos e atribui a revisão histórica ao objeto. A resposta externa também pode trazer versão do software, erros e termos de uso. O número histórico do objeto e a versão do serviço respondem a perguntas diferentes: qual revisão foi selecionada e qual implementação produziu sua representação. Colocar ambos no mesmo campo “versão” perde essa diferença.

unformatted não significa “recupere o pedido original”. Ele participa do mapeamento de atributos no ramo estruturado; o texto simples retorna antes desse mapeador. O parâmetro não desfaz os filtros anteriores nem comprova a identidade ou a autoridade de quem enviou uma atualização. Sem formatação não é sinônimo de sem filtragem.

Um cuidado prático seria guardar, ao lado do corpo, a URI, a base de origem, o tipo e a chave do objeto, a revisão solicitada, Accept, unformatted, o horário de captura, os cabeçalhos pertinentes e a representação com seu hash. É uma recomendação de arquivo para o usuário, não uma obrigação nova atribuída à RIPE. O formato pode variar; a identificação não deveria depender apenas do nome do arquivo ou da memória do operador.

Um hash comprova a integridade dos bytes guardados. Não recupera o contexto que ficou de fora nem demonstra a autorização da atualização antiga. Se regras de apresentação ou filtragem mudarem no futuro, os bytes visíveis de uma mesma revisão poderão diferir. Essa é uma hipótese de comparação a considerar, não um incidente observado ou prova de alteração do recurso.

A conveniência do texto é real. O salto indevido seria usá-lo, sem os registros correspondentes, como prova completa da submissão original, da autorização ou da titularidade de um recurso. O corpo pode ficar leve; a responsabilidade de identificar sua consulta precisa ter outro lugar para ficar.

Fontes

  1. Notas de lançamento do RIPE Whois 1.124
  2. Documentação oficial e histórico de lançamentos da RIPE Database
  3. WhoisVersionService no commit fixado do lançamento
  4. Executor das versões históricas e ordem dos filtros
  5. Mapeador de atributos do servidor
  6. Mapeador de objetos da resposta estruturada
  7. Objeto de retorno que contém o RPSL histórico