Confiabilidade em zonas públicas DNS do Azure

DNS do Azure fornece resolução de nomes usando Microsoft Azure infraestrutura. Este artigo se concentra em zonas DNS públicas, que normalmente você cria para domínios que você possui e usa para publicar registros para aplicativos e serviços que estão disponíveis na Internet. Os nomes de host que você resolve são nomes DNS acessíveis publicamente e os endereços IP resolvidos geralmente são endereços IP públicos acessíveis da Internet.

DNS do Azure é um serviço não regional que não está associado a uma zona de disponibilidade específica ou Azure região.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como DNS do Azure zonas públicas respondem a falhas transitórias, falhas na zona de disponibilidade, falhas em toda a região, interrupções de serviço, ameaças à segurança e configuração incorreta, interrupções de portal e ferramentas de gerenciamento e manutenção de serviço. Ele também descreve como proteger e restaurar a configuração de zona e explica os principais requisitos de SLA (contrato de nível de serviço).

Recomendações de implantação de produção para confiabilidade

Para implantações de produção de DNS do Azure zonas públicas, siga estas recomendações para aprimorar a confiabilidade:

  • Delegue para todos os servidores de nomes: O DNS do Azure atribui quatro servidores de nomes a cada zona DNS pública. Configure sua delegação de domínio para usar todos os quatro servidores de nome. Essa configuração fornece isolamento de falhas e é necessária para se qualificar para o SLA DNS do Azure.

  • Configure os valores TTL apropriados: Defina valores TTL (vida útil) que equilibram o volume de consultas com a rapidez com que os clientes recebem alterações de registro. Valores TTL mais baixos permitem que os clientes recebam alterações mais cedo, mas aumentam o volume de consulta. Valores TTL mais altos reduzem o volume de consultas, mas podem atrasar o failover após a alteração de um registro.

  • Use registros de alias para recursos do Azure com suporte:Os registros de alias refletem automaticamente as alterações em um recurso subjacente do Azure durante a resolução de DNS e ajudam a evitar registros de DNS obsoletos.

Visão geral da arquitetura de confiabilidade

Esta seção descreve alguns dos aspectos importantes de como o serviço funciona que são mais relevantes do ponto de vista da confiabilidade. A seção apresenta a arquitetura lógica, que inclui alguns dos recursos e recursos que você implanta e usa. Também discute a arquitetura física, que fornece detalhes sobre como o serviço funciona nos bastidores.

Arquitetura lógica

O recurso primário que você implanta é uma zona, que contém os conjuntos de registros DNS para um domínio. Um conjunto de registros associa um nome DNS a um valor, como um endereço IP ou endpoint. Os nomes que uma zona DNS pública resolve são acessíveis por meio da Internet.

Para tornar o DNS do Azure autoritativo para o seu domínio, delegue o domínio aos servidores de nomes que o Azure atribui quando você cria a zona. Depois que a delegação estiver em vigor, você criará conjuntos de registros para os tipos de registro DNS compatíveis com DNS do Azure. Você também pode criar registros de alias que fazem referência a recursos Azure, como endereços IP públicos, perfis do Gerenciador de Tráfego e pontos de extremidade Azure Front Door, para que o registro DNS permaneça sincronizado com o recurso de destino.

Durante a resolução DNS, resolvedores recursivos de DNS seguem a hierarquia do DNS para alcançar os servidores de nomes autoritativos do DNS do Azure da sua zona.

Important

DNS do Azure resolve nomes, mas não monitora a integridade do ponto de extremidade ou roteia o tráfego do aplicativo. A confiabilidade da solução geral depende da configuração dos recursos aos quais seus registros DNS se referem, como máquinas virtuais e balanceadores de carga.

Este artigo não aborda esses recursos, mas suas configurações de disponibilidade afetam diretamente a resiliência do aplicativo. Examine os guias de confiabilidade dos serviços do Azure em sua solução para saber como cada serviço dá suporte aos seus requisitos de confiabilidade.

