Resumen

  • RFC 9877 registra geofeed1, la relación geofeed y el tipo application/geofeed+csv para que un objeto de red RDAP pueda señalar una geofeed servida por HTTPS.
  • El enlace acredita dónde estaba disponible una fuente en una respuesta concreta; no demuestra por sí solo la actualidad de sus filas, la presencia física de una red ni la ubicación de una persona.
  • Antes de usarla hay que conservar el rango del objeto, descartar filas ajenas, comprobar la autoridad del publicador, medir la antigüedad y autorizar por separado la decisión resultante.

El cliente consulta una dirección y recibe el objeto más específico. No hay enlace. Repite la operación sobre el bloque padre y aparece una geofeed. La tentación es llamar a ese segundo resultado «la ubicación». En realidad, el recorrido solo ha resuelto una pregunta: dónde encontrar una declaración potencialmente pertinente.

RFC 9877, publicado como estándar de la IETF en octubre de 2025, crea una sintaxis estable para esa búsqueda. El servidor RDAP puede añadir a un objeto IP una relación geofeed, recomendar el tipo application/geofeed+csv y apuntar a una URL HTTPS. El identificador geofeed1 informa de una conducta adicional del servidor.

El propio RFC deja fuera de alcance la descarga y el uso de los datos. No es una letra pequeña: separa el catálogo de la evaluación. Que el catálogo sepa llegar al archivo no significa que haya verificado cada lugar, ni que haya concedido permiso para decidir sobre clientes, tráfico o personas.

La promesa condicional de geofeed1

Cuando un servidor anuncia geofeed1 en rdapConformance, debe incluirlo en las respuestas de consulta o búsqueda con objetos de red y en la ayuda. Si posee una URL para el objeto y puede devolverla, debe incluir el enlace. Puede haber restricciones regulatorias u otras que impidan exponerlo.

Por eso, la falta de enlace bajo esa declaración permite una inferencia limitada: el servidor no tiene datos geofeed disponibles para ese objeto en esas condiciones. No autoriza a decir que el prefijo carece de geografía, que un agregado superior tampoco tiene enlace o que el titular no publica por otra vía.

Además, un servidor puede usar la relación y el tipo registrados sin anunciar geofeed1. Un consumidor robusto mira dos cosas: la capacidad declarada y los enlaces efectivamente recibidos. Convertirlas en una única bandera borra información y produce falsos negativos.

HTTPS añade autenticación e integridad del canal. No demuestra que el sitio web controle todos los prefijos descritos. La identidad del servidor que entrega bytes y la autoridad sobre recursos numéricos son hechos relacionados, pero no idénticos.

Subir al padre obliga a recordar el rango

RFC 9082 hace que una consulta IP devuelva el objeto más específico que cubre la dirección o el rango pedido. RFC 9877 advierte que la geofeed puede vivir en un objeto menos específico. El cliente puede remontar la jerarquía, pero cada salto cambia el ámbito de la referencia.

Si una geofeed compartida contiene más espacio que el objeto que aportó el enlace, toda fila fuera del rango de ese objeto debe ignorarse. El filtro es parte de la autorización técnica. Descargar correctamente un CSV no da derecho a importar todas sus líneas.

RFC 8805 recomienda confirmar que quien publica tiene autoridad sobre los recursos. El arranque de RFC 9224 ayuda a localizar el servicio RDAP que puede hacer afirmaciones autorizadas sobre la disposición del recurso. Es una procedencia más fuerte para la referencia, no una certificación del significado de cada ciudad o país.

Una geofeed es información operativa suministrada por el titular. Puede usar granularidad aproximada, quedar atrasada respecto de una migración o describir un punto de servicio que no coincide con la trayectoria de cada usuario. Anycast, redes corporativas y accesos móviles hacen especialmente peligrosa la idea de una coordenada única. El vocabulario correcto es «ubicación declarada para un prefijo y un momento», no «usuario localizado».

La firma no decide el uso

RFC 9632, sucesor de RFC 9092, define una autenticación RPKI opcional. Una firma válida puede vincular mejor el archivo con un certificado que cubre el espacio. No prueba que la semántica sea exacta, que la información siga vigente ni que una aplicación pueda usarla para denegar acceso o elevar una alerta.

El sistema debería conservar estados separados: referencia descubierta, descarga completada, transporte validado, rango guardado, filas filtradas, publicador comprobado, firma evaluada, frescura calculada, finalidad permitida y resultado observado. Una sola etiqueta de «geolocalizado» impide reconstruir el error cuando cambia el archivo.

La frecuencia revela otro límite. RFC 9877 prohíbe búsquedas frecuentes en tiempo real que carguen indebidamente los servicios. RFC 9632 aconseja respetar la caché HTTP y, sin una señal de vigencia, no descargar más de una vez por semana. Consultar hoy una API que sirve un archivo antiguo no vuelve actual el dato.

También está la privacidad. El publicador debe cuidar que la geofeed no exponga la ubicación de un individuo, y los operadores de registro han de revisar si su marco regulatorio permite ofrecer la función. El protocolo hace accesible una fuente; no borra la limitación de finalidad ni la obligación de minimizar daño.