Glosario de DNS

¿Qué es el reenvío condicional de DNS?

Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Puntos claveLos puntos clave se generan con la ayuda de la inteligencia artificial. Dado que los resúmenes automáticos pueden contener en ocasiones errores u omitir contexto importante, consulta siempre la entrada completa del blog para obtener toda la información.

Conditional DNS forwarding is a DNS configuration technique that routes queries for specific domain names to designated DNS servers rather than using default resolvers, enabling organizations with multiple namespaces—such as those from mergers, hybrid cloud deployments, and partner connections—to resolve internal, partner, and cloud domains without copying zone data across systems. The mechanism compares incoming query names against configured domain suffixes and forwards matching queries to appropriate servers while resolving non-matching queries through the default path, with proper network reachability, consistent rule management, and security controls being critical to prevent timeouts, intermittent failures, and exposure of internal naming information. Common operational challenges include stale forwarding rules pointing to decommissioned servers, blocked forwarding paths due to firewall changes, inconsistent rules across multiple DNS servers, and overlapping domain rules that cause subdomains to resolve against servers lacking the necessary zone data.

  • Conditional forwarding differs from regular forwarders by applying forwarding behavior only to queries matching configured domain suffixes, allowing each domain to be routed to a different designated server while non-matching names follow the normal resolution path.
  • Stale forwarding rules, blocked network paths, inconsistent configurations across servers, and overlapping domain rules represent the primary failure modes that cause DNS timeouts, intermittent application outages, and NXDOMAIN responses in production environments.
  • Conditional forwarding operates using the recursive query model defined in RFC 1034 and RFC 1035, requiring the target server to accept recursive queries from the forwarder and necessitating direct testing of target servers and firewall rule verification to troubleshoot resolution failures.

El reenvío DNS condicional de un vistazo

AttributeValue
Full nameConditional DNS forwarding
CategoryDNS resolver configuration
Protocol and portDNS, typically UDP and TCP port 53
OSI layerLayer 7 (application)
Primary useResolving specific domains through designated DNS servers across separate networks and namespaces
Related termsDNS forwarder, recursive resolver, split-horizon DNS, authoritative DNS server, DNS zone

Cómo funciona el reenvío condicional de DNS

Un servidor DNS configurado con reenvío condicional compara cada nombre de consulta entrante con una lista de reglas de dominio. El resultado determina si el servidor reenvía la consulta o la resuelve normalmente.

  1. Recibir la consulta: un cliente envía una consulta recursiva a su servidor DNS configurado, por ejemplo, una solicitud de un nombre de host en un dominio asociado o interno.
  2. Coincidencia del dominio: el servidor compara el nombre consultado con sus dominios de reenvío configurados y selecciona el sufijo que mejor coincida.
  3. Reenviar la consulta: si se cumple una regla, el servidor envía la consulta a los servidores DNS indicados para ese dominio en lugar de utilizar su ruta predeterminada.
  4. Utilizar la ruta predeterminada: si ninguna regla coincide, el servidor resuelve el nombre como de costumbre, utilizando sugerencias de raíz o un redireccionador de uso general.
  5. Devolver la respuesta: el servidor retransmite la respuesta al cliente y puede almacenarla en caché según el tiempo de vida del registro.

Los pasos no abordan el comportamiento en caso de fallo. Los servidores difieren en cuanto a si recurren a la resolución predeterminada cuando un servidor designado no responde, y esa configuración afecta tanto a la fiabilidad como al lugar donde se exponen las consultas. Los destinos de reenvío también deben ser accesibles a través de la red, con reglas de enrutamiento y de cortafuegos que permitan el tráfico DNS.

Por qué es importante el reenvío condicional de DNS en las redes empresariales

Las organizaciones rara vez gestionan un único espacio de nombres. Las fusiones, la nube híbrida, las conexiones con socios y las zonas privadas añaden dominios a los que el resolutor predeterminado no puede dar respuesta. El reenvío condicional permite que cada uno de esos espacios de nombres se resuelva a través del servidor que alberga sus datos, sin necesidad de copiar los datos de la zona entre sistemas ni de sustituir la infraestructura DNS existente.

Desde el punto de vista operativo, las reglas de reenvío son una configuración que tiende a dispersarse por muchos servidores y a desajustarse con el tiempo. Una regla obsoleta que apunta a un servidor fuera de servicio provoca tiempos de espera y fallos intermitentes que los usuarios interpretan como interrupciones en el servicio de las aplicaciones. El comportamiento de los «stubs» de DNS y del reenvío se basa en el modelo de consulta recursiva descrito en los RFC 1034 y RFC 1035, por lo que la resolución de problemas implica rastrear qué servidor recibió una consulta y adónde se envió. Una gestión coherente de las reglas y la supervisión de los destinos de reenvío reducen este riesgo.

La seguridad es importante porque las consultas reenviadas salen del resolutor local y pueden atravesar redes en texto sin cifrar. El envío de nombres de dominio internos a un servidor externo o no fiable puede revelar la nomenclatura interna. Las reglas deben especificar únicamente destinos de confianza, limitar el reenvío de zonas privadas a rutas internas y restringir qué redes pueden acceder a dichos servidores. El cifrado del transporte entre resolutores, cuando sea compatible, reduce aún más la exposición.

Comparación del reenvío condicional de DNS con términos relacionados

Reenvío DNS condicional frente a servidor DNS de reenvío

