Exportação do estado cadastral: como tornar recuperáveis os registros de recursos numéricos da Internet

Uma exportação útil permite que outro operador verifique o estado registrado e seu histórico. Manter uma cópia é apenas o começo; a transição também precisa ser compreensível e testável.

Quando uma entidade de registro está disponível, um recurso numérico da Internet pode parecer uma simples consulta. Você consulta um prefixo IP ou um número de sistema autônomo e recebe um registro. Esse registro é útil, mas é apenas uma visão de um estado mais amplo: quem a entidade de registro reconhecia, o que mudou, quais serviços foram delegados, quais autorizações de roteamento existiam e quais evidências sustentam a resposta atual.

A pergunta mais difícil surge quando a entidade de registro está indisponível, é contestada, foi comprometida ou está sendo substituída. O estado legítimo do recurso ainda pode ser compreendido e verificado por alguém que não tenha o banco de dados original e os procedimentos internos?

A questão da continuidade: se o sistema de registro atual parar de responder amanhã, de quais informações um titular legítimo ou sucessor precisaria para reconstruir o último estado verificado sem inventar um novo?

Comece separando três estados diferentes

Muitas discussões sobre entidades de registro ficam confusas porque três perguntas diferentes são tratadas como uma só:

• Estado cadastral: o que uma autoridade registra atualmente sobre o recurso, o titular reconhecido, os contatos, os eventos, a delegação e o status.
• Estado operacional: como o recurso está sendo usado na prática, incluindo DNS reverso, relações com provedores e continuidade do serviço.
• Estado do roteamento: qual sistema autônomo está originando uma rota e se a autorização de roteamento correspondente é válida.

Esses estados podem estar de acordo, mas não precisam mudar ao mesmo tempo. Um prefixo pode migrar entre provedores enquanto seu titular reconhecido permanece o mesmo. Um registro cadastral pode estar correto enquanto uma rota está mal configurada. Uma autorização de roteamento pode ser válida enquanto um objeto de contato está obsoleto. Uma exportação útil deve preservar as relações entre esses estados e mostrar qual afirmação cada evidência sustenta.

O que o RDAP oferece e o que não oferece

O RDAP é a camada padrão de consulta de dados cadastrais. Seu modelo JSON descreve objetos como redes IP, números de sistemas autônomos, entidades, eventos e links. Isso facilita a consulta e a interpretação de um registro em uso entre diferentes entidades de registro. A estrutura é definida pela RFC 9083.

O RDAP responde a uma pergunta de consulta no presente: o que a entidade de registro que atende à consulta retorna para este objeto agora? A resposta pode incluir o registro atual e informações sobre eventos, mas uma resposta em tempo real não é automaticamente um pacote independente de continuidade. Por si só, ela não garante que um titular tenha uma sequência portátil e autenticada de estados anteriores, um registro completo de transições ou o material necessário para um processo ordenado de sucessão.

Essa diferença importa. Um diretório em operação é uma janela para um sistema. Uma exportação do estado cadastral é uma forma de preservar estado verificado suficiente para avaliar a continuidade quando a janela, o sistema ou a relação institucional muda.

O que o RPKI comprova e o que não comprova

O RPKI responde a uma pergunta de roteamento. Uma Autorização de Origem de Rota identifica um sistema autônomo que o titular do espaço de endereços autorizou a originar rotas para um ou mais prefixos. O perfil e as regras de validação são descritos na RFC 9582.

Essa é uma evidência valiosa, mas não é uma resposta completa para toda questão cadastral. Uma ROA válida não comprova, por si só, todo o histórico jurídico ou administrativo de um recurso, não identifica todos os contatos operacionais, não estabelece a continuidade do DNS reverso nem resolve uma disputa sobre qual estado cadastral deve ser reconhecido. A autorização RPKI é uma camada de um registro de continuidade, não um substituto para esse registro.

Uma definição de trabalho para exportação do estado cadastral

