Primero aclara: ¿quieres consultar registro, enrutamiento, ubicación o riesgo?
Existen muchas herramientas de consulta de IP, pero la distinción fundamental es que responden preguntas diferentes. Si quieres saber bajo qué organización está registrado un bloque de direcciones, el correo de contacto o el punto de entrada para reportes de abuso, debes revisar los datos de registro RDAP; si quieres conocer qué sistemas autónomos anuncian actualmente un prefijo en la red, revisa las instantáneas de la tabla de enrutamiento BGP; si quieres saber si un prefijo específico tiene una autorización de origen de ruta válida, revisa el estado de validación RPKI; y si quieres evaluar el riesgo de abuso o proxy de una IP, puedes consultar un informe de reputación de IP. Mezclar estas preguntas, o esperar que una sola herramienta ofrezca simultáneamente la ubicación física exacta, la ruta en tiempo real y una puntuación de riesgo comercial, suele llevar a conclusiones erróneas.
El campo de país en una página puede provenir del registro de recursos o de una base de datos GeoIP; primero debes leer claramente la fuente. Si un usuario ve incoherencias entre el país, el idioma de la página o la marca de red e infiere que se usó VPN o Anycast, la evidencia no es suficiente. Puedes empezar con la Consulta de IP para registrar cada campo y luego verificar por separado RDAP, BGP y la estimación de ubicación; si te interesa la reputación, consulta también el Reputación IP: cómo interpretar riesgos y listas negras. Estas herramientas no responden a la misma pregunta.
El personal de operaciones, al tratar fallos o incidentes de seguridad, debe limitar la conclusión de cada herramienta a su alcance de evidencia. Por ejemplo, una consulta de enrutamiento BGP solo te indica los anuncios de ruta observados y los atributos AS_PATH, no puede demostrar directamente por qué enlaces físicos pasan los paquetes de extremo a extremo. Trata la salida de la consulta como una pista de investigación y combínala con otras evidencias como traceroute, datos de flujo o contadores de interfaz para formar un juicio fiable. Evitar negar toda otra información con un único resultado de consulta es una disciplina básica al interpretar datos de IP.
¿Qué preguntas de registro puede responder RDAP?
RDAP (Protocolo de Acceso a Datos de Registro) proporciona datos de registro mediante respuestas estructuradas, tanto para recursos de números de Internet como para registros de dominios; este artículo se centra en recursos de redes IP y sistemas autónomos. La respuesta puede incluir rangos de direcciones, identificadores de objeto, roles de contacto y eventos, pero el grado de publicidad y completitud de los campos depende de la política del organismo de registro y del registro específico. No presupongas que cada consulta tendrá un usuario final, un historial completo o un correo de abuso utilizable.
Es importante señalar que la dirección de contacto en RDAP es una dirección de registro pública, normalmente la oficina o sede legal de la organización registrante, y no equivale a la ubicación del dispositivo IP ni a la posición actual del usuario. Por ejemplo, la dirección RDAP de una multinacional puede estar registrada en la ciudad de su sede central, mientras que el servidor que realmente usa esa IP puede estar en un centro de datos de otro país. Usar directamente el mapa de direcciones RDAP como “localización de IP” sobreestima la precisión. Las especificaciones RFC 9082 y RFC 9083 definen la estructura de consulta y respuesta de RDAP, pero no exigen que los datos de registro incluyan ubicación física.
Cuando necesites confirmar la parte responsable del registro de un prefijo, usar directamente la herramienta Consulta RDAP para ver el registro original es más fiable que depender de resúmenes de segunda mano. El resultado mostrará el nombre de red, código de país, organismo de registro, estado (como allocated, assigned), historial de eventos y correo de contacto de abuso. Estos campos ayudan a los operadores a juzgar si un bloque tiene información de registro no actualizada desde hace tiempo, si pertenece a una asignación especial, pero no permiten inferir si ese bloque está lanzando ataques, aloja servicios maliciosos o pertenece a un usuario final concreto. La evidencia RDAP solo cubre el ciclo de vida del registro, no el comportamiento en tiempo real.
¿Por qué el ASN no equivale a la marca del proveedor de servicios?
El ASN (número de sistema autónomo) identifica un dominio de política de enrutamiento controlado por uno o más operadores de red. Los prefijos bajo un mismo ASN pueden usarse para diversos negocios, incluyendo alojamiento en centros de datos, servicios en la nube, CDN, redes de contenido y servicios de proxy transparente para distintas marcas minoristas o inquilinos. Por lo tanto, solo con el ASN no se puede determinar a qué marca de consumidor o ubicación concreta pertenece una IP. Un ASN de un gran proveedor de nube puede alojar simultáneamente direcciones IP de decenas de empresas, y el nombre de la organización registrante puede no tener ninguna relación directa con esas empresas.
Un sistema autónomo puede cubrir múltiples regiones y negocios, y el nombre de la organización puede diferir de la marca minorista, del cliente o del inquilino de nube. Un operador multinacional puede anunciar prefijos en varios países, y una misma empresa puede gestionar varios ASN. Anycast es un posible modo de despliegue del servicio; sus límites operativos se describen en RFC 4786, pero no se puede inferir directamente la ubicación geográfica de una IP concreta, la identidad del inquilino o el despliegue Anycast a partir del país de registro del ASN o del nombre de la empresa.
En el análisis de seguridad, un ASN pequeño tampoco puede equipararse simplemente a alto riesgo. Un sistema autónomo con pocos prefijos e historial corto puede ser un proveedor de contenido emergente legítimo, una red de investigación o un ISP regional. El juicio de riesgo debe basarse en el comportamiento de enrutamiento, la estabilidad histórica de anuncios, el estado de validación RPKI y los registros reales de quejas de abuso, no solo en el tamaño del ASN o la antigüedad de la información de registro. Consultar el enrutamiento BGP y el historial de un ASN puede ayudar a entender sus hábitos de anuncio, pero sigue siendo solo una evidencia auxiliar para el juicio.
Prefijo BGP, ASN de origen y AS_PATH
La consulta BGP muestra la información del plano de control recibida por un punto de observación concreto, incluyendo el prefijo, el ASN de origen, el AS_PATH y la hora. Al consultar una sola IP, la herramienta puede seleccionar el prefijo más largo que cubre esa IP. La coincidencia de prefijo más largo es una regla importante en la búsqueda en la tabla de reenvío: cuando hay una coincidencia más específica en la tabla, el paquete se reenvía según esa entrada; es diferente de la selección de mejor ruta en BGP entre múltiples rutas candidatas para el mismo prefijo. Ninguna de las dos puede dar directamente una lista completa de enlaces físicos.
El atributo AS_PATH enumera la secuencia de sistemas autónomos por los que pasa la ruta, pero no equivale a la ruta de reenvío real de los paquetes en el plano de datos. Las políticas de enrutamiento, la preferencia local, los valores MED, las confederaciones BGP y los túneles MPLS pueden hacer que la ruta real de los paquetes difiera del AS_PATH del plano de control. Por ejemplo, un paquete puede pasar por un peer remoto que no aparece en el AS_PATH. Por lo tanto, usar la Consulta de rutas BGP para determinar el anunciante actual de un prefijo puede ayudar a juzgar el control de la ruta, pero no permite inferir con precisión la ruta de tráfico de extremo a extremo.
Si necesitas ver el historial de anuncios de un prefijo, por ejemplo, si cambió de ASN de origen antes o si apareció un anuncio más específico, puedes consultar los datos de Historial BGP. Las instantáneas históricas pueden mostrar el estado del anuncio y los cambios del AS_PATH en un momento dado, pero la falta de datos históricos también puede deberse a puntos de observación incompletos o rutas no recogidas. Cualquier vista de un único colector de rutas es solo una parte del estado global del enrutamiento de Internet y no puede considerarse la verdad completa. Combinando datos de múltiples puntos de observación se puede tener una idea más fiable de la estabilidad del enrutamiento.
RPKI: Valid, Invalid y NotFound
RPKI (Resource Public Key Infrastructure) autoriza a un ASN a anunciar un prefijo específico mediante la emisión de ROA (Route Origin Authorization), pudiendo especificar opcionalmente una longitud máxima de prefijo maxLength. Al realizar la validación de origen, el router o la herramienta de validación compara el prefijo y el ASN de origen de la ruta BGP con el conjunto de VRP (Validated ROA Payload) generado a partir de los ROA válidos. El resultado de la validación se clasifica en tres estados: Valid, Invalid y NotFound.
El estado Valid significa que existe al menos un VRP cuyo prefijo autorizado cubre el prefijo anunciado por la ruta, el ASN de origen coincide y la longitud del prefijo está dentro del rango permitido (normalmente considerando maxLength). El estado Invalid significa que existe uno o más VRP que cubren el prefijo, pero el ASN de origen no coincide o la longitud del prefijo excede el rango autorizado. Según la RFC 6811, Invalid no equivale automáticamente a secuestro de ruta o comportamiento malicioso, ya que los errores de configuración, el retraso en la actualización del ROA o los errores operativos del propio operador pueden causar Invalid.
El estado NotFound indica que no hay ningún VRP que cubra el prefijo, normalmente porque el titular del recurso no ha creado un ROA o el validador aún no ha obtenido los datos de ROA más recientes. NotFound no debe interpretarse como una señal de ataque, solo indica que no se puede determinar la autorización de origen mediante RPKI. Usando la herramienta de Validación RPKI se puede ver el estado de validación de un prefijo IP específico, los detalles del ROA coincidente y la hora de validación. El personal de operaciones debe registrar la marca de tiempo de cada validación, porque los datos RPKI cambian dinámicamente y el estado de un prefijo puede cambiar con la publicación o revocación de un ROA.
¿Por qué Valid no es un certificado de seguridad?
La validación de origen RPKI comprueba si el ASN de origen y la longitud del prefijo de una ruta están autorizados por los datos de los ROA validados en ese momento. Un resultado Valid no autentica el resto del AS_PATH, no demuestra la seguridad de los paquetes ni la fiabilidad de los dispositivos finales, y no evalúa el comportamiento del usuario o la seguridad del contenido. Una red maliciosa puede tener un ROA válido para su propio prefijo, obtener el estado Valid para su ruta y seguir realizando actividades dañinas en su infraestructura. Por tanto, que la ruta que cubre una IP tenga un resultado Valid no garantiza que esa dirección no se utilice para abusos ni que el servicio sea de confianza.
De igual manera, el estado Invalid no puede juzgarse directamente como secuestro de ruta. Escenarios de ingeniería comunes incluyen: el operador no actualizó el ROA a tiempo al migrar un prefijo, o configuró erróneamente maxLength provocando que no se permita un anuncio más específico. Estos son problemas de configuración del registro de rutas y se pueden restaurar al estado Valid corrigiendo el ROA. Por otro lado, un secuestrador real puede usar un prefijo no cubierto (es decir, NotFound) para anunciar, lo que demuestra aún más que el estado por sí solo no constituye una conclusión de seguridad.
Al informar al operador, se debe conservar la hora de observación, el prefijo específico, el ASN de origen, el ASN autorizado y maxLength del VRP que cubre, así como el validador o la fuente de datos. Una redacción de ejemplo sería: "En la hora indicada, 203.0.113.0/24, origen AS64496 fue validado como Invalid; existe un VRP que cubre, pero no hay ningún registro que cumpla simultáneamente los requisitos de origen y longitud." Aquí se usan recursos de ejemplo de documentación, no una alerta de enrutamiento real. El receptor necesita verificar el conjunto completo de coincidencias, no puede ignorar otra autorización válida solo por ver un VRP no coincidente.
¿Por qué difieren el país de registro y el país de localización?
La discrepancia entre el país de registro y el país de localización no indica automáticamente un error de localización o la presencia de Anycast. Las direcciones IP son asignadas por registros regionales de Internet a organizaciones multinacionales, que pueden elegir registrar en el país de su sede central mientras que el uso real ocurre en sucursales o centros de datos globales. Por ejemplo, una empresa europea registra todo un bloque de IP en los Países Bajos, pero los servidores alquilados están en Singapur; al consultar, el país de registro muestra Países Bajos, mientras que la latencia de red y las observaciones de enrutamiento apuntan a Singapur. Esto es normal, no una anomalía.
Cuando un ISP ascendente obtiene un bloque grande de recursos, puede asignarlo a diferentes clientes o regiones, y los registros, las bases de datos de localización comerciales y la caché del sitio web se actualizan cada uno por su cuenta. Las transferencias de recursos, los cambios de asignación o las revisiones de datos pueden causar desfases temporales, no se puede asumir que se sincronizarán después de un número fijo de semanas o meses. Se debe registrar la hora y la fuente de la consulta específica, distinguir entre el objeto de registro actual, las instantáneas históricas y las estimaciones de ubicación, evitando usar un campo para reemplazar el significado de otro.
Los factores de diseño de red incluyen CDN, proveedores de nube y líneas dedicadas transnacionales, que despliegan direcciones del mismo prefijo en varios países. En este caso, ningún "país de registro" único puede representar el punto de entrada real del tráfico. Para juzgar si una IP ofrece servicio en un país específico, se deben combinar la ruta AS en el enrutamiento BGP, mediciones activas de ping/traceroute e información pública de regiones del proveedor de nube. Inferir Anycast solo por la inconsistencia del país es evidencia insuficiente.
¿Cuál es la diferencia entre Anycast y broadcast?
Anycast permite que múltiples instancias de un servicio usen la misma dirección, y el enrutamiento envía una solicitud a una de las instancias alcanzables; los despliegues comunes en Internet anuncian el prefijo que contiene esa dirección desde múltiples ubicaciones. La instancia seleccionada depende de la política de enrutamiento y no garantiza la más cercana geográficamente, la de menor latencia o la de menor carga. Broadcast envía el mensaje a múltiples receptores dentro del dominio de difusión, son completamente diferentes. La práctica de ingeniería de Anycast se puede consultar en la RFC 4786.
Para determinar si una dirección usa Anycast, se puede combinar la documentación explícita del operador sobre esa dirección de servicio con mediciones realizadas desde múltiples ubicaciones y en el mismo período, junto con identificadores de instancia. El mismo ASN puede aparecer en varios sitios Anycast, por lo que no es necesario que los ASN de destino sean diferentes; tampoco que los ASN o las rutas traceroute distintas prueben automáticamente Anycast, ya que los cambios de enrutamiento, túneles y limitaciones de medición pueden afectar los resultados. Se debe indicar hasta qué punto la evidencia respalda la conclusión y no calificar una dirección basándose solo en unas pocas etiquetas de país.
Un error común es considerar la diferencia en el campo de país como prueba de Anycast, por ejemplo, que la misma IP aparezca como Estados Unidos y Alemania en distintas bases de datos comerciales. Esto solo indica inconsistencia en las fuentes de geolocalización, posiblemente por problemas de registro, enrutamiento o actualización de bases de datos, y no es condición suficiente para Anycast. Todo juicio operativo debe distinguir claramente entre posibilidad y prueba, evitando presentar hipótesis no verificadas como conclusiones.
Caso ilustrativo: ¿quiénes son el registrante, el operador y el arrendatario?
El siguiente es un escenario ilustrativo, no basado en mediciones reales. Supongamos que se consulta la dirección de ejemplo de documentación 192.0.2.10. RDAP muestra que el país de registro es Estados Unidos y la organización registrante es Example Corp, mientras que el ASN de origen anunciado en BGP pertenece a un proveedor de nube europeo. Esta diferencia podría deberse a que Example Corp arrienda el bloque de direcciones al proveedor de nube, que despliega nodos de borde en Fráncfort y Tokio pero no actualiza la información de registro. Con solo estos datos, no se puede confirmar la ubicación física actual de la IP ni si se usa Anycast.
Continuando con esta hipótesis: dos puntos de medición ubicados cerca de Fráncfort y Tokio llegan cada uno a su instancia de servicio local y obtienen identificadores de instancia distintos y verificables, siendo el objetivo de solicitud la misma dirección de ejemplo de documentación 192.0.2.10. Combinando esto con la declaración explícita del operador sobre Anycast para esa dirección, se puede respaldar la conclusión de despliegue en múltiples ubicaciones. Aquí solo se describe un ejemplo lógico; no se afirma que desde cualquier punto del mundo se obtenga una latencia menor a 10 milisegundos. RPKI Valid solo verifica la autorización de origen del prefijo y no prueba la ubicación de las instancias.
En este caso, las incógnitas incluyen: la identidad concreta del arrendatario, si los puertos del servicio están abiertos para todas las regiones, el mecanismo de sincronización de estado entre instancias y si hay filtrado de paquetes en redes intermedias. El personal operativo debe registrar estas incógnitas fielmente, en lugar de ocultar la falta de evidencia con la etiqueta "Anycast". Clasificar no implica malicia; no coincidir tampoco es un ataque. Delimitar claramente los límites es la base del juicio profesional.
¿Por qué los registros históricos no coinciden con los resultados actuales?
Los eventos en RDAP suelen describirse con campos como eventAction y eventDate, por ejemplo registration o last changed; algunas interfaces los resumen como "updated". Estas fechas describen eventos del objeto registrado, no el momento de la mudanza física del servidor. Cambiar el correo electrónico, el estado o los datos administrativos puede alterar la fecha de actualización, mientras que la ubicación del servicio puede cambiar sin reflejarse en esos campos. Se deben conservar los nombres originales de los eventos y no interpretar todas las fechas como migración de la dirección.
La división de prefijos y la transferencia de recursos son causas frecuentes. Si un bloque grande /16 se divide en varios /24, algunos subbloques pueden asignarse a otras organizaciones, pero el campo de país en la información de registro del padre conserva el valor original. Al consultar RDAP para un /24, puede devolver el valor histórico del país del padre, mientras que BGP muestra que ese subbloque ya es anunciado por un ASN de otro país. Distintos puntos de observación también causan inconsistencias: las bases de datos IP comerciales usan fuentes y tiempos de recolección diferentes, con diferencias de instantáneas de hasta meses.
El siguiente ejemplo hipotético ilustra cómo registrar las pruebas. El manejo correcto es conservar todos los registros originales y anotar la hora de consulta. Por ejemplo: en enero de 2024, RDAP mostraba el país como Reino Unido; en junio de 2024, la ruta BGP pasaba por Alemania; en septiembre de 2024, el extremo de traceroute de un punto de observación estaba en Países Bajos. No se puede decir simplemente "la IP se mudó a Países Bajos"; se debe decir "existen diferencias según el momento y el punto de observación, posiblemente por ajustes de enrutamiento o retraso en las bases de datos". Así se preserva la evidencia y se evita la sobreinferencia.
¿Cómo combinar la evidencia y conservar las incógnitas?
Un juicio completo de consulta de IP debe dividirse en cuatro categorías de evidencia. El contexto de registro proviene de RDAP y WHOIS, incluyendo organización registrante, país, fecha de registro, correo de contacto y estado, pero no contiene ubicación física ni identidad del usuario final. El estado de enrutamiento proviene de BGP y RPKI, incluyendo el ASN anunciado, la ruta AS, la validez RPKI (Valid o Invalid) y la visibilidad; solo refleja la accesibilidad del plano de control, no garantiza la ruta completa del plano de datos. La estimación de ubicación proviene de bases de datos IP comerciales, latencia y traceroute, y es un juicio probabilístico.
El comportamiento directo debe registrarse por separado, como si inicia escaneos activamente, si hay resoluciones de dominios maliciosos o si responde a puertos específicos. Una IP con información de registro de un ISP residencial, incluso si su geolocalización coincide con una ciudad, no implica que pertenezca a un usuario doméstico real, porque puede haber proxies o servicios de alojamiento. Para los puntos clave sobre IP residencial y nativa, consulta IP residencial, de ISP y de centro de datos: diferencias. Cuando la cobertura de puntos de observación es insuficiente, la misma IP puede aparecer como inaccesible por ruta en algunas regiones; esto no prueba que sea inaccesible globalmente, consulta Reputación de una subred /24: cobertura y riesgos.
Supongamos que el país de registro es Canadá, el ASN es administrado por un ISP canadiense, RPKI es Valid, las bases de datos comerciales estiman Toronto y algunos puntos de medición canadienses muestran baja latencia. Se puede indicar que estos resultados son consistentes con una ubicación de servicio en Canadá, pero no se debe escribir como prueba de ubicación física ni inferir de RPKI que el servicio funciona con normalidad. El registro es información, el enrutamiento es observación, la ubicación es estimación y el registro de comportamiento también tiene fuentes y límites de medición; todas las conclusiones deben anotar momento, condiciones y lo que aún no se puede confirmar.
Preguntas frecuentes y materiales de revisión
Pregunta frecuente uno: ¿un cambio de ASN significa cambio de operador? No necesariamente. El ASN representa un dominio de política de enrutamiento; un operador grande puede tener múltiples ASN, y una empresa puede migrar a un proveedor de nube manteniendo su bloque de IP original. Se debe verificar si el prefijo IP es anunciado por diferentes ASN en la misma ruta BGP o si hay cambios en la ruta AS, y combinar con la información de registro para determinar si realmente cambió el proveedor de red.
La validación de origen RPKI no previene todos los ataques de enrutamiento ni autentica el AS_PATH completo. La redacción rigurosa es "la ruta es Valid, Invalid o NotFound con respecto al conjunto actual de VRP"; no se debe simplificar Invalid como "ROA inválido", pues no son el mismo concepto. RDAP tampoco es una herramienta de localización personal de terminales: aunque el objeto público contenga información personal o de contacto, sigue siendo información de registro de recursos y no permite identificar a la persona que realiza la solicitud actual ni su domicilio preciso.
El marco de revisión de tickets debe exigir que el solicitante proporcione: hora de consulta (UTC), IP o prefijo específico, instantánea de RDAP/WHOIS, tabla de rutas BGP o fuente de observación de traceroute, estado actual (como fallo de conexión o fuga de rutas) y el requerimiento concreto. El personal operativo, con base en esto, primero verifica los campos de registro, luego revisa RPKI y la ruta AS, y finalmente consulta la geolocalización y las mediciones activas. Usar este marco reduce errores como "el campo de país no coincide, por lo tanto fue hackeado".
