Fiabilidad en las zonas privadas de Azure DNS

zonas privadas de Azure DNS proporcionan una resolución de nombres segura dentro de las redes virtuales de Azure. Puede definir el ámbito de las zonas DNS privadas a una o varias redes virtuales y las organizaciones normalmente las usan para las aplicaciones internas. Los nombres de host que resuelva son nombres DNS locales que no son accesibles públicamente a través de Internet. Las direcciones IP resueltas suelen ser direcciones IP privadas que no son accesibles desde Internet. Azure DNS es un servicio global que no está enlazado a ninguna zona de disponibilidad específica ni a una sola región.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de capacidades para apoyar la resiliencia y la recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que las zonas privadas de Azure DNS sean resilientes frente a diversas interrupciones y posibles problemas, incluidos los fallos transitorios y los fallos que afectan a toda una región. También proporciona información clave sobre el acuerdo de nivel de servicio (SLA) del servicio de zonas privadas de Azure DNS.

Recomendaciones de implementación de producción para la confiabilidad

En el caso de las cargas de trabajo de producción, se recomienda seguir estas recomendaciones:

  • Configure los valores de TTL adecuados: Establezca valores de período de vida (TTL) que equilibran el rendimiento con el tiempo de recuperación. Los valores de TTL más bajos permiten una conmutación por error más rápida, pero aumentan el volumen de consultas. Considere 300 segundos (5 minutos) como punto de partida para las cargas de trabajo de producción.

  • Divida las zonas DNS grandes: Si tiene una zona DNS grande, considere dividir la zona para mejorar la fiabilidad general y la eficiencia operativa.

Introducción a la arquitectura de confiabilidad

En esta sección se describen algunos de los aspectos importantes de cómo funciona el servicio que es más relevante desde una perspectiva de confiabilidad. En la sección se presenta la arquitectura lógica, que incluye algunos de los recursos y características que se implementan y usan. También se describe la arquitectura física, que proporciona detalles sobre cómo funciona el servicio en segundo plano.

Arquitectura lógica

El recurso principal que implemente es una zona, que representa un conjunto de registros DNS que asignan nombres de host (nombres de dominio) a direcciones IP. Los nombres de host que resuelve la zona suelen ser nombres DNS locales que no son accesibles públicamente desde Internet.

Las zonas DNS privadas se crean como recursos independientes y se vinculan a redes virtuales específicas mediante la creación de vínculos de red virtual. Cuando las solicitudes DNS proceden de clientes dentro de esas redes virtuales, las zonas DNS privadas participan en el proceso de resolución. Puede crear manualmente entradas en una zona DNS o configurar el registro automático de máquinas virtuales en vínculos de red virtual. Las zonas DNS privadas de Azure permiten la resolución de DNS entre redes virtuales de distintas regiones de Azure, incluso sin interconectar de forma explícita las redes virtuales. Sin embargo, todas las redes virtuales están vinculadas a la zona DNS privada.

El proceso de resolución de nombres DNS implica varios componentes, incluidos solucionadores DNS y capas intermedias que procesan solicitudes antes de llegar a los servidores DNS autoritativos. Las zonas privadas usan los mismos protocolos y comportamientos DNS que las zonas públicas, incluidos los valores de TTL y los mecanismos de almacenamiento en caché.

Importante

La confiabilidad de la solución general depende de la configuración de los recursos a los que hacen referencia los registros DNS, como máquinas virtuales y equilibradores de carga.

En este artículo no se tratan esos recursos, pero sus configuraciones de disponibilidad afectan directamente a la resistencia de la aplicación. Revise las guías de confiabilidad de los servicios de Azure de la solución para obtener información sobre cómo cada servicio admite sus requisitos de confiabilidad.

Arquitectura física

Azure DNS es un servicio no regional. Microsoft implementa su infraestructura en varias zonas de disponibilidad en varias regiones de Azure en todo el mundo. Este diseño permite que Azure DNS permanezcan resistentes durante una interrupción de zona o región de disponibilidad porque la infraestructura de otra zona o región sigue respondiendo a las solicitudes de resolución.

Los protocolos globales de Internet, como Anycast, DNS y Border Gateway Protocol (BGP), enrutan automáticamente las solicitudes entrantes de resolución de DNS a la infraestructura de Azure DNS en buen estado más próxima.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para más información, vea Recomendaciones para gestionar errores temporales.

Azure DNS controla los errores transitorios a través de su infraestructura DNS global.

Si se produce un error transitorio durante la resolución DNS, el cliente o el solucionador intermedio deben reintentar la solicitud. Configure los valores de tiempo de espera adecuadamente. Normalmente, un tiempo de espera de 2 a 5 segundos es suficiente para un cliente DNS.

El período de vida de cada registro DNS (TTL) también afecta al modo en que la solución controla los errores. Si el TTL es muy bajo, los clientes realizan más solicitudes a Azure DNS, lo que crea más oportunidades para errores transitorios. Si el TTL es muy alto, en caso de un fallo real en un servidor backend que le obligue a redirigir a otra dirección IP, los clientes podrían experimentar retrasos en la conmutación por error hasta que caduque el TTL. Configure las TTL cuidadosamente para equilibrar la disponibilidad, la latencia y la capacidad de respuesta.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Azure DNS funciona como un servicio no regional. Microsoft distribuye su infraestructura en varias zonas de disponibilidad en varias regiones de Azure y replica los cambios en las zonas DNS privadas en esa infraestructura. No selecciona zonas de disponibilidad ni configura redundancia de zona. Durante una interrupción de zona de disponibilidad, la infraestructura de otra zona o región sigue respondiendo a las solicitudes de resolución.

