Resolução de nomes para recursos em redes virtuais do Azure
Cuidado
Este artigo faz referência ao CentOS, uma distribuição do Linux que está se aproximando do status de EOL (fim da vida útil). Considere seu uso e planeje adequadamente. Para obter mais informações, veja as Diretrizes sobre fim da vida útil do CentOS.
O Azure pode ser usado para hospedar soluções IaaS, PaaS e 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 que não mudam e são fáceis de lembrar simplifica o processo de comunicação, em vez de depender de endereços IP.
Quando os recursos implantados nas redes virtuais precisam resolver os nomes de domínio para endereços IP internos, eles podem usar um desses quatro métodos:
Resolução de nome 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 usado depende de como seus recursos precisam se comunicar entre si. A tabela a seguir ilustra os cenários e as soluções de resolução de nomes correspondentes:
Observação
As zonas privadas do DNS do Azure são a solução preferida e oferecem flexibilidade no gerenciamento de zonas e registros DNS. Para ver mais informações, consulte Como usar o DNS do Azure para domínios privados.
Observação
Se você usar o DNS fornecido pelo Azure, o sufixo apropriado será aplicado automaticamente às suas máquinas virtuais. Para todas as outras opções, você deve usar nomes de domínio totalmente qualificados (FQDN) ou aplicar manualmente o sufixo DNS apropriado às suas máquinas virtuais.
| Cenário | Solução | Sufixo DNS |
|---|---|---|
| A resolução de nomes entre as 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 serviços de nuvem diversos. | Zonas privadas do DNS do Azure, Resolvedor Privado de DNS do Azure ou Servidores DNS gerenciados pelo cliente que encaminham consultas entre redes virtuais para resolução pelo Azure (proxy DNS). Confira Resolução de nomes usando o seu próprio servidor DNS. | Somente 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 localizadas na mesma rede virtual. | Resolvedor Privado de DNS do Azure ou Servidores DNS gerenciados pelo cliente que encaminham consultas entre redes virtuais para resolução pelo Azure (proxy DNS). Confira Resolução de nomes usando o seu próprio servidor DNS. | Somente FQDN |
| Resolução de nomes de Aplicativos Web do Serviço de Aplicativo para VMs na mesma rede virtual. | Resolvedor Privado de DNS do Azure ou Servidores DNS gerenciados pelo cliente que encaminham consultas entre redes virtuais para resolução pelo Azure (proxy DNS). Confira Resolução de nomes usando o seu próprio servidor DNS. | Somente FQDN |
| Resolução de nomes de Aplicativos Web do Serviço de Aplicativo em uma rede virtual para VMs em redes virtuais diferentes. | Resolvedor Privado de DNS do Azure ou Servidores DNS gerenciados pelo cliente que encaminham consultas entre redes virtuais para resolução pelo Azure (proxy DNS). Confira Resolução de nomes usando o seu próprio servidor DNS. | Somente FQDN |
| Resolução de nomes de computador e de serviço locais em 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 DNS secundário sincronizado usando transferências de zona, por exemplo). Confira Resolução de nomes usando o seu próprio servidor DNS. | Somente FQDN |
| Resolução de nomes de host do Azure de computadores locais. | Encaminhe consultas para um servidor de proxy DNS gerenciado pelo cliente na rede virtual correspondente. O servidor proxy encaminha consultas para resolução pelo Azure. Confira Resolução de nomes usando o seu próprio servidor DNS. | Somente FQDN |
| DNS inverso para IPs internos. | Zonas privadas do DNS do Azure, resolução de nome 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 serviços de nuvem diferentes, não em uma rede virtual. | Não aplicável. Não há suporte para a conectividade entre VMs e instâncias de função em diferentes serviços de nuvem 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 da zona DNS se você usar o DNS fornecido pelo Azure. Você não pode controlar os nomes de zona DNS ou o ciclo de vida dos registros DNS. Se você precisar de uma solução de DNS com todos os recursos para as redes virtuais, poderá usar as zonas privadas de DNS do Azure com os Servidores DNS gerenciados pelo cliente ou um Resolvedor Privado de DNS do Azure.
Junto com a resolução de nomes DNS públicos, o Azure fornece uma 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, por isso somente o nome do host já é suficiente. Porém, em redes virtuais implantadas usando o modelo de implantação clássico, serviços de nuvem diferentes têm sufixos DNS distintos. 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 em uma rede virtual, portanto, o FQDN não é necessário. Os nomes DNS podem ser atribuídos a VMs e a adaptadores de rede. Embora a resolução de nomes fornecida pelo Azure não exija configurações, não é a opção apropriada para todos os cenários de implantação, conforme detalhado na tabela anterior.
Observação
Ao usar funções Web e de trabalho nos serviços de nuvem, você também pode acessar os endereços IP internos das instâncias de função utilizando a API REST do Gerenciamento de Serviços do Azure. Para saber mais, veja Referência da API REST de Gerenciamento de Serviços. O endereço se baseia no nome da função e no número da instância.
Recursos
A resolução de nomes fornecida pelo Azure inclui os seguintes recursos:
Facilidade de uso. Nenhuma configuração é necessária.
Alta 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 as VMs e as instâncias de função no 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 ao resolver nomes em diferentes serviços de nuvem.
Você pode usar nomes de host que descrevem melhor as suas implantações, em vez de trabalhar com nomes gerados automaticamente.
Considerações
Pontos que devem ser considerados ao usar a resolução de nomes fornecida pelo Azure:
Não será possível modificar o sufixo DNS criado pelo Azure.
A pesquisa de DNS está no escopo de uma rede virtual. Os nomes DNS criados para uma rede virtual não podem ser resolvidos de outras redes virtuais.
Não será possível registrar manualmente seus próprios registros.
Não há suporte para o WINS e NetBIOS. Não será possível ver as VMs no Windows Explorer.
Os nomes de host devem ser compatíveis com DNS. Os nomes deverão usar apenas 0-9, a-z e '-' e não poderão começar ou terminar com um '-'.
O tráfego da consulta DNS é restrita a cada VM. Essa limitação não deve afetar a maioria dos aplicativos. Se a limitação da solicitação for observada, certifique-se de que o armazenamento em cache do cliente está habilitado. Para saber mais, veja Configuração de cliente DNS.
Use um nome diferente para cada máquina virtual em uma rede virtual para evitar problemas de resolução de DNS.
Apenas as VMs dos primeiros 180 serviços de nuvem são registradas para cada rede virtual em um modelo de implantação clássico. Esse limite não se aplica às redes virtuais no Azure Resource Manager.
O endereço IP do DNS do Azure é 168.63.129.16. Este é um endereço IP estático e não muda.
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 no formato [vmname].internal.cloudapp.net serão adicionados automaticamente quando você iniciar uma VM e removidos quando a VM for interrompida (desalocada). Consulte 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 é possível exibi-la ou editá-la diretamente. A pesquisa direta no FQDN do formato [vmname].internal.cloudapp.net resolve o endereço IP atribuído à máquina virtual.
Se uma Zona privada 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 está no formato [vmname].[privatednszonename] e o outro está no formato [vmname].internal.cloudapp.net. Consulte 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 retornarem conforme mostrado anteriormente, a pesquisa direta de qualquer FQDN retorna o endereço IP da VM.
As pesquisas de DNS reverso têm como escopo uma determinada rede virtual, mesmo que seja emparelhada com outras redes virtuais. As consultas DNS reverso para endereços IP de máquinas virtuais localizadas em redes virtuais com emparelhamento retornam NXDOMAIN.
Observação
Os registros de DNS reverso (PTR) não são armazenados em uma zona de DNS privada de encaminhamento. Os registros de DNS reverso são armazenados em uma zona de DNS reverso (in-addr.arpa). A zona DNS reversa padrão associada a uma vnet não é visível ou editável.
É possível desabilitar a função de DNS reverso em uma rede virtual criando sua própria zona de pesquisa inversa usando zonas privadas DNS do Azure e, em seguida, vinculando essa zona à rede virtual. Por exemplo, se o espaço de endereços IP da 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. Essa zona substitui as zonas de pesquisa inversa padrão para a rede virtual. Essa zona está vazia. O DNS reverso retorna NXDOMAIN, a menos que você crie essas entradas manualmente.
Não há suporte para o registros automático de registros PTR. Se você quiser criar entradas, insira-as manualmente. Você deve desabilitar o registro automático na rede virtual se estiver habilitado para outras zonas. Essa limitação se deve a restrições que permitem que apenas uma zona privada seja vinculada se o registro automático estiver habilitado. 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.
Observação
Como as zonas privadas DNS do Azure são globais, você poderá criar uma pesquisa de DNS reverso para abranger várias redes virtuais. Para fazer isso, crie uma zona privada DNS do Azure para pesquisas inversas (uma zona in-addr.arpa) e vincule-a às redes virtuais. Será necessário gerenciar manualmente os registros DNS reversos para as VMs.
Configuração do cliente DNS
Esta seção aborda o armazenamento em cache do lado do cliente e tentativas do lado do cliente.
Armazenamento em cache do lado do cliente
Nem todas as consultas DNS precisam ser enviada pela rede. O armazenamento em cache do lado do cliente ajuda a reduzir a latência e melhorar a resistência a pontos de luz de rede resolvendo consultas de DNS recorrentes a partir de um cache local. Os registros DNS contêm um mecanismo Time-To-Live (TTL) que permite que o cache armazene o registro o maior tempo possível sem afetar a atualização de registro. Como resultado disso, 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 do Linux não incluem cache por padrão. Se você desconfiar que não haja um cache local, adicione um cache DNS a cada VM Linux.
Há muitos pacotes diferentes de cache de DNS 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;a /etc/dhclient-eth0.conf:Use o seguinte comando para reiniciar o serviço de rede:
service network restart
Observação
O pacote dnsmasq é apenas um dos vários caches DNS disponíveis para o Linux. Antes de usá-lo, verifique sua adequação para suas necessidades específicas e se nenhum outro cache está instalado.
Tentativa 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 é manipulada no próprio protocolo DNS. Cada cliente DNS (sistema operacional) pode apresentar uma lógica de repetição diferente dependendo da preferência dos criadores:
- Os sistemas operacionais Windows tentam novamente após um segundo e, em seguida, novamente após mais dois, quatro e outros quatro segundos.
- A configuração padrão do Linux tenta novamente após cinco segundos. É recomendável 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. Examine a linha options, 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 options 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 do NetworkManager:
systemctl restart NetworkManager.service
Resolução de nome usando seu próprio servidor DNS
Esta seção aborda as VMs, as instâncias de função e os aplicativos Web.
Observação
O Resolvedor Privado 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 DNS baseada em VM, no entanto, há muitos benefícios para usar o Resolvedor Privado 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, pode ser necessário usar os domínios do Active Directory do Microsoft Windows Server e resolver os nomes de DNS entre as redes virtuais. Para cobrir esses cenários, o Azure permite que você use seus próprios servidores DNS.
Os servidores DNS em uma rede virtual podem encaminhar consultas DNS para os resolvedores recursivos no Azure. Esse procedimento permite que você resolva os nomes de host dentro dessa rede virtual. Por exemplo, um DC (controlador de domínio) em execução no Azure pode responder a consultas DNS de seus domínios e encaminhar todas as outras consultas ao Azure. O encaminhamento de consultas permite que as VMs vejam tanto seus recursos locais (pelo DC) quanto nomes de host fornecidos pelo Azure (pelo encaminhador). O acesso a resolvedores recursivos no Azure é fornecido por meio da 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 do DNS do Azure (168.63.129.16) também precisará ser adicionado à lista para manter o serviço não ininterrupto.
O encaminhamento do DNS também possibilita a resolução do DNS entre redes virtuais e permite que os computadores locais resolvam nomes de host fornecidos pelo Azure. Para resolver o nome de host da VM, a VM do servidor DNS deve residir na mesma rede virtual e ser configurado para encaminhar consultas de nome de host ao Azure. Como o sufixo DNS é diferente em cada rede virtual, você pode usar regras de encaminhamento condicionais para enviar consultas DNS a fim de serem resolvidas pela rede virtual correta. A imagem a seguir mostra duas redes virtuais e uma rede local fazendo a resolução do DNS entre redes virtuais usando esse método. Um encaminhador DNS de exemplo está disponível na galeria de Modelos de Início Rápido do Azure e no GitHub.
Observação
Uma instância de função pode executar a resolução de nomes de máquinas virtuais na mesma rede virtual. Isso é feito usando o FQDN, que consiste no nome do host da VM e o sufixo DNS internal.cloudapp.net. 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 (servidores DNS de encaminhamento personalizados entre as duas redes virtuais).
Quando você estiver usando a resolução de nomes fornecida pelo Azure, o protocolo DHCP do Azure fornecerá um sufixo DNS interno (.internal.cloudapp.net) para cada VM. Esse sufixo permite que a resolução de nomes do host, assim como os registros de nomes do host, estejam na zona internal.cloudapp.net. Quando você estiver usando sua própria solução de resolução de nomes, esse sufixo não será fornecido às VMs porque interferirá em outras arquiteturas de DNS (como cenários conectados ao 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 as redes virtuais nos modelos de implantação do Azure Resource Manager, o sufixo está disponível por meio da API REST da interface de rede ou por meio do cmdlet do PowerShell Get-AzNetworkInterface e o comando CLI do Azure az network nic show.
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.
Se você fornecer sua própria solução de DNS, será necessário:
Fornecer resolução de nome do host apropriada, por exemplo, por meio de DDNS. Se estiver usando DDNS, talvez será necessário desabilitar a limpeza de registros DNS. As concessões de DHCP do Azure são longas e a eliminação pode remover os registros DNS prematuramente.
Fornecer a resolução recursiva apropriada para permitir a resolução de nomes de domínio externo.
Ser acessível (TCP e UDP na porta 53) dos clientes a que ela serve e ser capaz de acessar a Internet.
Ter proteção contra acesso da Internet, para atenuar as ameaças impostas por agentes externos.
Observação
- Para melhor desempenho, quando estiver usando VMs do Azure como servidores DNS, o IPv6 deverá ser desabilitado.
- Os NSGs atuam como firewalls para os pontos de extremidade do resolvedor de DNS. Você deve modificar ou substituir as regras de segurança do NSG para permitir o acesso à porta UDP 53 (e, opcionalmente, à porta TCP 53) aos pontos de extremidade do ouvinte do DNS. Depois que os servidores DNS personalizados são definidos em uma rede, o tráfego pela porta 53 passa a ignorar os NSGs da sub-rede.
Importante
Se você estiver usando Servidores DNS do Windows como Servidores DNS Personalizados que encaminham solicitações DNS para Servidores DNS do Azure, aumente o valor do Tempo Limite de Encaminhamento em mais de 4 segundos a fim de permitir que Servidores DNS Recursivos do Azure executem operações de recursão adequadas.
Para obter mais informações sobre esse problema, confira Tempo limite de resolução de encaminhadores e encaminhadores condicionais.
Essa recomendação também pode ser aplicada a outras plataformas de Servidor DNS com valor de tempo limite de encaminhamento de 3 segundos ou menos.
Se isso não for feito, os registros da Zona DNS Privada poderão ser resolvidos com endereços IP públicos.
Aplicativos Web
Suponha que você precise executar a resolução de nome de seu aplicativo Web criado usando o Serviço de Aplicativo, vinculado a uma rede virtual, para as VMs na mesma rede virtual. Além de configurar um servidor DNS personalizado que tenha um encaminhador DNS para encaminhar as consultas para o Azure (IP virtual 168.63.129.16), execute as seguintes etapas:
Habilite a integração da rede virtual para seu aplicativo Web, caso não tenha feito isso, conforme descrito em Integrar o aplicativo a uma rede virtual.
Se for necessário executar a resolução de nomes do 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 Resolvedor Privado de DNS do Azure em ambas as vnets.
Para usar servidores DNS personalizados:
Configure um servidor DNS na sua rede virtual de destino em uma VM que também pode encaminhar consultas para um resolvedor recursivo do Azure (IP virtual 168.63.129.16). Um encaminhador DNS de exemplo está disponível na galeria de Modelos de Início Rápido do Azure e no GitHub.
Configure um encaminhador de DNS na rede virtual de origem em uma VM. Configure o encaminhador de DNS para encaminhar consultas para o servidor DNS em sua rede virtual de destino.
Configure o servidor DNS de origem nas configurações da sua rede virtual de origem.
Habilite a integração da rede virtual para seu aplicativo Web para vincular à rede virtual de origem seguindo as instruções em Integrar seu aplicativo com uma rede virtual.
Para usar um Resolvedor Privado de DNS do Azure, consulte Links do conjunto de regras.
Especificar servidores de DNS
Quando você usa seus próprios servidores DNS, o Azure permite que você especifique vários servidores DNS por rede virtual. Você também pode especificar diversos servidores DNS por adaptador de rede (para o Azure Resource Manager) ou por um serviço de nuvem (para o modelo de implantação clássico). Os servidores DNS especificados para um adaptador de rede ou serviço de nuvem têm precedência sobre aqueles especificados para a rede virtual.
Observação
As propriedades de conexão de rede, como os IPs de servidor DNS, não devem ser editadas diretamente em máquinas virtuais do Windows. Isso ocorre porque eles podem ser apagados durante a recuperação do serviço quando o adaptador de rede virtual é substituído. Este artigo se aplica a VMs do Windows e do Linux.
Ao usar o modelo de implantação do Azure Resource Manager, será possível especificar servidores DNS para uma rede virtual e uma interface de rede. Para ver os detalhes, consulte Gerenciar uma rede virtual e Gerenciar um adaptador de rede.
Observação
Se você optar pelo servidor DNS personalizado para a sua rede virtual, você precisará 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.
Observação
Se você alterar as configurações de DNS para uma rede virtual ou máquina virtual que já está implantada, deverá executar uma renovação de concessão DHCP em todas as VMs afetadas na rede virtual para que as novas configurações entrem em vigor. 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. Confira a documentação relevante para seu tipo de sistema operacional.
Próximas etapas
Modelo de implantação do Azure Resource Manager: