Cómo saber dónde está alojada una web (y cuándo no se puede)

"¿Quién aloja este sitio web?" suena a pregunta con una sola respuesta. En la práctica, la respuesta honesta suele ser una cadena corta: el DNS lo lleva una empresa, el tráfico pasa por otra, el servidor pertenece a una tercera y el correo no tiene nada que ver con ninguna de ellas.

Esta guía muestra el método paso a paso, qué demuestra realmente cada paso y el punto en el que los datos públicos se acaban.

Paso 1: resolver el dominio a direcciones IP

Todo empieza por los registros A (IPv4) y AAAA (IPv6).

$ dig +short A www.example.com
192.0.2.10

$ dig +short AAAA www.example.com
2001:db8::10

En Windows, nslookup www.example.com da la misma información.

Dos detalles que se pasan por alto con facilidad:

example.com y www.example.com son nombres distintos. A menudo apuntan al mismo sitio, pero no siempre. Uno puede ser un servicio de redirección y el otro el sitio real. Compruebe el nombre de host en el que acaban realmente los visitantes.
Puede haber un CNAME en medio. Si www es un alias de algo como example.hosting-platform.example.net, el nombre de destino ya dice mucho. Los nombres de host de plataformas y CDN suelen ser reconocibles.

$ dig +short www.example.com
sites.platform.example.net.
192.0.2.10

Paso 2: encontrar la red propietaria de la IP

Una dirección IP pertenece a un bloque, y ese bloque lo anuncia a Internet un sistema autónomo (AS): una red con su propia política de enrutamiento y un número como AS64500. Empresas de hosting, proveedores de nube, operadores y grandes empresas operan todos sistemas autónomos.

Asociar una dirección a su AS le da:

el número y el nombre del AS, por ejemplo "AS64500 EXAMPLE-HOSTING"
el prefijo en el que se enruta la dirección, como 192.0.2.0/24
el país de asignación anotado por el registro regional de Internet (RIPE NCC, ARIN, APNIC, LACNIC o AFRINIC)

Para un sitio en un hosting compartido corriente, un VPS o una instancia en la nube, el nombre del AS es la respuesta que busca la mayoría. Si la red es una empresa de hosting conocida, esa empresa opera el servidor. El glosario amplía qué es un ASN.

Lo que no demuestra:

Los revendedores son invisibles. Una pequeña marca de hosting que alquila servidores a un gran operador de centros de datos aparece como el gran operador.
La nube no es un "host" en el sentido tradicional. Un nombre de AS que pertenece a un gran proveedor de nube le dice dónde se ejecuta la máquina. No le dice nada sobre quién la administra.
El país de asignación no es la ubicación del servidor. Es donde la organización registró el bloque. Un proveedor puede usar un bloque registrado en un país en un centro de datos de otro continente. Las bases de datos comerciales de geolocalización intentan hacerlo mejor, y también son conjeturas fundamentadas.

Paso 3: leer el DNS inverso

El DNS inverso asocia una dirección de vuelta a un nombre mediante un registro PTR.

$ dig +short -x 192.0.2.10
srv-10.fra1.hosting.example.net.

El registro PTR lo controla quien posee el bloque de IP, no el propietario del sitio web. Eso es lo que lo hace útil. Los nombres por defecto de los proveedores suelen contener su propio dominio, un código de región o de centro de datos (fra1 en este caso) y un identificador de servidor. Un PTR personalizado como web01.example.com sugiere un servidor dedicado o un VPS cuyo propietario se tomó la molestia de configurarlo.

Salvedades: muchas direcciones no tienen PTR en absoluto, y un PTR no es más que una afirmación del titular del bloque. Si importa, compruebe que el nombre resuelve hacia delante a la misma dirección; los detalles están en qué es el DNS inverso.

Por qué las CDN y los proxies ocultan el origen

Si el paso 2 devuelve Cloudflare, Fastly, Akamai, Amazon CloudFront o una red similar, ha encontrado el borde (edge), no el host.

Una CDN de proxy inverso funciona así: el DNS del dominio apunta a las direcciones de la CDN. Los visitantes se conectan a la ubicación más cercana de la CDN. La CDN sirve contenido en caché o reenvía la petición al servidor de origen, cuya dirección solo conocen la CDN y el propietario del sitio.

De ahí se deduce:

