Quem trabalha com provedor de Internet provavelmente já viu esse tipo de reclamação:

“Meu cliente está no Paraná, mas o site acha que ele está em São Paulo.”
“O streaming está dizendo que estou em outro país.”
“O banco bloqueou o acesso porque achou estranho o local do IP.”
“O Google está mostrando previsão do tempo de outra cidade.”

É uma situação meio ingrata, porque na maior parte das vezes a rede está funcionando. O cliente navega, o BGP está ok, o DNS responde, o traceroute chega, a latência está aceitável.

Mas, para o usuário final, a percepção é simples: alguma coisa está errada com a Internet dele.

E, muitas vezes, está mesmo. Não na conectividade, mas na forma como aquele endereço IP está sendo geolocalizado por terceiros.

IP não tem cidade gravada dentro dele

A primeira coisa importante é entender que um IP não nasce com uma cidade dentro dele.

Não existe, no protocolo IP, um campo dizendo:

este endereço fica em Apucarana

ou:

este prefixo pertence a Londrina

A geolocalização por IP é uma inferência. Empresas de conteúdo, bancos, CDNs, plataformas antifraude, buscadores, serviços de streaming e bases comerciais tentam descobrir onde aquele IP provavelmente está sendo usado.

Para isso, elas cruzam várias informações: dados de registros de Internet, comportamento de tráfego, medições, histórico, informações de usuários, bases comerciais, DNS, BGP, entre outras coisas.

Na maioria dos casos funciona bem o suficiente. Mas quando erra, incomoda bastante.

Um provedor pode receber um bloco novo, comprar ou transferir recursos, mudar prefixos entre cidades, ativar um POP novo, reorganizar CGNAT, dividir IPv6 por região, trocar upstreams ou simplesmente começar a usar um bloco que antes estava associado a outra localidade.

Só que as bases externas podem demorar para aprender isso.

E aí começam os chamados.

Onde entra o geofeed

 O geofeed é uma forma padronizada do próprio operador da rede dizer:

“Estes prefixos IP estão sendo usados nestas localidades.”

Ele não muda o roteamento. Não mexe no BGP. Não anuncia nada para a Internet. Não é uma sessão com upstream.

É só um arquivo CSV publicado em HTTPS, seguindo um formato definido na RFC 8805 [1].

 Um exemplo simples:

192.0.2.0/24,BR,BR-PR,Apucarana,
198.51.100.0/24,BR,BR-PR,Londrina,
203.0.113.0/24,BR,BR-SP,Sao Paulo,
2001:db8:100::/48,BR,BR-RS,Porto Alegre,

Cada linha associa um prefixo a uma localização aproximada.

O formato é:

ip_prefix,alpha2code,region,city,postal_code

Na prática:

192.0.2.0/24,BR,BR-PR,Apucarana,

quer dizer:

o prefixo 192.0.2.0/24 está no Brasil, no Paraná, em Apucarana

A vírgula no final é importante. Ela representa o último campo, postal_code, vazio.

O que cada campo significa

O primeiro campo é o prefixo IP. Pode ser IPv4 ou IPv6, em formato CIDR.

 Exemplos:

192.0.2.0/24,BR,BR-PR,Apucarana,
2001:db8::/32,BR,BR-PR,Londrina,

O segundo campo é o país, usando ISO 3166-1 alpha-2. Para Brasil, usamos BR.

 O terceiro campo é a região, usando ISO 3166-2. No caso dos estados brasileiros:

BR-PR  Paraná
BR-SP  São Paulo
BR-SC  Santa Catarina
BR-RS  Rio Grande do Sul

A lista oficial pode ser consultada na plataforma da ISO [4]. Para consulta rápida, também existe a página ISO 3166-2:BR, que lista os códigos dos estados brasileiros [5].

O quarto campo é a cidade.

O quinto campo é o código postal. Ele existe no formato, mas normalmente não recomendo usar para provedor. A própria RFC trata esse campo com cuidado, porque ele pode dar uma granularidade exagerada [1].

Para ISP, na maioria dos casos, país, estado e cidade já são suficientes.

Geolocalização é aproximação, não GPS

Esse ponto é mais importante do que parece.

Quando falamos de geofeed, é fácil cair na tentação de tentar ser preciso demais. Mas geolocalização por IP não é GPS.

Na NANOG 96, o Sid Mathur apresentou uma palestra chamada High-quality IP Geofeeds using AI Coding Assistants and MCP. Uma das mensagens mais úteis da apresentação é justamente essa: geolocalização IP é estatística e inexata. O ideal é pensar em regiões geográficas, não em um ponto exato no mapa [6].

