Reenvío inteligente

Cómo funciona

Cuando Edge recibe una consulta DNS, determina la zona de la que debe seleccionar el espacio de nombres DNS adecuado. Para ello, tiene en cuenta la zona de destino correspondiente, la IP o red de origen, las políticas de seguridad y el orden de prioridad de los reenviadores.

Tras determinar la zona, Edge selecciona el espacio de nombres DNS adecuado (o los espacios de nombres adecuados) para la resolución. Una vez que Edge determina un conjunto de reenviadores potenciales a los que consultar, prueba cada espacio de nombres seleccionado por orden, buscando una respuesta válida. Si el resolutor recibe una respuesta negativa de un espacio de nombres, recordará la respuesta y pasará al siguiente espacio de nombres, intentando resolver la consulta de nuevo hasta que reciba una respuesta positiva. Si se agotan todos los espacios de nombres sin obtener una respuesta positiva, se devuelve una respuesta negativa al cliente.

Para aprovechar el reenvío inteligente, se configura un espacio de nombres con uno o más reenviadores DNS y, opcionalmente, puede incluir listas de dominios de coincidencia y de excepción. Cada sitio de Edge tiene al menos un espacio de nombres asociado, hasta un máximo de 10. Las cachés de DNS se segmentan por espacios de nombres para evitar respuestas mixtas procedentes de diferentes rutas de resolución. Edge puede optimizar al máximo el rendimiento de las consultas y mantener los estados entre diversas autoridades DNS para garantizar una experiencia óptima para el cliente.

Los espacios de nombres también permiten el solapamiento de zonas. Se pueden añadir o modificar registros individuales en una zona de un servidor autoritativo sin necesidad de que todos los registros de recursos de dicha zona estén disponibles. Los entornos dinámicos, como la computación en la nube, requieren solapamiento de zonas, ya que diferentes redes pueden utilizar la misma zona pero necesitan respuestas distintas para subconjuntos de registros. A diferencia de las reglas de reenvío condicional tradicionales u otras soluciones de resolución, las políticas de reenvío de Edge proporcionan esta flexibilidad con una administración sencilla y facilitan la gestión de los registros de recursos DNS.

Figura 1. Un entorno de red que cuenta con recursos en AWS y Azure y que tiene un dominio llamado xyz.com. Si ninguna de las consultas coincide, se reenviará a un resolutor externo.

Nueve tipos de casos de uso

En esta sección se describen nueve casos prácticos que demuestran las ventajas de utilizar el reenvío inteligente de Edge para ampliar el reenvío DNS tradicional y obtener un mayor control sobre la resolución en entornos híbridos y distribuidos.

Caso de uso 1: Zonas DNS de vista dividida

Las empresas suelen utilizar vistas diferentes de la misma zona para el DNS privado y el público. Esto permite que los mismos servicios, con los mismos nombres, puedan resolverse tanto a nivel interno como externo. La vista dividida (a menudo denominada «split brain» o «split horizon») permite gestionar cada vista por separado, como si se tratara de zonas diferentes.

Sin embargo, los registros de recursos de la vista de la zona externa también deben mantenerse en la vista interna. Esto da lugar a errores. Las empresas han intentado resolver esto utilizando proxies web para arbitrar las ubicaciones de los servicios. En algunos entornos, una «raíz interna» anula la zona raíz pública, segmentando por completo estos espacios de nombres DNS. El paso al acceso directo a Internet rompe este sistema, dejando a las empresas sin una forma de resolver los registros de vista dividida.

Edge interviene a nivel de DNS para gestionar las vistas divididas de las zonas DNS. Los clientes pueden resolver múltiples vistas y utilizar el acceso directo a Internet para las zonas que se encuentran fuera de la infraestructura DNS corporativa.

Cómo ayuda Edge: El reenvío inteligente le permite crear dos espacios de nombres para xyz.com: uno interno y otro externo. Edge sigue intentando la resolución tras una respuesta negativa para garantizar que esta se realice con éxito. Una consulta destinada a xzy.com tendría una zona coincidente que indicaría que debe consultarse tanto en el espacio de nombres interno como en el externo de xyz.com, devolviendo la respuesta externa solo si no se encuentra ninguna respuesta interna. Esto elimina la necesidad de gestionar un DNS de vista dividida.

