Menú

Made4it

  • 25/05/2026

Cómo configurar Geofeed en Registro.br

En el artículo anterior hablamos sobre geofeed, RFC 8805, RFC 9632, RDAP y por qué es importante para los proveedores.

Ahora pasemos a la práctica.

La idea es crear un ejemplo sencillo de publicación de un geofeed utilizando Registro.br, con un archivo CSV publicado en HTTPS y validación a través de WHOIS y RDAP.

Para no utilizar ningún bloque real, los ejemplos que figuran a continuación utilizan bloques reservados para pruebas y documentación. En entorno de producción, como es lógico, deberá sustituirlos por los bloques reales de la ASN.

Ejemplo de escenario

Imaginemos que el proveedor dispone de un bloque de direcciones IPv4 /22 y utiliza cada una de las direcciones /24 en una ciudad diferente.

Para el ejemplo de IPv4, utilizaremos:

198.18.0.0/22

Este bloque forma parte de un espacio reservado para pruebas y evaluaciones comparativas. No debe utilizarse en entornos de producción en Internet. En este caso, solo sirve para que el ejemplo parezca una operación real, sin mostrar el prefijo.

La división operativa sería la siguiente:

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

En IPv6, utilizaremos el bloque de documentación:

2001:db8::/32

Y dividirlo en /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

Este enfoque se ajusta más a la realidad: un bloque más amplio registrado y, dentro de él, divisiones por ciudad o región.

Un archivo por bloque

Por el momento, Registro.br mantiene una política más restrictiva en cuanto a la publicación de geofeeds.

En la práctica, lo más seguro es trabajar con un archivo por bloque registrado, que contenga únicamente el propio bloque o sus subbloques.

Entonces, si el bloque registrado es:

198.18.0.0/22

Tiene sentido disponer de un único archivo para este /22, que contenga los /24 internos:

geofeeds_198.18.0.0_22.csv

Contenido:

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,

Fíjese en lo más importante: todas las líneas se encuentran dentro del bloque « 198.18.0.0/22 ».

Esto es diferente a mezclar bloques independientes en el mismo archivo.

Por ejemplo, si tuviera dos bloques diferentes registrados en Registro.br, como:

198.18.0.0/22
198.18.8.0/22

No sería una buena idea incluirlo todo en el mismo archivo CSV en este momento. Lo más seguro sería crear un archivo para cada bloque.

Archivo IPv6

En el caso de IPv6, siguiendo la misma lógica, el bloque registrado sería:

2001:db8::/32

El archivo podría llamarse:

geofeeds_2001-db8_32.csv

Contenido:

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,

Aquí también se aplica la misma regla: los archivos « /40 » se encuentran dentro de la carpeta « /32 ».

En un proveedor real, el nivel de detalle puede variar. Puede utilizar /40, /44, /48 u otro tamaño, dependiendo de cómo se haya planificado el IPv6. Lo importante es que el geofeed refleje el funcionamiento de forma coherente y no intente ser más preciso de lo que la red realmente permite.

Formato correcto del archivo CSV

La RFC 8805 define el formato básico del geofeed [1]:

ip_prefix,alpha2code,region,city,postal_code

Sin embargo, en el archivo publicado, normalmente no se incluye encabezado.

Entonces, no lo haga así:

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

Haga lo siguiente:

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

Algunos detalles importantes:

El archivo debe estar en UTF-8.

El prefijo debe estar en formato CIDR.

El país de Brasil es BR.

El estado debe cumplir con la norma ISO 3166-2. Paraná es BR-PR, São Paulo es BR-SP y Rio Grande do Sul es BR-RS.

El nombre de la ciudad no debe contener ninguna coma.

El campo del código postal debe quedar en blanco, pero debe mantenerse la coma final.

Dónde consultar los códigos de los estados

En el campo «región», utilice la norma ISO 3166-2.

Algunos ejemplos:

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

La fuente oficial es la Plataforma de consulta en línea de la ISO [4].

Para una consulta rápida, la página ISO 3166-2:BR también recoge los códigos de los estados brasileños [5].

Publicación del archivo

Puede publicar el archivo CSV en la propia página web del proveedor, en un servidor web, en un bucket público o mediante GitHub Pages.

Lo más importante es que la URL debe descargar el archivo directamente.

Ejemplo para IPv4:

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

Ejemplo para IPv6:

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

O bien, utilizando GitHub Pages:

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

Tenga cuidado con enlaces del tipo:

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

Para Registro.br, la URL debe proporcionar el archivo CSV directamente.

Ejemplo con GitHub Pages

Una opción sencilla para laboratorios o pequeños proveedores es utilizar GitHub Pages.

El flujo es:

  1. crear una cuenta en GitHub;
  2. crear un repositorio llamado « geofeeds »;
  3. cree el archivo « geofeeds_198.18.0.0_22.csv »;
  4. introducir en él el contenido del archivo CSV;
  5. activar GitHub Pages en el repositorio;
  6. Acceda a la URL pública generada.

El archivo IPv4 quedaría así:

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,

La URL final podría quedar así:

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

Si, al abrir esa URL, el navegador descarga o muestra únicamente el contenido CSV, va por buen camino.

Si al abrir una página de GitHub aparece con diseño, botones, menú y vista previa, es un error.

Tipo de contenido

Registro.br puede verificar el tipo de contenido publicado.

Lo ideal es que el servidor responda con:

Content-Type: text/csv

o:

Content-Type: application/geofeed+csv

La RFC 9877 define el tipo « application/geofeed+csv » para los archivos geofeed [3].

Para validar:

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

Ejemplo de respuesta esperada:

HTTP/2 200
content-type: text/csv

o:

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

Validación de la sintaxis

Antes de registrarse en Registro.br, conviene comprobar el archivo con un validador.

Una opción práctica es:

https://opengeofeed.org/validator

Ayuda a detectar errores tontos, como:

  • campo que falta;
  • estado en un formato incorrecto;
  • prefijo no válido;
  • Archivo CSV con errores;
  • línea duplicada;
  • país no válido;
  • uso incorrecto de la región.

Ejemplo incorrecto:

198.18.0.0/24,BR,PR,Apucarana

Problemas:

  • PR debería ser BR-PR;
  • faltaba la coma final;
  • El número de campos ha quedado incoherente.

Correcto:

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

Configuración en Registro.br

Una vez que haya publicado y validado el archivo, acceda al portal de Registro.br.

El proceso general es el siguiente:

  1. acceder al portal;
  2. acceder al área de Numeración;

3. Seleccione el bloque y abra la opción «Configurar Geofeed»;

4. Indique la URL HTTPS del archivo;

geofeed-registrobr-paso-3-configuración-url.png
  1. guardar.
geofeed-registrobr-paso-4-geofeed-publicado.png

Ejemplo de IPv4:

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

Ejemplo de IPv6:

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

Le recordamos una vez más: estos bloques son solo ejemplos con fines de documentación. En entorno de producción, utilizaría los bloques reales.

Comprobación en WHOIS

Una vez configurado, compruebe si el geofeed aparece en WHOIS.

Ejemplo de 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

Ejemplo de IPv6:

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

Resultado esperado:

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

En entorno de producción, sustitúyalos por las direcciones IP reales de los bloques configurados.

Validación en el RDAP

También se puede validar a través de 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"
}

El RDAP es importante porque constituye la vía más estructurada para que los sistemas automatizados detecten el geofeed.

La RFC 9877 se creó precisamente para estandarizar este enlace de geofeed en las respuestas RDAP [3].

Comprobando si ha quedado al descubierto

Además de WHOIS y RDAP, una herramienta útil es GeolocateMuch:

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

En un entorno real, utilice el prefijo o la dirección IP.

Esta herramienta permite comprobar si el geofeed está siendo detectado a partir de datos públicos.

Lista de comprobación final

Antes de darlo por terminado, revíselo:

[ ] 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

Errores habituales

Combinar bloques diferentes en un mismo archivo

Incorrecto:

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

Si el archivo pertenece al bloque « 198.18.0.0/22 », el prefijo « 198.18.8.0/24 » no forma parte de él.

Utilizar el nombre del estado sin el prefijo del país

Incorrecto:

198.18.0.0/24,BR,PR,Apucarana,

Correcto:

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

Olvidar la coma final

Incorrecto:

198.18.0.0/24,BR,BR-PR,Apucarana

Correcto:

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

Incorrecto:

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

Correcto, utilizando GitHub Pages:

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

Buenas prácticas operativas

Una vez configurado, no olvide que hay que mantenerlo.

Revise el geofeed cuando haya:

  • nuevo bloque;
  • transferencia de fondos;
  • activación de un nuevo POP;
  • mudanza a otra ciudad atendida;
  • reorganización de CGNAT;
  • separación de prefijos por localidad;
  • cambio en el uso de IPv6;
  • adquisición o fusión con otro proveedor;
  • quejas recurrentes por una ubicación errónea.

Lo ideal es que la información proceda de una fuente fiable: IPAM, documentación de los POP, inventario de bloques o base de datos interna de la operación.

Un Geofeed creado «sobre la marcha» funciona al principio, pero se convierte en un problema cuando la red crece.

Conclusión

Configurar Geofeed en Registro.br no es complicado.

Lo que requiere atención son los detalles.

Un archivo por bloque registrado.
Solo el bloque o sus subbloques.
CSV en UTF-8.
URL HTTPS con descarga directa.
Estado según la norma ISO 3166-2.
Validación en WHOIS y en RDAP.

De este modo, el proveedor pasa a publicar una fuente oficial para que los usuarios de servicios de geolocalización comprendan mejor dónde se están utilizando sus direcciones IP.

No resuelve todos los problemas de geolocalización de la noche a la mañana, pero encamina la operación por el buen camino.

Y, sobre todo, evita que el proveedor de servicios de Internet se limite a reaccionar únicamente cuando el cliente presenta una reclamación.

Referencias

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

[2] RFC 9632 – Encontrar y utilizar datos de Geofeed
https://www.rfc-editor.org/rfc/rfc9632

[3] RFC 9877 – Extensión RDAP para datos Geofeed
https://www.rfc-editor.org/rfc/rfc9877

[4] Plataforma de navegación en línea ISO – ISO 3166 / Brasil
https://www.iso.org/obp/ui/#iso:code:3166:BR

[5] ISO 3166-2:BR – lista de códigos de los estados brasileños
https://en.wikipedia.org/wiki/ISO_3166-2:BR

[6] OpenGeofeed Validator
https://opengeofeed.org/validator

[7] GeolocateMuch — prueba de detección de geofeed
https://geolocatemuch.com/

Made4it surge para satisfacer las necesidades del mercado, que cada vez exige más soluciones personalizadas.

Whatsapp Facebook-f Youtube Linkedin-in Instagram

Quiénes somos

Contenidos

Socios

Dossier de prensa

Hablar con un especialista

Productos

Menú

Servicios

Menú

Contactos

Menú