Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
zonas privadas do DNS do Azure fornecem resolução segura de nomes nas redes virtuais do Azure. Você pode definir o escopo de zonas DNS privadas para uma ou mais redes virtuais e as organizações normalmente as usam para aplicativos internos. Os nomes de host que você resolve são nomes DNS locais que não são publicamente acessíveis pela Internet. Os endereços IP resolvidos geralmente são endereços IP privados que não são acessíveis da Internet. DNS do Azure é um serviço global que não está associado a nenhuma zona de disponibilidade específica ou a uma única 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 tornar DNS do Azure zonas privadas resilientes a várias possíveis interrupções e problemas, incluindo falhas transitórias e falhas em toda a região. Ele também fornece informações importantes sobre o SLA (contrato de nível de serviço) de zonas privadas DNS do Azure.
Recomendações de implantação de produção para confiabilidade
Para cargas de trabalho de produção, recomendamos que você siga estas recomendações:
Configure os valores TTL apropriados: Defina valores TTL (vida útil) que equilibram o desempenho com o tempo de recuperação. Valores de TTL mais baixos permitem um failover mais rápido, mas aumentam o volume de consultas. Considere 300 segundos (5 minutos) como ponto de partida para cargas de trabalho de produção.
Fragmentar grandes zonas DNS: Se você tiver uma zona DNS grande, considere fragmentar sua zona para melhorar sua confiabilidade geral e eficiência operacional.
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 representa um conjunto de registros DNS que mapeiam nomes de host (nomes de domínio) para endereços IP. Os nomes de host que a zona resolve geralmente são nomes DNS locais que não são acessíveis publicamente pela Internet.
Você cria zonas DNS privadas como recursos autônomos e as vincula a redes virtuais específicas criando links de rede virtual. Quando as solicitações DNS vêm de clientes dentro dessas redes virtuais, as zonas DNS privadas participam do processo de resolução. Você pode criar entradas manualmente em uma zona DNS ou configurar o registro automático de VMs em links de rede virtual. As zonas privadas do DNS do Azure oferecem suporte à resolução de DNS entre redes virtuais em diferentes regiões do Azure, mesmo sem configurar explicitamente o emparelhamento entre as redes virtuais. No entanto, todas as redes virtuais devem estar vinculadas à zona DNS privada.
O processo de resolução de nomes DNS envolve vários componentes, incluindo resolvedores DNS e camadas intermediárias que processam solicitações antes de alcançar os servidores DNS autoritativos. As zonas privadas usam os mesmos protocolos e comportamentos DNS que zonas públicas, incluindo valores TTL e mecanismos de cache.
Importante
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 é um serviço não regional. Microsoft 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 (Border Gateway Protocol) roteiam automaticamente solicitações de resolução DNS de entrada para a infraestrutura de DNS do Azure íntegra mais próxima.
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á repetir a solicitação. Configure valores de tempo limite adequadamente. Um tempo limite de 2 a 5 segundos geralmente é 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 farão mais solicitações para DNS do Azure, o que cria mais oportunidades para 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 privadas 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
DNS do Azure zonas privadas são resilientes a interrupções de região porque os dados de zona estão disponíveis globalmente. Se uma região tiver uma interrupção, suas redes virtuais e recursos, como VMs, poderão ficar indisponíveis, mas a resolução de nomes continuará funcionando.
O exemplo a seguir mostra como os dados de zona privada permanecem disponíveis em várias regiões. A zona azure.contoso.com privada está vinculada a redes virtuais em três regiões: região A, região B e região C. A autoregistração está habilitada nas regiões A e B. O diagrama mostra a região A enfrentando uma interrupção:
Suponha que uma interrupção temporária ocorra na região A. VMs nas regiões B e C ainda podem consultar nomes DNS na zona privada, incluindo nomes que são autoregisterados da região A. Eles podem continuar a resolver o endereço IP da VM1 na região A, mesmo que a VM1 não esteja disponível. A interrupção do serviço na região A não afeta a resolução de nomes nas outras regiões.
O exemplo anterior não mostra um cenário de recuperação de desastres em que sua solução faz a comutação para uma instância substituta da VM1 em outra região. No entanto, como as zonas privadas são globais, você pode recriar a VM1 na rede virtual de outra região para assumir a carga de trabalho.
Se você criar redes virtuais e recursos de rede em várias regiões, precisará planejar e implementar sua estratégia de várias regiões para aplicativos que exigem failover entre regiões.
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 privadas, consulte Protegendo zonas e registros DNS privados.
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 outras infraestruturas podem interromper a conectividade com o serviço DNS do Azure.
Monitorar interrupções de serviço
Microsoft não notificará você automaticamente quando uma região está inoperante. No entanto, você pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo eventuais falhas na região, e pode configurar alertas Service Health para notificar você sobre problemas.
Teste para interrupções de serviço
Azure Chaos Studio fornece um conjunto de falhas para simular problemas com a resolução DNS. Por exemplo, o agente do Chaos Studio fornece o tipo de falha DNS Failure, e o AKS (Serviço de Kubernetes do Azure) Chaos Mesh fornece a funcionalidade DNS Chaos. Você pode usar esses tipos de falha para testar como seus aplicativos e infraestrutura respondem quando as solicitações de resolução DNS falham, o que pode ocorrer durante uma falha parcial na rede.
Resiliência a interrupções de portal e ferramentas de gerenciamento
Se você gerenciar sua zona DNS no portal Azure, prepare-se para cenários em que não possa acessá-la, especialmente se precisar reconfigurar sua zona DNS durante uma interrupção da plataforma.
Você pode usar várias ferramentas para implantar e gerenciar DNS do Azure zonas privadas. Saiba como usar CLI do Azure ou Azure PowerShell para gerenciar sua zona privada. Como alternativa, use IaC (infraestrutura como código), como Bicep ou Terraform, para provisionar e configurar sua zona privada. 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 privadas.
Para preservar a configuração completa de recursos Azure, defina suas zonas DNS privadas usando IaC, como Bicep ou Terraform, e armazene as definições no controle do código-fonte. Teste periodicamente as definições para que você possa usá-las para reimplantar sua configuração.
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 quando você atende a determinadas condições. Essas condições incluem a repetição de solicitações com falha por pelo menos 60 segundos consecutivos. Examine o documento SLA para obter as condições detalhadas.