Figura 2: Cuando un entorno tiene los mismos nombres de dominio internos y externos, el mayor reto suele ser garantizar que se utilice la ruta de resolución correcta.

Caso de uso 2: Mitigación de los riesgos de interrupción del servicio durante la migración

La mayoría de las migraciones de DNS utilizan períodos de transición planificados para migrar los datos. Una de las principales preocupaciones de las organizaciones es el riesgo de interrupciones del servicio durante la migración. Cada evento de migración (algunas migraciones abarcan más de 50 eventos a lo largo de varios años) conlleva el riesgo de que la falta de datos DNS o una configuración errónea de los mismos en el nuevo entorno pueda provocar una interrupción del servicio. Mitigar ese riesgo es fundamental.

Cómo ayuda Edge: Durante la migración a Integrity, puede utilizar el reenvío inteligente para crear una infraestructura DNS resiliente. De este modo se evitan las interrupciones del servicio causadas por registros DNS que faltan o están mal configurados. Edge consulta primero la nueva infraestructura de BlueCat. Si la respuesta es negativa, consulta entonces el servidor DNS heredado.

Figura 3: Estado inicial típico al utilizar Edge con una migración de DNS tradicional.

Caso de uso 3: Migración sigilosa para una finalización más rápida y un menor riesgo de interrupciones del servicio

Es posible migrar el DNS sin tiempo de inactividad. Sin embargo, puede resultar lento, laborioso, arriesgado y costoso, dependiendo de su infraestructura y de su tolerancia a las interrupciones del servicio. Antes de la mayoría de las migraciones, debe dedicar un esfuerzo considerable a depurar los datos DNS existentes para garantizar que solo se transfieran al nuevo entorno los registros precisos y relevantes.

Con Edge, las organizaciones pueden migrar desde entornos DNS heredados a la infraestructura DNS de Integrity de forma programada, pasiva y eficiente.

Durante la fase inicial del proceso de migración sigilosa de BlueCat, Edge se configura para reenviar las consultas DNS al entorno DNS heredado. Los registros devueltos por la infraestructura heredada se recrean y se copian en la nueva infraestructura DNS de BlueCat. Las consultas que reciben una respuesta negativa se reenvían a la nueva infraestructura DNS de BlueCat.

Tras un periodo determinado, se intercambiará el orden de los espacios de nombres. De este modo, la nueva infraestructura de BlueCat pasa a ser la principal para las consultas DNS. Cualquier consulta que reciba una respuesta negativa de BlueCat se reenviará entonces a la infraestructura DNS heredada. A continuación, el registro de cualquier consulta resuelta por la infraestructura DNS heredada se recreará en la nueva infraestructura DNS de BlueCat.

Cómo ayuda Edge: una migración sigilosa utiliza el registro de consultas de Edge para migrar los datos a medida que se consultan los registros. Al aprovechar los espacios de nombres, puede migrar registros sobre la marcha, lo que permite que la resolución continúe y elimina la necesidad de una transición tradicional.

Figura 4: Estado inicial típico al utilizar Edge con una migración sigilosa del DNS.

Figura 5: Un estado final típico al utilizar Edge con una migración sigilosa del DNS.

Caso de uso 4: Integración de redes a través del DNS para fusiones y adquisiciones

Integrar una fusión o adquisición en su infraestructura supone un reto. Las interrupciones del servicio u otros problemas causados por conflictos de nombres, solapamiento de espacios IP o reglas de reenvío complejas suelen requerir una intervención manual.

Edge permite que las consultas procedentes de redes heredadas y adquiridas eviten fallos de resolución al consultar directamente a los servidores DNS autoritativos. Esto ayuda a los equipos de red a identificar y resolver los datos del DNS. Junto con el proceso de migración sigilosa descrito anteriormente, esto permite una rápida fusión de los datos del DNS, al tiempo que se mantiene un enfoque pasivo y de bajo riesgo.

