¿Qué hace el DNS y cómo funciona?

DNS (Domain Name System) es la infraestructura de nomenclatura distribuida de internet que traduce nombres de dominio legibles por humanos — como example.com — en direcciones IP legibles por máquinas como 93.184.216.34. Sin DNS, cada solicitud del navegador, llamada API y entrega de correo electrónico requeriría que los usuarios y las aplicaciones conocieran la dirección numérica exacta de cada host remoto, haciendo que el internet moderno fuera operacionalmente imposible a escala.

En su núcleo, DNS es una base de datos jerárquica y globalmente distribuida. No es un único servidor ni un registro centralizado — es un árbol de delegación que abarca cientos de miles de servidores de nombres autoritativos en todo el mundo, coordinados a través de un pequeño conjunto de servidores raíz y regidos por estándares definidos en RFC 1034 y RFC 1035.

Por qué DNS es más que una simple “guía telefónica”

La analogía de la guía telefónica es útil para principiantes, pero subestima enormemente lo que DNS realmente hace. DNS es un sistema de búsqueda en tiempo real, tolerante a fallos y replicado globalmente que también gestiona:

• Enrutamiento de correo mediante registros MX, dirigiendo el correo electrónico a los servidores de correo correctos
• Descubrimiento de servicios mediante registros SRV, utilizados por protocolos como SIP, XMPP y las redes internas de Kubernetes
• Verificación de propiedad de dominio mediante registros TXT, utilizados para SPF, DKIM, DMARC y Google Search Console
• Nomenclatura canónica mediante registros CNAME, que permiten la integración con CDN y el balanceo de carga
• Direccionamiento IPv6 mediante registros AAAA
• Búsquedas inversas mediante registros PTR en la zona in-addr.arpa, fundamentales para la reputación de servidores de correo y la auditoría de seguridad
• Validación DNSSEC, que añade firmas criptográficas a las respuestas DNS para prevenir el envenenamiento de caché

Cada vez que envías un correo electrónico, te conectas a una VPN o cargas una aplicación web, DNS está resolviendo múltiples tipos de registros en segundo plano — a menudo decenas de consultas por carga de página.

La jerarquía DNS: cómo está estructurado el espacio de nombres

DNS está organizado como un árbol invertido. Comprender esta estructura es esencial para entender por qué la resolución funciona de la manera en que lo hace.

.  (Root Zone)
├── com
│   ├── example.com  (Second-Level Domain)
│   │   └── www.example.com  (Subdomain / FQDN)
├── org
├── net
└── uk
    └── co.uk

• Zona raíz (.): Gestionada por IANA. Existen 13 direcciones lógicas de servidores raíz (de la A a la M), operadas por organizaciones como Verisign, NASA e ICANN. En la práctica, son servidas por cientos de máquinas físicas mediante enrutamiento anycast.
• Dominios de nivel superior (TLDs): TLDs genéricos como .com, .net, .org, y TLDs de código de país como .uk, .de, .md. Cada TLD tiene su propio conjunto de servidores de nombres autoritativos.
• Dominios de segundo nivel (SLDs): El dominio que registras — example.com. El DNS autoritativo para esta zona está controlado por quien registró el dominio.
• Subdominios: www, mail, api, staging — estos son registros dentro de la zona SLD, completamente controlados por el propietario del dominio.

Paso a paso: cómo se resuelve una consulta DNS

Una resolución DNS recursiva completa implica hasta siete intercambios de red distintos. Esta es la secuencia precisa:

Paso 1 — Verificación de caché del navegador

Cuando escribes www.example.com en tu navegador, el sistema operativo primero verifica su caché DNS local. En Linux, esto puede ser gestionado por systemd-resolved; en Windows, por el servicio DNS Client. Si existe un registro en caché válido y su TTL (Time to Live) no ha expirado, la resolución se detiene aquí.

Puedes inspeccionar la caché DNS local en Linux con:

resolvectl statistics

O vaciarla con:

sudo resolvectl flush-caches

En Windows:

ipconfig /displaydns
ipconfig /flushdns

Paso 2 — Consulta al resolver recursivo

Si no existe una respuesta en caché, el sistema operativo reenvía la consulta al resolver recursivo configurado (también llamado servidor DNS recursivo o resolver de servicio completo). Este suele ser:

• El resolver de tu ISP (asignado mediante DHCP)
• Un resolver público: 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9)
• Un resolver autogestionado como Unbound o BIND en tu propia infraestructura de VPS Hosting

El resolver recursivo hace el trabajo pesado. Recorrerá la jerarquía DNS en tu nombre y almacenará en caché los resultados para responder consultas futuras más rápidamente.