A exportação do estado cadastral é uma proposta de pacote de continuidade que torna portátil, compreensível e testável o estado verificado essencial de um recurso IPv4, IPv6 ou ASN. Ela deve permitir que um leitor independente responda a quatro perguntas:

1. De qual recurso e de qual titular reconhecido estamos falando?
2. Qual foi o último estado verificado e quando ele entrou em vigor?
3. Quais mudanças relevantes ocorreram depois desse estado?
4. Quais evidências e qual autoridade sustentam uma transição legítima ou um processo legítimo de sucessão?

Isso é mais específico do que uma cópia integral de banco de dados e mais útil do que uma captura de tela. A exportação deve conter o estado de que um sucessor precisa, deixando de fora dados de clientes sem relação com o recurso, estratégias comerciais privadas e detalhes internos de implementação que não contribuam para comprovar o recurso.

A exportação mínima útil

Uma exportação prática pode ser organizada em um pequeno conjunto de registros conectados. Cada registro deve conter um identificador estável, a data e hora de entrada em vigor, sua fonte e informações suficientes para detectar uma mudança sem explicação.

• Identidade do recurso: o prefixo IPv4, o prefixo IPv6 ou o ASN, sua relação com um recurso de nível superior ou com uma alocação, quando pertinente, e seus identificadores cadastrais.
• Titular reconhecido: a organização ou entidade reconhecida no estado verificado, o identificador cadastral, a data de entrada em vigor e o status desse reconhecimento.
• Contatos: os contatos administrativos, técnicos, de abuso e de segurança de que um sucessor ou uma parte que dependa do registro realmente precisa.
• Histórico relevante: transferências, mudanças de nome ou de organização, delegações, mudanças de status, disputas e as evidências ou autorizações associadas a cada evento.
• Relações operacionais: as relações pertinentes com provedores, usuários delegados, DNS reverso e serviços, com seus períodos de vigência e estado de encerramento.
• Referências de roteamento e segurança: o ASN de origem pertinente, referências a ROAs ou objetos RPKI, o estado de publicação e o momento em que esse estado foi observado.
• Estado de conflito: se existe uma disputa, um bloqueio ou uma reivindicação conflitante, qual recurso é afetado e qual foi o último estado não contestado.
• Trilha de auditoria: quem alterou o quê, quando, sob qual autoridade, de qual valor para qual valor e com qual resultado de verificação.
• Informações de integridade: números de versão, carimbos de data e hora, hashes de objetos, assinaturas e um manifesto de exportação para que o destinatário possa verificar a origem e detectar modificações.

A exportação não precisa reproduzir todas as tabelas internas do banco de dados. Precisa preservar as relações que dão sentido à resposta pública e tornam a transição auditável.

Por que um backup não basta

Um backup costuma ser projetado para restaurar um sistema para o mesmo operador. A exportação do estado cadastral é projetada para permitir que outra parte autorizada compreenda e verifique o estado quando o sistema, a organização ou o arranjo operacional original não puder simplesmente ser restaurado.

• Um backup pode exigir software proprietário, relações não documentadas e as credenciais originais.
• Uma exportação deve ser legível por um sucessor independente e deve identificar as evidências por trás de cada afirmação relevante.
• Um backup pode conter muito mais dados do que o titular de um recurso tem direito de receber ou deseja receber.
• Uma exportação deve se limitar ao recurso, ser autenticada, legível por máquina e portátil.

A distinção não é uma preferência técnica. É a diferença entre preservar uma máquina e preservar a capacidade de reconhecer um estado legítimo.

O que acontece quando a continuidade é necessária

Um processo de continuidade não deve começar permitindo que dois sistemas reivindiquem o mesmo recurso. Deve começar pelo congelamento do último estado verificado e pela explicitação da transição.