Si un recurso que se implementa en una sola zona de disponibilidad, como una máquina virtual, deja de estar disponible durante un error de zona, Azure DNS continúa devolviendo la dirección IP configurada del recurso porque no supervisa el estado del punto de conexión. Si realiza una conmutación por error a un recurso en una zona en buen estado, usted es responsable de actualizar el registro DNS para que los clientes usen el recurso en buen estado. Como alternativa, sitúe los recursos detrás de un balanceador de carga con redundancia de zona que redirija el tráfico a las máquinas virtuales de las zonas en buen estado.

Resistencia a errores en toda la región

Las zonas privadas de Azure DNS resisten las interrupciones regionales porque los datos de la zona están disponibles globalmente. Si una región tiene una interrupción, sus redes virtuales y recursos, como las máquinas virtuales, podrían no estar disponibles, pero la resolución de nombres sigue funcionando.

En el ejemplo siguiente se muestra cómo permanecen los datos de zona privada disponibles en varias regiones. La zona azure.contoso.com privada está vinculada a redes virtuales en tres regiones: región A, región B y región C. El registro automático está habilitado en las regiones A y B. En el diagrama se muestra la región A que experimenta una interrupción:

Diagrama que muestra una zona DNS privada vinculada a redes virtuales en tres regiones mientras la región A no está disponible.

Supongamos que se produce una interrupción temporal en la región A. Las máquinas virtuales de las regiones B y C todavía pueden consultar nombres DNS en la zona privada, incluidos los nombres que se registran automáticamente desde la región A. Pueden seguir resolviendo la dirección IP de VM1 en la región A, aunque VM1 no esté disponible. La interrupción del servicio en la región A no afecta a la resolución de nombres en las otras regiones.

En el ejemplo anterior no se muestra un escenario de recuperación ante desastres en el que la solución conmuta por error a un reemplazo de VM1 en otra región. Sin embargo, dado que las zonas privadas son globales, puede volver a crear VM1 en la red virtual de otra región para asumir la carga de trabajo.

Si crea redes virtuales y recursos de red en varias regiones, debe planificar e implementar su estrategia multirregional para las aplicaciones que requieren conmutación por error entre regiones.

Resistencia a amenazas de seguridad y configuración incorrecta

Los ataques de seguridad y los errores de configuración son dos de los riesgos de confiabilidad más significativos para las zonas DNS. Varias clases de ataques se dirigen específicamente a la resolución de DNS, y un error de configuración accidental puede interrumpir sus cargas de trabajo con la misma gravedad.

Para obtener instrucciones de seguridad completas específicas de zonas DNS privadas, consulte Protección de registros y zonas DNS privadas.

Resistencia a interrupciones del servicio

Azure DNS es un servicio altamente resistente, con un Acuerdo de Nivel de Servicio de disponibilidad de 100% cuando la aplicación cumple ciertas condiciones. Las interrupciones del servicio son extremadamente inusuales, pero los problemas de red u otros problemas de infraestructura pueden interrumpir la conectividad con el servicio Azure DNS.

Supervisión de interrupciones de servicio

Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

Prueba de interrupciones del servicio

Azure Chaos Studio proporciona un conjunto de errores para simular problemas con la resolución de DNS. Por ejemplo, el agente de Chaos Studio proporciona el tipo de error de DNS Failure y Azure Kubernetes Service (AKS) Chaos Mesh proporciona la funcionalidad Chaos de DNS. Puede usar estos tipos de error para probar cómo responden las aplicaciones y la infraestructura cuando se produce un error en las solicitudes de resolución DNS, lo que puede producirse durante un error de red parcial.

Resiliencia ante interrupciones del portal y herramientas de gestión

Si administra la zona DNS en el portal de Azure, prepárese para escenarios en los que no pueda acceder a ella, especialmente si necesita volver a configurar la zona DNS durante una interrupción de la plataforma.

Puede usar varias herramientas para implementar y administrar Azure DNS zonas privadas. Aprenda a usar CLI de Azure o Azure PowerShell para administrar la zona privada. Como alternativa, use la infraestructura como código (IaC), como Bicep o Terraform, para implementar y configurar la zona privada. Estas herramientas permanecen operativas incluso si el portal de Azure está degradado.

Copias de seguridad y restauración

Azure DNS es un servicio sin estado. No proporciona copias de seguridad administradas ni restauración a un momento dado para zonas DNS privadas.

Para conservar la configuración completa de recursos Azure, defina las zonas DNS privadas mediante IaC, como Bicep o Terraform, y almacene las definiciones en el control de código fuente. Pruebe periódicamente las definiciones para poder usarlas para volver a implementar la configuración.

Resistencia al mantenimiento del servicio

Microsoft aplica periódicamente actualizaciones de servicio y realiza otro mantenimiento. La plataforma Azure controla estas actividades automáticamente, lo que garantiza que el mantenimiento sea transparente y sin problemas. No se espera ningún tiempo de inactividad durante los eventos de mantenimiento a menos que se le haya informado a través del mantenimiento planeado de Azure Service Health.

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte los SLAs de los servicios en línea.

Azure DNS proporciona un Acuerdo de Nivel de Servicio de disponibilidad de 100% para respuestas de consulta DNS válidas cuando cumple ciertas condiciones. Estas condiciones incluyen reintentar las solicitudes fallidas durante al menos 60 segundos consecutivos. Revise el documento del Acuerdo de Nivel de Servicio para conocer las condiciones detalladas.