Quando os dados de registro mudam, por que uma rede em funcionamento pode desaparecer?

Imagine que seu serviço continua funcionando em uma conexão móvel, mas clientes de outra rede já não conseguem acessá-lo. Os servidores estão operando normalmente. Os cabos estão conectados. Uma possível explicação é que outra rede deixou de aceitar a rota para seus endereços depois que um registro foi alterado.

O elo que falta é a decisão entre o registro e o roteador. Uma alteração no banco de dados pode afetar a conectividade quando um sistema usa essa mudança para construir um filtro ou avaliar um anúncio. Para entender a falha, acompanhe essa cadeia. “O registro está errado” é apenas o começo do diagnóstico.

As conexões físicas podem permanecer intactas quando uma alteração de registro afeta a aceitação de rotas. Acompanhe as evidências e a política de quem recebe o anúncio.

Primeiro, pergunte qual registro mudou

Um prefixo IP é um bloco de endereços. Um número de sistema autônomo, ou ASN, identifica uma rede que troca rotas com outras redes. BGP é o protocolo que essas redes usam para anunciar quais destinos conseguem alcançar.

Vários tipos de registros acompanham essa troca. Eles respondem a perguntas diferentes:

• Registros cadastrais: qual organização está associada a um bloco de endereços no cadastro e quem deve ser contatado. A documentação do banco de dados RIPE distingue o registro de recursos, as informações de roteamento e os registros de contato, embora compartilhem um mesmo banco de dados.
• Registros do Internet Routing Registry (IRR, registro de roteamento da internet): informações que os operadores podem usar para construir listas de rotas que aceitarão. Um registro descreve o roteamento pretendido; ele próprio não anuncia uma rota.
• Registros da Resource Public Key Infrastructure (RPKI, infraestrutura de chaves públicas de recursos): incluem autorizações assinadas de origem de rota, chamadas ROAs, a partir das quais os validadores produzem dados para verificar a rede de origem e o comprimento de prefixo permitido.

Um e-mail de contato desatualizado não retira diretamente uma rota BGP. A ausência de uma rota no filtro gerado por um provedor pode fazer com que esse provedor deixe de aceitá-la. Chamar as duas situações de “dados de registro inválidos” esconde a diferença que importa.

Como um registro se transforma em uma rota rejeitada

Considere um provedor que constrói seus filtros de clientes a partir de dados de IRR. Veja uma possível sequência de falha:

1. Um registro de rota é removido, ou o conjunto de roteamento do cliente deixa de incluí-lo.
2. A próxima geração de filtros do provedor omite essa rota.
3. O novo filtro chega aos roteadores do provedor, que rejeitam o anúncio do cliente.
4. Se não restar nenhuma alternativa utilizável, as pessoas que dependem desse caminho perdem o acesso.

Os dados precisam efetivamente alimentar esse filtro para que a cadeia ocorra. A política de registro de roteamento publicada pela NTT DATA oferece um exemplo concreto de filtros de clientes baseados em IRR e atualizações automatizadas. Ela também documenta a rejeição de rotas com estado RPKI Invalid e a supressão de registros IRR conflitantes. Esses são mecanismos operacionais identificáveis, não um interruptor universal à disposição de uma entidade de registro.

O que “Invalid” realmente significa na RPKI

Na validação de origem, a rota anunciada é comparada com dados de autorização validados. A RFC 6811 define três resultados:

• Valid: pelo menos uma autorização que abrange a rota corresponde ao ASN de origem e permite o comprimento do prefixo anunciado.
• Invalid: existem dados de autorização que abrangem a rota, mas nenhum atende às duas condições.
• NotFound: nenhum dado de autorização abrange a rota.

Por exemplo, uma rota anunciada pela rede A pode passar a Invalid se sua autorização correspondente desaparecer enquanto permanecer uma autorização para a rede B que abranja a rota. Se não restar nenhuma autorização que abranja a rota, o resultado será NotFound. Aqui, “Invalid” é um resultado da validação de roteamento, não um veredicto sobre titularidade ou legitimidade institucional. A validação de origem também não autentica todo o caminho que uma rota afirma ter percorrido.

O próximo passo é a política configurada pelo operador. A RFC 8481 separa a atribuição de um estado de validação da ação tomada com base nele: a política deve ser configurada pelo operador. Uma rede configurada para rejeitar rotas Invalid pode então rejeitar esse anúncio. Uma edição no registro e uma rejeição estão conectadas por esses mecanismos; não são o mesmo evento.

