Cómo funciona el DNS: recorrido completo de una consulta

Cada vez que abres una web o una aplicación se conecta a su servidor, el equipo tiene que convertir un nombre en una dirección numérica antes de hablar con nadie. De eso se encarga el DNS, el sistema de nombres de dominio: una base de datos repartida entre muchos servidores que contesta en varios saltos, casi siempre acortados por las cachés. Lo definen dos especificaciones de noviembre de 1987, las RFC 1034 y 1035 de la IETF, que lo dividen en tres piezas: el espacio de nombres con sus registros, los servidores de nombres y los resolutores.

Repasamos cómo funciona el DNS: las piezas, el recorrido completo de una consulta, las cachés, los registros, los fallos y quién ve tus consultas, con las especificaciones del protocolo y la documentación de quienes lo mantienen, consultadas entre el 22 de octubre y el 5 de noviembre de 2026.

---

Qué resuelve el DNS y por qué existe

La página de introducción de la ICANN lo explica sin tecnicismos: todo lo que se conecta a internet tiene un número único, su dirección IP, y como esas direcciones cuestan de recordar, el sistema de nombres de dominio usa letras, números y guiones para formar un nombre más fácil de recordar.

La portada de Google Public DNS lo compara con la guía telefónica de internet: cada vez que visitas una web, el ordenador hace una búsqueda DNS, y como las páginas complejas necesitan varias antes de empezar a cargar, un equipo puede llegar a hacer cientos al día.

Antes del DNS, la correspondencia entre nombres y direcciones vivía en un único fichero, HOSTS.TXT, que mantenía el Network Information Center y que todos los equipos descargaban por FTP. La RFC 1034 cuenta por qué dejó de servir: el ancho de banda que consumía repartir cada versión crecía con el cuadrado del número de equipos, y el crecimiento explosivo de la red no auguraba nada bueno. La solución fue una base de datos distribuida, con caché local para ganar rendimiento.

Al escribir una dirección en el navegador, resolver el nombre es uno de los pasos de un camino más largo, que ya recorrimos en Qué ocurre paso a paso al escribir una dirección en el navegador. Aquí abrimos ese paso entero.

---

Las piezas: del equipo al servidor autoritativo

La RFC 9499, el documento de terminología del DNS de marzo de 2024, pone nombre a cada pieza. Un resolutor es un programa que saca información de los servidores de nombres en respuesta a las peticiones de los clientes.

En tu equipo vive un resolutor mínimo, el stub resolver de la jerga: uno que no puede hacer toda la resolución por sí mismo y depende de un resolutor recursivo. La RFC 1034 lo pensó para un PC sin recursos para hacer el trabajo completo, y lo único que necesita es una lista de servidores que hagan las consultas por él. El sistema operativo, además, guarda su propia caché.

El resolutor recursivo es el que trabaja de verdad: responde desde su caché o pregunta a otros servidores hasta conseguir la respuesta final, y lo normal es que guarde lo que recibe. Casi siempre es el de tu proveedor, porque, como explica la guía de configuración del servicio del buscador, el protocolo DHCP suele configurar el sistema para usar los servidores de nombres del operador.

Arriba del todo está la zona raíz, que la página de gestión de la IANA define como el nivel más alto de la jerarquía de nombres, formado sobre todo por las delegaciones de los dominios de primer nivel, como .edu o .in; entre sus tareas están asignar los gestores de esos dominios y registrar sus datos técnicos de delegación. La sirven los servidores raíz: root-servers.org, la web de sus operadores, explica que son 13 servidores raíz operados por 12 organizaciones independientes, y el 4 de noviembre contaba 2.048 instancias en funcionamiento. Para arrancar, el resolutor necesita un fichero de pistas con los nombres y las direcciones IP de esos servidores, que en muchos programas ya viene incorporado.

Un escalón por debajo están los dominios de primer nivel, o TLD, como com o jp, que se suelen dividir en dominios de país y genéricos. Y al final está el servidor autoritativo del dominio, que conoce el contenido de su zona por conocimiento propio y contesta sin preguntar a nadie; es el que figura en los registros NS de la zona.

---

El recorrido de una consulta, paso a paso

Supongamos que el navegador necesita la dirección de un nombre nuevo. Primero pregunta al resolutor del equipo, que mira su caché. Si no está, lo pasa al resolutor recursivo configurado con una consulta recursiva, la que lleva activado el bit «se desea recursión» de la cabecera.

El resolutor recursivo sigue el algoritmo de cuatro pasos de la RFC 1034. Uno: mirar si la respuesta está en su información local y, si está, devolverla. Dos: buscar los mejores servidores a los que preguntar, del propio nombre hacia la raíz; el ejemplo de la especificación busca servidores de Mockapetris.ISI.EDU, luego de ISI.EDU, de EDU y, por último, de la raíz. Tres: enviarles consultas hasta que uno conteste. Cuatro: analizar la respuesta.

Si el resolutor llega en blanco, pregunta a un servidor raíz, que no tiene la dirección final pero contesta con una remisión a los servidores del TLD. El resolutor guarda esa delegación y vuelve al paso dos con ellos, que a su vez remiten a los servidores autoritativos del dominio. Estos dan la respuesta marcada como autoritativa, y el resolutor la guarda en caché y se la devuelve al equipo.

Hay dos desvíos. Si la respuesta es un alias, el resolutor lo guarda, cambia el nombre buscado por el canónico y vuelve a empezar; si un servidor falla o contesta algo raro, lo tacha de la lista y prueba con el siguiente. Todo viaja normalmente por UDP al puerto 53, preferido para las consultas por su menor sobrecarga, aunque también funciona por TCP. El recorrido, con lo que se guarda en cada salto:

---

