Qué es el DNS recursivo: Cómo funciona y por qué es importante
¿Qué es el DNS recursivo? Vea cómo un resolvedor responde a las búsquedas, utiliza el almacenamiento en caché y dónde se aplican las comprobaciones de seguridad, con ejemplos claros.
Published 2 de noviembre de 2026
Un resolutor DNS recursivo es el servidor que toma una búsqueda de nombre desde su dispositivo y encuentra la dirección IP correspondiente en su nombre consultando otros servidores DNS, almacenando luego la respuesta para su reutilización.
Supongamos que cambió una configuración en su WiFi WiFi para invitados, pero un visitante aún puede acceder a un sitio que usted quería bloquear. Antes de volver a modificar el firewall, verifique qué resolutor utiliza su dispositivo y si su política se aplica a las respuestas en caché. Esos detalles suelen explicar la diferencia entre cambiar una regla y verla funcionar.
Tabla de contenido
- Lo que hace un DNS Resolver Recursivo por su dispositivo
- Comparación entre Servidores DNS Recursivos y Autoritativos
- Cómo una Búsqueda Recursiva Recorre la Jerarquía DNS
- Almacenamiento en Caché, TTL y Cuánto Tarda un Cambio
- Filtrado y Seguridad en el Resolver
- Interrupciones, Respuestas Obsoletas y Errores Comunes
- Confirme qué Resolver Utiliza su Red Antes de Cambiarlo
Qué hace un resolutor de DNS recursivo por su dispositivo
Un resolutor DNS recursivo busca respuestas DNS para un dispositivo, de forma muy parecida a un concierge de hotel que se comunica con varios departamentos en lugar de enviar al huésped de mostrador en mostrador. El huésped hace una pregunta y espera una respuesta, no indicaciones para continuar la búsqueda.
Suponga que el huésped de un hotel abre su laptop e ingresa el nombre de un sitio web. Si la laptop aún no tiene una respuesta utilizable de forma local, envía una consulta a su servicio DNS configurado. Ese servicio puede proporcionarlo la red del hotel, el proveedor de internet o un resolutor configurado de forma independiente.
Los roles detrás de una búsqueda
- Cliente: El dispositivo o aplicación que solicita una respuesta de DNS.
- Resolutor recursivo: El servicio responsable de buscar y devolver esa respuesta.
- Servidor autoritativo: El servidor que publica los registros DNS oficiales para el dominio solicitado.
La analogía del concierge facilita la separación de esas responsabilidades.
Para una búsqueda de dirección exitosa, el dispositivo recibe una dirección IP y un tiempo de vida, que por lo general se abrevia como TTL. Ese valor indica a los sistemas de caché cuánto tiempo pueden reutilizar la respuesta. El navegador puede utilizar entonces la dirección para comenzar a ponerse en contacto con el destino.
Recursivo no significa repetición sin fin. Describe la responsabilidad que acepta el resolutor: 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 que nada de esto está sucediendo. No necesita elegir servidores raíz ni entender quién aloja el DNS del sitio web.
Una comprobación de comprensión útil es simple: su dispositivo solicita una dirección, el resolutor la encuentra y su navegador la utiliza para iniciar una conexión.
Comparación entre servidores de DNS recursivos y autoritativos
Resolutor recursivo frente a servidor autoritativo
| Criterio | Resolutor recursivo | Servidor autoritativo |
|---|---|---|
| Función principal | Encuentra respuestas para los clientes mediante la consulta a otros servidores | Publica los registros oficiales de los dominios de los que es responsable |
| Origen de las respuestas | Su memoria caché o servidores DNS ascendentes | Sus propios registros de zona |
| Operador habitual | Proveedor de internet, servicio de resolutor público, propietario de la red | Propietario del dominio o proveedor de alojamiento web |
| Contactado directamente por los dispositivos | Sí | Por lo general no; los resolutores se comunican con él |
| Almacena respuestas en caché para otros dominios | Sí, sujeto al TTL y a las reglas de caché local | No, no como parte de su función autoritativa |
La distinción clave es recuperación frente a autoridad. Un resolutor recursivo recupera información para alguien más. Un servidor autoritativo publica información para un dominio bajo su responsabilidad.
Esa diferencia es importante al resolver problemas. Si todos reciben la dirección incorrecta para el sitio web de su organización, verifique los registros autoritativos. Si solo los visitantes de una red en particular tienen problemas, investigue el resolutor de esa red, su caché y su política.
Los operadores pueden solaparse sin fusionar los roles
Un proveedor de internet puede ejecutar un DNS recursivo para los suscriptores, mientras que un proveedor de alojamiento publica un DNS con autoridad para los clientes. El propietario de una red también puede operar un resolutor 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 mientras resuelve nombres de internet no relacionados para los empleados. El rol pertenece a la solicitud que se está gestionando, no solo al nombre de la empresa en el servicio.
El reenvío agrega otra distinción. Un servidor DNS local puede pasar las solicitudes a un resolutor ascendente en lugar de contactar a la jerarquía directamente. Comprender el reenvío de DNS le ayuda a identificar qué servicio realiza la búsqueda externa.
Un servidor con autoridad 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 cada servidor etiquetado como DNS realiza el mismo trabajo.
Cómo recorre la jerarquía de DNS una búsqueda recursiva
Considere una búsqueda de www.example.com cuando ni el dispositivo ni su resolutor disponen de la información necesaria para responder.
El dispositivo envía una consulta recursiva, pidiéndole a su resolutor un resultado final. El resolutor normalmente realiza consultas iterativas aguas arriba: los servidores raíz y de dominio de nivel superior proporcionan las referencias, mientras que el servidor autoritativo proporciona el registro solicitado.
Este diagrama muestra el recorrido general antes de los intercambios individuales.
Siga la solicitud y la respuesta
El dispositivo contacta a su resolutor configurado. Envía el nombre del sitio web porque necesita una dirección antes de poder contactar al destino.
El resolutor verifica su caché. Una respuesta utilizable en caché finaliza la búsqueda de inmediato. No hay razón para solicitar información a los servidores ascendentes que el resolutor aún pueda reutilizar.
En caso de no encontrarla en 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 resolutor conserva una copia reutilizable y envía el resultado al dispositivo.
Las solicitudes posteriores pueden usar esa copia en caché. Mientras la respuesta siga siendo utilizable, el resolutor no necesita repetir el proceso ascendente para el mismo nombre y tipo de registro.
La jerarquía distribuye la responsabilidad. Los servidores raíz identifican las autoridades de dominio de nivel superior, esas autoridades identifican los servidores de nombres de dominio y los administradores de dominio mantienen los registros de destino.
Una respuesta almacenada en caché sigue siendo una respuesta legítima
La respuesta del resolutor normalmente es sin autoridad. Esto significa que está retransmitiendo información en lugar de responder como la autoridad del dominio, no que la respuesta no sea confiable.
Algunas implementaciones reenvían la solicitud a un servicio recursivo ascendente, el cual realiza este trabajo en su nombre. Asimismo, un resolutor con referencias en caché puede omitir partes del trayecto ilustrado.
Las reglas de la caché local también importan. Las notas de APNIC de RIPE 91 identifican temporizadores máximos de caché del resolutor observados comúnmente de 6 horas, 12 horas, 24 horas y 7 días, lo que demuestra por qué los administradores no deben asumir que todos los resolutores siguen límites de caché idénticos.
Para ver otra perspectiva del proceso de búsqueda, este video sigue la resolución de DNS.
Almacenamiento en caché, TTL y cuánto tarda un cambio
Un dominio se bloquea a las 9:00 y una laptop en la misma red todavía lo abre a las 9:40. El desfase proviene de la reutilización. Un TTL funciona como el tiempo de expiración de un boleto de estacionamiento: le indica al resolutor cuánto tiempo puede seguir entregando una respuesta almacenada antes de tener que volver a consultar aguas arriba.
Para un registro estándar en caché, la cantidad que importa es el tiempo de vida restante. El temporizador de caché máximo de un resolvedor puede acortar ese tiempo de vida, mientras que un mínimo aplicado localmente puede alargarla. Los máximos de resolvedor observados incluyen 6 horas, 12 horas, 24 horas y 7 días, según las notas de APNIC de RIPE 91. Estas configuraciones rigen la frescura del registro. Deciden cuánto tarda un bloqueo solo cuando el diseño de filtrado se basa en actualizar la respuesta DNS en lugar de verificar la política actual.
La configuración de la caché y lo que significa para un nuevo bloqueo
| Configuración de caché | Valor típico | Efecto en un nuevo bloqueo o cambio |
|---|---|---|
| TTL de cero segundos | Sin tiempo de vida reutilizable | Bajo el manejo normal del 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 resolver | 6 horas | Limita la retención de registros cuyo TTL es más largo |
| Temporizador de caché máximo del resolver | 12 horas | Trunca los TTL de registros más largos a medio día |
| Temporizador de caché máximo del resolver | 24 horas | Permite que una respuesta persista durante la noche, hasta un día completo |
| Temporizador de caché máximo del resolver | 7 días | Permite una retención de una semana solo cuando el TTL del registro también lo permite |
Separe los cambios de registro de los cambios de políticas
Supongamos que la dirección autoritativa de un sitio cambia un minuto después de que un resolvedor almacene en caché la respuesta anterior. Ese resolvedor puede seguir devolviendo la dirección anterior hasta que finalice el tiempo de vida efectivo, que es el menor entre el TTL del registro y el máximo propio del resolvedor, ajustado para cualquier mínimo exigido. Con un TTL de registro de 24 horas y un límite de 6 horas, los usuarios llegan a la nueva dirección dentro de las seis horas. Con un TTL de registro de 7 días bajo un límite de 7 días, pueden esperar una semana completa.
Ahora la dirección sigue siendo la misma, pero un equipo de seguridad marca el dominio como malicioso. Un resolutor que vuelve a verificar la política 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 la respuesta se actualiza deja la vía abierta durante el resto del tiempo de vida efectivo, lo que podría significar un día de exposición en 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. Un cambio llega a los usuarios en el último de esos dos momentos.
Para cambios urgentes, pruebe tanto un dominio consultado previamente como uno sin guardar en caché. Monitoree los aciertos de caché, el volumen de consultas entrantes y la entrega de actualizaciones de políticas como mediciones independientes. Una búsqueda nueva y rápida no garantiza nada sobre los usuarios que aún conservan una respuesta en caché.
Filtrado y seguridad en el resolutor
Un resolutor puede aplicar reglas a las búsquedas que recibe antes de que el dispositivo inicie una conexión. Sin embargo, la recursividad por sí sola no proporciona esas reglas. La clasificación de contenido, la inteligencia sobre amenazas y las comprobaciones de autenticidad de DNS son funciones independientes.
El filtrado de contenido establece reglas de acceso
El filtrado de DNS basado en categorías le 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 WiFi para invitados 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 según la política de la red en la que se encuentra el dispositivo. Eso hace que la identidad de la red sea importante, no solo el dominio solicitado.
Las funciones principales son distintas, incluso cuando un mismo servicio las proporciona.
La defensa contra amenazas evalúa el destino
Los controles de amenazas pueden rechazar búsquedas de dominios conocidos de phishing y malware. Nuestra protección contra amenazas también bloquea las llamadas de comando y control provenientes de dispositivos infectados durante la búsqueda, lo que evita que esos intentos de conexión se inicien a través de esa ruta de resolución.
Esa es una contención útil, pero no elimina el malware del dispositivo. La protección de endpoints y los controles de firewall 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 establece que un resolvedor consciente de la seguridad debe considerar la validez de la firma al seleccionar tiempos de vida en caché, teniendo en cuenta las imprecisiones del reloj.
Por lo tanto, los administradores necesitan una hora del sistema precisa y un manejo de caché que conserve el estado de validación. Un resolutor debe distinguir los datos legítimamente no firmados de los datos firmados que no superan la validación.
- 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 resolvedor.
- Reglas consistentes: Los dispositivos que usan la misma política de red reciben un trato consistente, pero las rutas de resolución alternativas necesitan controles separados.
- Verificació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 phishing firmado correctamente sigue siendo un dominio de phishing. El filtrado decide si se debe permitir el acceso; DNSSEC establece si la información DNS firmada es auténtica.
Interrupciones, respuestas desactualizadas y errores de concepto comunes
Un invitado abre un sitio web mientras su servidor DNS autoritativo no está disponible, pero la página aun así se carga. Es posible que el resolutor tenga una respuesta almacenada en caché que no ha expirado, por lo que no necesita contactar a ese servidor autoritativo para esta solicitud.
Algunos resolvedores también pueden servir respuestas obsoletas después del vencimiento habitual cuando los servidores ascendentes no están disponibles. Esa es una estrategia de disponibilidad, no una prueba de que los registros DNS permanezcan actualizados indefinidamente. El explicador de DNS de Cloudflare proporciona la distinción fundamental entre el resolvedor que recupera información y el servidor autoritativo que la suministra.
Las respuestas en caché explican por qué una interrupción con autoridad 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 guardar en caché los resultados no exitosos. La caché negativa conserva información como la no existencia de un nombre, lo que evita búsquedas repetidas del mismo nombre faltante. Después de que un administrador crea ese nombre, es posible que algunos clientes continúen recibiendo el resultado negativo almacenado en caché hasta que expire.
La gestión de fallas plantea una cuestión de política independiente. Un diseño de filtrado fail-open (permitir en caso de falla) permite la resolución sin sus verificaciones de política normales cuando estas no están disponibles. Un diseño fail-closed (bloquear en caso de falla) rechaza las solicitudes que no puede aprobar, lo que conserva la restricción pero podría interrumpir el acceso legítimo.
Las fallas 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.
Supuestos que provocan errores operativos
- La recursión significa bloqueo automáticamente: La recursión recupera respuestas; los administradores agregan el bloqueo a través de una capa de política.
- Un filtro DNS controla cada conexión: Las direcciones de destino codificadas y algunas rutas VPN pueden evitar la búsqueda protegida por completo.
- Cambiar el DNS de la red traslada a todos los clientes al instante: La configuración existente, las concesiones DHCP y las elecciones de resolvedor a nivel de navegador pueden dejar los dispositivos en otra ruta.
Al investigar una interrupción, distinga entre una autoridad inalcanzable, un registro expirado, una respuesta negativa, una falla de validación y un rechazo por política. Pueden parecer similares para un invitado, pero requieren soluciones diferentes.
La recursión traslada las respuestas. Las políticas y la resiliencia determinan qué respuestas entregará 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 activa, comience por mapear la ruta actual. Registre la configuración operativa para que pueda restaurarla si las pruebas exponen una dependencia de aplicaciones o de nombres internos.
Verifique la ruta antes del despliegue
- Encuentre el servicio DNS configurado del dispositivo. Utilice sus configuraciones de red o una herramienta de búsqueda DNS. La dirección de un enrutador puede representar un servicio de reenvío, por lo que también debe rastrear su destino ascendente.
- Inspeccione la configuración de DHCP y del controlador. Confirme qué resolutor 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, además de la respuesta prevista ante fallas 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 es un ajuste de DNS por red o un cambio de DHCP en el controlador, sin instalar nada en los dispositivos cliente. Eso cubre los dispositivos que siguen la configuración de DNS de la red, en lugar de garantizar que todas las aplicaciones la utilicen.
Pruebe las VPN y el DNS sobre HTTPS, los cuales pueden crear rutas de resolución alternativas. Nuestro equipo muestra cómo gestiona la red las VPN y el DNS cifrado antes de una prueba de evaluación.
Un resolutor recursivo con políticas es la elección adecuada cuando la red necesita filtrado antes de que se inicien las conexiones y el propietario acepta su comportamiento de caché y de fallas.
Purple Shield ofrece DNS de protección, filtrado de contenido, defensa contra amenazas y bloqueo de anuncios a nivel de DNS para WiFi para invitados y redes públicas WiFi sin agentes en los dispositivos. Visite Purple Shield para analizar la ruta del resolutor de su red, las políticas que necesita y cómo probar la aplicación antes de implementar un cambio de DNS.