Por que algumas pessoas perdem o acesso antes de outras

Nem todas as redes usam os mesmos filtros, provedores ou dados no mesmo momento. A RFC 7115 explica que os caches de RPKI podem ter visões diferentes e que não há um intervalo único garantido para a chegada das atualizações aos roteadores.

No exemplo inicial, uma rede pode já ter agido com base nos dados alterados enquanto outra ainda tem um caminho aceito. Isso torna possível uma interrupção parcial. Não prova que a entidade de registro tenha causado uma interrupção específica: os engenheiros ainda precisam examinar a rota afetada, os dados em uso e a decisão que a rejeitou.

Encontre o elo rompido antes de fazer mais alterações

A pergunta útil para a recuperação é específica: qual sistema deixou de aceitar qual anúncio, e por quê? Um operador pode investigá-la com o provedor:

1. Identifique o anúncio. Registre o prefixo afetado e o ASN de origem e verifique se a rota esperada continua sendo anunciada.
2. Localize a rejeição. Compare o filtro instalado pelo provedor e o resultado da validação com a rota. Pergunte qual fonte de dados e qual atualização produziram essa decisão.
3. Preserve as evidências. Guarde os registros, as observações e as marcações de data e hora relevantes para que seja possível distinguir uma atualização equivocada de um anúncio não autorizado.
4. Corrija e verifique. Coordene a correção exata do registro ou da configuração, confirme que ela chegou aos sistemas que consomem os dados e teste o acesso a partir das redes que apresentaram falha.

Desativar a validação em toda parte também removeria a proteção contra anúncios indevidos. A tarefa operacional é restabelecer as evidências corretas e o roteamento pretendido e, depois, verificar o resultado. Uma edição bem-sucedida no banco de dados, por si só, não demonstra que os clientes conseguem se conectar novamente.

A questão mais profunda: evidências úteis podem se transformar em poder concentrado

É aqui que a cadeia técnica encontra o argumento de Lu Heng. Um administrador não precisa encaminhar os pacotes de ninguém para influenciar a acessibilidade de uma rede. Se outros sistemas dependem dos registros que ele controla, suas decisões podem impor custos a operadores e clientes muito além de seu escritório.

Na Nota 65, Primazia do Código em Funcionamento, Lu Heng argumenta que a coordenação deve ser limitada pelas necessidades das redes em operação. Um papel na manutenção de registros não pode se ampliar por conta própria até se tornar um mandato político permanente. O fato de um registro estar assinado responde a uma pergunta técnica sobre a declaração; não estabelece o direito de governar todos os afetados por ela.

Sua proposta vai além de um processo melhor de reclamações. As regras comuns devem proteger a unicidade, o controle verificável e a interoperabilidade, enquanto os participantes validam o estado localmente e decidem quais mudanças compatíveis adotar. Um novo comitê com poder de veto ilimitado reproduziria o problema sob outro nome.

A continuidade precisa de uma saída que outras redes consigam usar

Uma alternativa utilizável precisa levar adiante registros confiáveis, declarações de segurança e relações operacionais. Outras redes precisam conseguir verificar e usar esses registros. Simplesmente copiar um banco de dados não faz com que aceitem um substituto, e declarar independência não corrige uma rota rejeitada.

A Nota 72 explicita o resultado pretendido: registros corretos, continuidade operacional e capacidade real de deixar um coordenador que esteja falhando. O desafio prático é construir essa capacidade sem perder a unicidade compartilhada e a compatibilidade que permitem a comunicação entre redes independentes.

O guia de exportação do estado do registro explora a parte desse trabalho que envolve levar os registros para o novo ambiente. Esse é um componente da transição, ao lado da verificação, da adoção pelos operadores e dos testes de continuidade.

Prepare-se enquanto o serviço ainda funciona

Peça à sua equipe que acompanhe um bloco de endereços importante desde seus registros até os provedores e clientes que dependem dele. Quem pode alterar cada registro? Quem o consome? Como um erro seria corrigido se o administrador atual estivesse indisponível ou sob contestação?

Estabelecer essas respostas entre organizações leva tempo. Encontrá-las antes de uma falha cria espaço para agir; descobri-las durante uma interrupção deixa o custo com os clientes. A urgência está em construir independência prática enquanto a continuidade ainda pode ser protegida.

Continue com a Nota 65: Primazia do Código em Funcionamento para acompanhar o argumento completo de Lu Heng em favor de uma coordenação baseada em redes em operação, verificação local e adoção voluntária.