Geofeed no Registro.br: uma boa prática que todo ISP deveria implementar

DanielTecnet — Fri, 19 Jun 2026 15:35:03 GMT

Criação de Geofeed no Registro.br e sua Importancia

Página nova

= Geofeed no Registro.br: uma boa prática que todo ISP deveria implementar =

''Como melhorar a precisão da geolocalização dos seus endereços IPv4 e IPv6 utilizando Geofeed e os recursos disponíveis no Registro.br.''

== Introdução ==

Imagine a seguinte situação:

O cliente mora em Teresina.

O aplicativo do banco entende que ele está em Fortaleza.

O serviço de streaming entrega conteúdo da região errada.

Uma plataforma antifraude interpreta o acesso como suspeito.

O suporte recebe a reclamação.

Na maioria das vezes não existe qualquer problema na rede " camada 1 to 3 ".

O BGP está correto.

O DNS está funcionando.

A latência está adequada.

O problema está na forma como a Internet entende a localização dos endereços IP utilizados pelo assinante.

É justamente nesse cenário que o Geofeed se torna uma ferramenta extremamente importante.

== O que é Geofeed? ==

Geofeed é um padrão definido pela IETF através das RFC 8805 e RFC 9632 que permite ao detentor dos recursos IP publicar oficialmente a localização geográfica de seus prefixos.

Na prática, trata-se de um arquivo CSV hospedado em HTTPS contendo informações sobre onde cada bloco IPv4 ou IPv6 está sendo utilizado.

Esse arquivo pode ser consumido por diversos provedores de dados e plataformas da Internet, tais como:

* MaxMind
* IPInfo
* Cloudflare
* Google
* Plataformas antifraude
* Bancos
* Aplicativos de geolocalização
* Sistemas de segurança

O objetivo é reduzir inconsistências e melhorar a precisão das informações de localização utilizadas pelos serviços da Internet.

== Como funciona? ==

[[Arquivo:Geofeed_fluxo_registrobr.png|center|1000px|Fluxo simplificado do funcionamento do Geofeed]]

O processo é relativamente simples:

# O ISP cria um arquivo Geofeed.

# O arquivo é publicado em HTTPS.

# A URL é associada ao bloco IP no Registro.br.

# Bases de geolocalização consomem essas informações.

# Aplicações passam a identificar corretamente a localização dos usuários.

== Por que isso é importante para os provedores? ==

Muitos ISPs investem continuamente em:

* Backbone próprio
* MPLS
* IX.br
* PNI
* CDNs
* RPKI
* Segurança de roteamento

Porém, acabam negligenciando uma informação extremamente importante: a localização dos recursos IP perante a Internet.

A ausência de um Geofeed bem configurado pode gerar:

* Erros em sistemas antifraude
* Bloqueios indevidos em bancos
* Conteúdo regional incorreto
* Publicidade geográfica errada
* Aumento de chamados no suporte
* Dificuldades em processos de troubleshooting

Em muitos casos, o assinante percebe o problema como uma falha da rede, quando na realidade trata-se apenas de uma geolocalização incorreta.

== Exemplo de arquivo Geofeed ==

Para fins de documentação e treinamento, devem ser utilizados blocos reservados para documentação conforme RFC 5737 e RFC 3849.

Exemplo:

<pre>
# prefix,country,subdivision,city

192.0.2.0/24,BR,BR-PI,Teresina
198.51.100.0/24,BR,BR-CE,Fortaleza
203.0.113.0/24,BR,BR-MA,Sao Luis
2001:db8:100::/48,BR,BR-PI,Teresina
</pre>

Após criado, o arquivo pode ser publicado em:

<pre>
https://geo.seuprovedor.com.br/geofeed.csv
</pre>

== Como configurar no Registro.br ==

[[Arquivo:Geofeed_passo_a_passo_registrobr.png|center|1200px|Passo a passo para configuração do Geofeed no Registro.br]]

O Registro.br incorporou suporte ao Geofeed dentro da área de recursos de numeração, tornando o processo bastante simples.

O procedimento consiste em:

# Acessar sua conta no Registro.br.

# Entrar na área de Numeração.

# Selecionar o bloco IPv4 ou IPv6 desejado.

# Clicar em "Configurar Geofeed".

# Informar a URL HTTPS onde o arquivo CSV está hospedado.

# Salvar a configuração.

# Aguardar a propagação das informações.

== Um erro muito comum: configurar apenas o IPv4 ==

Durante implementações de Geofeed, um erro bastante frequente é publicar apenas os prefixos IPv4 e esquecer completamente os prefixos IPv6.

Embora muitos operadores ainda associem geolocalização principalmente ao IPv4, a realidade é que diversas aplicações modernas operam em Dual Stack e realizam consultas independentes para IPv4 e IPv6.

Isso significa que o mesmo assinante pode apresentar localizações diferentes dependendo do protocolo utilizado.

Exemplo:

<pre>
IPv4: 198.51.100.25
Localização: Teresina/PI

IPv6: 2001:db8:100::25
Localização: Fortaleza/CE
</pre>

Nesse cenário, uma plataforma pode identificar o usuário em Teresina enquanto outra o identifica em Fortaleza.

As consequências incluem:

* Conteúdo regional inconsistente
* Erros em plataformas antifraude
* Problemas em bancos e aplicativos financeiros
* Publicidade incorreta
* Dificuldades de troubleshooting

Por esse motivo, sempre que um Geofeed for implementado, todos os recursos públicos devem ser contemplados:

* Prefixos IPv4
* Prefixos IPv6
* Blocos de clientes corporativos (quando aplicável)
* Prefixos utilizados em diferentes cidades ou regiões

A regra é simples:

'''Se um prefixo é anunciado na Internet, ele deve possuir uma localização consistente no Geofeed.'''

== Geofeed não substitui um bom planejamento de endereçamento ==

Outra observação importante é que o Geofeed não corrige problemas de alocação.

Se um mesmo bloco IP é utilizado simultaneamente em diversas cidades, a precisão da geolocalização será naturalmente reduzida.

Quanto mais organizada for a distribuição dos blocos IPv4 e IPv6 por POP, cidade ou região, melhores serão os resultados obtidos.

Exemplo:

<pre>
198.51.100.0/24 → Teresina/PI
198.51.101.0/24 → Parnaíba/PI
198.51.102.0/24 → Picos/PI

2001:db8:100::/48 → Teresina/PI
2001:db8:200::/48 → Parnaíba/PI
2001:db8:300::/48 → Picos/PI
</pre>

== Geofeed faz parte do ecossistema de boas práticas ==

Hoje os operadores já reconhecem a importância de diversas boas práticas operacionais:

{| class="wikitable"
! Recurso

| ! Finalidade |
| ------------------------------------------ |
| IRR |
| Define quem pode anunciar os prefixos |
| - |
| RPKI / ROA |
| Valida a autorização dos anúncios |
| - |
| PeeringDB |
| Informa como conectar à rede |
| - |
| Whois |
| Identifica os responsáveis pelos recursos |
| - |
| Geofeed |
| Informa onde os IPs estão sendo utilizados |
| } |

Assim como mantemos IRR, RPKI, PeeringDB e informações de Whois atualizadas, também devemos manter a geolocalização dos recursos consistente e atualizada.

== Considerações importantes ==

A publicação do Geofeed não garante atualização imediata em todas as plataformas.

Cada fornecedor possui seu próprio ciclo de coleta e atualização.

Dependendo da plataforma, a propagação pode levar de alguns dias até algumas semanas.

Além disso, em determinados casos ainda pode ser necessário solicitar correções diretamente aos provedores das bases de geolocalização.

== Conclusão ==

Assim como o RPKI ajuda a proteger os anúncios BGP, o Geofeed ajuda a melhorar a forma como a Internet enxerga sua rede.

Não basta apenas anunciar seus prefixos corretamente.

Também é importante informar ao ecossistema onde esses recursos estão sendo utilizados.

Em um cenário cada vez mais dependente de geolocalização, segurança e experiência do usuário, manter informações consistentes para IPv4 e IPv6 deixou de ser um diferencial e passou a ser uma boa prática operacional para qualquer ISP moderno.

A Internet já sabe quem você é.

Já sabe quais prefixos você anuncia.

Agora ela também pode saber onde eles estão.

== Referências ==

* RFC 8805 - A Format for Self-Published IP Geolocation Feeds
* RFC 9632 - Geofeed Update
* Registro.br
* NIC.br
* Brasil Peering Forum
== Autor ==

Daniel Melo
Engenheiro de Redes

Arquivo:Geofeed passo a passo registrobr.png

DanielTecnet — Fri, 19 Jun 2026 15:20:12 GMT

DanielTecnet carregou Arquivo:Geofeed passo a passo registrobr.png

Página nova

Arquivo:Geofeed fluxo registrobr.png

DanielTecnet — Fri, 19 Jun 2026 15:18:26 GMT

DanielTecnet carregou Arquivo:Geofeed fluxo registrobr.png

Página nova

Usuário:Erickandrade

Erickandrade — Wed, 17 Jun 2026 14:37:00 GMT

Portas de Amplificação DDoS e Botnets

Gondim — Sun, 14 Jun 2026 16:45:49 GMT

Usuário:Gidelson barbosa da silva

Gidelson barbosa da silva — Sun, 14 Jun 2026 13:10:18 GMT

A conta de usuário Gidelson barbosa da silva foi criada

← Edição anterior		Edição das 14h37min de 17 de junho de 2026
Linha 13:		Linha 13:

	E-mail: erick@erickandrade.com.br		E-mail: erick@erickandrade.com.br
−
−	~~WhatsApp: +55 (49) 99907-5599~~

@@ Linha 124: / Linha 124: @@
 == Checando se o problema foi resolvido ==
 Após aplicarmos os filtros, checaremos se os IPs estão com as portas de amplificação fechadas e para isso fiz um '''shell script em bash''', que usa alguns pacotes para validarmos o serviço. Como sempre estou usando para os nossos artigos a distribuição Debian GNU/Linux. Procure separar um ambiente para instalar esses pacotes e servir como base de testes. O ideal é que esteja de fora na Internet e sem qualquer bloqueio de Operadoras para esses testes poderem funcionar. Para usar o '''rpcinfo''' precisaremos do pacote '''rpcbind''' instalado, que após a instalação levantará o serviço rpc (111/udp) e na sequência iremos desabilitá-lo.
   # apt install nmap bind9-host bind9-dnsutils bsdextrautils netcat snmp samba-common-bin rpcbind ntp ldap-utils curl

Wiki BPF - Mudanças recentes [pt-br]

Geofeed no Registro.br: uma boa prática que todo ISP deveria implementar

Arquivo:Geofeed passo a passo registrobr.png

Arquivo:Geofeed fluxo registrobr.png

Usuário:Erickandrade

Portas de Amplificação DDoS e Botnets

Usuário:Gidelson barbosa da silva