Ele dá uma provocação boa: mais precisão nem sempre significa mais qualidade.

Para um ISP fixo, que sabe que determinado prefixo atende uma cidade específica, faz sentido informar a cidade:

192.0.2.0/24,BR,BR-PR,Apucarana,

Mas se o mesmo prefixo atende várias cidades próximas, talvez seja melhor parar no estado:

192.0.2.0/24,BR,BR-PR,,

Isso evita resolver o problema de um cliente e criar problema para outro.

Na mesma apresentação, ele também comenta casos bem reais: usuários bloqueados por conteúdo regional, streaming achando que a pessoa está em outro país, site mostrando clima errado e ISPs recebendo reclamações por algo que, muitas vezes, está fora da camada de conectividade [6].

Quem vive operação sabe que isso acontece.

O geofeed resolve tudo?

Não.

E é importante ser honesto aqui.

Publicar geofeed não obriga Google, Netflix, bancos, MaxMind, IPinfo, Cloudflare ou qualquer outro consumidor a aceitar imediatamente aquela informação.

A RFC 8805 trata o geofeed como uma fonte publicada pelo operador. Os consumidores podem coletar, validar, cruzar com outras bases e decidir se vão usar ou não [1].

Mesmo assim, publicar corretamente melhora muito sua posição.

Antes, você dependia de abrir chamado manual em várias bases diferentes, cada uma com um processo. Com geofeed, você cria uma fonte pública, padronizada e descobrível automaticamente.

Não é garantia de correção instantânea, mas é uma prática operacional muito melhor.

Como os outros descobrem seu geofeed?

Publicar o arquivo em uma URL é só parte da história.

Você precisa indicar, nos registros do bloco IP, onde está esse arquivo.

É aí que entra a RFC 9632 [2].

Ela define como associar um arquivo geofeed aos objetos de registro de recursos IP, como inetnum e inet6num.

Existem duas formas principais.

 A forma mais nova é usar o atributo próprio:

geofeed: https://geo.exemplo.com.br/geofeed-192.0.2.0-24.csv

A forma compatível com ambientes que ainda não suportam o atributo específico é usar remarks:

remarks: Geofeed https://geo.exemplo.com.br/geofeed-192.0.2.0-24.csv

O importante é que o consumidor consiga olhar para o registro do bloco e descobrir que existe um arquivo geofeed associado a ele.

E o RDAP?

O RDAP é o caminho mais moderno para consulta de dados de registro.

Enquanto o WHOIS tradicional retorna texto, o RDAP retorna JSON. Isso facilita muito para automação.

A RFC 9877 define como um servidor RDAP pode informar links de geofeed dentro da resposta de um objeto IP [3].

Um exemplo seria algo assim:

{
  "rel": "geofeed",
  "href": "https://geo.exemplo.com.br/geofeed-192.0.2.0-24.csv",
  "type": "application/geofeed+csv"
}

Ou seja: o consumidor consulta o RDAP de um IP, encontra o link geofeed, baixa o CSV e processa a informação.

O mais específico vence

Aqui a lógica é bem familiar para quem trabalha com rede.

O mais específico vence.

Mas vale separar duas coisas: granularidade de geolocalização não é necessariamente granularidade de anúncio BGP.

Na Internet real, em IPv4, o /24 costuma ser a menor unidade prática para anúncio global. Então, se você tem um bloco maior, como um /22, e internamente usa cada /24 em uma cidade diferente, o geofeed pode representar essa divisão por /24.

 Exemplo conceitual:

bloco-a/24,BR,BR-PR,Apucarana,
bloco-b/24,BR,BR-PR,Londrina,
bloco-c/24,BR,BR-SP,Sao Paulo,
bloco-d/24,BR,BR-RS,Porto Alegre,

O importante é entender a regra: quando existem entradas sobrepostas, o consumidor deve considerar a entrada mais específica como a melhor correspondência.

A RFC 8805 permite prefixos aninhados e orienta que o consumidor use a entrada mais específica como melhor correspondência [1].

A RFC 9632 segue a mesma ideia ao tratar da descoberta via registros de Internet: o objeto mais específico com referência de geofeed deve ser usado [2].

Qualidade do arquivo importa

Um geofeed ruim pode não ajudar. Em alguns casos, pode até atrapalhar.

Exemplo errado:

