Cómo funciona la resolución DNS: pasos, tipos de servidores, caché y fallos

Cuando tu navegador necesita una dirección para un nombre como pudgycat.io, el DNS ayuda a encontrarla. A veces la respuesta ya está en caché; otras, un resolutor tiene que preguntar a otros servidores. Esta guía explica ese proceso, por qué las respuestas pueden cambiar y cómo distinguir un problema de resolución de un sitio web que está teniendo un mal día. La agenda de direcciones de internet está sorprendentemente ocupada para ser algo que nadie recuerda haber abierto.

Índice

• Qué es el DNS y por qué lo necesitamos
• Cómo funciona la resolución DNS, paso a paso
• Los cuatro tipos de servidores DNS
• Tipos de registros DNS que conviene conocer
• Caché DNS y TTL
• Consultas DNS recursivas e iterativas
• Seguridad DNS: DNSSEC, DoH y DoT
• Cuando falla el DNS: problemas habituales
• Preguntas frecuentes

Qué es el DNS y por qué lo necesitamos

El sistema de nombres de dominio asocia nombres con registros de distintos tipos, entre ellos direcciones IP. Un navegador puede utilizar una dirección para contactar con un servicio, pero el DNS también permite enrutar correo y tiene otros usos. No recupera la página web en sí. Piensa en «encontrar el destino» y después «establecer la conexión»: dos tareas relacionadas que pueden fallar de forma independiente.

Las primeras correspondencias entre nombres de equipos y direcciones de internet se distribuían en un archivo central HOSTS.TXT. La especificación DNS de Paul Mockapetris explica por qué ese enfoque empezó a tener dificultades para crecer. En su lugar, el DNS distribuye la responsabilidad mediante una jerarquía. Su historia es de despliegue y evolución graduales, no de un único día en que todo el mundo cambió su configuración.

Nombres y direcciones IP

La dirección de un servicio puede cambiar sin que cambie su nombre. Un nombre también puede tener varios registros de dirección. Esa flexibilidad ayuda a separar el nombre que recuerdan los visitantes de las máquinas o ubicaciones de red que los atienden. El DNS no garantiza un número permanente por sitio web.

Cómo funciona la resolución DNS, paso a paso

Este es un recorrido de consulta simplificado, coherente con la explicación de DNS de Cloudflare. Los ajustes del navegador, el sistema operativo y la red pueden modificarlo; no es un viaje de ocho paradas que se repite cada vez que cargas una página.

1. Consulta local. El navegador o el sistema operativo quizá ya tengan una respuesta utilizable en caché.
2. Configuración local. Los archivos hosts y los ajustes de las aplicaciones pueden afectar a la resolución de nombres. Su prioridad exacta depende del sistema.
3. Elegir un resolutor. El dispositivo puede utilizar el resolutor de su red, un servicio público configurado o el proveedor de DNS cifrado del navegador.
4. Pedir una respuesta. Un resolutor recursivo puede responder desde su caché o continuar la búsqueda.
5. Encontrar la delegación pertinente. Si es necesario, el resolutor pregunta a un servidor raíz dónde encontrar los servidores del dominio de nivel superior.
6. Seguir la siguiente referencia. Un servidor TLD puede dirigirlo hacia los servidores autoritativos del dominio.
7. Obtener el registro. Una respuesta autoritativa puede contener una dirección, un alias que requiere otra consulta o un resultado negativo.
8. Devolver el resultado. El resolutor responde y los registros que cumplen los requisitos pueden guardarse en caché. El navegador puede entonces intentar establecer una conexión.

No existe un tiempo de consulta universal. Importan el estado de la caché, la distancia de red, los reintentos, la carga del servidor y la configuración. Además, el DNS es solo una parte de la carga de una página: una respuesta rápida no puede hacer que un servidor de aplicaciones lento se dé prisa.

Los cuatro tipos de servidores DNS

Son funciones que conviene reconocer. Los servidores raíz y TLD también son autoritativos para sus respectivas zonas; las categorías describen dónde se sitúa un servidor y qué servicio presta, no cuatro especies de máquinas sin relación entre sí.

1. Resolutor recursivo

Un resolutor recursivo busca respuestas en nombre de un cliente, a menudo utilizando información en caché y, en ocasiones, otro resolutor aguas arriba. Un router doméstico puede reenviar consultas en vez de realizar todo el trabajo por sí mismo. Los proveedores de resolutores públicos también tienen distintas políticas de filtrado y retención; «DNS público» no es una promesa uniforme de velocidad o privacidad.

2. Servidor de nombres raíz

Existen 13 identidades de servidores raíz, de la A a la M, operadas por 12 organizaciones mediante numerosas instancias distribuidas. El sitio de los operadores de servidores raíz describe ese sistema. Estos servidores sirven la zona raíz, incluidas las delegaciones de los TLD. «Trece raíces» no significa trece computadoras físicas con todo internet haciendo cola delante.

