Primeiro, esclareça: você quer consultar registro, rota, localização ou risco?
As ferramentas de consulta de IP são variadas, mas a distinção central está na pergunta que cada uma responde. Para saber sob qual órgão um bloco de endereços está registrado, o e-mail de contato ou o canal de denúncia de abuso, consulte os dados de registro via RDAP; para saber quais sistemas autônomos anunciam atualmente um determinado prefixo, consulte um snapshot da tabela de rotas BGP; para saber se um prefixo específico possui autorização de origem de rota válida, consulte o estado de validação RPKI; e para avaliar o risco de abuso ou proxy de um IP, consulte o relatório de reputação de IP. Misturar essas perguntas, ou esperar que uma única ferramenta forneça simultaneamente localização física precisa, caminho em tempo real e pontuação de risco comercial, geralmente leva a erros de julgamento.
O campo de país na página pode vir do registro de recursos ou de um banco de dados GeoIP; é preciso ler a fonte primeiro. Se um usuário vê inconsistência entre país, idioma da página ou marca da rede e infere que está usando VPN ou Anycast, a evidência não é suficiente. Você pode primeiro usar a Consulta de IP para registrar cada campo, e depois verificar separadamente RDAP, BGP e estimativa de localização; quando estiver preocupado com reputação, consulte o Reputação de IP: como interpretar riscos e bloqueios. Essas ferramentas não respondem à mesma pergunta.
Ao lidar com falhas ou incidentes de segurança, a equipe de operações deve limitar a conclusão de cada ferramenta ao escopo de sua evidência. Por exemplo, a consulta de rota BGP só informa os anúncios de rota observados e os atributos AS_PATH, e não pode provar diretamente por quais enlaces físicos os pacotes passam de ponta a ponta. Use a saída da consulta como pista de investigação e combine com outras evidências, como traceroute, dados de fluxo ou contadores de interface, para formar um julgamento confiável. Evitar negar todas as outras informações com base em um único resultado de consulta é a disciplina básica para interpretar dados de IP.
Quais perguntas de registro o RDAP pode responder?
O RDAP (Registration Data Access Protocol) fornece dados de registro por meio de respostas estruturadas, usado tanto para recursos de numeração da Internet quanto para registro de domínios; este artigo foca nos recursos de rede IP e sistemas autônomos. A resposta pode conter faixas de endereços, handles de objeto, papéis de contato e eventos, mas a publicidade e a completude dos campos são determinadas pela política do órgão de registro e pelos registros específicos. Não se pode presumir que toda consulta terá usuário final, histórico completo ou e-mail de abuso disponível.
É preciso notar que o endereço de contato no RDAP é um endereço de registro público, geralmente o endereço comercial ou legal da organização registrante, e não pode ser equiparado à localização do dispositivo IP ou à posição atual do usuário. Por exemplo, o endereço RDAP de uma empresa multinacional pode estar registrado na cidade da sede, enquanto o servidor que realmente usa esse IP pode estar em um data center em outro país. Usar o mapa do endereço RDAP diretamente como "localização de IP" superestima a precisão da localização. As especificações RFC 9082 e RFC 9083 definem a estrutura de consulta e resposta do RDAP, mas não exigem que os dados de registro contenham localização física.
Quando é necessário confirmar o responsável pelo registro de um prefixo, usar diretamente a ferramenta Consulta RDAP para ver o registro original é mais confiável do que depender de resumos de terceiros. O resultado da consulta mostrará o nome da rede, código do país, órgão de registro, estado (como allocated, assigned), histórico de eventos e e-mail de contato para abuso. Esses campos ajudam o operador a julgar se um bloco de endereços tem informações de registro desatualizadas ou se pertence a algum tipo de alocação especial, mas não permitem inferir se esse bloco está lançando ataques, hospedando serviços maliciosos ou se pertence a algum usuário final. A evidência RDAP cobre apenas o ciclo de vida do registro, não o comportamento em tempo real.
Por que o ASN não equivale à marca do provedor de serviços?
O ASN (Número de Sistema Autônomo) identifica um domínio de política de roteamento controlado por um ou mais operadores de rede. Prefixos sob o mesmo ASN podem ser usados para vários negócios, incluindo hospedagem em data center, serviços de nuvem, CDN, redes de conteúdo e serviços de proxy transparente fornecidos para diferentes marcas de varejo ou locatários. Portanto, apenas com o ASN não se pode determinar a qual marca de consumidor ou localização específica um IP pertence. O ASN de um grande provedor de nuvem pode hospedar simultaneamente endereços IP de dezenas de empresas, e o nome da organização registrante pode não ter nenhuma relação direta com essas empresas.
Um sistema autônomo pode cobrir várias regiões e negócios, e o nome da organização pode diferir da marca de varejo, cliente ou locatário de nuvem. Operadoras multinacionais podem anunciar prefixos em vários países, e a mesma empresa pode gerenciar vários ASNs. Anycast é uma das possíveis formas de implantação de serviço, cujos limites operacionais podem ser consultados na RFC 4786, mas não se pode inferir diretamente a localização geográfica de um IP específico, a identidade do locatário ou a implantação Anycast a partir do país de registro do ASN ou do nome da empresa.
Na análise de segurança, um ASN pequeno também não pode ser simplesmente igualado a alto risco. Um sistema autônomo com poucos prefixos e histórico curto pode ser um novo provedor de conteúdo legítimo, uma rede de pesquisa ou um ISP regional. O julgamento de risco deve se basear no comportamento de roteamento, estabilidade histórica de anúncios, estado de validação RPKI e registros reais de reclamações de abuso, e não apenas no tamanho do ASN ou na antiguidade das informações de registro. Consultar as rotas BGP e o histórico de um ASN pode ajudar a entender seus hábitos de anúncio, mas ainda é apenas uma das evidências para auxiliar o julgamento.
Prefixo BGP, ASN de origem e AS_PATH
A consulta BGP exibe as informações do plano de controle recebidas por um ponto de observação específico, incluindo prefixo, ASN de origem, AS_PATH e horário. Ao consultar um único IP, a ferramenta pode selecionar o prefixo mais longo que cobre esse IP. A correspondência de prefixo mais longo é uma regra importante na tabela de encaminhamento: quando há uma correspondência mais específica na tabela, o pacote é encaminhado conforme essa entrada; isso difere da seleção de melhor caminho no BGP para múltiplas rotas candidatas ao mesmo prefixo. Nenhum dos dois pode fornecer diretamente uma lista completa de enlaces físicos.
O atributo AS_PATH lista a sequência de sistemas autônomos pela qual a rota passou, mas não equivale ao caminho real de encaminhamento dos pacotes no plano de dados. Políticas de roteamento, preferência local, valores de MED, confederações BGP e túneis MPLS podem fazer com que o caminho real dos pacotes seja diferente do AS_PATH do plano de controle. Por exemplo, um pacote pode passar por um peer remoto que não aparece no AS_PATH. Portanto, usar uma Consulta de rotas BGP para determinar o anunciante atual de um prefixo pode ajudar a avaliar o controle de roteamento, mas não permite inferir com precisão o caminho de tráfego de ponta a ponta.
Se precisar ver o histórico de anúncio de um prefixo, como se ele já mudou de ASN de origem ou se houve anúncios mais específicos, consulte os dados de Histórico BGP. Instantâneos históricos podem mostrar o estado do anúncio e as mudanças no AS_PATH em um determinado momento, mas a ausência de dados históricos também pode ocorrer devido a pontos de observação incompletos ou rotas não coletadas. Qualquer visão de um único coletor de rotas é apenas uma parte do estado global de roteamento da Internet e não pode ser considerada a verdade completa. Combinar dados de múltiplos pontos de observação permite uma compreensão mais confiável da estabilidade do roteamento.
RPKI: Valid, Invalid e NotFound
O RPKI (Resource Public Key Infrastructure) emite ROAs (Route Origin Authorizations) para autorizar um determinado ASN a anunciar um prefixo específico e, opcionalmente, especificar o comprimento máximo do prefixo (maxLength). Ao realizar a validação de origem, o roteador ou a ferramenta de validação compara o prefixo e o ASN de origem da rota BGP com o conjunto de VRPs (Validated ROA Payloads) gerado a partir dos ROAs válidos. Os resultados da validação são classificados em três estados: Valid, Invalid e NotFound.
O estado Valid significa que existe pelo menos um VRP cujo prefixo autorizado cobre o prefixo anunciado, o ASN de origem corresponde e o comprimento do prefixo está dentro do intervalo permitido (geralmente considerando o maxLength). O estado Invalid significa que existe um ou mais VRPs cobrindo o prefixo, mas o ASN de origem não corresponde ou o comprimento do prefixo excede o intervalo autorizado. De acordo com a RFC 6811, Invalid não equivale automaticamente a sequestro de rota ou atividade maliciosa, pois erros de configuração, atrasos na atualização de ROAs ou falhas operacionais do próprio operador podem levar a esse estado.
O estado NotFound indica que não há nenhum VRP cobrindo o prefixo, geralmente porque o detentor do recurso não criou um ROA ou o validador ainda não obteve os dados mais recentes de ROA. NotFound não deve ser interpretado como um sinal de ataque; apenas indica que a autorização de origem não pode ser determinada pelo RPKI. Usar uma ferramenta de Validação RPKI permite verificar o estado de validação de um prefixo IP específico, os detalhes do ROA correspondente e o horário da validação. Os operadores devem registrar o timestamp de cada validação, pois os dados do RPKI são dinâmicos e o estado de um prefixo pode mudar conforme ROAs são publicados ou revogados.
Por que Valid não é um certificado de segurança?
A validação de origem RPKI verifica se o ASN de origem e o comprimento do prefixo de uma rota são autorizados pelos dados dos ROAs validados naquele momento. Um resultado Valid não autentica o restante do AS_PATH, não comprova a segurança dos pacotes nem a confiabilidade dos dispositivos finais, e não avalia o comportamento dos usuários ou a segurança do conteúdo. Uma rede maliciosa pode ter um ROA válido para seu próprio prefixo, obter o estado Valid para sua rota e ainda realizar atividades nocivas na própria infraestrutura. Portanto, um resultado Valid para a rota que abrange um IP não garante que esse endereço não seja usado para abusos ou que o serviço seja confiável.
Da mesma forma, o estado Invalid não pode ser diretamente julgado como sequestro de rota. Cenários comuns de engenharia incluem: operadores migrando prefixos sem atualizar o ROA em tempo hábil, ou definindo erroneamente o maxLength de modo que anúncios mais específicos não sejam permitidos. Esses são problemas de configuração no registro de rotas e podem ser corrigidos ajustando o ROA para restaurar o estado Valid. Por outro lado, um sequestrador real pode explorar prefixos não cobertos (ou seja, NotFound) para fazer anúncios, o que reforça que o estado por si só não constitui uma conclusão de segurança.
Ao reportar a um operador, preserve o horário da observação, o prefixo específico, o ASN de origem, o ASN autorizado do VRP que cobre e o maxLength, bem como o validador ou fonte de dados. Uma redação ilustrativa seria: "No horário listado, 203.0.113.0/24, origem AS64496 foi validado como Invalid; existe um VRP cobrindo, mas não há registro que atenda simultaneamente aos requisitos de origem e comprimento." Aqui são usados recursos de exemplo de documentação, não um alerta de rota real. O destinatário precisa verificar o conjunto completo de correspondências, não apenas um VRP não correspondente e ignorar outra autorização válida.
Por que o país de registro e o país de localização diferem?
A divergência entre o país de registro e o país de localização não indica automaticamente que a localização está errada ou que existe Anycast. Os endereços IP são alocados por registros regionais da Internet a organizações multinacionais, que podem optar por registrar no país da sede enquanto o uso real ocorre em filiais ou data centers globais. Por exemplo, uma empresa europeia registra todo o bloco de IP na Holanda, mas os servidores alugados estão em Singapura; ao consultar, o país de registro mostra Holanda, enquanto as medições de latência de rede e as observações de rota apontam para Singapura. Isso é normal, não uma anomalia.
Após um ISP upstream obter um grande bloco de recursos, ele pode alocá-lo a diferentes clientes ou regiões, e os registros de registro, as bases de dados de geolocalização comercial e os caches de sites são atualizados separadamente. Transferências de recursos, mudanças de alocação ou revisões de dados podem causar defasagens temporais, e não se deve presumir que elas serão sincronizadas após um número fixo de semanas ou meses. Deve-se registrar o horário e a fonte específicos da consulta, distinguindo a entidade de registro atual, o instantâneo histórico e a estimativa de localização, evitando substituir o significado de um campo pelo de outro.
Os fatores de layout de rede incluem CDNs, provedores de nuvem e linhas dedicadas transnacionais, que implantam endereços do mesmo prefixo em vários países. Nesse caso, qualquer "país de registro" único não pode representar o ponto de entrada real do tráfego. Para determinar se um IP oferece serviço em um país específico, deve-se combinar o AS path na rota BGP, medições ativas de ping/traceroute e informações públicas de região do provedor de nuvem. Inferir Anycast apenas pela inconsistência de país é evidência insuficiente.
Qual a diferença entre Anycast e broadcast?
Anycast permite que várias instâncias de serviço usem o mesmo endereço, e o roteamento encaminha uma solicitação para uma das instâncias alcançáveis; em implantações comuns na Internet, o prefixo que contém esse endereço é anunciado de vários locais. A instância selecionada depende das políticas de roteamento e não garante proximidade geográfica, menor latência ou menor carga. Já o broadcast envia o pacote para vários receptores dentro do domínio de broadcast; os dois são completamente diferentes. As práticas de engenharia de Anycast podem ser consultadas na RFC 4786.
Para avaliar Anycast, combine a documentação explícita do operador sobre o endereço de serviço com medições em múltiplos locais e horários, além de identificadores de instância. O mesmo ASN pode aparecer em vários pontos Anycast, portanto não é necessário que os ASNs de destino sejam diferentes; ASNs distintos ou caminhos de traceroute diferentes também não provam automaticamente Anycast, pois mudanças de rota, túneis e limitações de medição podem afetar os resultados. Deve-se indicar até que ponto as evidências suportam a conclusão, sem rotular o endereço apenas com base em alguns códigos de país.
Um erro comum é tratar diferenças no campo país como prova de Anycast, por exemplo quando o mesmo IP aparece como Estados Unidos em uma base comercial e Alemanha em outra. Isso apenas indica inconsistência nas fontes de dados de geolocalização, podendo ser resultado de problemas de registro, roteamento ou atualização de banco de dados, não uma condição suficiente para Anycast. Qualquer julgamento operacional deve distinguir claramente entre possibilidade e prova, evitando transformar suposições não verificadas em conclusões.
Caso ilustrativo: quem são o registrante, o operador e o locatário?
O cenário a seguir é ilustrativo e não se baseia em medições reais. Suponha a consulta ao endereço de exemplo da documentação 192.0.2.10: o RDAP mostra o país de registro como Estados Unidos, a entidade registrante como Example Corp, enquanto o ASN de origem anunciado no BGP pertence a um provedor de nuvem europeu. Essa diferença pode ocorrer porque a Example Corp alugou o bloco de endereços para o provedor de nuvem, que implantou nós de borda em Frankfurt e Tóquio sem atualizar as informações de registro. Apenas com esses dados, não é possível confirmar a localização física atual do IP nem se ele usa Anycast.
Continuando a hipótese: dois pontos de medição próximos a Frankfurt e Tóquio alcançam, cada um, a instância de serviço local e obtêm identificadores de instância diferentes e verificáveis, enquanto o alvo da solicitação é o mesmo endereço de exemplo da documentação 192.0.2.10. Combinado com a documentação explícita do operador sobre Anycast para esse endereço, isso sustenta o julgamento de implantação em múltiplos locais. Aqui descrevemos apenas um exemplo lógico, sem afirmar que qualquer ponto do globo obtém latência inferior a 10 milissegundos. O RPKI Valid apenas valida a autorização de origem do prefixo, não prova a localização da instância.
Neste caso, as incógnitas incluem: a identidade específica do locatário, se as portas de serviço estão abertas para todas as regiões, o mecanismo de sincronização de estado entre instâncias e se há filtragem de pacotes na rede intermediária. Os operadores devem registrar essas incógnitas com precisão, em vez de usar o rótulo "Anycast" para mascarar a falta de evidências. Classificação não implica má intenção, e a ausência de correspondência não implica ataque; delimitar claramente os limites é a base do julgamento profissional.
Por que os registros históricos e os resultados atuais divergem?
Os eventos do RDAP geralmente são descritos por campos como eventAction e eventDate, por exemplo registration ou last changed; algumas interfaces os resumem como "updated". Essas datas descrevem eventos do objeto de registro, não a data de realocação física do servidor. Alterações de e-mail, status ou dados administrativos podem mudar a data de atualização, e a localização do serviço pode mudar sem se refletir nos campos relevantes. Deve-se preservar os nomes originais dos eventos, sem interpretar todas as datas como migração de endereço.
A divisão de prefixos e a transferência de recursos são causas comuns. Quando um bloco /16 é dividido em vários /24, alguns sub-blocos podem ser alocados a outras organizações, mas o campo país do registro pai mantém o valor original. Nesse caso, consultar o RDAP de um /24 específico pode retornar o valor histórico do país do pai, enquanto a rota BGP mostra que esse sub-bloco já é anunciado por um ASN de outro país. Diferentes pontos de observação também causam inconsistência: bases IP comerciais baseiam-se em fontes e horários de coleta distintos, e as diferenças de snapshot podem chegar a meses.
O exemplo hipotético a seguir mostra como registrar as evidências. O tratamento correto é preservar todos os registros originais e anotar o horário da consulta. Por exemplo: em janeiro de 2024, o RDAP mostrava país Reino Unido; em junho de 2024, o caminho BGP passava pela Alemanha; em setembro de 2024, o destino de um traceroute em certo ponto de observação estava nos Países Baixos. Não se pode simplesmente dizer "o IP mudou para os Países Baixos"; deve-se dizer "existem divergências entre horários e pontos de observação, possivelmente envolvendo ajustes de rota ou atraso de banco de dados". Isso preserva as evidências e evita inferências excessivas.
Como combinar evidências e preservar incógnitas?
Um julgamento completo de consulta de IP deve ser dividido em quatro categorias de evidência. O contexto de registro vem do RDAP e WHOIS, incluindo entidade registrante, país, data de registro, e-mail de contato e status, mas não contém localização física nem identidade do usuário final. O estado de roteamento vem do BGP e RPKI, incluindo ASN anunciado, caminho AS, RPKI válido ou inválido e visibilidade, refletindo apenas a alcançabilidade do plano de controle, sem garantir o caminho completo do plano de dados. A estimativa de localização vem de bases IP comerciais, latência e traceroute, sendo um julgamento probabilístico.
O comportamento direto deve ser registrado separadamente, como se houve varredura ativa, resolução de domínio malicioso ou resposta a portas específicas. Um IP com registro de ISP residencial, mesmo que a geolocalização corresponda a uma cidade, não representa necessariamente um usuário doméstico real, pois podem existir serviços de proxy ou hospedagem. Os pontos essenciais sobre IP residencial versus IP nativo estão em IP residencial, de ISP e de datacenter: qual a diferença?. Quando a cobertura de pontos de observação é insuficiente, o mesmo IP pode parecer inalcançável em algumas regiões, o que não prova inalcançabilidade global, conforme Reputação de uma sub-rede /24: cobertura e risco.
Suponha país de registro Canadá, ASN gerenciado por um ISP canadense, RPKI Valid, bases comerciais estimam Toronto e alguns pontos de medição canadenses apresentam baixa latência. Pode-se afirmar que esses resultados são compatíveis com localização de serviço no Canadá, mas não se deve escrever isso como prova de localização física, nem inferir operação normal a partir do RPKI. Registro é dado, roteamento é observação, localização é estimativa e registros de comportamento têm fonte e limites de medição; todas as conclusões precisam indicar momento, condições e partes ainda não confirmáveis.
Perguntas frequentes e materiais de revisão
Pergunta frequente um: mudança de ASN significa troca de operadora? Não necessariamente. O ASN representa o domínio de política de roteamento; grandes operadoras podem possuir vários ASNs, e empresas podem migrar para provedores de nuvem mantendo o bloco IP original. É preciso verificar se o prefixo IP é anunciado por ASNs diferentes na mesma rota BGP, ou se há mudanças no caminho AS, e combinar com informações de registro para determinar se houve realmente troca de provedor de rede.
A validação de origem RPKI não previne todos os ataques de roteamento, nem autentica o AS_PATH completo. A redação rigorosa é "a rota é Valid, Invalid ou NotFound em relação ao conjunto atual de VRP"; não se deve simplificar Invalid como "ROA inválido", pois não são o mesmo conceito. O RDAP também não é uma ferramenta de localização de indivíduos: mesmo que objetos públicos contenham informações pessoais ou de contato, ainda são dados de registro de recursos e não permitem identificar a pessoa que faz a solicitação atual nem o endereço preciso.
O framework de revisão de chamados deve exigir que o solicitante forneça: horário da consulta (UTC), IP ou prefixo específico, snapshot de RDAP/WHOIS, tabela de rotas BGP ou fonte de observação de traceroute, estado atual (como falha de conexão ou vazamento de rota) e a demanda específica. Com base nisso, os operadores primeiro verificam os campos de registro, depois o RPKI e o caminho AS, e por fim consultam localização e medições ativas. Usar esse framework reduz erros de julgamento como "o campo país não corresponde, então foi hackeado".
