Qué es el DNS y cómo funciona realmente

Se puede llegar a cada dispositivo de internet mediante una dirección numérica: una dirección IP. Nadie quiere recordar 172.64.80.1, así que usamos nombres: example.com. El DNS, el Sistema de Nombres de Dominio, es el servicio de directorio que traduce el nombre que escribes a la dirección que una computadora necesita realmente. Es fácil darlo por hecho precisamente porque funciona con tanta fiabilidad en segundo plano en casi todas las solicitudes de red que haces.

La consulta, paso a paso

Cuando visitas un dominio por primera vez, tu dispositivo no conoce todavía su dirección IP. Se lo pregunta a un resolvedor (normalmente uno gestionado por tu ISP o por un proveedor público como Cloudflare o Google) para averiguarlo. Ese resolvedor tampoco tiene por qué saber la respuesta, así que avanza por una cadena de autoridad:

1. Un servidor raíz le indica los servidores responsables del dominio de nivel superior del dominio (.com, .org, .io, etc.).
2. El servidor del TLD le indica los servidores de nombres autoritativos del dominio concreto: los servidores que el propietario del dominio configuró realmente.
3. El servidor de nombres autoritativo devuelve el registro real: la dirección IP (o las direcciones) a la que apunta el dominio en ese momento.

Toda esa cadena suele completarse en bastante menos de un segundo, y el resultado se guarda después en caché para no tener que repetirlo en cada solicitud; más sobre eso en la sección de TTL de más abajo.

Un rastreo concreto, de principio a fin

Supongamos que a un resolvedor con la caché vacía le piden resolver blog.example.com. Primero pregunta a un servidor raíz, que no sabe la respuesta pero sabe quién gestiona .com, y lo dirige allí. El servidor del TLD .com tampoco conoce la respuesta final, pero sabe a qué servidores de nombres delega el propio example.com (por ejemplo, ns1.dnshost.com y ns2.dnshost.com), y dirige al resolvedor hacia ellos. Solo entonces el resolvedor pregunta a un servidor que realmente guarda los registros de example.com, y ese servidor, el autoritativo, responde con la respuesta real: un registro A, o un CNAME que obliga a dar un salto más. Cada paso de esa cadena es en sí mismo una consulta DNS, y por eso la primera consulta (en frío) de un dominio es claramente más lenta que todas las que siguen una vez que las respuestas intermedias están en caché.

El almacenamiento en caché ocurre en más capas que el resolvedor

El resolvedor recursivo no es el único lugar donde se guarda una respuesta en caché. La mayoría de los sistemas operativos mantienen su propia caché de DNS de corta duración, y algunos navegadores mantienen otra distinta encima. Esa es una segunda razón, muy habitual, por la que dos consultas del «mismo» dominio pueden parecer contradecirse: no siempre es un resolvedor distinto que da una respuesta distinta; a veces es tu propia máquina sirviendo una copia local algo obsoleta mientras una consulta directa y nueva ya mostraría la actual.

Los tipos de registro con los que te vas a encontrar

«Registro DNS» no es una sola cosa: un dominio tiene varios tipos de registro distintos uno junto al otro, y cada uno responde a una clase de pregunta diferente. Una consulta de la dirección IP de un dominio solo toca dos de ellos; el resto existen con fines totalmente distintos.

Por qué importa aunque nunca toques los registros DNS directamente

Entender este flujo da sentido a muchos comportamientos que de otro modo resultan confusos: por qué un cambio de DNS no surte efecto al instante, por qué un dominio puede resolverse bien desde una red y fallar desde otra, y por qué «el sitio está caído» a veces resulta ser un problema de DNS y no de servidor. Herramientas como esta saltan directamente al último paso (consultar directamente un resolvedor público cercano a la fuente autoritativa y mostrarte exactamente lo que devuelve) para que puedas ver el estado actual real del DNS de un dominio sin adivinar.

También explica por qué «DNS» e «internet» se confunden tanto en los diagnósticos informales. El DNS no transporta tu tráfico, no aloja tu contenido ni ejecuta tu aplicación: solo responde una pregunta, «a qué dirección apunta este nombre ahora mismo». Todo lo que ocurre después (la conexión propiamente dicha, la carga de la página, la respuesta de la API) es un sistema totalmente aparte, y por eso vale la pena aislar el DNS como un paso independiente y comprobable por separado antes de dar por hecho que hay un problema mucho mayor.