3. Servidor de nombres TLD

Los servidores autoritativos de un TLD sirven su zona, incluidas las delegaciones de nombres situados debajo. No conservan un directorio vivo de todos los dominios registrados jamás, ni contienen necesariamente la dirección final de cada sitio web. Una referencia indica al resolutor dónde debe preguntar a continuación.

4. Servidor de nombres autoritativo

Un servidor autoritativo sirve datos de una zona. Los administradores de dominios publican cambios a través de su proveedor DNS o su propio sistema; servidores redundantes pueden servir la misma zona. «Autoritativo» describe la responsabilidad sobre esos datos, no la propiedad del sitio web ni una garantía de que el operador lo haya configurado correctamente.

Tipos de registros DNS que conviene conocer

El DNS utiliza distintos tipos de registros para distintos fines. El registro de IANA los enumera junto con sus especificaciones. Entre los ejemplos habituales están:

• Registro A: asocia un nombre con una dirección IPv4.
• Registro AAAA: asocia un nombre con una dirección IPv6. Se pronuncia «cuádruple A».
• Registro CNAME: un alias. Apunta de un nombre a otro; por ejemplo, www.example.com como alias de example.com.
• Registro MX: intercambio de correo. Indica a los servidores de correo dónde entregar los mensajes destinados al dominio.
• Registro TXT: texto arbitrario. Se utiliza para SPF, DKIM, verificación de propiedad del dominio y, en el salvaje oeste de las tuberías de internet, a veces para configurar servicios.
• Registro NS: servidor de nombres. Enumera los servidores DNS autoritativos de un dominio.
• Registro PTR: apunta a otro nombre de dominio; las zonas de DNS inverso lo utilizan para asociar una dirección con un nombre. No tiene por qué invertir exactamente el registro A de un sitio web.
• Registro SRV: ubicación de un servicio. Define el nombre de host y el puerto de un servicio concreto; lo utilizan SIP, XMPP, Minecraft y otros similares.
• Registro CAA: autorización de autoridades de certificación. Indica qué autoridades pueden emitir certificados HTTPS para el dominio.

Puedes consultar cualquiera de estos registros desde una terminal. En Linux y macOS, dig pudgycat.io devuelve el registro A. dig -t MX pudgycat.io devuelve los registros de correo. En Windows, nslookup hace el mismo trabajo.

Caché DNS y TTL

Los registros de recursos DNS llevan un TTL, medido en segundos, que normalmente limita cuánto tiempo pueden reutilizarse desde una caché. RFC 1035 define ese campo. Estas duraciones ilustran el equilibrio entre opciones; no son ajustes obligatorios:

• 300 segundos: cinco minutos.
• 3600 segundos: una hora.
• 86400 segundos: un día.

Cambiar un registro autoritativo no borra inmediatamente las copias en caché. Reducir el TTL con antelación puede ayudar en un cambio planificado, pero las copias almacenadas con el TTL anterior siguen necesitando tiempo para caducar. Las respuestas negativas también pueden guardarse en caché, como explica RFC 2308. Algunos resolutores permiten servir datos caducados en determinadas condiciones de fallo, por lo que el TTL no es un cronómetro universal para todos los resultados observables.

Consultas DNS recursivas e iterativas

A menudo se confunden estos dos términos. Describen funciones diferentes dentro de la misma cadena.

Una consulta recursiva pide a un resolutor que obtenga la respuesta en vez de dejar que el cliente siga las referencias. El pequeño resolutor del lado del cliente suele llamarse stub resolver. Por tanto, «resolutor» no siempre significa un servicio recursivo público.

Con las consultas iterativas, el resolutor que pregunta puede seguir las referencias por sí mismo. Quizá ya tenga suficiente información de delegación en caché para saltarse el paso raíz o TLD. La jerarquía explica quién es responsable, no un itinerario fijo.

La delegación reparte la responsabilidad; la caché evita repetir trabajo. Ese es el truco arquitectónico, incluso cuando el recorrido real se acorta gracias a información que alguien ya posee.

Seguridad DNS: DNSSEC, DoH y DoT

El DNS clásico tiene dos propiedades desagradables: no está cifrado y no autentica las respuestas. Tres protocolos modernos resuelven distintas partes del problema.

DNSSEC

DNSSEC permite que un resolutor validador compruebe la autenticidad y la integridad de los datos DNS firmados mediante una cadena de confianza. No cifra las consultas, no certifica que un sitio web sea inofensivo ni autentica mágicamente datos sin firmar. Una cadena de validación rota puede, por sí misma, impedir la resolución.

DNS sobre HTTPS (DoH)

