Una dirección IP puede conducir al registro del rango de red que la contiene, pero rara vez conduce directamente a la persona o al sistema que se investiga. El registro público puede identificar a un proveedor de acceso, una universidad, una empresa, una administración pública, una plataforma de nube o, en algunos casos, a un cliente al que se reasignó un bloque. También puede incluir contactos técnicos y de abuso. Es información útil siempre que no se convierta al titular registrado en una afirmación sin pruebas sobre la ubicación física del servidor, la ruta activa o el usuario que había detrás de un evento.
Se sigue hablando de WHOIS de IP porque WHOIS sobre el puerto TCP 43 fue el método de consulta original. Para integraciones, RDAP es hoy una interfaz mucho más adecuada: devuelve objetos JSON definidos sobre HTTPS y permite descubrir el servicio correcto a partir de los datos de arranque de IANA. WHOIS y RDAP exponen datos del mismo sistema general de recursos numéricos, pero usan transportes y formatos de respuesta distintos.
Cómo funciona el registro de recursos numéricos de Internet
IANA coordina los espacios globales de IPv4, IPv6 y números de sistema autónomo. Entrega grandes bloques de recursos a cinco Registros Regionales de Internet. AFRINIC presta servicio en África; APNIC, en la región de Asia-Pacífico; ARIN, en Canadá, Estados Unidos y parte del Caribe; LACNIC, en América Latina y parte del Caribe; y RIPE NCC, en Europa, Oriente Medio y Asia Central. Cada RIR aplica políticas elaboradas por su comunidad regional.
La cadena de registro puede continuar a través de un registro nacional, un registro local de Internet, un proveedor de acceso, una empresa de alojamiento u otro operador. Una reasignación más específica puede nombrar a una organización situada más abajo en la cadena, pero no todas las asignaciones pequeñas son públicas. ARIN, por ejemplo, señala que algunas reasignaciones pequeñas de proveedores y determinados clientes residenciales con datos privados no aparecen en su registro público. En esos casos, el proveedor superior puede ser el contacto público más específico disponible.
Los registros históricos añaden otra dificultad. Parte del espacio se asignó antes de que existiera el sistema moderno de RIR, y algunos registros antiguos eran muy amplios o se dividieron después. Un ejemplo repetido durante años atribuye al MIT todo 18.0.0.0/8. Los registros en vivo de ARIN consultados el 10 de julio de 2026 muestran al MIT en el intervalo 18.0.0.0 a 18.31.255.255, es decir, 18.0.0.0/11. ARIN registra a Amazon el intervalo mayor que va de 18.32.0.0 a 18.255.255.255. Una etiqueta histórica no sustituye una consulta autoritativa actual.
El agotamiento de IPv4 tampoco significa que todo registro nuevo proceda de una compraventa sencilla. El fondo de IPv4 no asignado de IANA se agotó, pero las políticas de los RIR siguen contemplando transferencias, devoluciones, espacio recuperado, reservas, listas de espera y asignaciones finales limitadas. Las reglas varían por región y cambian con el tiempo. Para una decisión operativa deben consultarse el registro y la política vigentes, no una fecha fija ni la idea de que un solo RIR conserva direcciones disponibles.
WHOIS y RDAP son métodos de acceso, no sistemas de titularidad distintos
WHOIS tradicional está definido en el RFC 3912. El cliente envía una consulta de texto por TCP y recibe otra respuesta de texto sin una estructura común. Los RIR utilizan modelos de objetos y nombres de campos diferentes, por lo que un analizador preparado para un servicio puede fallar con otro. Las referencias de WHOIS pueden llevar desde IANA al RIR responsable y desde una asignación amplia a un registro más específico.
RDAP reúne varios estándares. El RFC 7480 define el transporte HTTP; el RFC 7482, las rutas de consulta; y el RFC 7483, las respuestas JSON. El RFC 9224 cubre el descubrimiento del servicio autoritativo. Una respuesta para una IP puede contener dirección inicial y final, identificador, nombre, tipo, código de país si el registro lo aporta, eventos, enlaces, avisos y entidades con funciones como titular registrado, contacto técnico, administrativo o de abuso.
curl -s 'https://domscan.net/v1/rdap?type=ip&query=8.8.8.8' \
-H 'X-API-Key: YOUR_KEY' | jq '{status, rdap: .rdap}'El parámetro type es importante. La API RDAP de DomScan interpreta por defecto una consulta sin tipo como un dominio, así que una dirección IP o un bloque CIDR requiere type=ip. Para números de sistema autónomo se utiliza type=autnum. El formulario RDAP del navegador está orientado actualmente a dominios, mientras que la API admite los tres tipos de objeto. La respuesta conserva el objeto RDAP original dentro de la envoltura de DomScan y añade resúmenes de la consulta y de las entidades. No intenta convertir respuestas distintas de cada RIR en un registro universal ficticio de propiedad.
Cómo leer un registro RDAP de red
Empieza por el intervalo. startAddress y endAddress indican el bloque registrado que contiene la dirección consultada. Puede aparecer también una representación CIDR o puede calcularse cuando el intervalo coincide con un prefijo. Este dato responde cuál es el objeto de registro más específico devuelto por el servicio. No demuestra que todas las direcciones del bloque se utilicen para la misma aplicación, el mismo cliente o la misma instalación física.
Después conviene leer el identificador, el nombre, el tipo, el identificador del bloque superior y los eventos. El identificador pertenece al objeto dentro del registro. El nombre es una etiqueta registral y no tiene por qué coincidir con la razón social exacta de una empresa. La referencia superior enlaza el bloque con una asignación más amplia. Las fechas de evento pueden reflejar el registro o la última modificación, pero una actualización reciente también puede ser mero mantenimiento administrativo.
Las entidades recogen la organización y los contactos relacionados con el registro. Hay que leer su función antes de utilizarlos. Un contacto de abuso es el destino operativo para un informe, mientras que una entidad con función de registrante representa al titular que consta en el registro. Un contacto técnico puede mantener los datos sin operar el servicio observado. Los datos de contacto también pueden estar desactualizados o ser indirectos; que un buzón no responda no invalida por sí solo el intervalo registrado.
Como ejemplo con fecha, la respuesta RDAP autoritativa de ARIN para 8.8.8.8, consultada el 10 de julio de 2026, devuelve el intervalo 8.8.8.0 a 8.8.8.255, el identificador NET-8-8-8-0-2, el nombre GOGL y una entidad de registrante con identificador GOGL. Esto permite afirmar que ARIN registra ese /24 en la ficha organizativa de Google. No permite saber qué servicio de Google generó un paquete, dónde estaba la máquina que lo sirvió ni quién utilizó la dirección en un momento concreto.
Lo que el registro no demuestra
- No ofrece información autoritativa de enrutamiento BGP ni demuestra qué sistema autónomo originaba la ruta en el momento del evento.
- No garantiza la ubicación física de un servidor, una persona o una red. Una dirección postal de contacto no es una medición geográfica.
- No acredita residencia de datos. Un proveedor global puede registrar un bloque en una jurisdicción y utilizar sus direcciones en muchas regiones.
- No identifica al cliente de una nube, VPN, CDN, empresa de alojamiento o proveedor de acceso, salvo que una reasignación pública más específica lo nombre.
- No identifica a una persona detrás de NAT de nivel operador, un proxy compartido o una dirección residencial dinámica.
- No demuestra intención maliciosa. La red de un proveedor registrado puede alojar a la vez clientes legítimos y abusivos.
ARIN expone estas limitaciones de forma directa. Su registro público no contiene información de enrutamiento y ARIN no puede garantizar que la dirección incluida en una ficha de recursos sea la ubicación física de la red. Cuando una investigación necesita identificar a un abonado, normalmente hay que localizar al proveedor correcto, conservar la marca de tiempo y el puerto relevantes y seguir el procedimiento legal o de abuso que corresponda.
Registro, enrutamiento, geolocalización y DNS inverso son señales distintas
El registro responde quién figura como titular o administrador de un rango de recursos numéricos. Las observaciones BGP muestran qué sistema autónomo anunció un prefijo desde un punto de observación y en un momento determinados. RPKI y los datos validados de registros de enrutamiento pueden ayudar a comprobar si un origen está autorizado. Las fuentes pueden coincidir, pero no son intercambiables. Las fugas y los secuestros de rutas son precisamente casos en los que el registro y el enrutamiento observado divergen.
La geolocalización de IP es otra capa de inferencia. Las bases de datos comerciales y comunitarias estiman país, región, ciudad, red o tipo de uso a partir de señales de enrutamiento, proveedor, mediciones y registro. La precisión cambia según el campo y la dirección. La Búsqueda de IP de DomScan utiliza un proveedor de geolocalización y red, junto con enriquecimiento de DomScan, clasificación de seguridad y DNS inverso confirmado hacia delante. No devuelve el objeto de asignación RDAP autoritativo del RIR ni sus contactos de abuso.
Los datos PTR son metadatos de nombre configurados por el operador. Un resultado de DNS inverso como mail.example.net puede orientar sobre el uso previsto de una dirección. FCrDNS comprueba si ese nombre PTR vuelve a resolver hacia la misma IP. Incluso una comprobación correcta no demuestra quién es el titular legal, el cliente o la persona que generó el tráfico. Debe tratarse como una señal de coherencia, no como una identidad.
Límites en nubes, CDN, VPN y direcciones compartidas
Una dirección de nube pública suele devolver al proveedor de nube o a una red situada por encima. El registro no revela la cuenta cliente que alquila una máquina virtual. Una dirección de CDN identifica infraestructura compartida en el borde, no el servidor de origen de cada sitio que utiliza esa red. Una salida de VPN identifica la red registrada o el proveedor de alojamiento, no al abonado. Un informe de abuso debería incluir IP de origen, hora UTC exacta, destino, protocolo, puertos y registros de apoyo para que el proveedor pueda consultar sus datos privados.
La NAT de nivel operador crea el mismo problema de atribución a mayor escala. Muchos abonados pueden compartir una única dirección pública. El registro apunta al operador, mientras que la atribución a un abonado puede requerir el mapa interno y sensible al tiempo que relaciona dirección, puerto de origen y marca temporal. Una IP sin hora ni puerto puede ser insuficiente incluso para el proveedor que gestionaba la NAT.
Flujo práctico para una investigación
- Conserva la evidencia original: dirección IP completa, hora UTC, puertos de origen y destino, protocolo, datos de la solicitud y procedencia del registro.
- Confirma que la dirección sea pública y enrutable globalmente. Los rangos privados, de documentación, bucle local, enlace local, multidifusión y otros usos especiales requieren otro tratamiento.
- Consulta RDAP con type=ip y registra intervalo, identificador, entidades, funciones, avisos, enlaces y fechas de evento.
- Usa la Búsqueda de IP de DomScan u otra fuente independiente para geolocalización, ASN, centro de datos, proxy, seguridad y FCrDNS, etiquetando esos campos como enriquecimiento.
- Revisa evidencia de enrutamiento o RPKI correspondiente al momento del evento si importa la red anunciante. No deduzcas la ruta únicamente a partir del titular registral.
- Envía un informe concreto al contacto de abuso o al canal del proveedor. Describe la conducta observada y las pruebas, sin atribuir intención a la organización registrada.
Para una lista de permitidos o una revisión de proveedor, pide al proveedor que documente los prefijos concretos y su relación con el servicio. Que el titular del RIR coincida puede apoyar la revisión, pero no prueba que una dirección compartida de nube pertenezca en exclusiva a ese proveedor. En materia de residencia de datos se necesitan contratos, configuración de despliegue, registros y arquitectura verificada. Los campos de país del registro o de una base de geolocalización no son, por sí solos, evidencia de cumplimiento.
IP inversa y acceso masivo
La IP inversa no forma parte del registro de un RIR. Un conjunto de datos de IP inversa intenta asociar nombres de host a una dirección a partir de observaciones DNS anteriores, certificados, rastreo web u otras fuentes. El endpoint /v1/reverse/ip de DomScan está obsoleto y solo busca entradas de caché pasiva generadas por consultas previas a DomScan. No cubre todo Internet, no enumera todos los dominios alojados y no puede descubrir el servidor de origen de un cliente de CDN.
Tampoco conviene diseñar una recopilación masiva a partir de límites anónimos supuestos. Cada RIR publica condiciones y políticas de acceso que pueden cambiar. ARIN ofrece datos Bulk Whois mediante solicitud y acuerdo para usos aprobados. RDAP admite códigos de estado HTTP, autenticación y límites específicos del servicio. Deben respetarse los avisos de la respuesta y utilizarse las vías de acceso masivo que ofrezca el registro cuando el volumen lo exija.
Dónde encaja DomScan
Utiliza GET /v1/rdap con type=ip cuando necesites el objeto registral autoritativo descubierto mediante RDAP. Utiliza la Búsqueda de IP cuando necesites una vista separada de enriquecimiento con geolocalización, ASN, señales de seguridad, clasificación de centro de datos y FCrDNS. La referencia sobre DNS inverso explica el contexto de PTR. Cada resultado responde a una pregunta distinta y ninguno identifica por sí solo a una persona usuaria.
Fuentes independientes: Recursos numéricos de IANA describe el sistema de asignación de los cinco RIR. La guía de IANA sobre abusos explica cómo localizar el registro responsable. Las preguntas frecuentes del registro público de ARIN enumeran tanto los datos disponibles como ausencias importantes. Los RFC 3912, 7480, 7482 y 7483 definen los protocolos de acceso.