192.0.2.0/24,BR,PR,Apucarana,

O correto é:

192.0.2.0/24,BR,BR-PR,Apucarana

Outro exemplo errado:

192.0.2.0/24,BR,BR-PR,Apucarana

Faltou o último campo vazio. O melhor é manter:

192.0.2.0/24,BR,BR-PR,Apucarana,

Outro erro comum é misturar blocos independentes dentro do mesmo arquivo, principalmente quando o sistema onde você vai publicar exige um arquivo por bloco.

Por exemplo, se o arquivo está associado ao bloco 192.0.2.0/24, não coloque dentro dele outro bloco independente como 198.51.100.0/24.

Mesmo que, nas RFCs, existam cenários onde um arquivo único possa ser usado com cuidado, na prática operacional é melhor começar simples: um arquivo por bloco, contendo somente aquele bloco ou sub-blocos dele.

No Brasil, atenção à política atual do Registro.br

O Registro.br começou a implementar o suporte às RFCs relacionadas a geofeed.

Por enquanto, a política está mais restrita. Na prática, o caminho mais seguro é manter um arquivo por bloco, contendo somente o próprio bloco ou sub-blocos dele, em UTF-8, com o número correto de campos e publicado de forma que o arquivo seja baixado diretamente.

Isso é importante porque uma coisa é o que a RFC permite em termos mais gerais. Outra coisa é como uma implementação específica valida e aceita os dados neste momento.

 Então, para usar no Registro.br, pense assim:

bloco 192.0.2.0/24      -> arquivo geofeed-192.0.2.0-24.csv
bloco 198.51.100.0/24   -> arquivo geofeed-198.51.100.0-24.csv
bloco 203.0.113.0/24    -> arquivo geofeed-203.0.113.0-24.csv

E cada arquivo deve conter somente o bloco correspondente ou sub-blocos dele.

Cadência de revisão

Geofeed não deveria ser um arquivo esquecido no servidor.

Ele precisa acompanhar a operação.

Mudou a distribuição de prefixos?
Ativou novo POP?
Recebeu bloco novo?
Transferiu recurso?
Separou CGNAT por cidade?
Reorganizou IPv6?
Fez aquisição de outro provedor?

Então revise o geofeed.

Na apresentação da NANOG, uma sugestão interessante é tratar isso com cadência. Pequenos ISPs podem revisar mensalmente. Grandes ISPs e operadoras móveis talvez precisem revisar semanalmente. Clouds e CDNs podem ter necessidade diária [6].

Para a maior parte dos provedores regionais, eu colocaria isso no checklist de mudanças de rede.

Conclusão

Geofeed é simples, mas resolve um problema real.

Ele ajuda o provedor a comunicar de forma padronizada onde seus prefixos IP estão sendo usados. Não garante que todas as bases do mundo vão corrigir imediatamente, mas cria uma referência pública, organizada e automatizável.

Em resumo:

  • a RFC 8805 define o formato do arquivo;
  • a RFC 9632 define como descobrir e usar esses arquivos via registros de Internet;
  • a RFC 9877 leva essa informação para o RDAP;
  • o Registro.br já começou a suportar esse processo;
  • para o Brasil, neste momento, é melhor trabalhar com um arquivo por bloco.

Assim como RPKI, IRR, PeeringDB, DNS reverso e boa documentação de IPAM, geofeed passa a fazer parte da maturidade operacional de um ISP.

 Não é só “arrumar cidade no Google”. É cuidar da identidade dos seus recursos IP na Internet.

Referências

[1] RFC 8805 — A Format for Self-Published IP Geolocation Feeds
https://www.rfc-editor.org/rfc/rfc8805

[2] RFC 9632 — Finding and Using Geofeed Data
https://www.rfc-editor.org/rfc/rfc9632

[3] RFC 9877 — RDAP Extension for Geofeed Data
https://www.rfc-editor.org/rfc/rfc9877

[4] ISO Online Browsing Platform — ISO 3166 / Brazil
https://www.iso.org/obp/ui/#iso:code:3166:BR

[5] ISO 3166-2:BR — lista de códigos dos estados brasileiros
https://en.wikipedia.org/wiki/ISO_3166-2:BR

[6] NANOG 96 — High-quality IP Geofeeds using AI Coding Assistants and MCP
https://nanog.org/events/nanog-96/content/5683/

[7] Vídeo da apresentação — High-quality IP Geofeeds
https://www.youtube.com/watch?v=x_vbTj_D91I