Como configurar Geofeed no Registro.br

No artigo anterior falamos sobre geofeed, RFC 8805, RFC 9632, RDAP e por que isso importa para provedores.

Agora vamos para a prática.

A ideia aqui é montar um exemplo simples de publicação de geofeed usando o Registro.br, com arquivo CSV publicado em HTTPS e validação via WHOIS e RDAP.

Para não usar nenhum bloco real, os exemplos abaixo usam blocos reservados para teste e documentação. Em produção, naturalmente, você deve substituir pelos blocos reais do ASN.

Cenário de exemplo

Vamos imaginar que o provedor tenha um bloco IPv4 /22 e use cada /24 em uma cidade diferente.

Para o exemplo IPv4, vamos usar:

198.18.0.0/22

Esse bloco faz parte de um espaço reservado para testes/benchmarking. Ele não deve ser usado em produção na Internet. Aqui ele serve apenas para deixar o exemplo com cara de operação real, sem expor prefixo.

A divisão operacional seria:

198.18.0.0/24      Apucarana - PR
198.18.1.0/24      Londrina - PR
198.18.2.0/24      Sao Paulo - SP
198.18.3.0/24      Porto Alegre - RS

No IPv6, vamos usar o bloco de documentação:

2001:db8::/32

E separar em /40:

2001:db8:0000::/40   Apucarana - PR
2001:db8:0100::/40   Londrina - PR
2001:db8:0200::/40   Sao Paulo - SP
2001:db8:0300::/40   Porto Alegre - RS

Essa abordagem fica mais próxima do mundo real: um bloco maior cadastrado e, dentro dele, divisões por cidade ou região.

Um arquivo por bloco

Por enquanto, o Registro.br mantém uma política mais restrita para publicação de geofeed.

Na prática, o caminho mais seguro é trabalhar com um arquivo por bloco cadastrado, contendo apenas o próprio bloco ou sub-blocos dele.

Então, se o bloco cadastrado é:

198.18.0.0/22

faz sentido ter um único arquivo para esse /22, contendo os /24 internos:

geofeeds_198.18.0.0_22.csv

Conteúdo:

198.18.0.0/24,BR,BR-PR,Apucarana,
198.18.1.0/24,BR,BR-PR,Londrina,
198.18.2.0/24,BR,BR-SP,Sao Paulo,
198.18.3.0/24,BR,BR-RS,Porto Alegre,

Perceba o ponto principal: todas as linhas estão dentro do bloco 198.18.0.0/22.

Isso é diferente de misturar blocos independentes no mesmo arquivo.

Por exemplo, se você tivesse dois blocos diferentes cadastrados no Registro.br, como:

198.18.0.0/22
198.18.8.0/22

não seria uma boa ideia colocar tudo no mesmo CSV neste momento. O mais seguro seria criar um arquivo para cada bloco.

Arquivo IPv6

Para o IPv6, seguindo a mesma lógica, o bloco cadastrado seria:

2001:db8::/32

O arquivo poderia se chamar:

geofeeds_2001-db8_32.csv

Conteúdo:

2001:db8:0000::/40,BR,BR-PR,Apucarana,
2001:db8:0100::/40,BR,BR-PR,Londrina,
2001:db8:0200::/40,BR,BR-SP,Sao Paulo,
2001:db8:0300::/40,BR,BR-RS,Porto Alegre,

Aqui também vale a mesma regra: os /40 estão dentro do /32.

Em um provedor real, a granularidade pode variar. Você pode usar /40, /44, /48 ou outro tamanho, dependendo de como o IPv6 foi planejado. O importante é que o geofeed represente a operação de forma coerente e não tente ser mais preciso do que a rede realmente permite.

Formato correto do CSV

A RFC 8805 define o formato base do geofeed [1]:

ip_prefix,alpha2code,region,city,postal_code

Mas no arquivo publicado, normalmente você não coloca cabeçalho.

Então não faça assim:

ip_prefix,alpha2code,region,city,postal_code
198.18.0.0/24,BR,BR-PR,Apucarana,

Faça assim:

198.18.0.0/24,BR,BR-PR,Apucarana,

Alguns detalhes importantes:

O arquivo deve estar em UTF-8.

O prefixo precisa estar em formato CIDR.

O país do Brasil é BR.

O estado precisa seguir ISO 3166-2. Paraná é BR-PR, São Paulo é BR-SP, Rio Grande do Sul é BR-RS.

A cidade não deve conter vírgula.

O campo de código postal deve ficar vazio, mas a vírgula final deve permanecer.

Onde consultar os códigos dos estados

Para o campo de região, use ISO 3166-2.

Alguns exemplos:

BR-PR  Paraná
BR-SP  São Paulo
BR-RS  Rio Grande do Sul
BR-SC  Santa Catarina
BR-MG  Minas Gerais
BR-RJ  Rio de Janeiro
BR-DF  Distrito Federal

A fonte oficial é a ISO Online Browsing Platform [4].