Cómo ayuda Edge: Los administradores pueden utilizar listas de dominios para configurar Edge de modo que enrute las solicitudes de los clientes al servidor DNS adecuado. A continuación, Edge utiliza la migración DNS sigilosa para transferir únicamente datos relevantes y precisos entre organizaciones. Tras la migración, se actualiza el orden de los espacios de nombres para garantizar rutas de resolución óptimas.

Caso de uso 5: Optimización de la ruta de las consultas DNS

En las redes tradicionales de tipo «hub-and-spoke», todo el tráfico no local se redirige a un centro de datos central. Esto suele provocar problemas de localización de las respuestas a las consultas DNS y puede saturar los circuitos WAN, que ya están muy utilizados y son costosos.

Edge optimiza la ruta de sus consultas DNS. Esto le permite adquirir routers más pequeños de los que necesitaría con el tráfico adicional, lo que reduce los requisitos de infraestructura en las sucursales y el gasto global en la WAN. Una ruta de consulta optimizada también ofrece ventajas ocultas, como una menor latencia y un acceso sin restricciones para el usuario final a servicios más localizados.

Por ejemplo, los servidores envían consultas a la zona store301.xyz.com de forma local, evitando el tráfico de retorno al centro de datos principal. El tráfico dirigido a servicios externos predefinidos y de confianza, como Office 365, se enruta directamente a un resolutor externo local a través de la conexión del proveedor de servicios de Internet (ISP) de la sucursal. Esto mejora el rendimiento, reduce los costes de la WAN y ofrece respuestas DNS más localizadas.

Cómo ayuda Edge: La configuración de Edge con listas de coincidencia de dominios o zonas para un espacio de nombres optimiza el enrutamiento de las consultas. Esto evita problemas de localización y reduce el exceso de tráfico DNS en los enlaces WAN.

Figura 6: Uso de Edge para proporcionar salida local a servicios de confianza, al tiempo que se garantiza que la resolución local se produzca correctamente.

Caso de uso 6: Creación de una única fuente de verdad para la integración del DNS en la nube

El DNS nativo de la nube suele gestionarse como un componente aislado. Esto impide que una única solución de DNS sea la única fuente de información fiable de la red. Para garantizar que la resolución DNS siga funcionando, los entornos de nube híbrida introducen

reglas de reenvío complejas, lo que da lugar a un enrutamiento ineficiente del tráfico de red a través de VPN o conexiones de red dedicadas. Los clientes que se pasen a una solución multicloud también se enfrentarán a complejas reglas de reenvío entre nubes. Además, las migraciones y las implementaciones en la nube pueden provocar problemas de resolución y rendimiento del DNS que son difíciles de depurar sin una visibilidad completa.

Con Edge, todo el tráfico DNS centrado en la nube se enruta a un resolutor DNS local, que determina cuál es el resolutor más adecuado al que reenviarlo. Los equipos de red pueden gestionar tanto el DNS en la nube como el local desde un único panel de control.

Los servicios de enlaces privados en las principales nubes suelen compartir zonas entre nubes privadas virtuales (VPC) o redes virtuales (VNet). Sin embargo, dado que Edge puede resolver en zonas superpuestas, los registros específicos de enlaces privados se resuelven correctamente.

Todos los datos de resolución están disponibles para su auditoría y depuración. Se realiza un seguimiento del origen de cada consulta y se dispone de una visibilidad completa de la latencia y otros datos de rendimiento.

La computación en la nube suele dividirse en servicios segmentados con un uso predecible del DNS. Esto ofrece amplias oportunidades para segmentar el DNS mediante políticas de acceso a servicios remotos o para reducir el riesgo de que los sistemas sean objeto de ataques que utilicen el DNS con fines de comando y control.

Cómo ayuda Edge: Con Edge, puede configurar los espacios de nombres de dos formas. En primer lugar, puede utilizar una lista de dominios que incluya el nombre de dominio adecuado para su proveedor de nube. El segundo método consiste en configurar los espacios de nombres en un orden de prioridad que busque primero el tráfico intra-VPC o intra-VNet, luego el de las VPC o VNet de servicios compartidos y, por último, el del DNS local.