La dirección IP que ve la comparte un número muy grande de sitios web sin relación entre sí.
Normalmente es anycast: la misma dirección se anuncia desde muchas ciudades a la vez. Preguntar en qué país está no tiene una respuesta con sentido.
El origen puede estar en cualquier parte: una instancia en la nube, un servidor en una oficina, otra empresa de hosting.

Es deliberado. Ocultar el origen es parte de cómo estos servicios protegen los sitios de los ataques directos. Para un sitio detrás de una CDN, la respuesta correcta a "¿dónde está alojado?" es: detrás de esa CDN; el origen no es observable públicamente.

Encontrará artículos que describen trucos para desenmascarar orígenes, como datos DNS históricos, adivinar subdominios o buscar otros hosts en los registros de certificados. A veces sacan a la luz un registro obsoleto o mal configurado. Son poco fiables, el resultado es fácil de malinterpretar, y usarlos para sortear una protección que alguien puso a propósito pasa de la consulta al reconocimiento. Si tiene una razón legítima para llegar al operador, como un abuso, un asunto legal o un aviso de seguridad, el proceso de abuso de la CDN y los canales de contacto del registrador existen exactamente para eso.

Qué añaden los registros NS y MX

Otros dos tipos de registro ayudan a completar el cuadro.

Los servidores de nombres (NS) muestran quién lleva el DNS del dominio.

$ dig +short NS example.com
ns1.dns-provider.example.net.
ns2.dns-provider.example.net.

Unos servidores de nombres que pertenecen a una empresa de hosting suelen significar que el sitio también está alojado allí, porque el hosting compartido incluye el DNS.
Unos servidores de nombres que pertenecen a un registrador solo significan que el propietario usa el DNS por defecto del registrador.
Unos servidores de nombres que pertenecen a una CDN confirman que la CDN está delante.

Los servidores de correo (MX) muestran dónde se recibe el correo. Con frecuencia es un proveedor de correo específico sin relación con el host web. Si el MX apunta a mail.example.com en una dirección contigua a la del servidor web, el sitio probablemente está en un paquete de hosting clásico todo en uno. El registro SPF a veces enumera otros servicios a través de los cuales el propietario envía correo.

Ninguno de estos datos es una prueba. Juntos suelen bastar para una conclusión razonable como "DNS y CDN en un proveedor, correo en otro, origen desconocido".

Un ejemplo resuelto

Suponga que consulta shop.example y encuentra:

www es un CNAME a shops.platform.example.net
la dirección resuelve a una red con el nombre de un gran proveedor de nube
el DNS inverso muestra un nombre de host genérico de nube
los registros NS apuntan al registrador del dominio
los registros MX apuntan a un servicio de correo alojado

Lectura razonable: la tienda funciona sobre una plataforma de comercio electrónico alojada (el CNAME la delata), que a su vez funciona sobre una gran nube. El propietario usa el DNS del registrador y un proveedor de correo aparte. "¿Quién la aloja?" tiene dos respuestas válidas, la plataforma y la nube que hay debajo, y cuál necesita depende de por qué pregunta.

Límites y buenas maneras

Limítese a las consultas públicas. Las consultas DNS, la asociación de IP a ASN y una petición HTTPS normal son lo que ya hace cualquier navegador y cualquier resolver. Escanear puertos, probar subdominios por fuerza bruta y sondear orígenes son otra actividad, con otro peso legal y ético.
No sobreinterprete los datos. El nombre de una red identifica infraestructura, no a la persona que lleva un sitio web. Un país de asignación no es una conclusión sobre la jurisdicción.
Denuncie los abusos por la puerta adecuada. El contacto de abuso de la red (listado en los registros del RIR), el formulario de abuso de la CDN y la dirección de abuso del registrador son los canales que llevan a alguna parte.
Cuente con que las cosas cambian. Los sitios se mudan. Una respuesta es una instantánea con una marca de tiempo.

Compruébelo con OrbitProbe

La consulta de IP y hosting de OrbitProbe resuelve un dominio a sus direcciones IPv4 e IPv6 y muestra, para cada una, el DNS inverso, el ASN, el nombre de la red, el prefijo y el país de asignación. Las direcciones que están en rangos conocidos de CDN y proxy se etiquetan como direcciones de borde, para que no las confunda con el origen. Para ver al lado los servidores de nombres, los MX y los datos de registro, use el informe completo de dominio en vivo.