Cómo Funciona el Sistema de Nombres de Dominio (DNS)

Cada vez que abre un sitio web, envía un correo o llama a una API, su dispositivo tiene que responder primero una pregunta sencilla: ¿qué dirección IP corresponde a este nombre? El Sistema de Nombres de Dominio (DNS) es el directorio global y distribuido que la responde. Es una de las piezas más antiguas de la infraestructura de internet que se siguen usando a diario y, como suele funcionar de forma invisible, muchos propietarios de sitios solo descubren cómo opera cuando algo falla. Esta guía recorre de principio a fin el viaje de una consulta DNS con un lenguaje claro, explica por qué la caché es tan importante y muestra los comandos con los que puede verlo todo por sí mismo.

Qué hace realmente el DNS

Los ordenadores enrutan el tráfico con direcciones numéricas como 93.184.215.14 (IPv4) o 2606:2800:21f:cb07:6820:80da:af6b:8b2c (IPv6). Las personas preferimos nombres. El DNS traduce entre ambos, pero es mucho más que una tabla de búsqueda: es una base de datos jerárquica y delegada en la que ningún servidor conoce todas las respuestas. La responsabilidad se divide en zonas y cada zona la gestiona quien la controla.

Este diseño tiene tres consecuencias prácticas:

• Escalabilidad: los servidores raíz no necesitan conocer miles de millones de nombres de host, solo dónde encontrar cada dominio de nivel superior.
• Autonomía: una vez que un dominio se le delega, usted decide qué registros contiene sin pedir permiso a nadie.
• Resiliencia: cada nivel lo atienden varios servidores, a menudo repartidos por distintos continentes mediante enrutamiento anycast.

Los registros individuales de una zona, como A, AAAA, CNAME y MX, se explican con detalle en nuestra guía para entender los registros DNS. Aquí nos centramos en cómo un resolutor encuentra esos registros en primer lugar.

La jerarquía DNS: raíz, TLD y servidores autoritativos

Si lee un nombre de dominio de derecha a izquierda, estará recorriendo el árbol DNS de arriba abajo. El nombre www.example.com. termina en realidad con un punto invisible que representa la raíz.

El vínculo entre niveles se llama delegación. Cuando registra un dominio y configura sus servidores de nombres en el registrador, este envía esos registros NS al registro, que los publica en la zona del TLD. Si los servidores de nombres están dentro del propio dominio (por ejemplo, ns1.example.com), el registro publica además los registros glue, es decir, las direcciones IP de esos servidores, para evitar el problema del huevo y la gallina.

Paso a paso: qué ocurre al escribir una URL

Imagine que visita www.example.com por primera vez desde una red nueva. La consulta avanza más o menos así:

1. Comprobaciones locales. El navegador revisa su propia caché y después pregunta al sistema operativo, que consulta su caché y el archivo hosts.
2. Del resolutor stub al resolutor recursivo. Si no hay nada en caché, el resolutor stub integrado en el sistema envía la consulta al resolutor recursivo configurado: normalmente el de su proveedor de internet, su router o un servicio público como 1.1.1.1, 8.8.8.8 o 9.9.9.9.
3. El resolutor pregunta a un servidor raíz. El resolutor incluye una lista de direcciones de servidores raíz (root hints). Pregunta a uno de ellos por www.example.com. La raíz no conoce la respuesta, pero devuelve una referencia: estos son los servidores de nombres de .com.
4. El resolutor pregunta a los servidores del TLD. Un servidor de .com responde con otra referencia: los servidores autoritativos de example.com, junto con los registros glue si hacen falta.
5. El resolutor pregunta al servidor autoritativo. Este servidor aloja la zona y devuelve la respuesta real, por ejemplo un registro A con una dirección IPv4, marcada con el indicador AA (respuesta autoritativa).
6. La respuesta se entrega y se guarda en caché. El resolutor devuelve la respuesta a su dispositivo y la almacena, junto con las referencias recopiladas, durante el TTL de cada registro.

El resolutor realiza consultas iterativas hacia la jerarquía mientras atiende la consulta recursiva de su dispositivo. Su portátil pregunta una vez y espera; el resolutor hace el recorrido. En la práctica, los pasos 3 y 4 casi nunca son necesarios, porque el resolutor ya tiene en caché las referencias de la raíz y de .com.

Observarlo con dig +trace

La utilidad dig (incluida en las herramientas de BIND y disponible en Linux y macOS) puede hacer el recorrido por sí misma e imprimir cada referencia. La salida está abreviada:

$ dig +trace www.example.com A

.                 518400  IN  NS  a.root-servers.net.
.                 518400  IN  NS  b.root-servers.net.
;; Received 239 bytes from 127.0.0.53#53

com.              172800  IN  NS  a.gtld-servers.net.
com.              172800  IN  NS  b.gtld-servers.net.
;; Received 1170 bytes from 198.41.0.4#53(a.root-servers.net)

