A DNS stub resolver is a client-side software component that forwards DNS queries from applications to a configured recursive resolver rather than performing lookups itself, operating as an intermediary between applications and DNS servers. The stub resolver's configuration—typically distributed via DHCP or endpoint management tools—directly affects application performance and connection reliability, with misconfigurations causing slow page loads, failed logins, and intermittent lookup failures even when network infrastructure is healthy. Security and operational challenges arise from unencrypted DNS traffic on port 53, stale local caches, unreachable resolver addresses, and VPN-induced split DNS conflicts, all of which require careful configuration and monitoring to prevent widespread client-side DNS resolution failures.
Cómo funciona el resolutor DNS stub
Un resolutor stub se sitúa entre las aplicaciones de un dispositivo y un resolutor recursivo. No realiza búsquedas iterativas por sí mismo, por lo que su función se limita a reenviar las consultas y devolver los resultados.
- La aplicación solicita un nombre: una aplicación invoca una función de la biblioteca del sistema, como getaddrinfo, para buscar un nombre de host.
- Se comprueban las fuentes locales: el resolutor stub puede consultar primero un archivo de hosts o una caché local y responder de inmediato si encuentra una coincidencia.
- La consulta se envía a un resolutor recursivo: si no hay una respuesta local, el stub envía una consulta DNS con el indicador de recursión activado a la dirección del resolutor con la que ha sido configurado. Esa dirección suele obtenerse a través de DHCP o configurarse manualmente.
- Se devuelve una respuesta: el resolutor recursivo realiza la búsqueda completa y responde. El stub devuelve las direcciones o el código de error a la aplicación y puede almacenar el resultado en caché durante el tiempo de vida del registro.
Si el primer resolutor configurado no responde, el stub suele volver a intentarlo o probar con el siguiente de su lista. Muchos stubs también pueden utilizar transportes cifrados, como DNS sobre TLS o DNS sobre HTTPS, para llegar al resolutor recursivo.
Problemas habituales con los resolutores DNS stub
Si el primer resolutor configurado está inactivo, el stub espera a que se agote el tiempo de espera antes de probar con el siguiente, por lo que los usuarios experimentan retrasos de varios segundos en cada búsqueda. El tiempo de conmutación por error varía según el sistema operativo, lo que hace que el síntoma sea inconsistente entre dispositivos.
Los nombres cortos se expanden utilizando los dominios de búsqueda configurados, por lo que una búsqueda puede generar varias consultas fallidas antes de que una tenga éxito. Una lista de sufijos incorrecta también puede resolver un nombre corto a un host no deseado.
Una caché local puede seguir devolviendo una dirección antigua después de que se haya modificado un registro, aunque el resolutor recursivo ya disponga de la nueva. Vaciando la caché del cliente se elimina el síntoma, lo que apunta al stub en lugar de al servidor.
Cuando un cliente VPN cambia la configuración del resolutor, los nombres internos pueden dejar de funcionar fuera de la VPN o los nombres públicos pueden dirigirse al resolutor interno. Las listas mixtas de resolutores, en las que solo algunos servidores conocen las zonas internas, provocan fallos intermitentes.
Una opción de servidor DNS incorrecta en un ámbito DHCP proporciona a todos los clientes de esa subred la misma dirección errónea del resolutor. A raíz de ello, se producen fallos en muchos dispositivos a la vez, aunque la conectividad IP siga funcionando.