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.
O DNS do Azure proporciona resolução de nomes utilizando a infraestrutura do Microsoft Azure. Este artigo foca-se nas zonas DNS públicas, que normalmente cria para domínios que possui e utiliza para publicar registos de aplicações e serviços disponíveis na internet. Os nomes de host que resolves são nomes DNS acessíveis publicamente, e os endereços IP resolvidos são geralmente endereços IP públicos acessíveis pela internet.
O DNS do Azure é um serviço não regional que não está vinculado a uma zona de disponibilidade específica ou região do Azure.
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 as zonas públicas do DNS do Azure respondem a falhas transitórias, falhas de zonas de disponibilidade, falhas regionais, interrupções de serviço, ameaças de segurança e má configuração, falhas de portais e ferramentas de gestão, e manutenção de serviços. Descreve também como proteger e restaurar a configuração da sua zona e explica os principais requisitos de acordo de nível de serviço (SLA).
Recomendações de implantação de produção para confiabilidade
Para implementações em produção de zonas públicas DNS do Azure, siga estas recomendações para aumentar a fiabilidade:
Delegue para todos os servidores de nomes: O DNS do Azure atribui quatro servidores de nomes a cada zona DNS pública. Configura a delegação do teu domínio para usar os quatro servidores de nomes. Esta configuração proporciona isolamento de falhas e é necessária para se qualificar para o SLA do DNS do Azure.
Configure os valores TTL adequados: Defina valores de time-to-live (TTL) que equilibrem o volume de consultas e a rapidez com que os clientes recebem alterações nos registos. Valores TTL mais baixos permitem que os clientes recebam alterações mais cedo, mas aumentam o volume de consultas. Valores de TTL mais elevados reduzem o volume de consultas, mas podem atrasar o failover após alterar um registo.
Use registos de alias para recursos Azure suportados:Os registos de alias refletem automaticamente alterações a um recurso Azure subjacente durante a resolução de DNS e ajudam a evitar registos DNS obsoletos.
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 implementas é uma zona, que contém os conjuntos de registos DNS de um domínio. Um conjunto de registos 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 através 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 cria a zona. Depois de a delegação estar em vigor, cria-se conjuntos de registos para os tipos de registos DNS que o DNS do Azure suporta. Também pode criar registos de alias que referenciam recursos do Azure, como endereços IP públicos, perfis do Traffic Manager e endpoints do Azure Front Door, para que o registo DNS permaneça sincronizado com o recurso alvo.
Durante a resolução de DNS, os resolvers recursivos de DNS seguem a hierarquia DNS para chegar aos servidores de nomes autoritativos do DNS do Azure para a sua zona.
Importante
O DNS do Azure resolve nomes, mas não monitoriza a saúde dos endpoints nem encaminha o tráfego da aplicação. 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 opera como um serviço não regional e 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 BGP encaminham automaticamente os pedidos de resolução DNS para a infraestrutura DNS do Azure saudável mais próxima.
A camada de serviço do DNS do Azure funciona numa configuração ativo-ativo, assente em duas pilhas de serviço independentes: uma executada em Linux e outra executada em Windows. Estas plataformas não partilham nem código nem hardware subjacente. Por serem independentes, um bug, vulnerabilidade ou falha que afete uma pilha não afeta a outra. Esta independência reduz o risco de uma interrupção total do serviço causada por um único ponto de falha e ajuda a proteger contra certas classes de vulnerabilidades zero-day.
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 de DNS, o cliente ou o resolvedor intermédio deve tentar novamente de acordo com a sua política de repetição de DNS configurada. Entre 2 e 5 segundos é geralmente um tempo 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 precisam de fazer mais pedidos ao DNS do Azure e há mais oportunidades potenciais para surgirem 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 públicas 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 DNS são resilientes a falhas de região porque os dados das zonas estão globalmente disponíveis e são implementados em múltiplas regiões do Azure. Se uma região tiver uma falha, os recursos que implementaste nessa região, como redes virtuais e VMs, podem não estar disponíveis, mas o DNS do Azure continua a resolver registos na tua zona.
Se tiver uma solução que precise de alternar entre várias regiões, como para fins de recuperação de desastres, considere usar o Gestor de Tráfego do Azure ou o Azure Front Door. Estes serviços fornecem capacidades automáticas de failover, que pode usar se uma região não for saudável.
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 públicas, consulte Proteger a implementação do seu DNS do Azure e Proteger Zonas e Registos DNS.
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 interrupções de serviço são extremamente invulgares, mas problemas de rede ou de outras infraestruturas podem perturbar a conectividade ao serviço DNS do Azure.
A resiliência do DNS do Azure deve-se em parte à sua arquitetura globalmente distribuída de planos de serviço ativo-ativo.
Utilizar múltiplos servidores de nomes
O DNS do Azure atribui quatro servidores de nomes a cada zona DNS pública. Quando delegares o teu domínio, configura os quatro servidores de nomes. Se um resolvedor não consegue aceder a um servidor de nomes, pode consultar outro.
Monitorizar interrupções de serviço
Use o Azure Service Health para monitorizar o estado de saúde do DNS do Azure. Configure alertas de Saúde do Serviço para o notificar sobre incidentes de serviço.
Teste para interrupções de serviço
O Azure Chaos Studio disponibiliza falhas que simulam falhas na resolução de DNS em alguns tipos de cargas de trabalho de teste. Estas falhas não desencadeiam uma falha no DNS do Azure. O agente do Chaos Studio disponibiliza a falha Falha de DNS, e o AKS Chaos Mesh disponibiliza a funcionalidade DNS Chaos. Use estas falhas para testar como as suas aplicações e infraestrutura respondem quando a resolução DNS falha, como durante uma falha parcial da rede.
Resiliência face a falhas de portais e ferramentas de gestão
Se gerir a sua zona DNS pública no portal do Azure, prepare um caminho alternativo de gestão para cenários em que não possa aceder ao portal, especialmente se precisar de reconfigurar a zona durante uma interrupção.
Se o portal do Azure não estiver disponível, utilize o CLI do Azure, o Azure PowerShell ou o infrastructure as code (IaC) como Bicep ou Terraform para gerir a sua zona DNS pública. 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 públicas.
Para preservar a configuração completa dos recursos do Azure, defina as suas zonas DNS públicas usando IaC, como Bicep ou Terraform, e armazene as definições no controlo de versão. Teste as definições periodicamente para que possa usá-las para redistribuir a sua configuração.
Como opção adicional de recuperação ao nível do registo, exporte um ficheiro de zona compatível com BIND. A importação de ficheiros de zona tem limitações e não preserva todas as definições de recursos específicas do Azure, por isso não uses um ficheiro de zona exportado como único artefacto de recuperação. Revise as limitações de importação documentadas e verifique os registos depois de restaurar uma zona.
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, desde que certas condições sejam cumpridas. Estas condições incluem tentar novamente pedidos falhados repetidamente durante, pelo menos, 60 segundos consecutivos e usar todos os servidores de nomes que o DNS do Azure atribui à sua zona. Consulte o documento do SLA para as condições detalhadas.