Paso 3 — Referencia al servidor raíz

El resolver recursivo consulta uno de los 13 clústeres de servidores raíz. El servidor raíz no conoce la dirección IP de www.example.com. En cambio, devuelve una referencia — una lista de servidores de nombres autoritativos para la zona TLD .com, junto con sus direcciones IP (llamados registros glue).

Paso 4 — Consulta al servidor de nombres TLD

El resolver consulta los servidores de nombres TLD .com (operados por Verisign). Estos servidores tampoco tienen la respuesta final. Devuelven otra referencia — los servidores de nombres autoritativos para example.com específicamente (p. ej., ns1.example.com, ns2.example.com).

Paso 5 — Consulta al servidor de nombres autoritativo

El resolver consulta el servidor de nombres autoritativo para example.com. Este servidor contiene el archivo de zona real y devuelve la respuesta definitiva — el registro A que contiene la dirección IPv4 (o AAAA para IPv6).

Paso 6 — Almacenamiento en caché y entrega de la respuesta

El resolver recursivo almacena en caché la respuesta según el valor TTL del registro (p. ej., 300 segundos = 5 minutos, 86400 segundos = 24 horas). Luego devuelve la dirección IP al sistema operativo del cliente, que la pasa al navegador.

Paso 7 — Conexión TCP/IP

El navegador usa la dirección IP resuelta para abrir una conexión TCP (típicamente en el puerto 443 para HTTPS). El trabajo de DNS ha concluido. El servidor web responde y la página se carga.

Todo este proceso — pasos 2 al 6 — típicamente se completa en 20–120 milisegundos con una caché de resolver activa, y en menos de 500 milisegundos para una resolución completamente fría y sin caché que recorre todos los niveles de la jerarquía.

Tipos de registros DNS: referencia técnica

Los registros CAA merecen una mención especial: instruyen a las Autoridades de Certificación sobre qué organizaciones tienen permitido emitir Certificados SSL para tu dominio — un control de seguridad crítico que frecuentemente se pasa por alto.

Tipos de consultas DNS: recursivas vs. iterativas vs. no recursivas

La mayoría de los dispositivos de usuario final envían consultas recursivas a su resolver configurado. El resolver mismo utiliza consultas iterativas al recorrer la jerarquía.

TTL: el parámetro DNS más incomprendido

El TTL (Time to Live) es el número de segundos que un registro DNS puede ser almacenado en caché por los resolvers y los clientes. Es establecido por el propietario del dominio en el archivo de zona.

• TTL bajo (60–300 segundos): Propagación más rápida de los cambios. Esencial antes de migraciones planificadas, cambios de IP o eventos de conmutación por error. Aumenta la carga de consultas en los servidores autoritativos.
• TTL alto (3600–86400 segundos): Reduce la carga del resolver y acelera las consultas repetidas. Los cambios tardan más en propagarse globalmente.

Información operativa crítica: Al planificar una migración de servidor o un cambio de IP, reduce tu TTL a 300 segundos al menos 48 horas antes del cambio. Esto garantiza que, en el momento en que actualices el registro A, ningún resolver esté almacenando en caché el valor antiguo por más de 5 minutos. No hacer esto es una de las causas más comunes de tiempo de inactividad prolongado durante las migraciones.

Cuando registras un dominio a través de Registro de Dominios y lo apuntas a un nuevo servidor, la ventana de propagación está directamente gobernada por el valor TTL anterior — no por alguna regla arbitraria de “24–48 horas” que se cita frecuentemente de manera incorrecta.

Protocolos de transporte DNS: UDP, TCP, DoH y DoT

El DNS tradicional opera sobre UDP puerto 53 para consultas de menos de 512 bytes. Las respuestas que superan este tamaño desencadenan una alternativa a TCP puerto 53. Las respuestas DNSSEC, las transferencias de zona (AXFR) y los registros TXT de gran tamaño comúnmente requieren TCP.

Los protocolos modernos de privacidad DNS han cambiado significativamente este panorama:

DoH vs. DoT — la diferencia operativa real: DoH tuneliza DNS dentro del tráfico HTTPS en el puerto 443, haciéndolo indistinguible del tráfico web normal. Esto es útil para la privacidad, pero dificulta significativamente la monitorización y el filtrado de redes empresariales. DoT utiliza un puerto dedicado (853), que los administradores de red pueden monitorizar, bloquear o inspeccionar de forma independiente. Para infraestructura autogestionada en un Servidor Dedicado, ejecutar un resolver local DoT o DoH te proporciona tanto privacidad como control total sobre la política de resolución.

