Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
As zonas privadas do DNS do Azure fornecem resolução segura de nomes dentro das redes virtuais do Azure. Pode definir zonas DNS privadas para uma ou mais redes virtuais, e as organizações normalmente utilizam-nas para aplicações internas. Os nomes de host que resolves são nomes DNS locais que não são publicamente acessíveis pela internet. Os endereços IP resolvidos são frequentemente endereços privados que não são acessíveis pela internet. O DNS do Azure é um serviço global que não está vinculado 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 oferecer 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 as zonas privadas do DNS do Azure resilientes a vários potenciais cortes e problemas, incluindo falhas transitórias e falhas regionais. Também fornece informações-chave sobre o acordo de nível de serviço (SLA) das zonas privadas do DNS do Azure.
Recomendações de implantação de produção para confiabilidade
Para cargas de trabalho em ambientes de produção, recomendamos seguir estas recomendações:
Configure valores TTL apropriados: Defina valores de tempo de vida (TTL) que equilibrem desempenho com tempo de recuperação. Valores 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 em produção.
Fragmentar zonas DNS grandes: Se tiver uma zona DNS grande, considere fragmentar a sua zona para melhorar a sua fiabilidade geral e eficiência operacional.
Visão geral da arquitetura de confiabilidade
Esta secção descreve alguns dos aspetos importantes do funcionamento do serviço que são mais relevantes do ponto de vista da fiabilidade. A secção apresenta a arquitetura lógica, que inclui alguns dos recursos e funcionalidades que implementa e utiliza. Também discute a arquitetura física, detalhando como o serviço funciona nos bastidores.
Arquitetura lógica
O recurso principal que implementa é uma zona, que representa um conjunto de registos DNS que mapeiam nomes de host (nomes de domínio) para endereços IP. Os nomes de hosts que a zona resolve são geralmente nomes DNS locais que não são publicamente acessíveis através da internet.
Cria-se zonas DNS privadas como recursos autónomos e liga-as a redes virtuais específicas criando ligações de rede virtual. Quando os pedidos DNS vêm de clientes dentro dessas redes virtuais, as zonas DNS privadas participam no processo de resolução. Pode criar manualmente entradas numa zona DNS ou configurar o auto-registo de VMs em ligações de rede virtuais. As zonas privadas do DNS do Azure suportam resolução DNS entre redes virtuais em regiões do Azure, mesmo sem fazer peering explícito das redes virtuais. No entanto, todas as redes virtuais devem estar vinculadas à zona DNS privada.
O processo de resolução de nomes DNS envolve múltiplos componentes, incluindo resolvers DNS e camadas intermédias que processam pedidos antes de chegarem aos servidores DNS autoritativos. As zonas privadas utilizam os mesmos protocolos e comportamentos DNS que as zonas públicas, incluindo valores TTL e mecanismos de cache.
Importante
A fiabilidade da sua solução global depende da configuração dos recursos a que os seus registos DNS se referem, como máquinas virtuais e balanceadores de carga.
Este artigo não aborda esses recursos, mas as suas configurações de disponibilidade afetam diretamente a resiliência da sua aplicação. Consulte os guias de fiabilidade para serviços Azure na sua solução para saber como cada serviço suporta os seus requisitos de fiabilidade.
Arquitetura física
O DNS do Azure é um serviço não regional. A Microsoft implementa a sua infraestrutura em múltiplas zonas de disponibilidade em várias regiões do Azure em todo o mundo. Este design permite que o DNS do Azure se mantenha resiliente durante uma interrupção de zona ou região de disponibilidade, porque a infraestrutura noutra zona ou região continua a responder a pedidos de resolução.
Protocolos globais de internet como Anycast, DNS e Border Gateway Protocol (BGP) encaminham automaticamente os pedidos de resolução DNS recebidos para a infraestrutura DNS do Azure saudável mais próxima.
Resiliência a falhas transitórias
Falhas transitórias são falhas curtas e intermitentes em componentes. Eles ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. As falhas transitórias corrigem-se após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente tentando novamente as solicitações afetadas.
Todos os aplicativos hospedados na nuvem devem seguir as diretrizes de tratamento de falhas transitórias do Azure quando se comunicam com quaisquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.
O DNS do Azure trata de falhas transitórias através da sua infraestrutura global de DNS.
Se ocorrer uma falha transitória durante a resolução DNS, o cliente ou o resolvedor intermédio deve tentar novamente o pedido. Configura os valores de timeout adequadamente. Um timeout de 2 a 5 segundos é geralmente suficiente para um cliente DNS.
O tempo de vida (TTL) de cada registo DNS também afeta a forma como a sua solução lida com falhas. Se o TTL for muito baixo, os clientes fazem mais pedidos ao DNS do Azure, o que cria mais oportunidades para falhas transitórias. Se o TTL for muito elevado, no caso de uma falha real num servidor backend que exija redirecionar para outro endereço IP, os clientes podem experienciar atrasos no failover até expirar o TTL. Configure os TTLs cuidadosamente para equilibrar disponibilidade, latência e capacidade de resposta.
Resiliência a falhas na zona de disponibilidade
Zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos para uma das zonas restantes.
O DNS do Azure opera como um serviço não regional. A Microsoft distribui a sua infraestrutura por múltiplas zonas de disponibilidade em várias regiões do Azure e replica alterações nas suas zonas DNS privadas nessa infraestrutura. Não selecionas zonas de disponibilidade nem configuras redundância de zonas. Durante uma interrupção numa zona de disponibilidade, a infraestrutura noutra zona ou região continua a responder a pedidos de resolução.
Se um recurso que implementa numa única zona de disponibilidade, como uma máquina virtual (VM), ficar indisponível durante uma falha de zona, o DNS do Azure continua a devolver o endereço IP configurado do recurso porque não monitoriza a saúde do endpoint. Se fizer failover para um recurso numa zona saudável, é responsável por atualizar o registo DNS para que os clientes usem o recurso saudável. Em alternativa, coloque os recursos atrás de um balanceador de carga redundante de zona que direcione o tráfego para VMs em zonas saudáveis.
Resiliência a falhas em toda a região
As zonas privadas do DNS do Azure são resilientes a falhas de região porque os dados das zonas estão disponíveis globalmente. Se uma região sofrer uma falha, as suas redes virtuais e recursos, como VMs, podem não estar disponíveis, mas a resolução de nomes continua a funcionar.
O exemplo seguinte mostra como os dados privados das zonas permanecem disponíveis em várias regiões. A zona azure.contoso.com privada está ligada a redes virtuais em três regiões: região A, região B e região C. O auto-registo está ativado nas regiões A e B. O diagrama mostra a região A a sofrer uma interrupção:
Suponha que ocorre uma interrupção temporária na região A. VMs nas regiões B e C ainda podem consultar nomes DNS na zona privada, incluindo nomes que estejam automaticamente registados na região A. Podem continuar a resolver o endereço IP do VM1 na região A, mesmo que o 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 a sua solução passe por failover para um substituto do VM1 noutra região. No entanto, como as zonas privadas são globais, pode recriar o VM1 numa rede virtual de outra região para assumir a carga de trabalho.
Se criar redes virtuais e recursos de rede em várias regiões, terá de planear e implementar a sua estratégia para várias regiões para aplicações que exijam recuperação após falha entre regiões.
Resiliência a ameaças de segurança e configurações incorretas
Ataques de segurança e erros de configuração são dois dos riscos de fiabilidade mais significativos para as zonas DNS. Várias classes de ataques visam especificamente a resolução DNS, e uma má configuração acidental pode perturbar as suas cargas de trabalho de forma igualmente severa.
Para orientações de segurança abrangentes específicas para zonas DNS privadas, consulte Proteção de Zonas e Registos DNS privados.
Resiliência face a interrupções de serviço
DNS do Azure é um serviço altamente resiliente, com um SLA de disponibilidade de 100% quando a sua candidatura cumpre certas condições. As falhas de serviço são extremamente invulgares, mas problemas de rede ou de infraestrutura podem perturbar a conectividade ao serviço DNS do Azure.
Monitorizar interrupções de serviço
A Microsoft não o avisa automaticamente quando uma região está indisponível. No entanto, pode usar o Azure Service Health para compreender a saúde geral do serviço, incluindo quaisquer falhas de região, e pode configurar alertas de Saúde do Serviço para o informar sobre problemas.
Teste para interrupções de serviço
O Azure Chaos Studio fornece um conjunto de falhas para simular problemas de resolução DNS. Por exemplo, o agente do Chaos Studio disponibiliza o tipo de falha Falha de DNS, e o Azure Kubernetes Service (AKS) Chaos Mesh disponibiliza a capacidade Caos de DNS. Pode usar estes tipos de falha para testar como as suas aplicações e infraestrutura respondem quando os pedidos de resolução DNS falham, o que pode ocorrer durante uma falha parcial da rede.
Resiliência face a falhas de portais e ferramentas de gestão
Se gerir a sua zona DNS no portal do Azure, prepare-se para cenários em que não possa aceder a ela, especialmente se precisar de reconfigurar a sua zona DNS durante uma falha na plataforma.
Pode usar várias ferramentas para implementar e gerir zonas privadas do DNS do Azure. Aprenda a usar CLI do Azure ou Azure PowerShell para gerir a sua zona privada. Em alternativa, use infraestrutura como código (IaC), como Bicep ou Terraform, para implementar e configurar a sua zona privada. Estas ferramentas mantêm-se operacionais mesmo que o portal Azure esteja degradado.
Backup e restauração
O DNS do Azure é um serviço sem estado. Não fornece backups geridos nem restauração pontual para zonas DNS privadas.
Para preservar a configuração completa dos recursos do Azure, defina as suas zonas DNS privadas usando IaC, como Bicep ou Terraform, e armazene as definições no controlo de versão. Testa periodicamente as definições para que as possas usar para redistribuir a tua configuração.
Resiliência à manutenção de serviços
A Microsoft aplica regularmente atualizações de serviço e realiza outras manutenções. A plataforma Azure gere estas atividades automaticamente, garantindo que a manutenção é fluida e transparente para si. Não é esperado qualquer tempo de indisponibilidade durante os eventos de manutenção, a menos que tenha sido informado através da manutenção planeada do Azure Service Health.
Contrato de nível de serviço
O contrato de nível de serviço (SLA) para serviços do 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 mais informações, consulte Acordos de Nível de Serviço (SLA) para serviços online.
DNS do Azure fornece um SLA de disponibilidade de 100% para respostas válidas a consultas DNS quando cumpre certas condições. Estas condições incluem repetir os pedidos que falharam durante pelo menos 60 segundos consecutivos. Consulte o documento do SLA para as condições detalhadas.