Resolutor DNS

Un resolutor DNS recibe consultas de los clientes y encuentra la dirección IP o el registro DNS correcto interrogando a otros servidores DNS en su nombre. Es el punto de entrada que la mayoría de aplicaciones usa hacia el DNS, y oculta a cada programa la complejidad de recorrer la jerarquía global de nombres.

En la práctica conviven dos tipos de resolutores. Un *resolutor stub* vive en el sistema operativo o en la biblioteca de la aplicación y reenvía cada consulta a un resolutor superior configurado — habitualmente leído de /etc/resolv.conf, recibido por DHCP o fijado manualmente. Un *resolutor recursivo*, también llamado full-service resolver, es ese resolutor superior: recorre raíz → TLD → servidor autoritativo y devuelve una respuesta terminada. La mayoría de operadores despliegan resolutores recursivos dedicados — Unbound, BIND, Knot Resolver — a los que los sistemas finales solo hablan en modo stub.

Para mantener baja la latencia y el tráfico, cada resolutor mantiene una caché indexada por nombre y tipo de registro y respeta el TTL de cada respuesta. Las respuestas negativas (NXDOMAIN, NODATA vacío) también se almacenan, acotadas por el campo minimum del SOA, motivo por el que la propagación DNS de un nombre nuevo puede ir por detrás de su publicación real. Los resolutores validantes realizan además la verificación DNSSEC y devuelven SERVFAIL en lugar de datos sin firmar cuando la cadena de confianza está rota.

Ejemplos públicos son Cloudflare 1.1.1.1, Google 8.8.8.8 y Quad9 9.9.9.9. Los ISP suelen operar sus propios resolutores y distribuirlos por DHCP, mientras que las redes corporativas despliegan a menudo resolutores internos que combinan recorrido público desde la raíz con respuestas en split-horizon para zonas privadas. Los resolutores también recuperan los registros MX, PTR, SPF, DKIM y DMARC usados por el correo, por lo que un fallo del nivel recursivo rompe mucho más que la simple navegación web.