¿Qué es el reenvío de DNS? Cómo funciona y por qué es importante
¿Qué es el reenvío de DNS? Conozca cómo se diferencian los reenviadores de los resolvedores recursivos, cómo funcionan la memoria caché y la conmutación por error, y dónde encaja el reenvío en las redes modernas.
Published 23 de octubre de 2026
El reenvío de DNS es el proceso en el que un resolvedor de DNS envía la consulta de un cliente a otro servidor DNS, el reenviador, en lugar de resolver el nombre directamente a través de la jerarquía de DNS. El resolvedor local aún puede responder desde su caché y aplicar políticas locales, mientras que el resolvedor ascendente realiza la búsqueda completa cuando es necesario. Pero si ese servidor ascendente falla, ¿qué parte del DNS está rota?
Esa distinción es muy importante cuando está configurando una red o intentando explicar por qué un sitio web no carga. Un resolutor de reenvío no solo transmite paquetes: puede responder solicitudes conocidas de forma local, dirigir consultas seleccionadas a diferentes servidores y definir qué resolutor ve el tráfico de DNS de un usuario.
Tabla de contenido
- Lo que realmente significa el reenvío de DNS
- Seguimiento de una consulta desde el cliente hasta la respuesta
- En qué se diferencia el reenvío de la recursión y el servicio autoritativo
- Reenvío condicional, Split Horizon y prevención de bucles
- Cómo el almacenamiento en caché y el TTL influyen en el rendimiento del reenvío
- Elección entre reenvío, recursión Root-Hints y DNS cifrado
- Implementación del reenvío en su red
Lo que realmente significa el reenvío de DNS
Piense en el resolutor local como la recepción de una oficina de correo. Un cliente solicita un sitio web por su nombre y el resolutor verifica si ya conoce la respuesta. Si tiene una respuesta válida en su caché, la devuelve. Si no es así, envía la consulta a un servidor DNS ascendente, el reenviador, que gestiona la búsqueda y devuelve una respuesta.
Esa disposición separa dos tareas. El resolutor local atiende a los clientes de la red y puede aplicar reglas locales. El resolutor ascendente asume el trabajo de resolver nombres que el servidor local no puede responder desde su caché o datos locales. Por lo tanto, el reenvío es una función arquitectónica, no automáticamente un producto de seguridad.
El DNS surgió en noviembre de 1983, cuando RFC 882 y RFC 883 introdujeron un sistema de nombres jerárquico para reemplazar el modelo HOSTS.TXT, que se había vuelto inmanejable. Antes del DNS, los administradores dependían de asignaciones de nombre a dirección mantenidas manualmente. En noviembre de 1987, RFC 1034 y RFC 1035 reemplazaron las especificaciones originales y se convirtieron en los estándares fundamentales para la arquitectura DNS moderna, según consta en la cronología de la historia del DNS.
Dónde encontrará el reenvío
Los ruters domésticos, las redes empresariales, el WiFi público, las escuelas y los entornos en la nube pueden utilizar el reenvío. Una organización podría usarlo para enviar búsquedas generales de internet a un servicio recursivo administrado, manteniendo al mismo tiempo el control local sobre la memoria caché, los registros, los nombres internos o las reglas de bloqueo.
El modelo mental útil es simple: el resolutor local es la recepción controlada; el resolutor ascendente es el especialista que realiza la búsqueda completa. Ese modelo también facilita la localización de un problema. Un cliente podría comunicarse con la recepción con éxito incluso si el resolutor ascendente no está disponible o devuelve un error.
Siguiendo una consulta desde el cliente hasta la respuesta
Una búsqueda típica comienza cuando un dispositivo solicita un nombre a su resolutor local. El resolutor consulta primero su memoria caché. Si la respuesta almacenada sigue siendo válida, puede devolverla sin contactar a un servidor ascendente. Si no hay una respuesta útil en la caché, el resolutor reenvía la consulta a un resolutor recursivo ascendente.
En la terminología de DNS, el reenvío implica que un resolvedor envía una consulta con el bit de recursión deseada (RD) activo. Ese bit señala que se le está pidiendo al resolvedor receptor que resuelva la consulta, en lugar de simplemente retransmitir un paquete sin esa solicitud. La definición del glosario de RFC 7719 distingue el reenvío de la retransmisión ciega de paquetes.
Cuando ocurre una falla en la caché (cache miss), el resolver recursivo ascendente realiza el trabajo de búsqueda. Puede utilizar su propia caché o consultar a través de la jerarquía de DNS para obtener la respuesta. Luego, la respuesta regresa al cliente a través del resolver de reenvío.
Las dos rutas posibles
- Acierto de caché: El resolutor local devuelve una respuesta válida guardada en caché. El servidor ascendente no interviene en esa búsqueda.
- Falla de caché: El resolutor local envía la consulta de forma ascendente, recibe la respuesta y se la devuelve al cliente.
Esta transferencia también define una división de responsabilidades muy útil. El resolutor local puede aplicar controles específicos de la red, mantener registros, usar reglas de DNS dividido o aplicar una política de validación de DNSSEC. El resolutor ascendente realiza la búsqueda recursiva cuando el resolutor local no puede responder desde su caché o datos locales.
Pista para la resolución de problemas: Si el resolvedor local responde a los clientes pero las búsquedas fallan cuando su caché no contiene la respuesta, verifique la ruta de reenvío y la respuesta ascendente antes de asumir que el servicio DNS autoritativo tiene la culpa.
En qué se diferencia el reenvío de la recursión y el servicio autoritativo
El reenvío de DNS, la recursión, el uso de proxy y el servicio autoritativo describen roles diferentes. Un solo sistema puede asumir más de un rol, pero los términos no son intercambiables. En una configuración típica de reenvío, el servidor local atiende a los clientes y mantiene una caché o políticas; un resolutor recursivo ascendente realiza la resolución para las búsquedas no encontradas en caché.
| Rol | Quién lo inicia | Realiza la búsqueda completa | Mantiene datos autoritativos | Síntoma de falla típico |
|---|---|---|---|---|
| Forwarder | Un resolvedor local le envía una consulta | Generalmente, cuando actúa como resolvedor recursivo de nivel superior (upstream) | No necesariamente | Tiempo de espera agotado o error del servicio de nivel superior |
| Resolvedor recursivo | Un cliente u otro resolvedor solicita la resolución | Sí, utilizando la caché o consultando a través de la jerarquía DNS | No necesariamente | Errores de resolución, tiempos de espera agotados o búsquedas fallidas |
| Proxy | Un cliente o servicio le envía tráfico | No de forma inherente; el reenvío mediante proxy transmite solicitudes según su diseño | No | La solicitud a través del proxy falla o no puede alcanzar su destino |
| Servidor autoritativo | Un resolvedor lo consulta para un dominio al que presta servicio | No, proporciona datos para su zona | Sí, para las zonas a las que presta servicio | Registros faltantes, incorrectos o no disponibles para esas zonas |
La distinción clave de la tabla es quién realiza la búsqueda completa. Un resolutor de reenvío envía una consulta no respondida hacia adelante; un resolutor recursivo gestiona la resolución, potencialmente consultando servidores autoritativos. Un servidor autoritativo proporciona registros para el dominio que administra en lugar de buscar en la jerarquía en nombre de un cliente.
Por qué la distinción cambia la resolución de problemas
Un resolvedor de reenvío puede devolver un tiempo de espera agotado hacia arriba, SERVFAIL o una respuesta en caché que ya no sea apropiada, incluso cuando la infraestructura de DNS autoritativo funcione con normalidad. Solucionar problemas únicamente en el servidor autoritativo en esa situación puede llevarlo por el camino equivocado. Verifique qué resolvedor recibió la solicitud, si tenía una respuesta en caché y qué sucedió en el siguiente salto.
También existe una dependencia de confianza. El RFC 7719 aborda la terminología de los resolvers, incluida la distinción entre reenviadores y resolvers recursivos. Las investigaciones sobre ataques de envenenamiento de caché distinguen estas funciones porque un reenviador depende de la integridad del resolver ascendente que utiliza. Si los controles de contenido forman parte del diseño, una red también puede utilizar el filtrado de DNS para aplicar políticas a las consultas antes de que los dispositivos se conecten a los destinos.
Reenvío condicional, Split Horizon y prevención de bucles
El reenvío no tiene por qué mandar cada consulta no respondida al mismo servidor ascendente. Con el reenvío condicional, un resolutor envía consultas de dominios seleccionados a un servidor designado. Por ejemplo, una red puede dirigir solicitudes de nombres internos a un servicio DNS interno y enviar otras solicitudes a un resolutor recursivo administrado.
Una idea relacionada es el DNS de horizonte dividido (split-horizon). Permite que una red devuelva diferentes respuestas para el mismo nombre según el origen de la solicitud. Alguien dentro de una organización podría recibir una respuesta interna, mientras que un solicitante externo recibe una respuesta diferente. El resolvedor local se convierte en un punto de decisión para mantener los nombres internos en la ruta adecuada.
La configuración debe dejar claro qué resolvedor posee cada ruta de consulta. Una regla que envía un nombre interno al servidor ascendente incorrecto puede generar una respuesta externa, un error al resolver o un resultado que difiere entre las partes de la red.
Prevención de bucles de resolvedor
Un bucle de reenvío ocurre cuando un resolutor envía una consulta a un segundo resolutor que, eventualmente, se la devuelve. La consulta puede circular entre servidores, provocando solicitudes repetidas, tiempos de espera agotados y consumo excesivo de recursos. La solución consiste en mapear las rutas de reenvío y asegurarse de que ninguna cadena de resolutores apunte de regreso a un servidor anterior.
Algunos nombres también necesitan un límite explícito. El RFC 9539 señala espacios de nombres como home.arpa que no deben reenviarse más allá de su alcance local previsto. Un resolvedor que funciona bien hasta que se agrega un segundo reenviador puede haber generado un bucle; un nombre local que comienza a resolverse públicamente puede requerir una regla de reenvío o de zona local más específica.
El siguiente video proporciona otra introducción visual a los conceptos de reenvío de DNS.
Cómo el almacenamiento en caché y el TTL moldean el rendimiento del reenvío
La caché de un reenviador funciona como la memoria de un intermediario útil: una vez que ha obtenido una respuesta desde arriba, puede responder por sí mismo a la siguiente pregunta idéntica. Ese único comportamiento explica la mayor parte del impacto del reenvío en el rendimiento. Cada acierto en caché elimina un viaje de ida y vuelta al resolvedor ascendente. Cada fallo agrega uno antes de que comience la búsqueda real.
El tiempo de vida (TTL) de cada registro establece el límite de esa memoria. El servidor autoritativo publica el TTL, y cualquier resolvedor a lo largo de la ruta puede reutilizar la respuesta en caché únicamente mientras siga siendo válida. Los TTL cortos mantienen las respuestas actualizadas, pero envían más consultas hacia arriba. Los TTL largos reducen el tráfico hacia arriba, pero pueden hacer que los clientes conserven direcciones desactualizadas después de un cambio de infraestructura.
La caché también se acumula a lo largo de la ruta. Una consulta puede ser atendida por la caché del cliente, la caché del reenviador o la caché del resolvedor ascendente, y cada capa ejecuta su propio conteo regresivo de TTL. Cuando un usuario reporta una respuesta desactualizada, la solución depende de qué capa la esté reteniendo, por lo que debe tratar a cada caché como un sospechoso independiente durante la resolución de problemas en lugar de borrar lo que esté más cerca.
Mida algo más que la latencia promedio
El tiempo promedio de búsqueda puede ocultar problemas que afectan a algunos usuarios o consultas más que a otros. Realice un seguimiento de la proporción de aciertos en caché, la latencia de búsqueda mediana y extrema, la tasa de tiempos de espera de nivel superior y el comportamiento de la caché negativa. Esas mediciones ayudan a distinguir entre un servicio de nivel superior lento y un forwarder que pierde constantemente oportunidades de caché o gestiona mal las búsquedas fallidas.
DNSSEC agrega un nivel adicional de complejidad. Un resolutor de validación obtiene firmas y claves además de la respuesta en sí, por lo que las fallas de caché en nombres firmados cuestan más que en los no firmados. Las respuestas validadas en caché evitan ese trabajo repetido, lo que hace que la tasa de aciertos sea aún más crítica en las rutas de validación.
Ninguna cifra única predice el tiempo de búsqueda en una red determinada. El resultado depende del estado de la caché en cada capa, la capacidad de respuesta ascendente, el trabajo de validación, la configuración del transporte y los reintentos tras un reenviador que no responde. Un reenviador con un comportamiento correcto también pasa los códigos de respuesta, el comportamiento de truncamiento, los registros DNSSEC y los indicadores sin cambios, para que los clientes vean la respuesta que envió el lado autoritativo.
Elegir entre reenvío, recursión de pistas raíz y DNS cifrado
El reenvío y la recursión mediante root-hints implican diferentes ventajas y desventajas. Con el reenvío, una organización selecciona resolvedores upstream para gestionar las consultas no respondidas. Esto puede simplificar las operaciones locales y centralizar las políticas, pero hace que la red dependa de los servicios upstream seleccionados. Con la recursión mediante root-hints, un resolvedor realiza la búsqueda iterativa por sí mismo, lo que reduce la dependencia de un único servicio recursivo upstream, pero otorga mayor responsabilidad de resolución a ese resolvedor.
| Opción de diseño | Dónde ocurre la resolución | Principal compromiso operativo |
|---|---|---|
| Reenvío | En el resolver recursivo ascendente seleccionado | Administración centralizada, con una dependencia ascendente |
| Recursión mediante root-hints | En el resolver recursivo local, que consulta a través de la jerarquía | Mayor control local, con mayor responsabilidad en la resolución directa |
| DNS cifrado dirigido por el cliente | En el resolver con el que el cliente contacta a través de una conexión cifrada | Es posible que la red local no vea ni controle la consulta de dominio |
El DNS cifrado hace que la elección sea menos directa. DNS over TLS y DNS over QUIC pueden proteger el tráfico DNS en tránsito, pero la pregunta clave es dónde finaliza el cifrado. Si un cliente cifra las consultas directamente hacia un resolvedor externo, es posible que un reenviador local no vea una consulta de dominio útil. Si el cifrado finaliza en un resolvedor empresarial aprobado, ese resolvedor aún puede aplicar políticas de red y reenviar consultas upstream.
El WiFi público necesita una política deliberada
Los operadores de WiFi público también deben considerar los portales cautivos. Es posible que los dispositivos necesiten resolución de nombres previa a la autenticación y verificaciones de conectividad antes de que los usuarios puedan iniciar sesión. El DNS cifrado puede complicar la detección del portal o retrasarla, por lo que los operadores deben decidir qué resolutores están aprobados, cómo debe funcionar la alternativa de respaldo y si es necesaria alguna excepción.
Un servicio de DNS de protección puede ubicarse en la ruta de resolución seleccionada y evaluar las búsquedas antes de que comiencen las conexiones. Purple Shield está diseñado para redes WiFi de recintos y visitantes, con filtrado de contenido basado en categorías, bloqueo de amenazas en la capa de DNS y políticas que se pueden gestionar por red. Se puede implementar como un servicio independiente o integrarse con redes de Purple Access. Para los equipos que evalúan los controles de DNS en comparación con controles más amplios de tráfico web, una visión general de secure web gateway describe un nivel diferente de aplicación.
Poner a trabajar el reenvío en su red
El reenvío concentra parte de la carga de trabajo de DNS en los servicios ascendentes que selecciona una organización. Las mediciones realizadas con los conjuntos de datos Day in the Life de DNS-OARC revelaron que aproximadamente el 99% de los resolvers recursivos generaron volúmenes moderados de consultas, mientras que alrededor del 1% se comportó de forma agresiva. Ese grupo más pequeño representó hasta el 98% del tráfico DNS observado en 2018 y el 93% en 2019; los investigadores estimaron que incluía aproximadamente 8,300 resolvers en 2018 y más de 14,000 en 2019 (estudio sobre el comportamiento agresivo de los resolvers). Un resolver local puede enviar solicitudes a servicios recursivos ascendentes que almacenan en caché y reutilizan respuestas, pero eso concentra la dependencia en su disponibilidad y comportamiento.
Antes de implementar o cambiar el reenvío, verifique que:
- Los upstreams son independientes: Configure al menos dos reenviadores donde el diseño lo permita.
- Las fallas tienen una respuesta definida: Establezca el comportamiento de tiempo de espera y reintento, y sepa qué reciben los clientes si un upstream no responde.
- El monitoreo cubre los síntomas: Vigile las respuestas SERVFAIL, los tiempos de espera y la latencia de respuesta.
- Las expectativas de privacidad son claras: Decida qué resolvedor upstream puede ver las consultas reenviadas.
Si el filtrado de DNS forma parte de la política de su red de invitados, compárelo con su enfoque de filtrado de contenido de WiFi más amplio. Luego, audite a qué resolutor reenvía su red y confirme que su política, disponibilidad y postura de privacidad coincidan con lo que pretende.
Purple Shield verifica las búsquedas de DNS antes de que los dispositivos se conecten y ofrece filtrado de contenido y bloqueo de amenazas para redes WiFi de recintos y visitantes. Si está evaluando cómo el reenvío puede respaldar esos controles, visite Purple Shield para explorar sus opciones de implementación.