Arquitetura física

DNS do Azure opera como um serviço não regional e implanta sua infraestrutura em várias zonas de disponibilidade em várias regiões Azure em todo o mundo. Esse design permite que DNS do Azure permaneçam resilientes durante uma interrupção de zona de disponibilidade ou região porque a infraestrutura em outra zona ou região continua respondendo às solicitações de resolução.

Protocolos globais de Internet, como Anycast, DNS e BGP, roteiam automaticamente solicitações de resolução DNS de entrada para a infraestrutura de DNS do Azure íntegra mais próxima.

O plano de serviço DNS do Azure opera em uma configuração ativa-ativa em duas pilhas de serviço independentes: uma em execução no Linux e outra em execução no Windows. Esses stacks não compartilham código nem hardware subjacente. Como eles são independentes, um bug, uma vulnerabilidade ou uma falha que afeta uma pilha não afeta a outra. Essa independência reduz o risco de uma interrupção completa do serviço causada por um único ponto de falha e ajuda a proteger contra determinadas classes de vulnerabilidades de dia zero.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para resolver falhas transitórias.

DNS do Azure lida com falhas transitórias por meio de sua infraestrutura DNS global.

Se ocorrer uma falha transitória durante a resolução DNS, o cliente ou resolvedor intermediário deverá tentar novamente de acordo com seu comportamento de repetição de DNS configurado. Entre 2 e 5 segundos geralmente é um tempo limite suficiente para um cliente DNS.

O TTL (tempo de vida útil) de cada registro DNS também afeta a forma como sua solução lida com falhas. Se o TTL for muito baixo, os clientes precisarão fazer mais solicitações para DNS do Azure e há mais oportunidades potenciais para surgirem falhas transitórias. Se o TTL for muito alto, no caso de uma falha verdadeira em um servidor de back-end que exija que você redirecione para um endereço IP diferente, os clientes poderão sofrer atrasos no failover até que o TTL expire. Configure os TTLs com cuidado para equilibrar disponibilidade, latência e capacidade de resposta.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

DNS do Azure funciona como um serviço não regional. Microsoft distribui sua infraestrutura em várias zonas de disponibilidade em várias regiões de Azure e replica as alterações em suas zonas DNS públicas nessa infraestrutura. Você não seleciona zonas de disponibilidade nem configura a redundância de zona. Durante uma interrupção de zona de disponibilidade, a infraestrutura em outra zona ou região continua respondendo às solicitações de resolução.

Se um recurso que você implanta em uma única zona de disponibilidade, como uma VM (máquina virtual), ficar indisponível durante uma falha de zona, DNS do Azure continuará retornando o endereço IP configurado do recurso porque ele não monitora a integridade do ponto de extremidade. Se você fizer failover para um recurso em uma zona íntegra, será responsável por atualizar o registro DNS para que os clientes usem o recurso íntegro. Como alternativa, coloque os recursos atrás de um balanceador de carga com redundância entre zonas que direciona o tráfego para VMs em zonas saudáveis.

Resiliência a falhas em toda a região

As zonas DNS são resilientes a interrupções de região porque os dados de zona estão disponíveis globalmente e implantados em várias regiões Azure. Se uma região tiver uma interrupção, os recursos implantados nessa região, como redes virtuais e VMs, poderão ficar indisponíveis, mas DNS do Azure continuar a resolver registros em sua zona.

Se você tiver uma solução que precise alternar entre várias regiões, como para fins de recuperação de desastre, considere usar Gerenciador de Tráfego do Azure ou Azure Front Door. Esses serviços fornecem recursos de failover automático, que você pode usar se uma região estiver com problemas.

Resiliência a ameaças de segurança e configuração incorreta