example.com.      172800  IN  NS  a.iana-servers.net.
example.com.      172800  IN  NS  b.iana-servers.net.
;; Received 361 bytes from 192.5.6.30#53(a.gtld-servers.net)

www.example.com.  300     IN  A   93.184.215.14
;; Received 60 bytes from 199.43.135.53#53(a.iana-servers.net)

Cada bloque es un salto: raíz, TLD y servidor autoritativo. El número que sigue al nombre es el TTL en segundos.

Caché y TTL: por qué el DNS es tan rápido

Si cada consulta recorriera el árbol completo, los servidores raíz y de TLD estarían saturados y navegar resultaría lento. La caché lo evita. Cada registro lleva un TTL (Time To Live, tiempo de vida), fijado por el propietario de la zona, que indica a los resolutores cuántos segundos pueden reutilizar la respuesta antes de volver a preguntar.

• TTL largos (horas o un día) reducen la carga de consultas y hacen que su sitio tolere mejor caídas breves de los servidores autoritativos, pero los cambios tardan más en llegar a todos.
• TTL cortos (de 60 a 300 segundos) le permiten cambiar de servidor con rapidez, a cambio de generar más consultas.
• Caché negativa: una respuesta de "este nombre no existe" (NXDOMAIN) también se guarda en caché durante un periodo derivado del registro SOA de la zona. Si crea un registro justo después de que alguien lo consultara, puede parecer que no funciona durante un rato.

Un buen hábito antes de una migración: reduzca el TTL de los registros que va a modificar uno o dos días antes, haga el cambio y vuelva a subir el TTL cuando el tráfico ya se haya trasladado.

Qué significa de verdad la "propagación DNS"

Cuando edita un registro, nada se envía activamente por internet. La "propagación" es simplemente el tiempo que tardan en caducar las copias en caché de miles de resolutores. Intervienen dos temporizadores distintos:

• Los cambios en los registros de su zona dependen de los TTL de esos registros.
• Los cambios de servidores de nombres afectan a la delegación publicada en la zona del TLD, cuyo TTL de NS fija el registro y, en algunos TLD, es de 48 horas o más. Los resolutores que guardaron la delegación antigua la siguen usando hasta que caduca.

Si mantiene al proveedor DNS anterior sirviendo los mismos registros durante el cambio de servidores de nombres, la transición será invisible para sus visitantes.

Problemas DNS habituales y cómo detectarlos

Una delegación rota (lame delegation) se produce cuando el TLD apunta a servidores de nombres que en realidad no sirven su zona, a menudo tras cancelar un plan de hosting sin actualizar los registros NS. Puede ver rápidamente a qué servidores de nombres está delegado un dominio, junto con su registrador y su fecha de caducidad, con la consulta WHOIS de TLDix.

Resolutores recursivos, privacidad y seguridad

El DNS clásico viaja por el puerto UDP 53 en texto plano, así que cualquiera en la ruta de red puede ver las consultas y, potencialmente, manipularlas. Varias mejoras abordan este problema:

• DNS over TLS (DoT) y DNS over HTTPS (DoH) cifran la conexión entre su dispositivo y el resolutor recursivo, lo que protege la privacidad en el primer tramo.
• La minimización de QNAME hace que los resolutores envíen a cada servidor solo la parte del nombre que necesita, de modo que la raíz no conoce el nombre completo que está buscando.
• DNSSEC añade firmas criptográficas para que los resolutores comprueben que las respuestas proceden realmente del propietario de la zona y no se han alterado. El cifrado oculta las consultas; DNSSEC demuestra su autenticidad. Resuelven problemas distintos y funcionan bien juntos.

Cómo mantener sano el DNS de su dominio

La mayoría de las caídas de DNS no se deben a ataques sofisticados, sino a descuidos corrientes: un dominio caducado, una cuenta de hosting DNS olvidada o un cambio de servidores de nombres que nadie documentó. Una rutina sencilla ayuda mucho:

1. Use al menos dos servidores de nombres autoritativos, idealmente en redes distintas.
2. Documente qué proveedor aloja su zona y quién tiene acceso.
3. Mantenga renovados el registro del dominio y la cuenta de hosting DNS, con renovación automática siempre que sea posible.
4. Compruebe la delegación tras cualquier cambio de proveedor con dig NS y dig +trace.
5. Controle las fechas de caducidad desde un único lugar. En el panel de dominios de TLDix puede seguir dominios, certificados SSL y renovaciones de hosting y recibir avisos antes de que algo venza.

Una vez que entiende la cadena que va de la raíz al servidor autoritativo, la mayoría de los misterios del DNS se vuelven sencillos: localice qué eslabón devuelve la respuesta inesperada, revise su TTL y corrija los datos en el origen.