¿Cómo se automatiza la conmutación por error basada en DNS para servicios críticos en entornos híbridos y en la nube?
automatización de DDIDDI unificado/BlueCat/
Updated
La conmutación automática por error del DNS tiene tres componentes: métodos de disponibilidad superpuestos en el fondo, contenido de la zona replicado en todos los proveedores que responden al dominio y automatización que reduce el tiempo entre la detección de un fallo y el cambio de la respuesta. Lo que las une es un plano de control que mantiene el registro de lo que debe existir y dónde. BlueCat ofrece dos vías para lograrlo: Micetro orquesta los servicios de DNS, BIND y DHCP de Microsoft que ya están en funcionamiento, e Integrity consolida DNS, DHCP e IPAM en una única plataforma.
¿Por qué un único servidor DNS pone en riesgo todos los servicios de la red?
Disponer de un único servidor DNS supone un punto único de fallo.
Cuando deja de responder, la resolución de nombres se detiene y la red y cualquier sitio web de acceso público quedan inaccesibles, independientemente del estado de los servidores subyacentes.
La alta disponibilidad tiene como objetivo garantizar un nivel de rendimiento operativo o de tiempo de actividad y, en muchos casos, un acuerdo de nivel de servicio exige un porcentaje específico. La configuración que lo garantiza debe ser tanto redundante como resiliente, con la conmutación por error preparada antes de que se produzca el fallo, en lugar de organizarse durante el mismo.
Existen cuatro vías para lograr una alta disponibilidad en los servicios DNS: conmutación por error de hardware, redundancia del protocolo DNS, arquitectura distribuida y comprobaciones de estado del equilibrador de carga. El hardware redundante toma el relevo automáticamente en la misma ubicación. La redundancia del protocolo DNS permite a los clientes probar con otro servidor. La arquitectura distribuida implica que la interrupción de un único servidor no afecta al servicio. Las comprobaciones de estado del equilibrador de carga retiran de la rotación cualquier destino que no esté en buen estado antes de que los clientes lleguen a él. Cada una tiene sus limitaciones, por lo que deben combinarse, y la automatización se sitúa por encima de las cuatro en lugar de sustituir a ninguna de ellas.
4
4
Existen cuatro vías para lograr una alta disponibilidad en los servicios DNS: conmutación por error de hardware, redundancia del protocolo DNS, arquitectura distribuida y comprobaciones de estado del equilibrador de carga. Juntas forman una red de seguridad superpuesta que ningún método por sí solo puede ofrecer.
If you have just one DNS server, what happens if it fails? Four avenues to DNS high availability are the key to a redundant and resilient network.
5 min·Blog
Leer más →
· 02 — MECÁNICA DE LA CONMUTACIÓN POR FALLO
¿Cómo funciona realmente la conmutación automática por error del DNS?
La conmutación automática por error del DNS se ejecuta en cuatro pasos.
En primer lugar, una comprobación de estado detecta que no se puede acceder a un destino. En segundo lugar, ese resultado desencadena un cambio a través de la API del plano de control del DNS, en lugar de una consola. En tercer lugar, el contenido del registro o de la zona se actualiza simultáneamente en todas las copias autorizadas. En cuarto lugar, los clientes se adaptan cuando caducan sus respuestas almacenadas en caché. El TTL del registro, y no la velocidad de la automatización, determina cuánto tiempo tarda ese último paso.
Detection decide qué se considera un fallo, y es ahí donde fallan la mayoría de los sistemas de conmutación por error desarrollados internamente. Una comprobación de estado del punto final de la aplicación te da mucha más información que un ping al servidor que la aloja, y el umbral debe ser lo suficientemente conservador como para no activarse ante una interrupción transitoria, sin dejar de cumplir el SLA. El cambio en sí mismo debería consistir en una llamada a la API en lugar de una modificación en la consola, ya que esta última solo afecta a una plataforma y no va más allá. La compatibilidad integral con las API REST, SOAP y JSON-RPC permite automatizar esos flujos de trabajo mediante scripts y repetirlos, en lugar de tener que realizarlos manualmente bajo presión.
La propagación es el punto débil de los entornos híbridos. Cuando las zonas se replican en un grupo de redundancia, una llamada a la API llega a todos los miembros, por lo que la respuesta del sistema en espera ya es correcta antes de que se active la conmutación por error, en lugar de escribirse durante el incidente. A continuación, los resolutores recursivos eliminan la respuesta antigua según el tiempo de vida (TTL). Por eso, los valores de TTL de los registros A del DNS deben reducirse a unos 300 segundos antes de los cambios previstos y volver a fijarse en 3600 o más una vez que el entorno se haya estabilizado.
An A record in DNS is the fundamental record type used to assign an IP address to a DNS name. Devices on their own do not understand how to communicate with…
1 min·Page
Leer más →
· 03 — LA LAGUNA EN LA RECUPERACIÓN ANTE DESASTRES
¿Por qué se dejan fuera de la planificación de la recuperación ante desastres el DNS, el DHCP y el IPAM?
El DNS y el DHCP suelen pasarse por alto en los planes de recuperación ante desastres, y la gestión de direcciones IP casi nunca se tiene en cuenta.”
equipos dan por sentado que los valores predeterminados basados en el servidor y el seguimiento manual son suficientes, y luego descubren durante la planificación que nada en el entorno registra qué debería existir y dónde, por lo que la conmutación por error no se puede probar, solo intentar.
Una organización descubrió, durante la planificación de la recuperación ante desastres, que el DNS respondía desde todos los controladores de dominio repartidos entre un centro de datos principal, un sitio de respaldo y varias instalaciones geográficas. El DHCP gestionaba más de 100 ámbitos repartidos de forma poco práctica entre dos servidores. El registro de las direcciones IP en uso se encontraba en una hoja de cálculo de Excel de la que se había realizado una copia de seguridad en el almacenamiento en la nube de un empleado.
El problema no eran los servidores en sí mismos. Era que ningún sistema tenía una visión completa del entorno, por lo que no había forma de verificar que un servidor de reserva respondiera correctamente hasta que el tráfico lo demostrara. Una vez que los datos de direcciones y la configuración de DNS se centralizaron en una única plataforma, en lugar de estar dispersos en conocimientos dispersos y una hoja de cálculo, la conmutación por error se convirtió en algo que el equipo podía ensayar y confirmar, y el evento probado se ejecutó sin pérdida de servicio y sin necesidad de intervención humana.
A BlueCat customer discusses why organizations can’t afford to overlook DNS, DHCP and IPAM when planning for a disaster.
4 min·Blog
Leer más →
· 04 — DESVIACIONES ENTRE PROVEEDORES Y VISTAS
¿Cómo pueden los equipos de red evitar que los registros DNS se desvíen entre proveedores y entre las vistas internas y externas?
Se reduce la deriva al establecer un único sistema como fuente de verdad y dejar que se sincronice con los niveles posteriores, en lugar de editar la misma zona en varias consolas.
Esa sincronización debe abarcar tanto las vistas internas como las externas, ya que una conmutación por error que solo actualice la zona pública hace que los clientes internos sigan resolviendo la dirección que ha fallado mucho después de que la conmutación pública se haya realizado con éxito.
Las actualizaciones manuales en múltiples consolas de gestión son una causa documentada de interrupciones del servicio y dejan tres lagunas: puntos únicos de fallo, en los que un único proveedor aloja una zona por sí solo; una mitigación limitada cuando ese proveedor sufre un ataque; y una visibilidad fragmentada entre interfaces independientes. Cuando la redundancia se construye a partir de copias replicadas de zonas en tiempo real, cada servidor mantiene sus propios registros NS y SOA, adecuadamente únicos, mientras que los registros A, CNAME, MX y el resto permanecen sincronizados, de modo que ninguna copia se desvía silenciosamente de las demás.
El DNS de horizonte dividido duplica el número de lugares en los que hay que modificar una respuesta. Si a esto le sumamos los reenviadores condicionales que apuntan a resolutores en la nube, las zonas privadas por VPC y las zonas integradas con Active Directory en los controladores de dominio, una simple conmutación por error lógica se convierte en un cambio que debe aplicarse en cuatro o cinco sistemas en el orden correcto. La solución radica en el ámbito de aplicación más que en el esfuerzo: las copias internas y externas de una zona deben encontrarse dentro del mismo límite de sincronización, de modo que un cambio realizado una sola vez se propague a ambas.
Discover how Micetro’s xDNS® simplifies hybrid cloud DNS management with redundancy, protection against DNS attacks, and enhanced visibility.
4 min·Blog
Leer más →
· 05 — CRITERIOS DE EVALUACIÓN
¿Qué deben buscar los equipos en una plataforma para la conmutación automática por error del DNS en entornos híbridos?
Hay que fijarse en cuatro aspectos: que el contenido de la zona se replique en todas las copias que respondan al dominio, un plano de control basado en API con integraciones de infraestructura como código, un acceso centralizado basado en roles con registro de auditoría completo y herramientas de recuperación probadas.
Cada uno de ellos es la inversa de un modo de fallo documentado anteriormente en esta página. La forma de implementar la plataforma —ya sea sobre los servidores que ya están en funcionamiento o como la plataforma en la que se estandariza una organización— es una decisión independiente que depende del tamaño del equipo y de los planes de modernización.”
La replicación y el control mediante API son los que permiten la conmutación por error. Los registros deben ser idénticos en todas las copias autorizadas antes de que se produzca un incidente, en lugar de crearse durante el mismo, y el cambio que los modifica debe consistir en una única llamada a la API, en lugar de una edición en la consola que se repita en cada plataforma. Una plataforma que cumpla ambos criterios convierte la conmutación por error en algo que un equipo puede ensayar según un calendario, en lugar de tener que intentarlo bajo presión.
La gobernanza y la recuperación determinan si el sistema se mantiene. Cada transacción y cada cambio de configuración deben autenticarse, registrarse y poder auditarse, con flujos de trabajo de aprobación en varios pasos para el control de cambios y permisos basados en roles lo suficientemente granulares como para llegar a zonas individuales y ámbitos DHCP. La agrupación en clústeres con bases de datos sincronizadas, copias de seguridad programadas y rutas de migración y recuperación documentadas cubren el aspecto de la recuperación.
Learn with BlueCat how visibility and control, process automation, and infrastructure reliability offer three reasons to adopt Unified DDI.
5 min·Blog
Leer más →
· 06 — ORQUESTAR LO QUE EJECUTAS
¿Cómo pueden los equipos garantizar que el DNS y el DHCP cumplan su SLA sin tener que rediseñar la red?
BlueCat Micetro garantiza que el DNS y el DHCP cumplan sus niveles de servicio mediante la orquestación de los servidores existentes a través de una superposición sin interrupciones, en lugar de sustituirlos.
organizaciones mantienen en producción Microsoft DNS, ISC BIND, ISC DHCP y Kea DHCP, al tiempo que obtienen un control unificado, redundancia y gestión de cambios sobre ellos?”
Micetro se instala en una máquina virtual, en la nube o en un servidor físico en menos de una hora, sin necesidad de una actualización radical de los servicios DNS y DHCP existentes. Un único agente proxy sustituye a la proliferación de agentes en los servidores de Microsoft, y los permisos granulares basados en roles en ámbitos DHCP y zonas DNS individuales limitan los cambios innecesarios en los controladores de dominio que afectan al tiempo de actividad.
En cuanto a la disponibilidad, la redundancia de xDNS reduce la exposición a puntos únicos de fallo del DNS y refuerza la mitigación de ataques DDoS y otros ataques al DNS. Los grupos de redundancia pueden abarcar BIND, DNS de Windows, DNS de Azure, Amazon Route 53, NS1, Dyn y Akamai Fast DNS, con un miembro alternativo que sigue prestando servicio de forma autoritativa a la zona durante una interrupción del servicio. La gestión centralizada de DHCP y las colas de flujo de trabajo de DNS someten cada cambio a un proceso de solicitud y aprobación.
Today’s enterprise networks span data centers, cloud environments, and distributed edge systems. DNS, DHCP, and IP address management (together known as…
With Micetro, integrate, orchestrate, and automate your current DNS, DHCP, and IPAM network infrastructure via a single web interface.
5 min·Page
Ver Micetro →
· 07 — CONSOLIDACIÓN EN UNA ÚNICA PLATAFORMA
¿Cómo consolidan los equipos el DNS, el DHCP y el IPAM en una única plataforma para garantizar una conmutación por error probada?
BlueCat Integrity consolida la gestión del DNS, el DHCP y las direcciones IP en una única plataforma que constituye una fuente única de información, de modo que la configuración de reserva se puede verificar antes de que se produzca un incidente, en lugar de tener que probarla con tráfico real.Integrity y Micetro son dos vías que conducen al mismo resultado: las organizaciones eligen una u otra, no ambas.
Integrity combina BlueCat Address Manager con los servidores BlueCat DNS/DHCP en una arquitectura de tipo «hub-and-spoke», en la que un único dispositivo de nivel empresarial gestiona miles de servidores DNS y DHCP. Las actualizaciones por fases permiten que los entornos pasen a estar bajo control centralizado de forma secuencial, en lugar de mediante una única transición, y la conmutación por error de DNS y DHCP mantiene la disponibilidad del servicio tanto para IPv4 como para IPv6. La recuperación ante desastres integrada y la información sobre alta disponibilidad permiten a los equipos validar su preparación, lo que convierte una prueba de recuperación en algo programado en lugar de algo que les sobreviene.
gobernanza y la automatización que conlleva. Una OpenAPI RESTful independiente del proveedor permite que la automatización gestione el DNS, el DHCP y el IPAM mediante programación e integre servicios de terceros, como ServiceNow, para el aprovisionamiento de autoservicio. Los controles de acceso basados en roles, las plantillas de red y las herramientas de modelado de IP definen de una sola vez cómo se estructura el espacio de direcciones, y las métricas en tiempo real basadas en Prometheus detectan los problemas antes de que se conviertan en tiempos de inactividad.”
Tame network complexity with Integrity's full-stack DDI management platform and get visibility and control over your DNS, DHCP, and IPAM.
9 min·Page
Ver integridad →
· 08 — caminos a seguir
¿Qué enfoque de conmutación por error es el adecuado para su entorno?
El enfoque adecuado depende de dónde se encuentre la fragilidad actual: en la topología, en la discrepancia entre copias que deberían coincidir o en el hecho de que exista redundancia, pero que se mantenga de forma totalmente manual. De las secciones anteriores se derivan tres vías de actuación.
PATH 01
resolución depende de un único servidor o de un único sitio, sea cual sea la plataforma
Corrige la topología antes de automatizarla
Combina la conmutación por error de hardware, la redundancia del protocolo DNS, la arquitectura distribuida y las comprobaciones de estado del equilibrador de carga, de modo que cada uno cubra los límites de los demás. La automatización basada en un único punto de fallo solo automatiza la interrupción del servicio. Una vez que existe una segunda opción, la automatización tiene a dónde realizar la conmutación por error.
entorno centrado en Microsoft que sigue en producción, sin intención de realizar una migración
Orquesta lo que ya ejecutas
Añade una capa de orquestación sin interrupciones sobre el DNS y el DHCP que ya están en producción. El control basado en roles, los registros de auditoría y las colas de aprobación se incorporan sin necesidad de migración, y la hoja de cálculo deja de ser el sistema de registro. Prueba la conmutación por error una vez que el plano de control pueda demostrar lo que es capaz de hacer.
infraestructura que se está estandarizando, o las pruebas de recuperación ante desastres que deben demostrarse
Consolidar en una única plataforma
Reúne el DNS, el DHCP y el IPAM en una única plataforma, de modo que una única fuente de información contenga lo que debe existir y dónde. La migración por fases evita una transición única, y una conmutación por error ensayada sustituye a una que solo se intenta una vez.
preguntas se plantean los equipos de red a la hora de planificar la conmutación por error del DNS entre entornos locales y en la nube.”,
The three most common are single points of failure where one provider carries a zone alone, limited mitigation when that provider is attacked, and fragmented visibility across separate management consoles. Each cloud has its own console, API, and data model, which makes consistent policy enforcement difficult. Replicating zones across providers under one control layer addresses all three.
Detection and the record change itself can complete in seconds when automated. Reaching users takes as long as the TTL on the affected records, because recursive resolvers continue serving the cached answer until it expires. A 3600 second TTL can leave clients pointed at a dead address for up to an hour after a technically successful failover, which is why TTLs are lowered ahead of planned changes.
Internal and external resolution follow different paths. External queries reach the public authoritative zone that failover updated, while internal clients resolve through internal views and conditional forwarders that were never included in the change. Those clients keep receiving the old address long after the public cutover succeeded, which is why a failover can appear complete from outside and broken from inside. The fix is to bring internal and external copies of a zone inside the same synchronization boundary.
Route changes through a controlled workflow rather than direct console edits, apply role-based permissions down to individual zones and DHCP scopes, and log every transaction so change history is auditable. Restricting who can alter records on domain controllers prevents the mistakes that replicate downstream and cause outages. On BlueCat Integrity, role-based access controls and a full-featured RESTful API let a team define policy once and apply approved changes consistently across the estate.
A recovery plan can only be rehearsed if something records what should exist where. When DNS configuration and address data live in separate consoles and a spreadsheet, a standby cannot be verified until live traffic proves it. BlueCat Integrity holds DNS, DHCP, and IPAM as one source of truth, with DNS and DHCP failover for IPv4 and IPv6 and built-in disaster recovery and high-availability insights that let teams validate readiness ahead of an event rather than during one.
By what the organization intends to do with the DNS and DHCP servers already in production. Micetro orchestrates them where they are, as a non-disruptive overlay over Microsoft DNS, BIND, ISC DHCP, and Kea, which suits estates where those servers are staying and there is no appetite for a migration. Integrity consolidates DNS, DHCP, and IPAM onto a single platform, which suits estates being standardized or disaster recovery testing that has to be proven. Both deliver one source of truth, API-driven change, and audited failover that can be rehearsed. They are alternatives rather than layers.
No. Micetro installs as a non-disruptive overlay on a virtual machine, in the cloud, or on bare metal in under an hour, and it orchestrates the DNS and DHCP servers already in production. Microsoft DNS, ISC BIND, ISC DHCP, and Kea DHCP stay exactly where they are while Micetro adds unified control, redundancy, and audit logging above them.
xDNS redundancy replicates zone content across on-premises and cloud DNS providers, including Windows DNS, BIND, Azure DNS, Route 53, NS1, Dyn, and Akamai Fast DNS, while each member keeps its own unique NS and SOA records. If one provider goes down or is attacked, an alternate provider in the redundancy group continues serving the zone authoritatively without manual intervention.
¿Todavía tienes dudas?
Obtén respuestas reales de un representante de BlueCat.
We’re using cookies on this website to improve your experience. Cookies help us learn how you interact with our website and remember you when you come back so we can tailor it to your interests.
To learn more about cookies and how we use them, read our cookie notice.
Some cookies are essential, while others help us to improve your experience by giving us insight into how you are using our website. You may adjust your preferences for non-essential cookies below.
To learn more about cookies and how we use them, read our cookie notice. You can also review our privacy policy for more details on the personal data we collect, use, hold, and disclose when you visit our website or use our products and services.
Functional cookies
Functional cookies are essential cookies that allow us to remember choices or changes you have made (such as to language settings or your choices regarding the use of cookies). These cookies cannot be turned off since they are essential for the operation of our Websites.
Analytics cookies
Analytics cookies are non-essential cookies that collect information on how visitors use our Websites. We use this information with your consent to measure the number of visitors to our Websites, determine whether specific content or communication has been viewed, and to help us improve our Websites and communication. These cookies can be turned off.
Personalisation Storage
Personalisation cookies are non-essential cookies that collect information when you fill out a form on this website. We only use this information with your consent to pre-fill other forms on the site. These cookies can be turned off.
Marketing cookies
Marketing cookies are cookies that are placed by third parties to collect information about your visits and actions on our Websites so that they or we can deliver ads to you later, such as when you are on certain third-party sites or platforms. These cookies may be used by those third parties to build a profile of your interests and show you relevant ads on other websites. These cookies also enable visitors to our Websites to share content on social networks and to enable and evaluate interactions with our communication and social media tools. These cookies can be turned off.