1. Identifique o gatilho: indisponibilidade, insolvência, comprometimento, migração, disputa ou outro evento de continuidade definido.
2. Preserve o último estado verificado: registre o recurso, o titular reconhecido, os contatos, o histórico relevante e as evidências que sustentam esse retrato do estado.
3. Verifique a exportação: confira assinaturas, hashes, carimbos de data e hora, referências de autorização e a integridade do manifesto.
4. Separe as camadas de evidência: compare o estado cadastral com o uso operacional, o DNS reverso, as observações de roteamento e o estado do RPKI, em vez de tratar uma camada como prova de todas as outras.
5. Registre o sucessor: defina como o estado anterior será substituído, como os conflitos serão tratados e como os sistemas dependentes descobrirão o sucessor reconhecido.
6. Publique a transição: torne o novo estado e o momento de sua entrada em vigor localizáveis, preservando o estado anterior como um registro histórico auditável.

O processo foi concebido para preservar a continuidade sem transformar uma indisponibilidade em oportunidade para que um reivindicante não verificado reescreva a história.

O que a exportação do estado cadastral não deve fazer

Uma exportação de continuidade não é um segundo cadastro que dá a todo destinatário o poder de reivindicar propriedade. Ela não deve criar reivindicações paralelas, contornar a política aplicável ao recurso, expor tráfego de clientes ou estratégias confidenciais, nem converter silenciosamente o uso operacional em controle administrativo reconhecido.

A exportação também deve declarar seus limites. Se um campo estiver indisponível, ocultado ou em disputa, o registro deve indicar isso. Reconhecer honestamente que algo é desconhecido é mais seguro do que apresentar um valor aparentemente completo, mas sem evidências.

Como testar uma exportação antes de uma crise

Um titular de recurso ou operador pode testar o conceito com uma revisão simples:

• Um leitor independente consegue identificar o recurso IPv4, IPv6 ou ASN exato?
• O leitor consegue identificar o último titular reconhecido verificado e a data de entrada em vigor?
• O leitor consegue reconstruir transferências, delegações e mudanças organizacionais relevantes?
• O leitor consegue distinguir o estado cadastral do roteamento atual e do uso operacional?
• O leitor consegue localizar as evidências pertinentes de RPKI e DNS reverso?
• O leitor consegue verificar se existe uma disputa ou reivindicação conflitante?
• O leitor consegue verificar quem produziu a exportação e se ela foi alterada depois?
• Um sucessor legítimo consegue usar o registro sem importar o banco de dados privado original?

Se a resposta a essas perguntas for não, a organização pode ter uma consulta em funcionamento ou um backup, mas ainda não tem um registro de continuidade testado.

Como isso se encaixa no ciclo de vida do IPv4

Um recurso IPv4 tem um ciclo de vida que inclui registros cadastrais, transferências, delegação operacional, roteamento e uma eventual mudança de uso. A exportação é o elo entre esses momentos. Comece por o que os dados cadastrais podem mostrar sobre um ciclo de vida IPv4 e depois diferencie a movimentação regional nas transferências entre RIRs de uma mudança de roteamento na migração da origem BGP.

O mesmo raciocínio se aplica à questão mais ampla da governança: quando um sistema coordena recursos únicos, a capacidade de verificar e transportar o estado não deve depender inteiramente de um único ponto administrativo indisponível. É por isso que a exportação do estado cadastral deve ser considerada junto às questões práticas de o que acontece se uma entidade de registro da Internet falhar e o que a comprovação de controle pode realmente demonstrar.

Conclusão

A exportação do estado cadastral é uma forma de tornar a continuidade concreta. Ela não substitui o RDAP, o RPKI, os dados de roteamento, o DNS reverso ou as políticas da entidade de registro. Ela conecta as evidências pertinentes em um registro autenticado, versionado e portátil que um leitor legítimo possa compreender quando não for possível simplesmente confiar no sistema original ou restaurá-lo.

Se a entidade de registro desaparecer, o objetivo não é permitir que qualquer um reivindique o recurso. O objetivo é preservar estado verificado suficiente para que a resposta legítima ainda possa ser reconhecida, testada e levada adiante.