Cachés y TTL: por qué casi nunca se hace el viaje entero

El recorrido completo es la excepción. La RFC 1034 da por buenos para el uso normal los datos que están en caché, y desaconseja que saltarse la caché para preguntar al autoritativo sea la opción por defecto. Como cada salto guarda lo que aprende, la siguiente consulta a otro nombre del mismo dominio ya no pasa por la raíz ni por el TLD.

Cuánto dura cada dato lo decide el TTL, el tiempo de vida de cada registro: un número en segundos que fija cuánto puede quedarse en caché antes de volver a consultar la fuente. Lo asigna el administrador de la zona, y un TTL de cero prohíbe guardarlo. Según la RFC 1034, lo razonable para un equipo típico son tiempos del orden de días, y si se prevé un cambio, el TTL se baja antes y se vuelve a subir después.

También se guarda lo que no existe: los servidores pueden repartir, y los resolutores guardar, los resultados negativos con su TTL, de modo que quien recibe un aviso de nombre inexistente puede dar por hecho que no existe durante ese tiempo. Es la caché negativa.

En Windows, la caché del equipo se ve y se vacía con ipconfig. La documentación de Microsoft explica que ipconfig /displaydns muestra la caché del resolutor del cliente DNS, con las entradas precargadas del archivo Hosts local y los registros obtenidos hace poco, que el servicio Cliente DNS usa para resolver rápido los nombres frecuentes antes de preguntar a sus servidores. Con ipconfig /flushdns se vacía y se reinicia esa caché, útil al diagnosticar problemas para descartar las entradas negativas y las añadidas de forma dinámica.

---

Los registros que más vas a ver

Lo que guarda el DNS son registros de recursos, cada uno con su tipo. La RFC 1035 los enumera con su código, y estos son los más habituales:

• A: la dirección de un equipo, lo que devuelve una consulta por la dirección de un nombre.
• AAAA: la dirección IPv6 de un equipo; la terminología de 2024 agrupa los de tipo A y AAAA como registros de dirección.
• CNAME: el nombre canónico de un alias; indica que el nombre consultado es un apodo de otro, y el resolutor sigue ese otro.
• MX: el intercambiador de correo, un equipo dispuesto a recibir el correo de ese nombre; si hay varios, se prefieren los de valor más bajo.
• TXT: cadenas de texto descriptivo, cuyo significado depende del dominio en el que estén.
• NS: el servidor de nombres autoritativo del dominio, el que siguen las remisiones de la raíz y del TLD.

---

Cuando la consulta falla

El fallo más claro es que el nombre no exista. La respuesta lleva el código Name Error, que la RFC 1035 reserva a las respuestas de un servidor autoritativo y que indica que el nombre de dominio consultado no existe; una especificación posterior lo bautizó también como NXDOMAIN. Por la caché negativa, un dominio recién creado o una errata pueden seguir dando «no existe» un rato después de corregirse, y ahí vaciar la caché del equipo tiene sentido.

Otro código es SERVFAIL: el servidor de nombres no pudo procesar la consulta por un problema propio, y el resolutor prueba con otro de su lista.

Luego está el tiempo de espera, cuando no llega respuesta. La RFC 1034 ya advertía de que una consulta recursiva puede tardar un tiempo arbitrario, y de que al resolutor del equipo le cuesta ajustar sus reintentos para cubrir a la vez los paquetes UDP perdidos y los servidores caídos.

Y está el caso malicioso, el envenenamiento de caché: colar respuestas falsas en la caché de un resolutor para mandar a sus usuarios a otra parte. Basta con saber que existe para entender por qué importa en qué resolutor confías.

---

Quién ve tus consultas y por qué importa el resolutor

El resolutor recursivo ve todas tus consultas: es su trabajo. La política de privacidad del resolutor público de Cloudflare recuerda que la mayoría de los dispositivos usan por defecto el del proveedor de internet, y que algunos proveedores y servicios de DNS de terceros registran las consultas, venden datos sobre la actividad en internet o los usan para dirigir anuncios. Además, las consultas suelen viajar en texto plano, así que cualquiera en el camino entre el dispositivo y el resolutor puede ver cada web que visitas y cada aplicación que usas, aunque el contenido vaya cifrado.

La alternativa es un resolutor público, un servicio gratuito y global que se usa en lugar del de tu proveedor. El del buscador se configura con las direcciones 8.8.8.8 y 8.8.4.4, y su portada aclara que es solo un resolutor de nombres: si lo pruebas, tus programas harán con él todas las búsquedas DNS. El de 1.1.1.1 se presenta como una opción más rápida y privada que la del proveedor, y entre sus compromisos están no vender datos personales de los usuarios, anonimizar la IP de origen recortándola (el último octeto en IPv4 y los últimos 80 bits en IPv6) y borrar los registros del resolutor en 25 horas.

Elegir resolutor es elegir quién ve tu lista de nombres. Se cambia en la configuración de red del sistema o, para toda la casa, en el router, como explicamos en Cómo configurar un router para optimizar tu red. Con un matiz que recoge la guía de 8.8.8.8: algunos proveedores dejan fijados sus servidores DNS en el equipo que entregan, y entonces hay que cambiarlo en cada ordenador conectado.

Lo del texto plano tiene remedio, y aquí solo lo nombramos: DNS sobre TLS (DoT) y DNS sobre HTTPS (DoH) cifran el tramo entre tu equipo y el resolutor, y los dos resolutores públicos los ofrecen junto al DNS tradicional por UDP o TCP.

---

Te puede interesar

Tech Planet participa en el programa de afiliados de Amazon. Si compras a través de estos enlaces, recibimos una pequeña comisión sin coste extra para ti, lo que nos ayuda a seguir creando contenido como este.