DNSSEC: integridad criptográfica para DNS

DNSSEC (DNS Security Extensions) añade una cadena de firmas criptográficas a las respuestas DNS, permitiendo a los resolvers verificar que una respuesta es auténtica y no ha sido manipulada en tránsito. Protege contra el envenenamiento de caché DNS (ataque Kaminsky) y la suplantación DNS mediante ataques de intermediario.

DNSSEC no cifra el tráfico DNS — solo lo firma. La cadena de firmas funciona de la siguiente manera:

1. El propietario de la zona genera una Clave de Firma de Zona (ZSK) y una Clave de Firma de Clave (KSK)
2. Cada conjunto de registros DNS se firma con la ZSK, produciendo registros RRSIG
3. La KSK firma el conjunto de registros DNSKEY
4. Un registro DS (Delegation Signer) se publica en la zona padre (p. ej., .com), creando la cadena de confianza hasta la raíz

Habilitar DNSSEC es muy recomendable para cualquier dominio que gestione transacciones financieras, autenticación o correo electrónico. Un DNSSEC mal configurado — en particular una firma expirada o un registro DS no coincidente — causará un fallo de resolución completo para los resolvers que validan, lo cual es un modo de fallo más grave que no tener DNSSEC en absoluto.

Fallos comunes de DNS y cómo diagnosticarlos

NXDOMAIN — Dominio inexistente

El servidor autoritativo confirmó que el dominio no existe. Causas comunes: error tipográfico en el nombre de dominio, registro de dominio expirado, registro DNS eliminado.

dig www.example.com
# Look for: status: NXDOMAIN

SERVFAIL — Fallo del servidor

El resolver no pudo completar la consulta. Causas comunes: fallo de validación DNSSEC, servidor autoritativo inaccesible, archivo de zona mal configurado.

dig +dnssec example.com
# Look for: status: SERVFAIL

Para omitir la validación DNSSEC y aislar el problema:

dig +cd example.com
# +cd = checking disabled; bypasses DNSSEC validation

Caché obsoleta / Retraso de propagación

Después de actualizar un registro DNS, los valores antiguos persisten en las cachés de los resolvers hasta que el TTL expira. Para consultar directamente el servidor autoritativo y omitir la caché del resolver:

dig @ns1.example.com www.example.com

Verificación de la propagación DNS globalmente

Usa dig con resolvers públicos específicos para verificar el estado de propagación:

dig @8.8.8.8 www.example.com A
dig @1.1.1.1 www.example.com A
dig @9.9.9.9 www.example.com A

DNS en entornos de hosting: configuraciones prácticas

Cuando despliegas un sitio web o una aplicación en un VPS con cPanel, la gestión DNS se maneja típicamente a través del clúster DNS de WHM o el Editor de Zonas de cPanel. Comprender la estructura subyacente del archivo de zona te permite realizar cambios que la interfaz gráfica no expone.

Un archivo de zona mínimo para example.com tiene este aspecto:

$TTL 3600
@   IN  SOA  ns1.example.com. admin.example.com. (
            2024010101  ; Serial
            3600        ; Refresh
            900         ; Retry
            604800      ; Expire
            300 )       ; Minimum TTL

@       IN  NS      ns1.example.com.
@       IN  NS      ns2.example.com.
@       IN  A       203.0.113.10
www     IN  A       203.0.113.10
mail    IN  A       203.0.113.20
@       IN  MX  10  mail.example.com.
@       IN  TXT     "v=spf1 ip4:203.0.113.20 ~all"

Para que el Hosting de Correo Electrónico funcione correctamente, el registro MX debe apuntar a un nombre de host (no directamente a una dirección IP), y ese nombre de host debe resolverse a su vez mediante un registro A. Una configuración incorrecta común es apuntar MX directamente a una IP — esto viola el RFC 2821 y causa fallos de entrega con servidores de correo estrictos.

Rendimiento DNS: qué afecta realmente a la velocidad de resolución

• Proximidad del resolver: Un resolver geográficamente cercano al cliente (o en la misma red) reduce drásticamente el tiempo de ida y vuelta.
• Tasa de aciertos de caché: Los dominios de alto tráfico con TTLs razonables casi siempre se sirven desde caché. La resolución con caché fría es entre 5 y 20 veces más lenta.
• Enrutamiento anycast: Los servidores raíz y los principales resolvers públicos utilizan anycast, enrutando las consultas automáticamente al nodo físico más cercano.
• Número de búsquedas DNS por página: Una sola página web puede desencadenar entre 20 y 50 consultas DNS (activos CDN, analíticas, fuentes, redes publicitarias). Los navegadores las paralelizan, pero cada nombre de host único requiere su propia búsqueda.
• Precarga DNS: Los navegadores modernos admiten <link rel="dns-prefetch" href="//cdn.example.com"> para resolver nombres de host de terceros antes de que sean necesarios, reduciendo la latencia percibida.

