Resumo

  • O RFC 9877 define geofeed1, a relação geofeed e o tipo application/geofeed+csv, permitindo que um objeto de rede no RDAP aponte para uma geofeed em HTTPS.
  • O link comprova uma rota de descoberta em determinada resposta. Não comprova a atualidade de cada linha, a presença física de uma rede ou a localização de uma pessoa.
  • Um uso responsável guarda o intervalo do objeto, elimina linhas fora dele, verifica a autoridade do publicador e a idade dos dados e submete o resultado a uma política própria.

Uma consulta pelo endereço retorna o objeto mais específico e nenhum link. Ao subir para o objeto pai, a geofeed aparece. O sistema poderia encerrar a busca com uma etiqueta de país. Mas qual foi o fato produzido: a ausência no filho, a presença no pai ou a linha encontrada no arquivo?

Cada elemento pertence a uma camada diferente.

Publicado no Standards Track da IETF em outubro de 2025, o RFC 9877 organiza justamente a primeira camada. A resposta RDAP pode usar sua estrutura comum de links para apresentar uma relação geofeed, com URL HTTPS e o tipo recomendado application/geofeed+csv. O identificador geofeed1 sinaliza o comportamento da extensão.

Isso elimina improvisos na forma de descobrir a fonte. O documento, porém, declara fora de escopo o ato de buscar e usar a geofeed. Não é omissão: é uma divisão de responsabilidades. O diretório informa onde há uma declaração; não inspeciona datacenters, rotas anycast ou a posição de usuários.

Uma declaração de conformidade com limites

Quando o servidor anuncia geofeed1 em rdapConformance, deve fazê-lo nas respostas de consulta ou busca que contenham objetos de rede e na resposta de ajuda. Se ele possui uma URL para o objeto e pode fornecê-la, deve incluir o link. Restrições regulatórias ou semelhantes podem impedir a divulgação.

A ausência do link passa a permitir uma conclusão estreita: naquele servidor, para aquele objeto e naquelas condições, a geofeed não está disponível. Não permite afirmar que o pai também não tenha uma, que o detentor nunca publicou outra fonte ou que o prefixo não tenha geografia operacional.

Há ainda o caso inverso. Relações e tipos já registrados podem ser usados numa resposta RDAP sem a declaração geofeed1. Portanto, software cuidadoso lê separadamente a capacidade anunciada e os links efetivamente recebidos. Um único campo booleano cria lacunas de evidência.

O uso obrigatório de HTTPS protege o canal e autentica o endpoint web. A WebPKI não demonstra, sozinha, que esse endpoint pode falar por todos os prefixos no CSV. Integridade de transporte e autoridade sobre recursos numéricos são controles distintos.

O objeto pai amplia a fronteira

Pelo RFC 9082, a consulta IP devolve o objeto de rede mais específico que cobre o alvo. O RFC 9877 admite que a geofeed esteja apenas num pai menos específico e sugere que o cliente avalie a subida recursiva.

Ao subir, é preciso levar junto o limite. Se o arquivo compartilhado contiver endereços além do objeto que apresentou o link, todas essas linhas devem ser ignoradas. O fato de o arquivo ser válido não autoriza sua totalidade no contexto da consulta. O intervalo do objeto funciona como fronteira de competência.

O RFC 8805 recomenda verificar se o publicador tem autoridade sobre os recursos relevantes. O bootstrap do RFC 9224 ajuda a alcançar o serviço RDAP capaz de fazer afirmações autorizadas sobre a disposição do recurso. Isso melhora a procedência do apontador; não certifica o conteúdo geográfico de cada linha.

Uma geofeed é uma declaração operacional do detentor do espaço. Ela pode ser deliberadamente aproximada, permanecer em cache depois de uma mudança ou representar um ponto de presença sem descrever o caminho de cada cliente. Redes móveis, anycast e alocações multinacionais tornam especialmente frágil a ideia de um único lugar. O registro correto é “geografia declarada para este prefixo, neste instante e nesta granularidade”, não “pessoa localizada”.

Autenticação e exatidão não são sinônimos

O RFC 9632, que tornou o RFC 9092 obsoleto, descreve uma autenticação RPKI opcional. Uma assinatura válida pode vincular melhor o arquivo a um certificado que cobre o espaço de endereços. Ainda assim, não confirma a semântica do local, não torna o dado atual e não autoriza decisões de acesso, fraude ou aplicação de regras.

O processo precisa conservar estados independentes: link descoberto, arquivo obtido, canal validado, intervalo registrado, linhas filtradas, publicador verificado, assinatura avaliada, idade calculada, finalidade de privacidade aprovada e efeito observado. Reduzir tudo a “localizado” inviabiliza uma investigação posterior.

A frequência de coleta também revela a idade real do conhecimento. O RFC 9877 proíbe consultas frequentes em tempo real que causem carga indevida. O RFC 9632 recomenda obedecer aos sinais HTTP e, sem eles, não coletar mais de uma vez por semana. Uma chamada instantânea a uma API não rejuvenesce a fonte que ela consulta.

Quanto à privacidade, o publicador deve evitar expor a localização de qualquer indivíduo, e o operador de registro precisa avaliar se o ambiente regulatório permite oferecer a função. Descoberta padronizada não remove limitação de finalidade nem transforma um dado de infraestrutura em identificação pessoal legítima.