Un servidor DNS de reenvío pasa las consultas que no puede responder a otro resolutor, mientras que el reenvío condicional aplica ese comportamiento solo a los nombres que coinciden con los dominios configurados. ¿Qué es un servidor DNS de reenvío?

AttributeConditional DNS forwardingForwarding DNS server
ScopeApplies only to queries matching listed domain suffixesTypically applies to all queries not answered locally
DestinationCan differ for each domainUsually one set of upstream resolvers
Typical useReaching internal, partner or cloud namespacesOffloading recursion to an upstream resolver
FallbackNames with no matching rule resolve by the default methodUpstream resolver is the default path for unresolved names

Reenvío DNS condicional frente a DNS de horizonte dividido

El reenvío condicional dirige las consultas a diferentes servidores según el nombre de dominio, mientras que el DNS de horizonte dividido devuelve respuestas diferentes para el mismo nombre dependiendo de quién lo solicite. ¿Qué es el DNS de horizonte dividido?

AttributeConditional DNS forwardingSplit-horizon DNS
Decision basisQueried domain nameSource of the query, such as internal or external client
What changesWhich server answersWhich answer the client receives
Data locationZone data stays on the target serverSeparate views or zones hold different data for one name

Problemas habituales con el reenvío condicional de DNS

Una regla sigue apuntando a un servidor fuera de servicio o renumerado. Las consultas para ese dominio agotan el tiempo de espera, y los usuarios informan de aplicaciones lentas o que fallan, mientras que otros nombres se resuelven con normalidad.

Un cortafuegos o un cambio en el enrutamiento bloquea el tráfico DNS desde el servidor de reenvío hacia el destino, a menudo en el puerto UDP o TCP 53. Las respuestas de gran tamaño que requieren TCP fallan en primer lugar, lo que hace que el síntoma sea intermitente.

Las reglas se añaden en algunos servidores DNS, pero no en otros. El mismo nombre se resuelve desde un sitio y falla desde otro, dependiendo del resolutor que utilice el cliente.

Dos servidores se reenvían mutuamente un dominio, o un destino lo reenvía de vuelta al origen. Las consultas rebotan hasta que se agota el tiempo de espera, y la carga del resolutor aumenta con las respuestas SERVFAIL.

Una regla de sufijo amplia y otra más restrictiva apuntan a servidores diferentes, y los administradores esperan que prevalezca la incorrecta. Los subdominios se resuelven entonces en un servidor que carece de la zona y devuelven NXDOMAIN.

Descubre cómo el DDI unificado simplifica las operaciones de red

Gestiona el DNS, el DHCP y las direcciones IP desde una única plataforma con automatización, visibilidad y control integrados.

Preguntas frecuentes sobre el reenvío condicional de DNS

Términos relacionados

Network visualization showing IP addresses and interconnected nodes representing IPAM infrastructure and data flow

Establecimiento de modelos de flujo de trabajo y aprobación de IPAM regulados y preparados para auditorías para las redes de la organización

Descubre soluciones de gestión de direcciones IP para flujos de trabajo de IPAM regulados y preparados para auditorías. Habilita aprobaciones por ámbitos…

Read more
Content Hub

Comprender el modelo OSI: dónde encajan el DNS y el direccionamiento IP dentro de las 7 capas

Comprende las siete capas del modelo OSI y cómo encajan en ellas el DNS y el direccionamiento IP. Aprende los fundamentos de la arquitectura de redes con…

Read more
Fiber optic cables with glowing blue and cyan light points representing high-speed network data transmission and connectivity

Escalabilidad del DNS y la gestión de direcciones IP (IPAM) para redes empresariales IPv6 y de doble pila

Amplíe el DNS y el IPAM para redes empresariales de doble pila. Descubra cómo Micetro ayuda a los equipos a gestionar las migraciones a IPv6 con sistemas…

Read more
Hand holding digital pen interacting with holographic network diagrams and data visualization on laptop screen, representing

Integración de DNS, DHCP e IPAM en flujos de trabajo de infraestructura como código basados en Ansible y Git

La integración de DNS, DHCP e IPAM en los flujos de trabajo de IaC basados en Ansible y Git con Micetro convierte los cambios de direcciones y registros en…

Read more
Podcast

Podcast: Cómo la IA está cambiando el desarrollo de software empresarial

La IA transforma la automatización de redes, pero una implementación segura requiere sólidas prácticas de software, pruebas y experiencia en el ámbito…

Read more
Podcast

Podcast: Por qué las plataformas abiertas son importantes en las operaciones de red

Las plataformas abiertas y la arquitectura «API-first» permiten operaciones de red inteligentes, automatización y flujos de trabajo impulsados por IA en…

Read more
Network engineer reviewing LiveNX flow and telemetry data visualized across server racks in a hybrid multicloud environment

Obtenga respuestas a partir de los datos de LiveNX que ya tiene con LiveAssist

Descubre cómo LiveAssist, el complemento basado en IA para LiveNX, convierte tus datos de red en respuestas rápidas y guiadas, con un valor que podrás…

Read more
LiveWire GEN3 device offerings overview with descriptions of deep packet visibility and deployment options

Oferta de dispositivos LiveWire GEN3

BlueCat LiveWire es una plataforma de captura de paquetes y análisis forense de redes que ofrece una visibilidad profunda a nivel de paquetes en entornos…

Read more

Artículos relacionados