Os ataques de segurança e os erros de configuração são dois dos riscos de confiabilidade mais significativos para zonas DNS. Várias classes de ataques atingem especificamente a resolução de DNS, e uma má configuração acidental pode interromper suas cargas de trabalho com a mesma gravidade.

Para obter diretrizes de segurança abrangentes específicas para zonas DNS públicas, consulte Proteger sua implantação de DNS do Azure e proteger zonas e registros DNS.

Resiliência a interrupções de serviço

DNS do Azure é um serviço altamente resiliente, com um SLA de disponibilidade de 100% quando seu aplicativo atende a determinadas condições. Interrupções de serviço são extremamente incomuns, mas problemas de rede ou problemas com outra infraestrutura podem interromper a conectividade com o serviço DNS do Azure.

A resiliência do DNS do Azure se deve, em parte, à sua arquitetura de plano de atendimento ativo-ativo, distribuída globalmente.

Usar vários servidores de nomes

DNS do Azure atribui quatro servidores de nome a cada zona DNS pública. Ao delegar seu domínio, configure todos os quatro servidores de nome. Se um resolvedor não conseguir alcançar um servidor de nome, ele poderá consultar outro.

Monitorar interrupções de serviço

Use Integridade do Serviço do Azure para monitorar a integridade do DNS do Azure. Configure os alertas de integridade do serviço para notificar você sobre incidentes no serviço.

Teste para interrupções de serviço

O Azure Chaos Studio oferece falhas que simulam falhas na resolução de DNS em determinados tipos de cargas de trabalho de teste. Essas falhas não disparam uma interrupção no DNS do Azure. O agente do Chaos Studio oferece a falha Falha de DNS, e o AKS Chaos Mesh oferece a capacidade Caos de DNS. Use essas falhas para testar como seus aplicativos e infraestrutura respondem quando a resolução DNS falha, como durante uma falha parcial de rede.

Resiliência a interrupções de portal e ferramentas de gerenciamento

Se você gerenciar sua zona DNS pública no portal Azure, prepare um caminho de gerenciamento alternativo para cenários em que não possa acessar o portal, especialmente se precisar reconfigurar a zona durante uma interrupção.

Se o portal Azure estiver indisponível, use o CLI do Azure, Azure PowerShell ou IaC (infraestrutura como código), como Bicep ou Terraform, para gerenciar sua zona DNS pública. Essas ferramentas permanecem operacionais mesmo se o portal de Azure estiver degradado.

Backup e restauração

DNS do Azure é um serviço sem estado. Ele não fornece backups gerenciados ou restauração pontual para zonas DNS públicas.

Para preservar a configuração completa de recursos Azure, defina suas zonas DNS públicas usando IaC, como Bicep ou Terraform, e armazene as definições no controle do código-fonte. Teste as definições periodicamente para que você possa usá-las para reimplantar sua configuração.

Como uma opção de recuperação de nível de registro adicional, exporte um arquivo de zona compatível com BIND. A importação de arquivo de zona tem limitações e não preserva cada configuração de recurso específica Azure; portanto, não use um arquivo de zona exportado como seu único artefato de recuperação. Examine as limitações de importação documentadas e verifique os registros depois de restaurar uma zona.

Resiliência à manutenção do serviço

A Microsoft aplica regularmente as atualizações de serviço e executa outras manutenções. A plataforma Azure manipula essas atividades automaticamente, garantindo que a manutenção seja perfeita e transparente para você. Não se espera tempo de inatividade durante eventos de manutenção, a menos que você tenha sido avisado por meio de manutenção planejada do Integridade do Serviço do Azure.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

DNS do Azure fornece um SLA de disponibilidade de 100% para respostas de consulta DNS válidas, desde que determinadas condições sejam atendidas. Essas condições incluem repetir solicitações com falha repetidamente por pelo menos 60 segundos consecutivos e usar todos os servidores de nome que DNS do Azure atribui à sua zona. Examine o documento SLA para obter as condições detalhadas.