Qué es el DNS recursivo: cómo funciona y por qué es importante
¿Qué es el DNS recursivo? Descubra cómo un resolutor responde a las búsquedas, utiliza el almacenamiento en caché y dónde se aplican los controles de seguridad, con ejemplos claros.
Published 2 de noviembre de 2026
Un solucionador DNS recursivo es el servidor que recibe una búsqueda de nombre desde su dispositivo y encuentra la dirección IP correspondiente en su nombre consultando a otros servidores DNS, almacenando después la respuesta para su reutilización.
Imagine que ha cambiado una configuración en su WiFi para invitados WiFi, pero un visitante todavía puede acceder a un sitio que pretendía bloquear. Antes de volver a modificar el cortafuegos, compruebe qué solucionador utiliza su dispositivo y si su directiva se aplica a las respuestas almacenadas en caché. Esos detalles suelen explicar el desfase entre la modificación de una regla y su funcionamiento efectivo.
Índice de contenidos
- Qué hace un resolvedor DNS recursivo por su dispositivo
- Comparativa entre servidores DNS recursivos y autoritativos
- Cómo recorre la jerarquía DNS una búsqueda recursiva
- Almacenamiento en caché, TTL y tiempo que tarda un cambio
- Filtrado y seguridad en el resolvedor
- Interrupciones, respuestas desactualizadas y errores de concepto comunes
- Confirme qué resolvedor utiliza su red antes de cambiarlo
Qué hace un resolutor DNS recursivo por su dispositivo
Un resolutor DNS recursivo busca respuestas DNS para un dispositivo, de forma muy parecida al conserje de un hotel que se pone en contacto con varios departamentos en lugar de enviar a un huésped de mostrador en mostrador. El huésped hace una pregunta y espera una respuesta, no instrucciones para continuar la búsqueda.
Supongamos que el huésped de un hotel abre su ordenador portátil e introduce el nombre de un sitio web. Si el portátil no dispone de una respuesta local utilizable, envía una consulta a su servicio DNS configurado. Dicho servicio puede ser proporcionado por la red del hotel, el proveedor de Internet o un resolutor configurado de forma independiente.
Los roles tras una búsqueda
- Cliente: el dispositivo o la aplicación que solicita una respuesta DNS.
- Solucionador recursivo: el servicio responsable de buscar y devolver dicha respuesta.
- Servidor autoritativo: el servidor que publica los registros DNS oficiales para el dominio solicitado.
La analogía del conserje facilita la separación de esas responsabilidades.
Para una búsqueda de dirección correcta, el dispositivo recibe una dirección IP y un tiempo de vida, habitualmente abreviado como TTL. Este valor indica a los sistemas de almacenamiento en caché cuánto tiempo pueden reutilizar la respuesta. A continuación, el navegador puede utilizar la dirección para empezar a contactar con el destino.
Recursivo no significa repetición sin fin. Describe la responsabilidad que acepta el solucionador: encontrar la respuesta final para el cliente o devolver un error adecuado si no puede hacerlo.
Por lo general, el huésped del hotel no sabe nada de esto. No necesita elegir servidores raíz ni entender quién aloja el DNS del sitio web.
Una comprobación sencilla ayuda a comprenderlo: su dispositivo solicita una dirección, el solucionador la encuentra y su navegador la utiliza para iniciar una conexión.
Comparativa entre servidores DNS recursivos y autoritativos
Resolutor recursivo frente a servidor autoritativo
| Criterio | Resolvedor recursivo | Servidor autoritativo |
|---|---|---|
| Función principal | Encuentra respuestas para los clientes consultando a otros servidores | Publica los registros oficiales de los dominios de los que es responsable |
| Origen de las respuestas | Su caché o servidores DNS ascendentes | Sus propios registros de zona |
| Operador habitual | Proveedor de internet, servicio de resolvedor público, propietario de la red | Propietario del dominio o proveedor de alojamiento |
| Contactado directamente por los dispositivos | Sí | Normalmente no; contactan con él los resolvedores |
| Guarda en caché respuestas de otros dominios | Sí, sujeto al TTL y a las reglas de caché local | No, no como parte de su función autoritativa |
La diferencia clave radica en la recuperación frente a la autoridad. Un resolutor recursivo recupera información para un tercero. Un servidor autoritativo publica información sobre un dominio que está bajo su responsabilidad.
Esta diferencia es importante a la hora de solucionar problemas. Si todo el mundo recibe una dirección incorrecta para el sitio web de su organización, compruebe los registros autoritativos. Si solo tienen problemas los visitantes de una red concreta, investigue el resolutor de dicha red, su caché y su directiva.
Los operadores pueden solaparse sin necesidad de fusionar sus funciones
Un proveedor de internet puede ejecutar un DNS recursivo para los suscriptores, mientras que un proveedor de alojamiento publica un DNS autoritativo para los clientes. El propietario de una red también puede operar un solucionador interno para los dispositivos del personal.
La misma organización, y a veces el mismo software de servidor, pueden realizar ambas tareas. Un servidor podría responder de forma autoritativa para un dominio interno y, al mismo tiempo, resolver nombres de Internet no relacionados para los empleados. La función depende de la solicitud que se esté gestionando, no solo del nombre de la empresa que presta el servicio.
El reenvío añade otra distinción. Un servidor DNS local puede pasar las solicitudes a un solucionador ascendente en lugar de contactar directamente con la jerarquía. Entender el reenvío de DNS le ayuda a identificar qué servicio realiza la búsqueda externa.
Un servidor autoritativo no suele ser el punto de control de filtrado de contenido del visitante. Publica los registros del dominio, en lugar de aplicar las reglas de red del visitante.
Pregunta de diagnóstico: ¿Este servidor responde a partir de registros de los que es responsable o busca registros en nombre de un cliente?
Esa pregunta es más útil que asumir que todos los servidores etiquetados como DNS realizan el mismo trabajo.
Cómo recorre una búsqueda recursiva la jerarquía del DNS
Considere una búsqueda de www.example.com cuando ni el dispositivo ni su solucionador disponen de la información necesaria para responder.
El dispositivo envía una consulta recursiva, solicitando a su resolutor un resultado final. El resolutor suele realizar consultas iterativas aguas arriba: los servidores raíz y de dominio de nivel superior proporcionan referencias, mientras que el servidor autoritativo proporciona el registro solicitado.
Este diagrama muestra el trayecto general antes de los intercambios individuales.
Siga la solicitud y la respuesta
El dispositivo contacta con su resolvedor configurado. Envía el nombre del sitio web porque necesita una dirección antes de poder contactar con el destino.
El resolvedor comprueba su caché. Una respuesta utilizable en caché finaliza la búsqueda de inmediato. No hay motivo para solicitar a servidores ascendentes información que el resolvedor aún puede reutilizar.
En caso de no encontrarla en la caché, consulta a un servidor raíz. El servidor raíz lo dirige hacia los servidores responsables del dominio de nivel superior correspondiente, en este caso .com.
Consulta a un servidor .com. Ese servidor identifica los servidores de nombres autoritativos para example.com, reduciendo la búsqueda a las autoridades designadas del dominio.
Consulta a un servidor autoritativo. El servidor autoritativo devuelve el registro de dirección solicitado y su TTL, expresado en segundos.
Almacena y devuelve la respuesta. El resolvedor conserva una copia reutilizable y envía el resultado al dispositivo.
Las solicitudes posteriores pueden utilizar esa copia en caché. Mientras la respuesta siga siendo utilizable, el resolvedor no necesita repetir el trayecto ascendente para el mismo nombre y tipo de registro.
La jerarquía distribuye la responsabilidad. Los servidores raíz identifican las autoridades de los dominios de nivel superior, esas autoridades identifican los servidores de nombres de dominio y los administradores de dominios mantienen los registros de destino.
Una respuesta almacenada en caché sigue siendo una respuesta legítima
La respuesta del solucionador suele ser no autoritativa. Esto significa que está retransmitiendo información en lugar de responder como autoridad del dominio, no que la respuesta sea poco fiable.
Algunas implementaciones reenvían la solicitud a un servicio recursivo ascendente, que realiza este trabajo en su nombre. Asimismo, un solucionador con referencias en caché puede omitir partes del recorrido ilustrado.
Las reglas de caché local también son importantes. Las notas de APNIC sobre RIPE 91 identifican temporizadores de caché máxima del solucionador observados con frecuencia de 6 horas, 12 horas, 24 horas y 7 días, lo que demuestra por qué los administradores no deben asumir que todos los solucionadores siguen límites de caché idénticos.
Para ver el proceso de consulta desde otra perspectiva, este vídeo muestra la resolución de DNS.
Caché, TTL y tiempo que tarda en aplicarse un cambio
Se bloquea un dominio a las 9:00 y un portátil de la misma red sigue abriéndolo a las 9:40. Este desfase se debe a la reutilización. El TTL funciona como la fecha de caducidad de un ticket de aparcamiento: indica al resolutor cuánto tiempo puede seguir entregando una respuesta almacenada antes de tener que volver a consultar aguas arriba.
Para un registro en caché ordinario, la cantidad que importa es el tiempo de vida restante. El temporizador de caché máximo de un solucionador puede acortar ese tiempo de vida, mientras que un mínimo aplicado localmente puede ampliarlo. Los máximos de solucionador observados incluyen 6 horas, 12 horas, 24 horas y 7 días, según las notas de APNIC de RIPE 91. Estos ajustes rigen la frescura del registro. Deciden cuánto tarda un bloqueo solo cuando el diseño del filtrado se basa en actualizar la respuesta DNS en lugar de comprobar la directiva actual.
La configuración de la caché y su significado para un nuevo bloqueo
| Ajuste de caché | Valor típico | Efecto en un nuevo bloqueo o cambio |
|---|---|---|
| TTL de cero segundos | Sin tiempo de vida reutilizable | Bajo la gestión normal de TTL, la siguiente solicitud activa una búsqueda ascendente |
| TTL corto | De segundos a minutos | Los cambios en los registros se vuelven visibles poco después de cada actualización |
| Temporizador de caché máximo del resolvedor | 6 horas | Limita la retención de registros cuyo TTL sea más largo |
| Temporizador de caché máximo del resolvedor | 12 horas | Acorta a medio día los TTL de registro más largos |
| Temporizador de caché máximo del resolvedor | 24 horas | Permite que una respuesta persista durante la noche, hasta un día entero |
| Temporizador de caché máximo del resolvedor | 7 días | Permite la retención durante una semana solo cuando el TTL del registro también lo permite |
Separe los cambios de registros de los cambios de directivas
Supongamos que la dirección autoritativa de un sitio cambia un minuto después de que un solucionador guarde en caché la respuesta anterior. Ese solucionador puede seguir devolviendo la dirección antigua hasta que finalice el tiempo de vida efectivo, que es el periodo más corto entre el TTL del registro y el máximo del propio solucionador, ajustado para cualquier mínimo aplicado. Con un TTL de registro de 24 horas y un límite de 6 horas, los usuarios acceden a la nueva dirección en un plazo de seis horas. Con un TTL de registro de 7 días bajo un límite de 7 días, pueden esperar una semana entera.
Ahora la dirección sigue siendo la misma, pero un equipo de seguridad marca el dominio como malicioso. Un solucionador que vuelve a comprobar la directiva actual antes de ofrecer una respuesta en caché bloquea el dominio en la siguiente búsqueda. Un diseño que solo vuelve a evaluar cuando se actualiza la respuesta deja la ruta abierta durante el resto del tiempo de vida útil, lo que podría suponer un día entero de exposición con un límite de 24 horas.
Regla práctica: pregunte cuándo actualiza el resolutor su respuesta de DNS y cuándo vuelve a evaluar su decisión de filtrado. El cambio llegará a los usuarios en el último de esos dos momentos.
Para cambios urgentes, pruebe tanto un dominio consultado previamente como uno que no esté en caché. Supervise los aciertos de la caché, el volumen de consultas ascendentes y la entrega de actualizaciones de directivas como métricas independientes. Una consulta reciente y rápida no garantiza nada sobre los usuarios que aún conserven una respuesta almacenada en caché.
Filtrado y seguridad en el resolutor
Un resolutor puede aplicar reglas a las consultas que recibe antes de que el dispositivo inicie una conexión. Sin embargo, la recursividad por sí sola no proporciona dichas reglas. La clasificación de contenidos, la inteligencia sobre amenazas y las comprobaciones de autenticidad del DNS son funcionalidades independientes.
El filtrado de contenidos establece reglas de acceso
El filtrado DNS basado en categorías permite al propietario de una red decidir a qué destinos pueden acceder los usuarios. Una atracción familiar podría restringir el contenido para adultos en la WiFi para invitados WiFi mientras mantiene reglas diferentes para una red administrativa.
Antes de que un dispositivo abra un sitio o una aplicación, consulta al DNS dónde encontrarlo y nosotros respondemos aplicando la directiva correspondiente a la red en la que se encuentra el dispositivo. Por tanto, la identidad de la red resulta fundamental, no solo el dominio solicitado.
Las funciones principales son distintas aunque las proporcione un mismo servicio.
La defensa contra amenazas evalúa el destino
Los controles de amenazas pueden rechazar las consultas a dominios conocidos de phishing y malware. Nuestra protección contra amenazas también bloquea las llamadas de comando y control procedentes de dispositivos infectados durante la consulta, lo que impide que dichos intentos de conexión se inicien a través de esa ruta de resolución.
Se trata de una contención útil, pero no elimina el software malicioso del dispositivo. La protección de los puntos finales y los controles del cortafuegos siguen teniendo sus propias funciones.
DNSSEC comprueba la autenticidad, no la seguridad
La validación de DNSSEC utiliza un ancla de confianza configurada y una cadena de firmas criptográficas para autenticar datos DNS firmados. RFC 4033 describe la validación segura y señala que un solucionador con reconocimiento de seguridad debe considerar la validez de la firma al seleccionar los tiempos de vida en caché, teniendo en cuenta las imprecisiones del reloj.
Por lo tanto, los administradores necesitan una hora precisa del sistema y una gestión de la caché que conserve el estado de validación. Un solucionador debe distinguir los datos legítimamente no firmados de los datos firmados cuya validación falla.
- Control temprano: El filtrado puede detener una búsqueda no deseada antes de que comience una conexión, pero solo para las solicitudes que utilizan ese solucionador.
- Reglas coherentes: Los dispositivos que utilizan la misma directiva de red reciben un tratamiento coherente, pero las rutas de resolución alternativas requieren controles independientes.
- Comprobación de autenticidad: DNSSEC ayuda a detectar respuestas firmadas falsificadas, pero no cifra las consultas ni determina si un dominio es malicioso.
Un dominio de suplantación de identidad (phishing) correctamente firmado sigue siendo un dominio de suplantación de identidad. El filtrado decide si debe permitirse el acceso; DNSSEC establece si la información DNS firmada es auténtica.
Interrupciones, respuestas obsoletas y errores de concepto comunes
Un invitado abre un sitio web mientras su servidor DNS autoritativo no está accesible y, aun así, la página se carga. Es posible que el resolutor disponga de una respuesta almacenada en caché que no haya caducado, por lo que no necesita contactar con dicho servidor autoritativo para esta solicitud.
Algunos solucionadores también pueden ofrecer respuestas obsoletas tras el vencimiento ordinario cuando los servidores en origen no están disponibles. Se trata de una estrategia de disponibilidad, no de una prueba de que los registros DNS permanezcan actualizados indefinidamente. El explicador de DNS de Cloudflare proporciona la distinción subyacente entre el solucionador que recupera información y el servidor autoritativo que la suministra.
Las respuestas almacenadas en caché explican por qué una interrupción autoritativa no siempre se convierte en una interrupción de navegación inmediata.
La disponibilidad y la protección requieren decisiones explícitas
Los resolutores también pueden almacenar en caché los resultados no satisfactorios. El almacenamiento en caché negativo conserva información como la no existencia de un nombre, evitando así búsquedas repetidas del mismo nombre ausente. Después de que un administrador cree dicho nombre, es posible que algunos clientes sigan recibiendo el resultado negativo almacenado en caché hasta que expire.
La gestión de errores plantea una cuestión de directivas independiente. Un diseño de filtrado con permissive al fallo (fail-open) permite la resolución sin sus comprobaciones de directivas habituales cuando estas no están disponibles. Un diseño restrictivo al fallo (fail-closed) rechaza las solicitudes que no puede aprobar, manteniendo la restricción pero pudiendo interrumpir el acceso legítimo.
Los fallos de validación de DNSSEC son otro caso distinto. Los operadores no deben tratar los datos firmados no válidos como autenticados simplemente para mantener la carga de una página.
Suposiciones que provocan errores operativos
- La recursividad implica automáticamente el bloqueo: La recursividad recupera respuestas; los administradores añaden el bloqueo a través de una capa de directiva.
- Un filtro DNS controla cada conexión: Las direcciones de destino codificadas de forma rígida y algunas rutas VPN pueden eludir por completo la búsqueda protegida.
- Cambiar el DNS de la red traslada al instante a todos los clientes: La configuración existente, las concesiones DHCP y las opciones de solucionador a nivel de navegador pueden dejar los dispositivos en otra ruta.
Al investigar una interrupción del servicio, diferencie entre una autoridad inaccesible, un registro caducado, una respuesta negativa, un fallo de validación y un rechazo por directiva. Aunque para un invitado puedan parecer similares, requieren soluciones distintas.
La recursividad traslada las respuestas. Las directivas y la resiliencia determinan qué respuestas proporcionará la red en condiciones cambiantes.
Confirme qué resolutor utiliza su red antes de cambiarlo
Si se pregunta qué es el DNS recursivo porque está a punto de modificar una red en producción, comience por mapear la ruta actual. Registre la configuración operativa para poder restaurarla si las pruebas revelan alguna dependencia de aplicaciones o de nombres internos.
Compruebe la ruta antes del despliegue
- Localice el servicio DNS configurado del dispositivo. Utilice sus ajustes de red o una herramienta de búsqueda de DNS. La dirección de un router puede representar un servicio de reenvío, por lo que debe rastrear también su destino ascendente.
- Inspeccione la configuración de DHCP y del controlador. Confirme qué resolvedor anuncia la red y si los clientes configurados manualmente lo siguen.
- Defina por escrito la directiva requerida. Identifique las categorías de contenido, los controles de malware, el registro de búsquedas y las diferencias entre el acceso del personal y el de los invitados.
- Elija un comportamiento de actualización aceptable. Especifique los retrasos tolerables en la actualización de registros y directivas, así como la respuesta prevista ante fallos del servicio.
- Realice una prueba piloto en una red limitada. Pruebe los sitios permitidos, los destinos bloqueados, los recursos internos y la recuperación antes de extender el cambio.
La implementación consiste en un ajuste de DNS por red o un cambio de DHCP en el controlador, sin necesidad de instalar nada en los dispositivos cliente. Esto cubre los dispositivos que siguen la configuración de DNS de la red, pero no garantiza que todas las aplicaciones la utilicen.
Pruebe las VPN y el DNS sobre HTTPS, ya que pueden crear rutas de resolución alternativas. Nuestro equipo le mostrará cómo gestiona la red las VPN y el DNS cifrado antes de iniciar una prueba.
Un solucionador recursivo con directivas es la opción adecuada cuando la red necesita un filtrado antes de que se inicien las conexiones y el propietario acepta su caché y su comportamiento ante fallos.
Purple Shield proporciona DNS de protección, filtrado de contenidos, defensa frente a amenazas y bloqueo de anuncios en la capa DNS para WiFi para invitados y redes públicas WiFi sin necesidad de agentes en los dispositivos. Visite Purple Shield para analizar la ruta del solucionador de su red, las directivas que necesita y cómo probar la aplicación de reglas antes de implementar un cambio de DNS.