Para consulta rápida, a página ISO 3166-2:BR também lista os códigos dos estados brasileiros [5].

Publicando o arquivo

Você pode publicar o CSV no próprio site do provedor, em um servidor web, em um bucket público ou usando GitHub Pages.

O ponto principal é que a URL precisa baixar o arquivo diretamente.

Exemplo para IPv4:

https://geo.seuprovedor.com.br/geofeeds_198.18.0.0_22.csv

Exemplo para IPv6:

https://geo.seuprovedor.com.br/geofeeds_2001-db8_32.csv

Ou, usando GitHub Pages:

https://usuario.github.io/geofeeds/geofeeds_198.18.0.0_22.csv
https://usuario.github.io/geofeeds/geofeeds_2001-db8_32.csv

Cuidado com links do tipo:

https://github.com/usuario/geofeeds/blob/main/geofeeds_198.18.0.0_22.csv

Esse link abre uma página HTML do GitHub, não o arquivo diretamente.

Para o Registro.br, a URL precisa entregar o CSV direto.

Exemplo com GitHub Pages

Um caminho simples para laboratório ou pequenos provedores é usar GitHub Pages.

O fluxo é:

criar uma conta no GitHub;
criar um repositório chamado geofeeds;
criar o arquivo geofeeds_198.18.0.0_22.csv;
colocar dentro dele o conteúdo CSV;
habilitar GitHub Pages no repositório;
acessar a URL pública gerada.

O arquivo IPv4 ficaria assim:

198.18.0.0/24,BR,BR-PR,Apucarana,
198.18.1.0/24,BR,BR-PR,Londrina,
198.18.2.0/24,BR,BR-SP,Sao Paulo,
198.18.3.0/24,BR,BR-RS,Porto Alegre,

A URL final poderia ficar assim:

https://usuario.github.io/geofeeds/geofeeds_198.18.0.0_22.csv

Se ao abrir essa URL o navegador baixar ou mostrar somente o conteúdo CSV, está no caminho certo.

Se abrir uma página do GitHub, com layout, botões, menu e preview, está errado.

Content-Type

O Registro.br pode validar o tipo de conteúdo publicado.

O ideal é que o servidor responda com:

Content-Type: text/csv

ou:

Content-Type: application/geofeed+csv

A RFC 9877 registra o tipo application/geofeed+csv para arquivos geofeed [3].

Para validar:

curl -I https://usuario.github.io/geofeeds/geofeeds_198.18.0.0_22.csv

Exemplo de resposta esperada:

HTTP/2 200
content-type: text/csv

ou:

HTTP/2 200
content-type: application/geofeed+csv

Validando a sintaxe

Antes de cadastrar no Registro.br, vale passar o arquivo em um validador.

Uma opção prática é:

https://opengeofeed.org/validator

Ele ajuda a pegar erro bobo, como:

campo faltando;
estado em formato errado;
prefixo inválido;
CSV malformado;
linha duplicada;
país inválido;
uso incorreto de região.

Exemplo errado:

198.18.0.0/24,BR,PR,Apucarana

Problemas:

PR deveria ser BR-PR;
faltou a vírgula final;
o número de campos ficou inconsistente.

Correto:

198.18.0.0/24,BR,BR-PR,Apucarana,

Configurando no Registro.br

Depois de publicar e validar o arquivo, acesse o portal do Registro.br.

O fluxo geral é:

entrar no portal;
acessar a área de Numeração;

3. selecionar o bloco e abrir a opção Configurar Geofeed;

4. informar a URL HTTPS do arquivo;

salvar.

Exemplo IPv4:

Bloco: 198.18.0.0/22
Geofeed: https://usuario.github.io/geofeeds/geofeeds_198.18.0.0_22.csv

Exemplo IPv6:

Bloco: 2001:db8::/32
Geofeed: https://usuario.github.io/geofeeds/geofeeds_2001-db8_32.csv

Lembrando novamente: estes blocos são apenas exemplos para documentação. Em produção, você usaria os blocos reais.

Validando no WHOIS

Depois de configurar, valide se o geofeed apareceu no WHOIS.

Exemplo IPv4:

whois -h whois.registro.br 198.18.0.0 | grep -i geofeed

Resultado esperado:

geofeed: https://usuario.github.io/geofeeds/geofeeds_198.18.0.0_22.csv

Exemplo IPv6:

whois -h whois.registro.br 2001:db8:: | grep -i geofeed

Resultado esperado:

geofeed: https://usuario.github.io/geofeeds/geofeeds_2001-db8_32.csv

Em produção, substitua pelos IPs reais dos blocos configurados.

Validando no RDAP

Também dá para validar via RDAP.

IPv4:

curl -s https://rdap.registro.br/ip/198.18.0.0 | jq '.links[] | select(.rel == "geofeed")'

Resultado esperado:

{
  "rel": "geofeed",
  "href": "https://usuario.github.io/geofeeds/geofeeds_198.18.0.0_22.csv",
  "type": "application/geofeed+csv"
}