DNS vs. mecanismos alternativos de resolución

El archivo /etc/hosts se evalúa antes que DNS en prácticamente todos los sistemas operativos. Esto lo hace invaluable para el desarrollo local — puedes mapear myapp.local a 127.0.0.1 sin tocar ninguna infraestructura DNS.

Conclusiones clave y lista de verificación

Usa esta lista de verificación al configurar o solucionar problemas de DNS en cualquier entorno de producción:

• Antes de cualquier migración de servidor: Reduce el TTL a 300 segundos al menos 48 horas de antelación
• Para la entregabilidad del correo electrónico: Verifica que los registros MX, SPF (TXT), DKIM (TXT), DMARC (TXT) y PTR estén todos correctamente configurados
• Para la seguridad: Habilita DNSSEC en tu dominio y añade registros CAA para restringir la emisión de certificados
• Para la privacidad: Usa DoT o DoH en dispositivos cliente y servidores; evita enviar DNS en texto plano sobre redes no confiables
• Para el rendimiento: Establece el TTL en 3600–86400 para registros estables; usa 300 solo para registros que cambian frecuentemente
• Para diagnósticos: Consulta siempre el servidor autoritativo directamente con dig @ns1.yourdomain.com para distinguir el retraso de propagación de una configuración incorrecta genuina
• Para la gestión de zonas: Incrementa el número de serie SOA cada vez que modifiques un archivo de zona — los resolvers lo usan para detectar cambios
• Para el hosting: Confirma que la delegación de servidores de nombres de tu registrador coincide con los registros NS en tu archivo de zona — una discrepancia es la causa más común de “DNS no funciona” después de una transferencia de dominio

Preguntas frecuentes

¿Cuál es la diferencia entre un resolver DNS y un servidor DNS autoritativo?

Un resolver recursivo (p. ej., 8.8.8.8) es un intermediario que consulta la jerarquía DNS en nombre de tu dispositivo y almacena los resultados en caché. Un servidor de nombres autoritativo contiene los registros de zona reales para un dominio específico y proporciona respuestas definitivas. Tu resolver consulta muchos servidores autoritativos; el servidor autoritativo de tu dominio solo responde para las zonas que aloja.

¿Por qué la propagación DNS tarda tiempo después de actualizar un registro?

El retraso de propagación es causado por el almacenamiento en caché basado en TTL. Cada resolver que previamente almacenó en caché tu registro antiguo continuará sirviéndolo hasta que el TTL expire. Si tu TTL era 86400 (24 horas), los resolvers pueden servir el registro antiguo hasta 24 horas después de tu actualización. Esto no es un error — es el mecanismo de caché previsto que hace que DNS sea escalable.

¿Qué es una fuga DNS y por qué importa?

Una fuga DNS ocurre cuando tu dispositivo envía consultas DNS fuera de tu resolver previsto — típicamente el resolver de tu ISP — incluso cuando usas una VPN o una herramienta de privacidad. Esto expone tu actividad de navegación a tu ISP. Puedes probar si hay fugas en dnsleaktest.com y solucionarlas configurando tu cliente VPN para forzar el enrutamiento DNS a través de su propio resolver.

¿Puede DNS ser utilizado como vector de ataque?

Sí. Los ataques comunes basados en DNS incluyen el envenenamiento de caché (inyección de registros falsos en la caché de un resolver), DDoS de amplificación DNS (uso de resolvers abiertos para inundar un objetivo con grandes respuestas DNS), secuestro DNS (redirección de consultas a servidores maliciosos) y tunelización DNS (exfiltración de datos codificándolos en cadenas de consultas DNS). DNSSEC mitiga el envenenamiento de caché; la limitación de velocidad y la limitación de velocidad de respuesta (RRL) en los servidores autoritativos mitigan la amplificación.

¿Cómo encuentro los servidores de nombres autoritativos para cualquier dominio?

Usa dig con el tipo de registro NS y el indicador +short para una salida limpia:

dig NS example.com +short

Para rastrear la ruta de delegación completa desde la raíz hasta el autoritativo, usa:

dig +trace example.com

Esto muestra cada salto de referencia — raíz → TLD → autoritativo — que es la forma más fiable de diagnosticar configuraciones incorrectas de delegación.