Resumo

  • A RFC 9910 define rdap-down como busca de filhos imediatos e rdap-bottom como o conjunto de objetos mais específicos que, juntos, cobrem o intervalo solicitado.
  • Na captura da ARIN para um /21, um /22 ativo apareceu junto de um /8 administrativo; o /8 cobre o espaço residual e não é declarado filho do /21.

A gaveta que parece invertida

A forma da resposta causa estranhamento. Para 149.112.152.0/21, o serviço RDAP da ARIN devolveu NET-149-112-152-0-1, uma alocação direta ativa representada por /22, e NET-149-0-0-0-0, um objeto administrativo representado por /8.

Um /8 não pode ser descendente mais específico de um /21. O serviço também não diz isso. A contradição surge quando “bottom” é entendido como “todas as folhas abaixo deste nó”. A RFC 9910 faz outra pergunta: quais objetos registrados, no nível mais específico disponível, cobrem em conjunto todo o valor INR fornecido pelo cliente?

O /22 cobre apenas metade do /21. Para os endereços restantes, o objeto registrado mais específico disponível nessa resposta é o /8. Por isso o conjunto se sobrepõe. Ele não divide o intervalo em descendentes mutuamente exclusivos; apresenta a geometria registral necessária para cobrir a consulta.

Down não é Bottom

A consulta paralela deixa a diferença concreta. rdap-down para o mesmo /21 devolveu somente a alocação /22. Essa relação busca o próximo nível de objetos registrados abaixo do valor informado. O /8 não é filho imediato e fica fora.

rdap-bottom calcula cobertura. Quando os objetos mais específicos cobrem apenas parte da consulta, um objeto abrangente pode permanecer no conjunto para responder pelo restante. A RFC 9910 afirma que os objetos bottom não precisam ser disjuntos e que um resultado pode ser menos específico que o próprio valor consultado. A documentação da ARIN aplica a mesma regra: se os objetos encontrados não cobrem tudo, o objeto de rede mais específico que cobre o residual também é retornado.

A função poupa o cliente de reconstruir recursivamente a árvore de registros. O risco está na apresentação posterior. Se uma interface chama cada linha de “subalocação”, transforma o objeto de cobertura em uma relação falsa. O prefixo está correto; a semântica da seleção foi descartada.

O limite da evidência

Os itens retornados são objetos ip network. Eles trazem handles, endereços inicial e final, representação CIDR, tipo específico do modelo da ARIN e status. Na captura, o /22 é DIRECT ALLOCATION com status active; o /8 tem status administrative.

Esses são atributos do registro. Não provam anúncio BGP, alcance, tráfego ou autorização por ROA. Os vetores opcionais de ASN de origem estavam vazios nos dois objetos. Esse vazio não prova ausência de rota; registra apenas o estado de um campo em uma resposta e horário determinados.

A RFC 9083 define o objeto de rede IP como informação de registro. A RFC 9082 explica que uma consulta IP comum mira a rede registrada mais específica que contém integralmente o valor consultado. Nenhuma das duas converte a geometria administrativa em estado operacional.

Preservar a relação

Um registro auditável mantém a relação solicitada, o intervalo de entrada, o horário, o handle, os limites, o CIDR, o tipo e o status de cada resultado. Com isso, o /8 deixa de ser anomalia: ele cobre no registro a parte que o /22 não cobre.

Coletores BGP, objetos IRR, validação RPKI e inventário interno continuam separados. A busca bottom descreve cobertura registral; não diz quem configura o roteador, controla a conta, detém título jurídico ou anuncia uma rota agora.

Quando o nome da relação some, uma resposta correta vira uma árvore de delegação inventada. O rótulo seguro é literal: cobertura pelos objetos registrados mais baixos disponíveis para o intervalo solicitado.

Fontes