IPv6:

curl -s https://rdap.registro.br/ip/2001:db8:: | jq '.links[] | select(.rel == "geofeed")'

Resultado esperado:

{
  "rel": "geofeed",
  "href": "https://usuario.github.io/geofeeds/geofeeds_2001-db8_32.csv",
  "type": "application/geofeed+csv"
}

O RDAP é importante porque é o caminho mais estruturado para sistemas automatizados descobrirem o geofeed.

A RFC 9877 foi criada justamente para padronizar esse link de geofeed dentro das respostas RDAP [3].

Validando se ficou descobrível

Além de WHOIS e RDAP, uma ferramenta útil é o GeolocateMuch:

https://geolocatemuch.com/?resource=198.18.0.0

Em ambiente real, use o prefixo ou IP.

Essa ferramenta ajuda a verificar se o geofeed está sendo descoberto a partir dos dados públicos.

Checklist final

Antes de considerar finalizado, revise:

[ ] Existe um arquivo por bloco cadastrado
[ ] O arquivo contém somente o bloco atual ou sub-blocos dele
[ ] O arquivo está em UTF-8
[ ] O arquivo está em CSV
[ ] Não existe cabeçalho
[ ] O prefixo está em CIDR
[ ] O país está como BR
[ ] O estado está no formato ISO 3166-2, exemplo BR-PR
[ ] A cidade não contém vírgula
[ ] O postal_code está vazio
[ ] A vírgula final foi mantida
[ ] A URL é HTTPS
[ ] A URL baixa diretamente o arquivo
[ ] O Content-Type é text/csv ou application/geofeed+csv
[ ] O arquivo passa no validador
[ ] O geofeed aparece no WHOIS
[ ] O geofeed aparece no RDAP

Erros comuns

Misturar blocos diferentes no mesmo arquivo

Errado:

198.18.0.0/24,BR,BR-PR,Apucarana,
198.18.8.0/24,BR,BR-SP,Sao Paulo,

Se o arquivo é do bloco 198.18.0.0/22, o prefixo 198.18.8.0/24 está fora dele.

Usar estado sem o prefixo do país

Errado:

198.18.0.0/24,BR,PR,Apucarana,

Correto:

198.18.0.0/24,BR,BR-PR,Apucarana,

Esquecer a vírgula final

Errado:

198.18.0.0/24,BR,BR-PR,Apucarana

Correto:

198.18.0.0/24,BR,BR-PR,Apucarana,

Usar link de preview do GitHub em vez do arquivo direto

Errado:

https://github.com/usuario/geofeeds/blob/main/geofeeds_198.18.0.0_22.csv

Correto, usando GitHub Pages:

https://usuario.github.io/geofeeds/geofeeds_198.18.0.0_22.csv

Boas práticas operacionais

Depois de configurar, não esqueça que isso precisa ser mantido.

Revise o geofeed quando houver:

novo bloco;
transferência de recurso;
ativação de novo POP;
mudança de cidade atendida;
reorganização de CGNAT;
separação de prefixos por localidade;
alteração de uso de IPv6;
aquisição ou fusão com outro provedor;
reclamações recorrentes de localização errada.

O ideal é que a informação venha de uma fonte confiável: IPAM, documentação de POPs, inventário de blocos ou base interna da operação.

Geofeed feito “de cabeça” até funciona no começo, mas vira problema quando a rede cresce.

Conclusão

Configurar geofeed no Registro.br não é complicado.

O que exige atenção é o detalhe.

Um arquivo por bloco cadastrado.
Somente o bloco ou sub-blocos dele.
CSV em UTF-8.
URL HTTPS baixando direto.
Estado no padrão ISO 3166-2.
Validação no WHOIS e no RDAP.

Com isso, o provedor passa a publicar uma fonte oficial para que os consumidores de geolocalização entendam melhor onde seus IPs estão sendo usados.

Não resolve todos os problemas de geolocalização do dia para a noite, mas coloca a operação no caminho certo.

E, principalmente, tira o ISP da posição de apenas reagir quando o cliente reclama.

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] OpenGeofeed Validator
https://opengeofeed.org/validator

[7] GeolocateMuch — teste de descoberta de geofeed
https://geolocatemuch.com/

Como configurar Geofeed no Registro.br

Cenário de exemplo

Um arquivo por bloco

Arquivo IPv6

Formato correto do CSV

Onde consultar os códigos dos estados

Publicando o arquivo

Exemplo com GitHub Pages

Content-Type

Validando a sintaxe

Configurando no Registro.br

Validando no WHOIS

Validando no RDAP

Validando se ficou descobrível

Checklist final

Erros comuns

Misturar blocos diferentes no mesmo arquivo

Usar estado sem o prefixo do país

Esquecer a vírgula final

Usar link de preview do GitHub em vez do arquivo direto

Boas práticas operacionais

Conclusão

Referências

Deixe um comentário Cancelar resposta

Links

Redes Sociais

Contatos