¿Qué es el reenvío de DNS? Cómo funciona y por qué es importante
¿Qué es el reenvío de DNS? Descubra en qué se diferencian los reenviadores de los resolutores recursivos, cómo funcionan la memoria caché y la conmutación por error, y qué lugar ocupa el reenvío en las redes modernas.
Published 23 de octubre de 2026
El reenvío de DNS es el proceso mediante el cual 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 de la cadena superior realiza la búsqueda completa cuando es necesario. Pero si ese servidor de la cadena superior falla, ¿qué parte del DNS se ha roto?
Esa distinción es importante cuando estás configurando una red o intentando explicar por qué no se carga un sitio web. Un resolver de reenvío no se limita a transmitir paquetes: puede responder localmente a solicitudes conocidas, dirigir consultas seleccionadas a diferentes servidores y definir qué resolver ve el tráfico DNS de un usuario.
Índice de contenidos
- Qué significa realmente el reenvío de DNS
- Seguimiento de una consulta desde el cliente hasta la respuesta
- Diferencias entre reenvío, recursión y servicio autoritativo
- Reenvío condicional, Split Horizon y prevención de bucles
- Cómo afectan la caché y el TTL al rendimiento del reenvío
- Elección entre reenvío, recursión mediante Root-Hints y DNS cifrado
- Cómo implementar el reenvío en su red
Qué significa realmente el reenvío de DNS
Imagine el resolutor local como la recepción de una oficina de correos. Un cliente solicita un sitio web por su nombre y el resolutor comprueba si ya conoce la respuesta. Si tiene una respuesta válida en su caché, la devuelve. Si no, envía la consulta a un servidor DNS ascendente, el agente de reenvío, que gestiona la búsqueda y devuelve una respuesta.
Esa disposición separa dos tareas. El resolutor local interactúa con 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 un producto de seguridad de forma automática.
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, cada vez más inmanejable. Antes de 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 estándares fundamentales para la arquitectura DNS moderna, tal como registra la cronología de la historia de DNS.
Dónde se encontrará con el reenvío
Los routers domésticos, las redes corporativas, el WiFi público, los colegios y los entornos en la nube pueden utilizar el reenvío. Una organización puede emplearlo para enviar búsquedas generales de internet a un servicio recursivo gestionado, manteniendo al mismo tiempo el control local sobre la caché, el registro, los nombres internos o las reglas de bloqueo.
El modelo mental útil es sencillo: 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 puede llegar con éxito a la recepción incluso si el resolutor ascendente no está disponible o devuelve un error.
Seguimiento de una consulta desde el cliente hasta la respuesta
Una búsqueda típica comienza cuando un dispositivo solicita un nombre a su resolver local. El resolver comprueba primero su caché. Si la respuesta almacenada sigue siendo válida, puede devolverla sin contactar con un servidor ascendente. Si no hay una respuesta útil en caché, el resolver reenvía la consulta a un resolver recursivo ascendente.
En la terminología de DNS, el reenvío implica que un resolutor envía una consulta con el bit de recursión deseada (RD) activado. Ese bit indica que se le está pidiendo al resolutor 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 se produce un fallo de caché, el resolutor recursivo ascendente realiza el trabajo de búsqueda. Puede utilizar su propia caché o consultar a través de la jerarquía DNS para obtener la respuesta. A continuación, la respuesta vuelve al cliente a través del resolutor de reenvío.
Las dos rutas posibles
- Acierto de caché (cache hit): El resolver local devuelve una respuesta válida guardada en caché. El servidor ascendente no interviene en esa búsqueda.
- Fallo de caché (cache miss): El resolver local envía la consulta al servidor ascendente, recibe la respuesta y se la devuelve al cliente.
La transferencia también define una división de responsabilidades muy útil. El resolver local puede aplicar controles específicos de la red, mantener registros, usar reglas de DNS dividido o aplicar una directiva de validación DNSSEC. El resolver ascendente realiza la búsqueda recursiva cuando el resolver local no puede responder a partir de su caché o sus datos locales.
Pista para la resolución de problemas: Si el resolutor local responde a los clientes pero las búsquedas fallan cuando su caché no contiene la respuesta, compruebe la ruta de reenvío y la respuesta ascendente antes de asumir que el servicio DNS autoritativo es el culpable.
En qué se diferencia el reenvío de la recursión y del servicio autoritativo
El reenvío de DNS, la recursividad, el proxy y el servicio autoritativo describen funciones diferentes. Un único sistema puede asumir más de una función, 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 directivas; un resolutor recursivo ascendente realiza la resolución en caso de fallos de caché.
| Rol | Quién lo inicia | Realiza la búsqueda completa | Contiene datos autoritativos | Síntoma típico de fallo |
|---|---|---|---|---|
| Reenviador | Un resolutor local le envía una consulta | Normalmente, cuando actúa como resolutor recursivo ascendente | No necesariamente | Tiempo de espera agotado o error del servicio ascendente |
| Resolutor recursivo | Un cliente u otro resolutor 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 por naturaleza; el retransmisor proxy reenvía solicitudes según su diseño | No | La solicitud a través de proxy falla o no puede alcanzar su destino |
| Servidor autoritativo | Un resolutor lo consulta para un dominio que administra | No, proporciona datos para su zona | Sí, para las zonas que administra | Registros no encontrados, 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 a servidores autoritativos. Un servidor autoritativo proporciona registros para el dominio que gestiona en lugar de buscar en la jerarquía en nombre de un cliente.
Por qué esta distinción cambia la resolución de problemas
Un resolvedor de reenvío puede devolver un tiempo de espera agotado en la cadena superior (upstream timeout), un error SERVFAIL o una respuesta almacenada en caché que ya no sea adecuada, incluso cuando la infraestructura de DNS autoritativo funcione normalmente. Resolver problemas únicamente en el servidor autoritativo en esa situación puede llevarle por el camino equivocado. Compruebe qué resolvedor recibió la solicitud, si tenía una respuesta en caché y qué ocurrió en el siguiente salto.
También existe una dependencia de confianza. El RFC 7719 aborda la terminología de los resolutores, incluida la distinción entre reenviadores y resolutores recursivos. Las investigaciones sobre ataques de envenenamiento de caché distinguen estos roles porque un reenviador depende de la integridad del resolutor 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 directivas 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 gestionado.
Un concepto relacionado es el DNS de horizonte dividido (split-horizon DNS). Permite que una red devuelva respuestas diferentes para el mismo nombre según la procedencia de la solicitud. Un usuario 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é resolutor es propietario de cada ruta de consulta. Una regla que envíe un nombre interno al servidor ascendente incorrecto puede producir una respuesta externa, un fallo en la resolución o un resultado que varíe entre distintas partes de la red.
Prevención de bucles de resolutores
Un bucle de reenvío ocurre cuando un resolver envía una consulta a un segundo resolver que, eventualmente, se la devuelve. La consulta puede circular entre servidores, lo que provoca solicitudes repetidas, tiempos de espera agotados y saturación de recursos. La solución consiste en mapear las rutas de reenvío y asegurarse de que ninguna cadena de resolvers apunte de nuevo a un servidor anterior.
Algunos nombres también necesitan un límite explícito. RFC 9539 señala espacios de nombres como home.arpa que no deben reenviarse más allá de su ámbito local previsto. Un resolutor que funciona hasta que se añade un segundo reenviador puede haber adquirido un bucle; un nombre local que comienza a resolverse públicamente puede necesitar una regla de zona local o de reenvío más específica.
El siguiente vídeo ofrece otra introducción visual a los conceptos de reenvío de DNS.
Cómo influyen la memoria caché y el TTL en el rendimiento del reenvío
La caché de un reenviador funciona como la memoria de un intermediario servicial: una vez que ha obtenido una respuesta de la cadena superior, puede responder por sí solo a la siguiente pregunta idéntica. Ese único comportamiento explica la mayor parte del impacto del reenvío en el rendimiento. Cada acierto de caché elimina un viaje de ida y vuelta al resolvedor de la cadena superior. Cada fallo añade 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 solo puede reutilizar la respuesta almacenada en caché mientras siga siendo válida. Los TTL cortos mantienen las respuestas actualizadas pero envían más consultas hacia la cadena superior. Los TTL largos reducen el tráfico hacia la cadena superior, pero pueden hacer que los clientes conserven direcciones obsoletas tras un cambio de infraestructura.
El almacenamiento en caché también se acumula a lo largo de la ruta. Una consulta se puede responder desde la caché del cliente, la caché del reenviador o la caché del resolvedor de la cadena superior, y cada capa ejecuta su propia cuenta atrás de TTL. Cuando un usuario informa de una respuesta desactualizada, la solución depende de qué capa la esté reteniendo, por lo que debe tratar cada caché como un sospechoso independiente durante la resolución de problemas en lugar de vaciar lo que tenga más cerca.
Mida algo más que la latencia media
El tiempo medio de búsqueda puede ocultar problemas que afectan a algunos usuarios o consultas más que a otros. Realice un seguimiento de la tasa de aciertos en caché, la latencia de búsqueda mediana y extrema, la tasa de tiempos de espera ascendentes y el comportamiento de la caché negativa. Estas métricas ayudan a distinguir un servicio ascendente lento de un reenviador que pierde constantemente oportunidades de caché o gestiona mal las búsquedas fallidas.
DNSSEC añade otra complicación. Un resolver con validación obtiene firmas y claves además de la propia respuesta, por lo que los fallos de caché en nombres firmados cuestan más que los fallos en nombres no firmados. Las respuestas validadas en caché evitan repetir ese trabajo, lo que hace que la tasa de aciertos sea aún más importante 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 de la cadena superior, el trabajo de validación, la configuración del transporte y reintentos tras un reenviador que no responde. Un reenviador con un comportamiento correcto también transmite los códigos de respuesta, el comportamiento de truncamiento, los registros DNSSEC y los indicadores sin cambios, de modo que los clientes ven la respuesta que envió el lado autoritativo.
Elección entre reenvío, recursión de pistas raíz y DNS cifrado
El reenvío y la recursión con indicadores raíz (root-hints) implican diferentes ventajas y desventajas. Con el reenvío, una organización selecciona resolutores de origen para gestionar las consultas no respondidas. Eso puede simplificar las operaciones locales y centralizar las directivas, pero hace que la red dependa de los servicios de origen elegidos. Con la recursión con indicadores raíz, un resolutor realiza la búsqueda iterativa por sí mismo, lo que reduce la dependencia de un único servicio recursivo de origen, pero asigna más responsabilidad de resolución a ese resolutor.
| Opción de diseño | Dónde se realiza la resolución | Principal compromiso operativo |
|---|---|---|
| Reenvío | En el resolutor recursivo ascendente seleccionado | Administración centralizada, con una dependencia ascendente |
| Recursión con root-hints | En el resolutor recursivo local, que realiza consultas 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 resolutor con el que contacta el cliente a través de una conexión cifrada | Es posible que la red local no vea ni controle la consulta de dominio |
El cifrado de DNS hace que la decisión sea menos sencilla. DNS over TLS y DNS over QUIC pueden proteger el tráfico DNS en tránsito, pero la cuestión importante es dónde finaliza el cifrado. Si un cliente cifra las consultas directamente hacia un resolutor externo, es posible que un reenviador local no vea una consulta de dominio utilizable. Si el cifrado finaliza en un resolutor empresarial aprobado, ese resolutor aún puede aplicar directivas de red y reenviar consultas hacia los servidores de origen.
El WiFi público requiere una directiva deliberada
Los operadores de WiFi público también deben tener en cuenta los Captive Portals. Es posible que los dispositivos necesiten resolución de nombres previa a la autenticación y comprobaciones 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 alternancia 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 contenidos basado en categorías, bloqueo de amenazas en la capa DNS y directivas 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 DNS frente a controles de tráfico web más amplios, una visión general de secure web gateway describe una capa de aplicación diferente.
Cómo poner a funcionar 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 que utilizan los conjuntos de datos Day in the Life de DNS-OARC revelaron que aproximadamente el 99 % de los resolutores recursivos generaban volúmenes de consultas moderados, mientras que alrededor del 1 % se comportaba 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 8300 resolutores en 2018 y más de 14 000 en 2019 (estudio sobre el comportamiento agresivo de los resolutores). Un resolutor local puede enviar solicitudes a servicios recursivos ascendentes que almacenan en caché y reutilizan las respuestas, pero eso concentra la dependencia en su disponibilidad y comportamiento.
Antes de desplegar o modificar el reenvío, compruebe que:
- Los servidores de origen son independientes: configure al menos dos reenviadores cuando el diseño lo permita.
- Los fallos tienen una respuesta definida: establezca el comportamiento de tiempo de espera y reintentos, y sepa qué reciben los clientes si un servidor de origen no responde.
- La supervisión cubre los síntomas: observe las respuestas SERVFAIL, los tiempos de espera y la latencia de respuesta.
- Las expectativas de privacidad son claras: decida qué resolutor de origen puede ver las consultas reenviadas.
Si el filtrado de DNS forma parte de la directiva de su red de invitados, compárelo con su enfoque de filtrado de contenido de WiFi más amplio. A continuación, audite a qué resolutor reenvía su red y confirme que su directiva, disponibilidad y postura de privacidad se ajustan a lo que busca.
Purple Shield comprueba las búsquedas DNS antes de que los dispositivos se conecten y ofrece filtrado de contenidos y bloqueo de amenazas para redes WiFi de recintos y de invitados. Si estás revisando cómo el reenvío puede respaldar estos controles, visita Purple Shield para explorar sus opciones de despliegue.