Name resolution for resources in Azure virtual networks (Resolução de nomes para recursos em redes virtuais do Azure)
Atenção
Este artigo faz referência ao CentOS, uma distribuição Linux que está se aproximando do status de Fim da Vida Útil (EOL). Por favor, considere o seu uso e planeje de acordo. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.
O Azure pode ser usado para hospedar IaaS, PaaS e soluções híbridas. Para facilitar a comunicação entre as máquinas virtuais (VMs) e outros recursos implantados em uma rede virtual, pode ser necessário permitir que eles se comuniquem entre si. O uso de nomes facilmente lembrados e imutáveis simplifica o processo de comunicação, em vez de depender de endereços IP.
Quando os recursos implantados em redes virtuais precisam resolver nomes de domínio para endereços IP internos, eles podem usar um dos quatro métodos:
Resolução de nomes que usa seu próprio servidor DNS (que pode encaminhar consultas para os servidores DNS fornecidos pelo Azure)
O tipo de resolução de nomes que utiliza depende do modo como os recursos têm de comunicar entre si. A tabela a seguir ilustra cenários e soluções de resolução de nomes correspondentes:
Nota
As zonas privadas do DNS do Azure são a solução preferida e oferecem flexibilidade no gerenciamento de suas zonas e registros DNS. Para obter mais informações, veja Utilizar o DNS do Azure para domínios privados.
Nota
Se você usar o DNS fornecido pelo Azure, o sufixo DNS apropriado será aplicado automaticamente às suas máquinas virtuais. Para todas as outras opções, você deve usar FQDN (Nomes de Domínio Totalmente Qualificados) ou aplicar manualmente o sufixo DNS apropriado às suas máquinas virtuais.
| Cenário | Solução | Sufixo DNS |
|---|---|---|
| Resolução de nomes entre VMs localizadas na mesma rede virtual ou instâncias de função dos Serviços de Nuvem do Azure no mesmo serviço de nuvem. | Zonas privadas do DNS do Azure ou resolução de nomes fornecida pelo Azure | Nome do host ou FQDN |
| Resolução de nomes entre VMs em diferentes redes virtuais ou instâncias de função em diferentes serviços de nuvem. | Zonas privadas do DNS do Azure, Resolvedor Privado de DNS do Azure ou servidores DNS gerenciados pelo cliente encaminhando consultas entre redes virtuais para resolução pelo Azure (proxy DNS). Consulte Resolução de nomes usando seu próprio servidor DNS. | Apenas FQDN |
| Resolução de nomes de um Serviço de Aplicativo do Azure (Aplicativo Web, Função ou Bot) usando a integração de rede virtual para instâncias de função ou VMs na mesma rede virtual. | Azure DNS Private Resolver ou servidores DNS gerenciados pelo cliente encaminhando consultas entre redes virtuais para resolução pelo Azure (proxy DNS). Consulte Resolução de nomes usando seu próprio servidor DNS. | Apenas FQDN |
| Resolução de nomes de Aplicativos Web do Serviço de Aplicativo para VMs na mesma rede virtual. | Azure DNS Private Resolver ou servidores DNS gerenciados pelo cliente encaminhando consultas entre redes virtuais para resolução pelo Azure (proxy DNS). Consulte Resolução de nomes usando seu próprio servidor DNS. | Apenas FQDN |
| Resolução de nomes de Aplicativos Web do Serviço de Aplicativo em uma rede virtual para VMs em uma rede virtual diferente. | Azure DNS Private Resolver ou servidores DNS gerenciados pelo cliente encaminhando consultas entre redes virtuais para resolução pelo Azure (proxy DNS). Consulte Resolução de nomes usando seu próprio servidor DNS. | Apenas FQDN |
| Resolução de nomes de computador e serviço locais de VMs ou instâncias de função no Azure. | Resolvedor Privado de DNS do Azure ou servidores DNS gerenciados pelo cliente (controlador de domínio local, controlador de domínio somente leitura local ou um DNS secundário sincronizado usando transferências de zona, por exemplo). Consulte Resolução de nomes usando seu próprio servidor DNS. | Apenas FQDN |
| Resolução de nomes de host do Azure de computadores locais. | Encaminhando consultas para um servidor proxy DNS gerenciado pelo cliente na rede virtual correspondente, o servidor proxy encaminha consultas para o Azure para resolução. Consulte Resolução de nomes usando seu próprio servidor DNS. | Apenas FQDN |
| DNS reverso para IPs internos. | Zonas privadas do DNS do Azure, resolução de nomes fornecida pelo Azure, Resolvedor Privado de DNS do Azure ou Resolução de nomes usando seu próprio servidor DNS. | Não aplicável |
| Resolução de nomes entre VMs ou instâncias de função localizadas em diferentes serviços de nuvem, não em uma rede virtual. | Não aplicável. A conectividade entre VMs e instâncias de função em diferentes serviços de nuvem não é suportada fora de uma rede virtual. | Não aplicável |
Resolução de nomes fornecida pelo Azure
A resolução de nomes fornecida pelo Azure fornece apenas recursos básicos de DNS autoritativo. O Azure gerencia os nomes e registros de zona DNS se você usar o DNS fornecido pelo Azure. Não é possível controlar os nomes de zona DNS ou o ciclo de vida dos registos DNS. Se precisar de uma solução de DNS completa para as suas redes virtuais, pode utilizar zonas privadas de DNS do Azure com servidores DNS geridos pelo Cliente ou um Resolvedor Privado de DNS do Azure.
Juntamente com a resolução de nomes DNS públicos, o Azure fornece resolução de nomes interna para VMs e instâncias de função que residem na mesma rede virtual ou serviço de nuvem. VMs e instâncias em um serviço de nuvem compartilham o mesmo sufixo DNS, portanto, o nome do host sozinho é suficiente. Mas em redes virtuais implantadas usando o modelo de implantação clássico, diferentes serviços de nuvem têm sufixos DNS diferentes. Nessa situação, você precisa do FQDN para resolver nomes entre diferentes serviços de nuvem. Em redes virtuais implantadas usando o modelo de implantação do Azure Resource Manager, o sufixo DNS é consistente em todas as máquinas virtuais de uma rede virtual, portanto, o FQDN não é necessário. Os nomes DNS podem ser atribuídos a VMs e interfaces de rede. Embora a resolução de nomes fornecida pelo Azure não exija nenhuma configuração, ela não é a escolha apropriada para todos os cenários de implantação, conforme detalhado na tabela anterior.
Nota
Ao usar funções Web e de trabalho de serviços de nuvem, você também pode acessar os endereços IP internos de instâncias de função usando a API REST de Gerenciamento de Serviços do Azure. Para obter mais informações, consulte a Referência da API REST de Gerenciamento de Serviços. O endereço é baseado no nome da função e no número da instância.
Funcionalidades
A resolução de nomes fornecida pelo Azure inclui os seguintes recursos:
Facilidade de utilização. Não é necessária qualquer configuração.
Elevada disponibilidade. Você não precisa criar e gerenciar clusters de seus próprios servidores DNS.
Você pode usar o serviço com seus próprios servidores DNS para resolver nomes de host locais e do Azure.
Você pode usar a resolução de nomes entre VMs e instâncias de função dentro do mesmo serviço de nuvem, sem a necessidade de um FQDN.
Você pode usar a resolução de nomes entre VMs em redes virtuais que usam o modelo de implantação do Azure Resource Manager, sem a necessidade de um FQDN. As redes virtuais no modelo de implantação clássico exigem um FQDN quando você está resolvendo nomes em diferentes serviços de nuvem.
Você pode usar nomes de host que melhor descrevam suas implantações, em vez de trabalhar com nomes gerados automaticamente.
Considerações
Pontos a considerar quando estiver a utilizar a resolução de nomes fornecida pelo Azure:
O sufixo DNS criado pelo Azure não pode ser modificado.
A pesquisa de DNS tem como escopo uma rede virtual. Os nomes DNS criados para uma rede virtual não podem ser resolvidos a partir de outras redes virtuais.
Não é possível registar manualmente os seus próprios registos.
WINS e NetBIOS não são suportados. Não consegue ver as suas VMs no Explorador do Windows.
Os nomes de host devem ser compatíveis com DNS. Os nomes devem usar apenas 0-9, a-z e '-', e não podem começar ou terminar com um '-'.
O tráfego de consulta DNS é limitado para cada VM. A limitação não deve afetar a maioria dos aplicativos. Se a limitação de solicitações for observada, verifique se o cache do lado do cliente está habilitado. Para obter mais informações, consulte Configuração do cliente DNS.
Use um nome diferente para cada máquina virtual em uma rede virtual para evitar problemas de resolução de DNS.
Apenas VMs nos primeiros 180 serviços de nuvem são registradas para cada rede virtual em um modelo de implantação clássico. Este limite não se aplica a redes virtuais no Azure Resource Manager.
O endereço IP DNS do Azure é 168.63.129.16. Este endereço é um endereço IP estático e não é alterado.
Considerações sobre DNS reverso
O DNS reverso para VMs tem suporte em todas as redes virtuais baseadas no Azure Resource Manager. Os registros de DNS reverso (PTR) gerenciados pelo Azure do formulário [vmname].internal.cloudapp.net são adicionados automaticamente quando você inicia uma VM e removidos quando a VM é interrompida (deslocalizada). Veja o seguinte exemplo:
C:\>nslookup -type=ptr 10.11.0.4
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
4.0.11.10.in-addr.arpa name = myeastspokevm1.internal.cloudapp.net
A zona DNS reversa internal.cloudapp.net é gerenciada pelo Azure e não pode ser exibida ou editada diretamente. A pesquisa direta no FQDN do formulário [vmname].internal.cloudapp.net resolve para o endereço IP atribuído à máquina virtual.
Se uma zona privada do DNS do Azure estiver vinculada à rede virtual com um link de rede virtual e o registro automático estiver habilitado nesse link, as consultas DNS reversas retornarão dois registros. Um registro é da forma [vmname].[ privatednszonename] e o outro é do formato [vmname].internal.cloudapp.net. Veja o seguinte exemplo:
C:\>nslookup -type=ptr 10.20.2.4
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
4.2.20.10.in-addr.arpa name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa name = mywestvm1.azure.contoso.com
Quando dois registros PTR são retornados como mostrado anteriormente, a pesquisa direta de qualquer FQDN retorna o endereço IP da VM.
As pesquisas reversas de DNS têm como escopo uma determinada rede virtual, mesmo que ela esteja emparelhada com outras redes virtuais. Consultas DNS reversas para endereços IP de máquinas virtuais localizadas em redes virtuais emparelhadas retornam NXDOMAIN.
Nota
Os registos de DNS reverso (PTR) não são armazenados numa zona DNS privada de encaminhamento. Os registros DNS reversos são armazenados em uma zona DNS reversa (in-addr.arpa). A zona DNS reversa padrão associada a uma vnet não é visível ou editável.
Você pode desabilitar a função DNS reversa em uma rede virtual criando sua própria zona de pesquisa inversa usando zonas privadas do DNS do Azure e, em seguida, vinculando essa zona à sua rede virtual. Por exemplo, se o espaço de endereço IP da sua rede virtual for 10.20.0.0/16, você poderá criar uma zona DNS privada vazia 20.10.in-addr.arpa e vinculá-la à rede virtual. Esta zona substitui as zonas de pesquisa inversa padrão para a rede virtual. Esta zona está vazia. DNS reverso retorna NXDOMAIN, a menos que você crie manualmente essas entradas.
Não há suporte para o registro automático de registros PTR. Se desejar criar entradas, introduza-as manualmente. Você deve desativar o registro automático na rede virtual se ele estiver habilitado para outras zonas. Esta limitação deve-se a restrições que permitem que apenas uma zona privada seja ligada se o registo automático estiver ativado. Consulte o guia de início rápido de DNS privado para obter detalhes sobre como criar uma zona DNS privada e vinculá-la a uma rede virtual.
Nota
Como as zonas privadas do DNS do Azure são globais, você pode criar uma pesquisa reversa de DNS para abranger várias redes virtuais. Para fazer isso, crie uma zona privada do DNS do Azure para pesquisas inversas (uma zona in-addr.arpa ) e vincule-a às redes virtuais. Você terá que gerenciar manualmente os registros DNS reversos para as VMs.
Configuração do cliente DNS
Esta seção aborda o cache do lado do cliente e as tentativas do lado do cliente.
Cache do lado do cliente
Nem todas as consultas DNS precisam ser enviadas pela rede. O cache do lado do cliente ajuda a reduzir a latência e melhorar a resiliência a blips de rede, resolvendo consultas DNS recorrentes a partir de um cache local. Os registros DNS contêm um mecanismo TTL (time-to-live), que permite que o cache armazene o registro pelo maior tempo possível sem afetar a atualização do registro. Assim, o cache do lado do cliente é adequado para a maioria das situações.
O cliente DNS padrão do Windows tem um cache DNS interno. Algumas distribuições Linux não incluem cache por padrão. Se você achar que ainda não há um cache local, adicione um cache DNS a cada VM Linux.
Há muitos pacotes de cache DNS diferentes disponíveis (como dnsmasq). Veja como instalar o dnsmasq nas distribuições mais comuns:
RHEL/CentOS (usa NetworkManager):
Instale o pacote dnsmasq com o seguinte comando:
sudo yum install dnsmasqHabilite o serviço dnsmasq com o seguinte comando:
systemctl enable dnsmasq.serviceInicie o serviço dnsmasq com o seguinte comando:
systemctl start dnsmasq.serviceUse um editor de texto para adicionar
prepend domain-name-servers 127.0.0.1;ao /etc/dhclient-eth0.conf:Use o seguinte comando para reiniciar o serviço de rede:
service network restart
Nota
O pacote dnsmasq é apenas um dos muitos caches DNS disponíveis para Linux. Antes de usá-lo, verifique sua adequação às suas necessidades específicas e verifique se nenhum outro cache está instalado.
Tentativas do lado do cliente
O DNS é principalmente um protocolo UDP. Como o protocolo UDP não garante a entrega de mensagens, a lógica de repetição é tratada no próprio protocolo DNS. Cada cliente DNS (sistema operacional) pode exibir uma lógica de repetição diferente, dependendo da preferência do criador:
- Os sistemas operacionais Windows tentam novamente após um segundo e, em seguida, novamente após mais dois segundos, quatro segundos e outros quatro segundos.
- A configuração padrão do Linux tenta novamente após cinco segundos. Recomendamos alterar as especificações de repetição para cinco vezes, em intervalos de um segundo.
Verifique as configurações atuais em uma VM Linux com cat /etc/resolv.conf. Veja a linha de opções , por exemplo:
options timeout:1 attempts:5
O arquivo resolv.conf é gerado automaticamente e não deve ser editado. As etapas específicas para adicionar a linha de opções variam de acordo com a distribuição:
RHEL/CentOS (usa NetworkManager):
Use um editor de texto para adicionar a linha
RES_OPTIONS="options timeout:1 attempts:5"ao arquivo /etc/sysconfig/network-scripts/ifcfg-eth0.Use o seguinte comando para reiniciar o serviço NetworkManager:
systemctl restart NetworkManager.service
Resolução de nomes que utiliza o seu próprio servidor DNS
Esta seção aborda VMs, instâncias de função e aplicativos Web.
Nota
O Resolvedor Privado de DNS do Azure substitui a necessidade de usar servidores DNS baseados em VM em uma rede virtual. A seção a seguir é fornecida se você deseja usar uma solução de DNS baseada em VM, no entanto, há muitos benefícios em usar o Resolvedor Privado de DNS do Azure, incluindo redução de custos, alta disponibilidade interna, escalabilidade e flexibilidade.
VMs e instâncias de função
Suas necessidades de resolução de nomes podem ir além dos recursos fornecidos pelo Azure. Por exemplo, talvez seja necessário usar domínios do Ative Directory do Microsoft Windows Server, resolver nomes DNS entre redes virtuais. Para cobrir esses cenários, o Azure permite que você use seus próprios servidores DNS.
Os servidores DNS dentro de uma rede virtual podem encaminhar consultas DNS para os resolvedores recursivos no Azure. Este procedimento permite que você resolva nomes de host dentro dessa rede virtual. Por exemplo, um controlador de domínio (DC) em execução no Azure pode responder a consultas DNS para seus domínios e encaminhar todas as outras consultas para o Azure. O encaminhamento de consultas permite que as VMs vejam seus recursos locais (por meio do DC) e os nomes de host fornecidos pelo Azure (por meio do encaminhador). O acesso aos resolvedores recursivos no Azure é disponibilizado através do IP virtual 168.63.129.16.
Importante
Se o Gateway de VPN estiver sendo usado nessa configuração junto com IP de servidor DNS personalizado na VNet, o IP DNS do Azure (168.63.129.16) também precisará ser adicionado à lista para manter o serviço sem interrupções.
O encaminhamento de DNS também permite a resolução de DNS entre redes virtuais e permite que suas máquinas locais resolvam nomes de host fornecidos pelo Azure. Para resolver o nome de host de uma VM, a VM do servidor DNS deve residir na mesma rede virtual e ser configurada para encaminhar consultas de nome de host para o Azure. Como o sufixo DNS é diferente em cada rede virtual, você pode usar regras de encaminhamento condicional para enviar consultas DNS para a rede virtual correta para resolução. A imagem a seguir mostra duas redes virtuais e uma rede local fazendo a resolução DNS entre redes virtuais, usando esse método. Um exemplo de encaminhador DNS está disponível na galeria de Modelos de Início Rápido do Azure e no GitHub.
Nota
Uma instância de função pode executar a resolução de nomes de VMs dentro da mesma rede virtual. Ele faz isso usando o FQDN, que consiste no nome do host da VM e internal.cloudapp.net sufixo DNS. No entanto, nesse caso, a resolução de nomes só será bem-sucedida se a instância de função tiver o nome da VM definido no esquema de função (arquivo .cscfg).
<Role name="<role-name>" vmName="<vm-name>">
As instâncias de função que precisam executar a resolução de nomes de VMs em outra rede virtual (FQDN usando o sufixo internal.cloudapp.net ) precisam fazer isso usando o método descrito nesta seção (encaminhamento de servidores DNS personalizados entre as duas redes virtuais).
Quando você estiver usando a resolução de nomes fornecida pelo Azure, o DHCP (Dynamic Host Configuration Protocol) do Azure fornece um sufixo DNS interno (.internal.cloudapp.net) para cada VM. Esse sufixo permite a resolução de nomes de host porque os registros de nome de host estão na zona de internal.cloudapp.net . Quando você está usando sua própria solução de resolução de nomes, esse sufixo não é fornecido às VMs porque interfere com outras arquiteturas DNS (como cenários de ingresso no domínio). Em vez disso, o Azure fornece um espaço reservado não funcional (reddog.microsoft.com).
Se necessário, você pode determinar o sufixo DNS interno usando o PowerShell ou a API:
- Para redes virtuais em modelos de implantação do Azure Resource Manager, o sufixo está disponível por meio da API REST da interface de rede, do cmdlet Get-AzNetworkInterface PowerShell e do comando az network nic show Azure CLI.
Se o encaminhamento de consultas para o Azure não atender às suas necessidades, forneça sua própria solução de DNS ou implante um Resolvedor Privado de DNS do Azure.
Se você fornecer sua própria solução de DNS, ela precisará:
Forneça uma resolução de nome de host apropriada, via DDNS, por exemplo. Se estiver a utilizar DDNS, poderá ter de desativar a eliminação de registos DNS. As concessões de DHCP do Azure são longas e a eliminação pode remover registros DNS prematuramente.
Fornecer resolução recursiva apropriada para permitir a resolução de nomes de domínio externos.
Ser acessível (TCP e UDP na porta 53) a partir dos clientes que atende e ser capaz de acessar a internet.
Estar protegido contra o acesso da Internet, para mitigar ameaças representadas por agentes externos.
Nota
- Para obter o melhor desempenho, quando você estiver usando VMs do Azure como servidores DNS, o IPv6 deve ser desabilitado.
- Os NSGs atuam como firewalls para seus pontos de extremidade do resolvedor de DNS. Você deve modificar ou substituir suas regras de segurança NSG para permitir o acesso da Porta UDP 53 (e, opcionalmente, da Porta TCP 53) aos seus pontos de extremidade de ouvinte DNS. Uma vez que os servidores DNS personalizados são definidos em uma rede, o tráfego através da porta 53 ignorará os NSG da sub-rede.
Importante
Se você estiver usando Servidores DNS do Windows como Servidores DNS Personalizados encaminhando solicitações DNS para Servidores DNS do Azure, certifique-se de aumentar o valor de Tempo Limite de Encaminhamento em mais de 4 segundos para permitir que os Servidores DNS Recursivos do Azure executem operações de recursão adequadas.
Para obter mais informações sobre esse problema, consulte Tempos limite de resolução de encaminhadores e encaminhadores condicionais.
Essa recomendação também pode se aplicar a outras plataformas de servidor DNS com valor de tempo limite de encaminhamento de 3 segundos ou menos.
Se não o fizer, os registos da Zona DNS Privada poderão ser resolvidos com endereços IP públicos.
Web Apps
Suponha que você precise executar a resolução de nomes do seu aplicativo Web criado usando o Serviço de Aplicativo, vinculado a uma rede virtual, para VMs na mesma rede virtual. Além de configurar um servidor DNS personalizado que tenha um encaminhador DNS que encaminhe consultas para o Azure (IP virtual 168.63.129.16), execute as seguintes etapas:
Habilite a integração de rede virtual para seu aplicativo Web, se ainda não tiver sido concluída, conforme descrito em Integrar seu aplicativo a uma rede virtual.
Se você precisar executar a resolução de nomes do seu aplicativo Web vinculado a vnet (criado usando o Serviço de Aplicativo) para VMs em uma vnet diferente que não esteja vinculada à mesma zona privada, use servidores DNS personalizados ou Resolvedores Privados de DNS do Azure em ambas as vnets.
Para usar servidores DNS personalizados:
Configure um servidor DNS em sua rede virtual de destino, em uma VM que também possa encaminhar consultas para o resolvedor recursivo no Azure (IP virtual 168.63.129.16). Um exemplo de encaminhador DNS está disponível na galeria de Modelos de Início Rápido do Azure e no GitHub.
Configure um encaminhador DNS na rede virtual de origem em uma VM. Configure este encaminhador DNS para encaminhar consultas para o servidor DNS na rede virtual de destino.
Configure o servidor DNS de origem nas configurações da rede virtual de origem.
Habilite a integração de rede virtual para que seu aplicativo Web seja vinculado à rede virtual de origem, seguindo as instruções em Integrar seu aplicativo a uma rede virtual.
Para usar um Resolvedor Privado de DNS do Azure, consulte Links do conjunto de regras.
Especificar servidores DNS
Quando estiver a utilizar os seus próprios servidores DNS, o Azure permite-lhe especificar vários servidores DNS por rede virtual. Também pode especificar vários servidores DNS por interface de rede (para o Azure Resource Manager) ou por serviço cloud (para o modelo de implementação clássico). Os servidores DNS especificados para uma interface de rede ou serviço de nuvem têm precedência sobre os servidores DNS especificados para a rede virtual.
Nota
As propriedades de conexão de rede, como IPs de servidor DNS, não devem ser editadas diretamente em VMs. Isso ocorre porque eles podem ser apagados durante a recuperação do serviço quando o adaptador de rede virtual é substituído. Isso se aplica a VMs Windows e Linux.
Ao usar o modelo de implantação do Azure Resource Manager, você pode especificar servidores DNS para uma rede virtual e uma interface de rede. Para obter detalhes, consulte Gerenciar uma rede virtual e Gerenciar uma interface de rede.
Nota
Se optar por um servidor DNS personalizado para a sua rede virtual, tem de especificar pelo menos um endereço IP do servidor DNS; caso contrário, a rede virtual ignorará a configuração e usará o DNS fornecido pelo Azure.
Nota
Se você alterar as configurações de DNS de uma rede virtual ou máquina virtual já implantada, para que as novas configurações de DNS entrem em vigor, você deverá executar uma renovação de concessão DHCP em todas as VMs afetadas na rede virtual. Para VMs que executam o sistema operacional Windows, você pode fazer isso digitando ipconfig /renew diretamente na VM. As etapas variam dependendo do sistema operacional. Consulte a documentação relevante para o seu tipo de SO.
Próximos passos
Modelo de implantação do Azure Resource Manager: