{"id":16784,"date":"2026-05-19T19:03:03","date_gmt":"2026-05-19T22:03:03","guid":{"rendered":"https:\/\/made4it.com.br\/geofeed-por-que-seus-ips-aparecem-na-cidade-errada-e-como-comecar-a-corrigir-isso\/"},"modified":"2026-05-20T09:06:11","modified_gmt":"2026-05-20T12:06:11","slug":"geofeed-por-que-seus-ips-aparecem-na-cidade-errada-e-como-comecar-a-corrigir-isso","status":"publish","type":"post","link":"https:\/\/made4it.com.br\/es\/geofeed-por-que-seus-ips-aparecem-na-cidade-errada-e-como-comecar-a-corrigir-isso\/","title":{"rendered":"Geofeed: por qu\u00e9 tus IP aparecen en la ciudad equivocada y c\u00f3mo empezar a solucionarlo"},"content":{"rendered":"\n

Cualquiera que trabaje con un proveedor de servicios de Internet probablemente haya visto este tipo de queja:<\/p>\n\n

\n

<\/p>\n<\/blockquote>\n\n

\n

\u00abMi cliente est\u00e1 en Paran\u00e1, pero el sitio web cree que est\u00e1 en S\u00e3o Paulo\u00bb.\u00abEl streaming est\u00e1 diciendo que estoy en otro pa\u00eds\u00bb.\u00abEl banco bloque\u00f3 el acceso porque pens\u00f3 que la ubicaci\u00f3n IP era extra\u00f1a\u00bb.\u00abGoogle est\u00e1 mostrando una previsi\u00f3n meteorol\u00f3gica para otra ciudad\u00bb.<\/p>\n<\/blockquote>\n\n

Es una situaci\u00f3n un poco ingrata, porque la mayor parte del tiempo la red funciona. El cliente navega, BGP est\u00e1 bien, DNS responde, traceroute pasa, la latencia es aceptable. <\/p>\n\n

Pero para el usuario final, la constataci\u00f3n es sencilla: algo va mal en su Internet.<\/p>\n\n

Y a menudo lo es. No en la conectividad, sino en la forma en que esa direcci\u00f3n IP est\u00e1 siendo geolocalizada por terceros. <\/p>\n\n

La IP no tiene ninguna ciudad registrada en su interior<\/h2>\n\n

Lo primero que hay que tener en cuenta es que una IP no nace con una ciudad dentro.<\/p>\n\n

No existe tal campo en el protocolo IP:<\/p>\n\n

este endere\u00e7o fica em Apucarana<\/code><\/pre>\n\n
o:<\/p>\n\n
este prefixo pertence a Londrina<\/code><\/pre>\n\n
La geolocalizaci\u00f3n de la IP es una inferencia. Las empresas de contenidos, los bancos, las CDN, las plataformas antifraude, los motores de b\u00fasqueda, los servicios de streaming y las bases comerciales intentan averiguar d\u00f3nde se est\u00e1 utilizando probablemente esa IP. <\/p>\n\n
Para ello, cruzan diversas informaciones: datos de registro de Internet, comportamiento del tr\u00e1fico, mediciones, historial, informaci\u00f3n de usuarios, bases comerciales, DNS, BGP, entre otras cosas.<\/p>\n\n
En la mayor\u00eda de los casos funciona bastante bien. Pero cuando va mal, es una verdadera molestia. <\/p>\n\n
Un proveedor puede recibir un nuevo bloque, comprar o transferir recursos, cambiar prefijos entre ciudades, activar un nuevo POP, reorganizar CGNAT, dividir IPv6 por regiones, intercambiar upstreams o simplemente empezar a utilizar un bloque que antes estaba asociado a otra ubicaci\u00f3n.<\/p>\n\n
S\u00f3lo que las bases externas pueden tardar en aprenderlo.<\/p>\n\n
Y entonces empiezan las llamadas.<\/p>\n\n
D\u00f3nde entra el geofeed<\/h2>\n\n
<\/a>  El geofeed es una forma normalizada de que el operador de red diga:<\/p>\n\n
\n
\u00abEstos prefijos IP se est\u00e1n utilizando en estos lugares\u00bb.<\/p>\n<\/blockquote>\n\n
No cambia el enrutamiento. No cambia BGP. No anuncia nada a Internet. No es una sesi\u00f3n ascendente.   <\/p>\n\n
No es m\u00e1s que un archivo CSV publicado a trav\u00e9s de HTTPS, siguiendo un formato definido en el RFC 8805 [1].<\/p>\n\n
<\/a>  Un ejemplo sencillo:<\/p>\n\n
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,<\/pre>\n\n
Cada l\u00ednea asocia un prefijo a una ubicaci\u00f3n aproximada.<\/p>\n\n
El formato es:<\/p>\n\n
ip_prefix,alpha2code,region,city,postal_code<\/code><\/pre>\n\n
En la pr\u00e1ctica:<\/p>\n\n
192.0.2.0\/24,BR,BR-PR,Apucarana,<\/code><\/pre>\n\n
Es decir:<\/p>\n\n
o prefixo 192.0.2.0\/24 est\u00e1 no Brasil, no Paran\u00e1, em Apucarana<\/code><\/pre>\n\n
La coma del final es importante. Representa el \u00faltimo campo, postal_code<\/code>, que est\u00e1 vac\u00edo. <\/p>\n\n
Qu\u00e9 significa cada campo<\/h2>\n\n
El primer campo es el prefijo IP. Puede ser IPv4 o IPv6, en formato CIDR. <\/p>\n\n
<\/a>  Ejemplos:<\/p>\n\n
192.0.2.0\/24,BR,BR-PR,Apucarana,\n2001:db8::\/32,BR,BR-PR,Londrina,<\/code><\/pre>\n\n
El segundo campo es el pa\u00eds, utilizando ISO 3166-1 alfa-2. Para Brasil, utilizamos BR<\/code>. <\/p>\n\n
<\/a>  El tercer campo es la regi\u00f3n, utilizando la norma ISO 3166-2. En el caso de los estados brasile\u00f1os: <\/p>\n\n
BR-PR Paran\u00e1BR-SP S\u00e3o PauloBR-SC Santa CatarinaBR-RS Rio Grande do Sul<\/pre>\n\n
La lista oficial puede consultarse en la plataforma ISO [4]. Para una referencia r\u00e1pida, tambi\u00e9n existe la p\u00e1gina ISO 3166-2:BR, que enumera los c\u00f3digos de los estados brasile\u00f1os [5]. <\/p>\n\n
El cuarto campo es la ciudad.<\/p>\n\n
El quinto campo es el c\u00f3digo postal. Existe en el formato, pero normalmente no recomiendo utilizarlo para los proveedores. La propia RFC trata este campo con precauci\u00f3n, porque puede dar demasiada granularidad [1].  <\/p>\n\n
Para el ISP, en la mayor\u00eda de los casos, el pa\u00eds, el estado y la ciudad son suficientes.<\/p>\n\n
La geolocalizaci\u00f3n es aproximaci\u00f3n, no GPS<\/h2>\n\n
Este punto es m\u00e1s importante de lo que parece.<\/p>\n\n
Cuando hablamos de geolocalizaci\u00f3n, es f\u00e1cil caer en la tentaci\u00f3n de intentar ser demasiado precisos. Pero la geolocalizaci\u00f3n IP no es un GPS. <\/p>\n\n
En NANOG 96, Sid Mathur present\u00f3 una charla titulada Geolocalizaci\u00f3n IP de alta calidad mediante asistentes de codificaci\u00f3n de IA y MCP<\/strong>. Uno de los mensajes m\u00e1s \u00fatiles de la presentaci\u00f3n es precisamente \u00e9ste: la geolocalizaci\u00f3n IP es estad\u00edstica e inexacta. Lo ideal es pensar en regiones geogr\u00e1ficas, no en un punto exacto del mapa [6].  <\/p>\n\n
Tiene raz\u00f3n: m\u00e1s precisi\u00f3n no siempre significa m\u00e1s calidad.<\/p>\n\n
Para un ISP fijo, que sabe que un prefijo concreto sirve a una ciudad concreta, tiene sentido informar a la ciudad:<\/p>\n\n
192.0.2.0\/24,BR,BR-PR,Apucarana,<\/code><\/pre>\n\n
Pero si el mismo prefijo sirve a varias ciudades cercanas, puede ser mejor detenerse en el estado:<\/p>\n\n
192.0.2.0\/24,BR,BR-PR,,<\/code><\/pre>\n\n
Esto evita resolver el problema de un cliente y crear un problema a otro.<\/p>\n\n
En la misma presentaci\u00f3n, tambi\u00e9n comenta casos muy reales: usuarios bloqueados por contenidos regionales, streaming pensando que la persona est\u00e1 en otro pa\u00eds, sitios web que muestran el tiempo equivocado e ISP que reciben quejas por algo que a menudo est\u00e1 fuera de la capa de conectividad [6].<\/p>\n\n
Cualquiera que viva en una operaci\u00f3n sabe que esto ocurre.<\/p>\n\n
\u00bfEl geofeed lo soluciona todo?<\/h2>\n\n
No.<\/p>\n\n
Y aqu\u00ed es importante ser honesto.<\/p>\n\n
Publicar un geofeed no obliga a Google, Netflix, los bancos, MaxMind, IPinfo, Cloudflare o cualquier otro consumidor a aceptar inmediatamente esa informaci\u00f3n.<\/p>\n\n
La RFC 8805 trata el geofeed como una fuente publicada por el operador. Los consumidores pueden recopilarlo, validarlo, cruzarlo con otras bases de datos y decidir si lo utilizan o no [1]. <\/p>\n\n
Aun as\u00ed, publicar correctamente mejora mucho tu posici\u00f3n.<\/p>\n\n
Antes, ten\u00edas que llamar manualmente a varias bases de datos diferentes, cada una con su propio proceso. Con geofeed, creas una fuente p\u00fablica, normalizada y descubrible autom\u00e1ticamente. <\/p>\n\n
No es una garant\u00eda de correcci\u00f3n instant\u00e1nea, pero es una pr\u00e1ctica operativa mucho mejor.<\/p>\n\n
\u00bfC\u00f3mo se enteran los dem\u00e1s de tu geofeed?<\/h2>\n\n
Publicar el archivo en una URL es s\u00f3lo una parte de la historia.<\/p>\n\n
Tienes que indicar d\u00f3nde est\u00e1 este archivo en los registros del bloque IP.<\/p>\n\n
Ah\u00ed es donde entra la RFC 9632 [2].<\/p>\n\n
Define c\u00f3mo asociar un archivo geofeed a objetos del registro de recursos IP, como inetnum<\/code> y inet6num<\/code>.<\/p>\n\n
Hay dos formas principales.<\/p>\n\n
<\/a>  La forma m\u00e1s novedosa es utilizar el atributo propio:<\/p>\n\n
geofeed: https:\/\/geo.exemplo.com.br\/geofeed-192.0.2.0-24.csv<\/code><\/pre>\n\n
La forma compatible con entornos que a\u00fan no admiten el atributo espec\u00edfico es utilizar remarks<\/code>:<\/p>\n\n
remarks: Geofeed https:\/\/geo.exemplo.com.br\/geofeed-192.0.2.0-24.csv<\/code><\/pre>\n\n
Lo importante es que el consumidor pueda mirar el registro de bloque y descubrir que hay un archivo geofeed asociado a \u00e9l.<\/p>\n\n
\u00bfQu\u00e9 pasa con el RDAP?<\/h2>\n\n
RDAP es la forma m\u00e1s moderna de consultar los datos del registro.<\/p>\n\n
Mientras que el WHOIS tradicional devuelve texto, el RDAP devuelve JSON. Esto hace que sea mucho m\u00e1s f\u00e1cil de automatizar. <\/p>\n\n
El RFC 9877 define c\u00f3mo un servidor RDAP puede informar de enlaces geofeed dentro de la respuesta de un objeto IP [3].<\/p>\n\n
Un ejemplo ser\u00eda algo as\u00ed<\/p>\n\n
{\n  \"rel\": \"geofeed\",\n  \"href\": \"https:\/\/geo.exemplo.com.br\/geofeed-192.0.2.0-24.csv\",\n  \"type\": \"application\/geofeed+csv\"\n}<\/code><\/pre>\n\n
En otras palabras: el consumidor consulta el RDAP de una IP, encuentra el enlace geofeed<\/code>, descarga el CSV y procesa la informaci\u00f3n.<\/p>\n\n
Gana el m\u00e1s espec\u00edfico<\/h2>\n\n
La l\u00f3gica aqu\u00ed es muy familiar para los que trabajan con redes.<\/p>\n\n
Gana el m\u00e1s espec\u00edfico.<\/p>\n\n
Pero conviene separar dos cosas: la granularidad de la geolocalizaci\u00f3n no es necesariamente la granularidad del anuncio BGP.<\/p>\n\n
En la Internet real, en IPv4, \/24<\/code> suele ser la unidad pr\u00e1ctica m\u00e1s peque\u00f1a para los anuncios globales. As\u00ed que si tienes un bloque m\u00e1s grande, como \/22<\/code>, e internamente utilizas cada \/24<\/code> en una ciudad diferente, el geofeed puede representar esta divisi\u00f3n mediante \/24<\/code>. <\/p>\n\n
<\/a>  Ejemplo conceptual:<\/p>\n\n
bloco-a\/24,BR,BR-PR,Apucarana,\nbloco-b\/24,BR,BR-PR,Londrina,\nbloco-c\/24,BR,BR-SP,Sao Paulo,\nbloco-d\/24,BR,BR-RS,Porto Alegre,<\/code><\/pre>\n\n
Lo importante es entender la regla: cuando hay entradas que se solapan, el consumidor debe considerar la entrada m\u00e1s espec\u00edfica como la mejor coincidencia.<\/p>\n\n
La RFC 8805 permite prefijos anidados e indica al consumidor que utilice la entrada m\u00e1s espec\u00edfica como la mejor coincidencia [1].<\/p>\n\n
La RFC 9632 sigue la misma idea cuando se trata del descubrimiento a trav\u00e9s de registros de Internet: debe utilizarse el objeto m\u00e1s espec\u00edfico con una referencia geoalimentada [2].<\/p>\n\n
La calidad del archivo importa<\/h2>\n\n
Una mala geoalimentaci\u00f3n puede no ayudar. En algunos casos, incluso puede estorbar. <\/p>\n\n
Ejemplo err\u00f3neo:<\/p>\n\n
192.0.2.0\/24,BR,PR,Apucarana,<\/code><\/pre>\n\n
La correcta es:<\/p>\n\n
192.0.2.0\/24,BR,BR-PR,Apucarana<\/code><\/pre>\n\n
Otro ejemplo err\u00f3neo:<\/p>\n\n
192.0.2.0\/24,BR,BR-PR,Apucarana<\/code><\/pre>\n\n
Falta el \u00faltimo campo vac\u00edo. Es mejor conservarlo: <\/p>\n\n
192.0.2.0\/24,BR,BR-PR,Apucarana,<\/code><\/pre>\n\n
Otro error frecuente es mezclar bloques independientes dentro de un mismo archivo, sobre todo cuando el sistema donde vas a publicar exige un archivo por bloque.<\/p>\n\n
Por ejemplo, si el archivo est\u00e1 asociado al bloque 192.0.2.0\/24<\/code>, no coloques otro bloque independiente dentro de \u00e9l, como 198.51.100.0\/24<\/code>.<\/p>\n\n
Aunque en las RFC hay supuestos en los que se puede utilizar un \u00fanico archivo con cuidado, en la pr\u00e1ctica operativa es mejor empezar de forma sencilla: un archivo por bloque, que contenga s\u00f3lo ese bloque o sub-bloques del mismo.<\/p>\n\n
En Brasil, atenci\u00f3n a la pol\u00edtica actual de Registro.br<\/h2>\n\n
Registro.br ha empezado a implementar el soporte para las RFC relacionadas con geofeed.<\/p>\n\n
De momento, la pol\u00edtica es m\u00e1s restrictiva. En la pr\u00e1ctica, lo m\u00e1s seguro es mantener un archivo por bloque, que contenga s\u00f3lo el propio bloque o sub-bloques del mismo, en UTF-8, con el n\u00famero correcto de campos y publicado de forma que el archivo se descargue directamente. <\/p>\n\n
Esto es importante porque una cosa es lo que permite la RFC en t\u00e9rminos m\u00e1s generales. Otra cosa es c\u00f3mo una implementaci\u00f3n concreta valida y acepta los datos en ese momento. <\/p>\n\n
<\/a>  As\u00ed que, para utilizar Registro.br, piensa en ello as\u00ed:<\/p>\n\n
bloco 192.0.2.0\/24      -> arquivo geofeed-192.0.2.0-24.csv\nbloco 198.51.100.0\/24   -> arquivo geofeed-198.51.100.0-24.csv\nbloco 203.0.113.0\/24    -> arquivo geofeed-203.0.113.0-24.csv<\/code><\/pre>\n\n
Y cada archivo s\u00f3lo debe contener el bloque o subbloques correspondientes.<\/p>\n\n
Revisar la cadencia<\/h2>\n\n
Geofeed no deber\u00eda ser un archivo olvidado en el servidor.<\/p>\n\n
Necesita supervisar la operaci\u00f3n.<\/p>\n\n
\u00bfHa cambiado la distribuci\u00f3n de los prefijos?\u00bfNuevo POP activado?\u00bfConseguiste un bloque nuevo?\u00bfHas transferido fondos?\u00bfHas ordenado el CGNAT por ciudades?\u00bfIPv6 reorganizado?\u00bfHas comprado otro proveedor?<\/p>\n\n
Luego revisa la geoalimentaci\u00f3n.<\/p>\n\n
En la presentaci\u00f3n de NANOG, una sugerencia interesante es tratar esto con cadencia. Los ISP peque\u00f1os pueden revisar mensualmente. Los grandes ISP y los operadores m\u00f3viles pueden necesitar revisar semanalmente. Las nubes y las CDN pueden necesitar una revisi\u00f3n diaria [6].   <\/p>\n\n
Para la mayor\u00eda de los proveedores regionales, yo pondr\u00eda esto en la lista de cambios de la red.<\/p>\n\n
Conclusi\u00f3n<\/h2>\n\n
Geofeed es sencillo, pero resuelve un problema real.<\/p>\n\n
Ayuda al proveedor a comunicar de forma normalizada d\u00f3nde se utilizan sus prefijos IP. No garantiza que todas las bases del mundo lo corrijan inmediatamente, pero crea una referencia p\u00fablica, organizada y automatizable. <\/p>\n\n
En resumen:<\/p>\n\n