Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure DNS proporciona resolución de nombres mediante la infraestructura de Microsoft Azure. Este artículo se centra en las zonas DNS públicas, que normalmente se crean para dominios que posee y se usan para publicar registros para aplicaciones y servicios que están disponibles en Internet. Los nombres de host que resuelva son nombres DNS accesibles públicamente y las direcciones IP resueltas suelen ser direcciones IP públicas accesibles desde Internet.
Azure DNS es un servicio no regional que no está enlazado a una zona de disponibilidad específica o Azure 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 las zonas públicas de Azure DNS responden a fallos transitorios, fallos de zona de disponibilidad, fallos que afectan a toda una región, interrupciones del servicio, amenazas de seguridad y errores de configuración, interrupciones del portal y de las herramientas de administración, y tareas de mantenimiento del servicio. También se describe cómo proteger y restaurar la configuración de la zona y se explican los requisitos clave del acuerdo de nivel de servicio (SLA).
Recomendaciones de implementación de producción para la confiabilidad
Para las implementaciones de producción de Azure DNS zonas públicas, siga estas recomendaciones para mejorar la confiabilidad:
Delegue en todos los servidores de nombres: Azure DNS asigna cuatro servidores de nombres a cada zona DNS pública. Configure la delegación de dominio para usar los cuatro servidores de nombres. Esta configuración proporciona aislamiento de errores y es necesario para calificar para el Acuerdo de Nivel de Servicio de Azure DNS.
Configure los valores de TTL adecuados: Establezca los valores de período de vida (TTL) que equilibran el volumen de consultas con la rapidez con la que los clientes reciben cambios de registro. Los valores de TTL inferiores permiten a los clientes recibir cambios antes, pero aumentar el volumen de consultas. Los valores de TTL más altos reducen el volumen de consultas, pero pueden retrasar la conmutación por error después de cambiar un registro.
Use registros de alias para recursos de Azure admitidos:los registros de alias reflejan automáticamente los cambios en un recurso de Azure subyacente durante la resolución DNS y ayudan a evitar registros DNS obsoletos.
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 contiene los conjuntos de registros DNS para un dominio. Un conjunto de registros asocia un nombre DNS a un valor, como una dirección IP o un punto de conexión. Los nombres que resuelve una zona DNS pública son accesibles a través de Internet.
Para que Azure DNS sea autoritativo para su dominio, delegue el dominio en los servidores de nombres que Azure asigna cuando crea la zona. Una vez que se haya implementado la delegación, se crean conjuntos de registros para los tipos de registro DNS que Azure DNS admite. También puede crear registros de alias que hagan referencia a recursos Azure, como direcciones IP públicas, perfiles de Traffic Manager y puntos de conexión de Azure Front Door, de modo que el registro DNS permanezca sincronizado con el recurso de destino.
Durante la resolución DNS, los solucionadores DNS recursivos siguen la jerarquía del DNS para llegar a los servidores de nombres autoritativos de Azure DNS de su zona.
Importante
Azure DNS resuelve los nombres, pero no supervisa el estado del punto de conexión ni enruta el tráfico de la aplicación. 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 funciona como un servicio no regional e 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 BGP, dirigen automáticamente las solicitudes entrantes de resolución de DNS a la infraestructura de Azure DNS en buen estado más cercana.
El plano de servicio de Azure DNS opera en una configuración activa-activa en dos entornos de servicio independientes: uno que se ejecuta en Linux y otro que se ejecuta en Windows. Estas pilas no comparten código ni hardware subyacente. Como son independientes, un error, una vulnerabilidad o un fallo que afecta a una pila no afecta a la otra. Esta independencia reduce el riesgo de una interrupción completa del servicio causada por un único punto de error y ayuda a protegerse contra determinadas clases de vulnerabilidades de día cero.
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 de DNS, el cliente o el resolutor intermedio debe reintentar según su comportamiento de reintento de DNS configurado. Entre 2 y 5 segundos suele ser un tiempo de espera 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 deben realizar más solicitudes para Azure DNS y hay más oportunidades potenciales para que surjan 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 públicas 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 DNS son resistentes a las interrupciones de regiones porque los datos de zona están disponibles globalmente e implementados en varias regiones de Azure. Si una región tiene una interrupción, los recursos que implementó en esa región, como las redes virtuales y las máquinas virtuales, podrían no estar disponibles, pero Azure DNS continúa resolviendo los registros de la zona.
Si tiene una solución que necesita cambiar entre varias regiones, como con fines de recuperación ante desastres, considere la posibilidad de usar Azure Traffic Manager o Azure Front Door. Estos servicios proporcionan capacidades de conmutación por error automática, que puede utilizar si una región presenta problemas.
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 las zonas DNS públicas, consulte Protección de la implementación de Azure DNS y Protección de zonas y registros DNS.
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 o problemas con otra infraestructura pueden interrumpir la conectividad con el servicio Azure DNS.
La resiliencia de Azure DNS se debe en parte a su arquitectura de plano de servicio activo-activo distribuida globalmente.
Uso de varios servidores de nombres
Azure DNS asigna cuatro servidores de nombres a cada zona DNS pública. Al delegar el dominio, configure los cuatro servidores de nombres. Si un solucionador no puede llegar a un servidor de nombres, puede consultar a otro.
Supervisión de interrupciones de servicio
Use Azure Service Health para supervisar el estado de Azure DNS. Configure las alertas de Service Health para notificarle los incidentes de servicio.
Prueba de interrupciones del servicio
Azure Chaos Studio proporciona fallos que simulan errores de resolución de DNS desde dentro de algunos tipos de cargas de trabajo de prueba. Estos errores no desencadenan una interrupción en Azure DNS. El agente de Chaos Studio proporciona el error de Error de DNS, y AKS Chaos Mesh proporciona la funcionalidad Caos de DNS. Use estos errores para probar cómo responden las aplicaciones y la infraestructura cuando se produce un error en la resolución DNS, como durante un error de red parcial.
Resiliencia ante interrupciones del portal y herramientas de gestión
Si administra la zona DNS pública en el portal de Azure, prepare una ruta de acceso de administración alternativa para escenarios en los que no pueda acceder al portal, especialmente si es posible que tenga que volver a configurar la zona durante una interrupción.
Si el portal de Azure no está disponible, use el CLI de Azure, el Azure PowerShell o la infraestructura como código (IaC), como Bicep o Terraform para administrar la zona DNS pública. 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 punto concreto en el tiempo para las zonas DNS públicas.
Para conservar la configuración completa de recursos Azure, defina las zonas DNS públicas mediante IaC, como Bicep o Terraform, y almacene las definiciones en el control de código fuente. Pruebe las definiciones periódicamente para poder usarlas para volver a implementar la configuración.
Como opción de recuperación de nivel de registro adicional, exporte un archivo de zona compatible con BIND. La importación de archivos de zona tiene limitaciones y no conserva todas las opciones de recursos específicas de Azure, por lo que no use un archivo de zona exportado como único artefacto de recuperación. Revise las limitaciones de importación documentadas y compruebe los registros después de restaurar una zona.
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, siempre y cuando se cumplan determinadas condiciones. Estas condiciones incluyen volver a intentar solicitudes con errores repetidamente durante al menos 60 segundos consecutivos y usar todos los servidores de nombres que Azure DNS asignan a la zona. Revise el documento del Acuerdo de Nivel de Servicio para conocer las condiciones detalladas.