Name resolution for resources in Azure virtual networks (Resolução de nomes para recursos em redes virtuais do Azure)

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:

• Zonas privadas do DNS do Azure

• Resolução de nomes fornecida pelo Azure

• Resolução de nomes que usa seu próprio servidor DNS (que pode encaminhar consultas para os servidores DNS fornecidos pelo Azure)

• Azure DNS Private Resolver

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:

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.

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 ao DNS 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.

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.

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:

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:

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.

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 para 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.

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.

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.

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.

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.

Próximos passos

Modelo de implantação do Azure Resource Manager:

• Gerenciar uma rede virtual

• Gerenciar uma interface de rede