Figura 7: Una configuración típica de integración en la nube. Las consultas se dirigen a la VPC o VNet, luego a una VPC o VNet de servicios compartidos y, a continuación, al DNS local.

Caso de uso 7: Omisión del proxy y acceso directo a Internet

Los servidores proxy suelen estar ubicados de forma centralizada en los centros de datos principales para optimizar los costes. Por lo tanto, el tráfico destinado a Internet se ve obligado a pasar por ubicaciones centrales, lo que a menudo puede provocar una localización inexacta del servicio, una alta latencia y una mala experiencia de usuario. La centralización de los servidores proxy complica aún más las conexiones locales a Internet en las oficinas remotas y sucursales.

Con Edge, puede garantizar que los clientes resuelvan todas las consultas, tanto internas como externas, habilitar la salida local para el acceso directo a Internet a servicios de confianza y mantener el control y la supervisión que requieren los equipos de seguridad.

Cómo ayuda Edge: Con los espacios de nombres de Edge, puede configurar el tráfico DNS para que consulte un resolutor interno, externo o basado en Internet en función del nombre de dominio de destino. Edge también se implementa en oficinas remotas o sucursales para proporcionar salida local.

Figura 8: Una configuración típica para el bypass del proxy con acceso directo a Internet desde una sucursal remota.

Caso de uso 8: Protección de dispositivos IoT

Las actualizaciones poco frecuentes y/o la falta de parches de seguridad para los dispositivos del Internet de las cosas (IoT) los hacen vulnerables a los ciberataques. Aunque los dispositivos IoT se gestionan en gran medida como cualquier otro nodo de la red, su naturaleza suele dar lugar a una supervisión insuficiente de su actividad. Esto, junto con el hecho de que muchos tienen acceso sin restricciones a los datos del DNS, los convierte en un objetivo lucrativo para los ciberdelincuentes.

Con Edge, puede restringir el acceso al DNS de los dispositivos IoT a registros específicos preaprobados y aplicarles políticas de seguridad, incluso cuando los controles tradicionales, como los agentes de seguridad, no estén disponibles.

Cómo ayuda Edge: Con Edge, puede implementar configuraciones DNS específicas y políticas de seguridad para gestionar de forma centralizada los dispositivos IoT. Las políticas DNS se aplican para permitir el acceso únicamente a servicios internos y externos predefinidos. Mediante los espacios de nombres, también puede especificar a qué dispositivos pueden realizar consultas los dispositivos IoT.

Figura 9: A los dispositivos IoT solo se les permite utilizar determinados servidores DNS seguros. Todo lo demás queda bloqueado.

Caso de uso 9: Ampliar Cisco Secure Access con visibilidad de las fuentes de las consultas IP

Cisco Secure Access proporciona resolutores basados en la nube para identificar y bloquear consultas asociadas a amenazas específicas. Uno de los inconvenientes de esta solución es que todas las solicitudes DNS deben pasar por los servidores DNS internos antes de llegar al sistema recursivo externo de Cisco Secure Access. Debido a ello, Cisco Secure Access pierde la dirección IP de origen del cliente para las consultas, lo que da lugar a puntos ciegos en la red interna.

Cómo ayuda Edge: BlueCat colabora en exclusiva con Cisco Secure Access para la protección frente a amenazas de DNS de cara al exterior. Edge reenvía las consultas DNS externas directamente a Cisco Secure Access para su filtrado, al tiempo que conserva la IP de origen del cliente mediante EDNS Client Subnet. Cuando el servicio de identidad está habilitado, las consultas se enriquecen con información de identidad del usuario procedente del proveedor de identidad de la organización, lo que permite a los administradores de Cisco Secure Access ver y actuar tanto sobre la IP de origen como sobre el ID de usuario de cada consulta, mejorando así la visibilidad y la aplicación de las políticas.

Figura 10: Configuración utilizada cuando se tiene el mismo dominio tanto a nivel interno como externo. Si la consulta tiene como destino Internet, se reenvía a Cisco Secure Access.