DNS sobre HTTPS (DoH) transporta mensajes DNS a través de una conexión HTTPS cifrada. Protege ese transporte frente a la escucha y alteración directas. El resolutor elegido sigue procesando la consulta, y el DNS cifrado no oculta todas las pistas sobre los sitios que visitas. Envolverlo en HTTPS no es una capa de invisibilidad perfecta.

DNS sobre TLS (DoT)

DNS sobre TLS (DoT) utiliza una conexión DNS protegida con TLS, normalmente en el puerto 853. Su puerto dedicado permite distinguir ese tráfico del HTTPS corriente con mayor facilidad. Al igual que DoH, protege la conexión cifrada configurada, no todas las etapas de una visita a un sitio web.

El transporte cifrado y los datos DNS firmados responden a riesgos diferentes. Ninguno elimina la necesidad de elegir un resolutor de confianza. En particular, cifrar una conexión con un resolutor malicioso no vuelve honestas sus respuestas.

Cuando falla el DNS: problemas habituales

El DNS es una posible causa de una visita fallida, junto con los problemas de red, TLS, alojamiento, aplicación y base de datos. Comprueba el síntoma antes de cambiar ajustes. Entre los resultados habituales relacionados con el DNS están:

• NXDOMAIN: el nombre consultado no existe. Un nombre existente sin un registro del tipo solicitado es una respuesta negativa distinta, a menudo llamada NODATA.
• SERVFAIL: la resolución falló. Los errores de validación DNSSEC son una posible causa, junto con otros problemas del servidor o de sistemas aguas arriba.
• Respuesta antigua en caché: un registro anterior puede seguir dentro de su TTL. Vaciar una caché local no vacía todos los resolutores aguas arriba.
• Respuesta incorrecta: una mala configuración o una manipulación pueden dirigir una consulta de forma equivocada. La validación DNSSEC y el transporte cifrado tienen funciones protectoras distintas y limitadas.
• Caída del resolutor: otro resolutor permitido puede ayudar a diagnosticar un problema del proveedor local. No puede reparar una zona autoritativa rota ni un servidor web caído.

Los ataques contra Dyn de octubre de 2016 muestran cómo una interrupción en un proveedor DNS puede afectar al acceso a muchos servicios a la vez. El análisis conservado del incidente de Dyn describe ataques contra su infraestructura de DNS gestionado y dice expresamente que no pudo verificar las informaciones sobre una magnitud de 1,2 Tbps. La lección no exige convertir una cifra sin confirmar en un hecho.

Para conocer la siguiente parte del recorrido entre un nombre y algo que se reproduce en pantalla, consulta nuestra explicación del streaming de video (en inglés). Resolver una dirección inicia el viaje; no entrega el video por sí solo.

Preguntas frecuentes

¿Cuánto tarda la resolución DNS?

Depende de la caché, las condiciones de la red y la necesidad de reintentos. Un resultado en la caché local puede llegar muy rápido, pero no existe un máximo universal fiable para una consulta sin caché.

¿Qué diferencia hay entre un resolutor DNS y un servidor DNS?

Un servidor DNS responde a consultas DNS. Un resolutor es el componente que obtiene respuestas; puede ser un pequeño stub del lado del cliente o un servicio recursivo. Los servidores raíz y TLD suelen proporcionar datos autoritativos de zona en lugar de realizar recursión para tu navegador.

¿Cómo vacío mi caché DNS?

En Windows, ipconfig /flushdns borra la caché del resolutor del cliente DNS. Otros sistemas y aplicaciones tienen sus propios procedimientos, que varían según la versión. Vaciar una caché no modifica los registros autoritativos ni borra la caché del proveedor.

¿Debería cambiar mi resolutor DNS?

Puede ser útil para diagnosticar problemas, pero el rendimiento y la privacidad varían según el proveedor y la red. Los dispositivos del trabajo o de un centro educativo pueden depender de un resolutor concreto para sus servicios internos. Revisa los ajustes y políticas aplicables, y anota la configuración original antes de cambiarla. Un resolutor diferente no es una cura universal para una conexión lenta.

¿Se puede utilizar el DNS para bloquear sitios web?

Sí. Un resolutor puede rechazar o alterar respuestas, pero el filtrado DNS es solo un método de bloqueo. Introducir directamente una IP puede no funcionar con alojamiento compartido y HTTPS. El DNS cifrado y DNSSEC no son formas garantizadas de eludir restricciones; pueden seguir aplicándose otros controles de red.

La idea principal

Es fácil olvidarse del DNS hasta que un nombre deja de resolverse. El modelo útil es una jerarquía de responsabilidades apoyada por cachés, no una cadena inflexible que se ejecuta en cada visita. Cuando un sitio falla, el DNS merece una comprobación, no una condena automática. Ni siquiera la agenda de internet puede arreglar una base de datos que se ha ido a almorzar.

Traducción al español del artículo original en inglés del 2026-05-26. Traducido con ayuda de IA el 1 de noviembre de 2026; las referencias temporales siguen siendo las del original.