Resumen

  • Dos descargas satisfactorias del 3 de septiembre devolvieron el mismo archivo: 13.569 registros para 13.546 prefijos distintos. Hay 23 pares repetidos, no 23 casos demostrados de ubicación incorrecta.
  • Nueve pares son idénticos. Otros catorce difieren en los campos de ubicación, y cuatro de ellos contienen códigos de país distintos para el mismo prefijo.
  • RFC 8805 distingue la duplicación de un prefijo de la coexistencia válida de redes anidadas. La coincidencia más específica no resuelve un empate entre dos /24 iguales.
  • La corrección debe conservar la diferencia entre ordenar las declaraciones y verificar la geografía. No se investigaron las cuentas que aportaron los datos ni se midieron efectos sobre usuarios o proveedores.

El salto de Uruguay a Paraguay puede caber en una regla de carga. En el geofeed público de LACNIC, la línea 2.631 asigna 170.51.97.0/24 a UY, con región UY-MO y ciudad Montevideo. La línea 12.633 vuelve a utilizar exactamente el mismo prefijo, esta vez con PY, PY-ASU y Asuncion.

No hay una red más pequeña dentro de otra. Tampoco aparece en esas filas una fecha que convierta la segunda en una actualización explícita de la primera. Quien leyera el archivo conservando la primera ocurrencia obtendría Uruguay; quien sustituyera cada clave por la última ocurrencia obtendría Paraguay.

Esas dos políticas son ejemplos, no comportamientos observados en un producto concreto. Sirven para exponer una posibilidad incómoda: dos programas pueden ofrecer respuestas distintas a partir de los mismos bytes sin haber realizado ninguna comprobación geográfica. La diferencia nace del lector, aunque el resultado parezca proceder de la fuente.

Una declaración útil no necesita ser un certificado

Conviene empezar por lo que el servicio intenta resolver. La explicación de LACNIC sobre geolocalización separa la dirección de contacto de una organización del lugar donde utiliza sus recursos. Una ciudad o un país en Whois pueden reflejar datos contractuales. No tienen por qué describir el despliegue de cada bloque.

El geofeed ofrece un vehículo específico para la segunda pregunta. Según la descripción del servicio, los administradores de organizaciones asociadas aportan voluntariamente país, región y ciudad mediante MiLACNIC, y la información se ofrece en un CSV público. Esa descripción fue publicada en 2020; recuperarla ahora no la convierte en un anuncio de lanzamiento de 2026.

La ventaja es modesta y real: el operador dispone de una forma común de declarar dónde usa sus direcciones, incluso mediante subdivisiones del bloque. LACNIC no necesita medir todos los puntos de la red para facilitar ese intercambio. Su propia documentación distingue además el servicio de los contenidos de las bases comerciales de geolocalización.

Por eso sería equivocado convertir cualquier discrepancia del archivo en una exigencia de que el registro certifique la geografía. Pero la defensa tiene un límite igualmente preciso. Un agregador puede reconocer que exporta dos veces la misma clave, y explicar cómo trata ese caso, sin declarar cuál de los dos lugares es verdadero.

El tamaño y la clase del problema

La primera petición satisfactoria de esta investigación comenzó el 3 de septiembre a las 10:31:23 UTC. Otra comenzó a las 10:45:12 y terminó a las 10:45:48. Ambos archivos tienen 438.145 bytes y son idénticos byte a byte. Entre ellos hubo dos solicitudes que agotaron su tiempo de espera. Este registro de capturas no permite estimar disponibilidad ni reconstruir la duración histórica de la duplicación.

El contenido sí permite un recuento reproducible. Hay 13.569 líneas de datos: 10.782 de IPv4 y 2.787 de IPv6. Al agrupar por dirección de red y longitud de prefijo, normalizando las representaciones válidas de IPv6, quedan 13.546 prefijos distintos. Veintitrés aparecen dos veces cada uno: 46 líneas participan en los pares y hay 23 registros excedentes respecto de una fila por prefijo. La agrupación literal de los campos de prefijo arroja el mismo resultado.

Nueve pares son copias exactas. Por ejemplo, 200.123.12.0/24 aparece dos veces consecutivas con los mismos datos de Lima, Perú. No son dos observaciones independientes de Lima: el archivo ofrece dos filas iguales.

Otros diez pares conservan el país, pero cambian la información de ubicación. En cuatro varía la región o la ciudad; en seis cambia solamente el detalle disponible. 200.63.248.0/21 figura una vez con Ibarra y otra con Quito, ambas en Ecuador. En cambio, para 200.80.255.0/24 una fila contiene Argentina y Buenos Aires y la otra deja únicamente el país.

La distinción importa. Una ciudad omitida no demuestra un fallo. Una ciudad presente tampoco demuestra que la fila sea más reciente. Preferir el registro más completo puede parecer razonable, pero no añade una fecha de modificación ni una comprobación de campo.

Los cuatro pares restantes discrepan en el país. Además del /24 que combina Uruguay y Paraguay, 181.238.0.0/24, 181.239.32.0/24 y 186.182.0.0/24 aparecen con PY y AR: Paraguay y Argentina. Son cuatro conflictos entre códigos en esta captura, no cuatro redes cuya ubicación se haya demostrado falsa.

El denominador tampoco debe cambiar de nombre. Se contaron registros y prefijos, no abonados, organizaciones, sistemas autónomos o rutas efectivamente utilizadas. El pequeño conjunto merece revisión precisamente porque puede delimitarse, no porque permita afirmar que toda la base es poco fiable.

El desempate que la longitud no ofrece

El formato tiene una regla relevante. RFC 8805, en su sección 2.1.3, considera erróneas las entradas duplicadas de una dirección o prefijo y recomienda registrarlas para revisión administrativa. En cambio, admite prefijos anidados y recomienda utilizar la coincidencia de mayor longitud. Los campos de ubicación son opcionales.

El archivo contiene, por ejemplo, 177.126.48.0/22 y 177.126.48.0/24. El /24 está dentro del /22. Para una dirección cubierta por ambos, la mayor longitud distingue la declaración más específica. El mismo principio no establece una preferencia entre 170.51.97.0/24 y otra ocurrencia de 170.51.97.0/24.

No conviene confundir los dos casos para producir una cifra mayor. Rechazar toda superposición eliminaría subdivisiones que el formato permite. Exigir una ciudad a cada fila impondría una obligación que el formato no contiene y podría fomentar una precisión innecesaria. La anomalía investigada es una clave repetida, con o sin valores diferentes.

Tampoco basta con cargar el CSV en una tabla que solo admita una fila por prefijo. Esa operación garantiza una propiedad de la tabla de destino. Sin una política visible, puede ocultar qué declaración se descartó y por qué. El resultado queda ordenado, pero la disputa original desaparece de la vista.

Corregir sin inventar una respuesta

Para las nueve copias idénticas, una salida canónica sin repeticiones puede reducir ruido conservando los aportes originales. Cuando las filas difieren, hace falta otra clase de tratamiento: identificar el conflicto, mantener su procedencia cuando esté disponible y ofrecer un camino para corregirlo. La mera posición en el archivo no es ese camino.

Una revisión puede concluir que una fila estaba desactualizada, que hubo una duplicación de salida o que la declaración requería una formulación diferente. Aquí no se ha comprobado ninguna de esas causas. También podría existir un despliegue distribuido que no se describa adecuadamente mediante dos filas competidoras para la misma clave. La posibilidad de una explicación legítima no vuelve inequívoca la representación.

El consumidor conserva su propia responsabilidad. Puede tratar la ubicación declarada como una pista y contrastarla con otras fuentes apropiadas. Lo importante es no presentar una elección mecánica como si la hubiera resuelto el registro. Si una aplicación utiliza países para seleccionar contenidos o tomar decisiones de acceso, debería poder distinguir un valor comprobado de uno elegido al resolver un conflicto de carga.

No se consultaron historiales privados, cuentas de miembros, bases comerciales ni resultados geográficos de estos prefijos. No se sabe quién aportó cada fila, cuándo lo hizo, cuál refleja el uso actual o qué proveedor la consumió. Tampoco se documentó un rechazo de servicio. Una explicación de cómo podría propagarse un desacuerdo no es la prueba de que se haya propagado.

La conclusión, por tanto, puede mantenerse pequeña. Hay un conjunto verificable de claves repetidas en dos capturas iguales. Hacer visible su tratamiento mejoraría la utilidad del archivo común. No hace falta convertir a LACNIC en árbitro mundial de ubicaciones para pedir que el consumidor no tenga que adivinar qué significa encontrar dos países bajo el mismo prefijo.