Configurar a resolução de nomes DNS para redes virtuais do Azure

As redes virtuais do Azure dão suporte a vários métodos de resolução de nomes para IaaS (infraestrutura como serviço), PaaS (plataforma como serviço) e soluções híbridas. Para habilitar a comunicação entre máquinas virtuais e outros recursos em uma rede virtual, você precisa de uma configuração DNS adequada. Usar nomes facilmente lembrados e consistentes 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:

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.

As zonas de DNS privado do Azure são a solução preferencial e oferecem flexibilidade no gerenciamento de registros e zonas DNS. Para ver mais informações, confira Usar o DNS do Azure para domínios privados.

Note

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 FQDNs (nomes de domínio totalmente qualificados) ou aplicar manualmente o sufixo DNS apropriado às suas máquinas virtuais.

Scenario Solution sufixo DNS
Resolução de nomes entre máquinas virtuais 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 de DNS privado do Azure ou resolução de nomes fornecida pelo Azure Nome do host ou FQDN
Resolução de nomes entre máquinas virtuais em diferentes redes virtuais ou instâncias de função em diferentes serviços de nuvem. zonas de DNS privado 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 máquinas virtuais 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 máquinas virtuais 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 máquinas virtuais em uma rede virtual diferente. 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 computadores e serviços locais de instâncias de função ou máquinas virtuais 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 por meio de 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 de DNS gerenciada pelo cliente na rede virtual correspondente. O servidor proxy encaminha consultas para o Azure para resolução. Confira Resolução de nomes usando o seu próprio servidor DNS. Somente FQDN
DNS inverso para IPs internos. zonas de DNS privado do Azure, resolução de nomes fornecida pelo Azure, Resolvedor Privado de DNS do Azure ou resolução de nomes usando seu servidor DNS. Não aplicável
Resolução de nomes entre máquinas virtuais ou instâncias de função localizadas em diferentes serviços de nuvem, não em uma rede virtual. Não aplicável. Não há suporte para conectividade entre máquinas virtuais 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 oferece apenas funcionalidades básicas 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 precisar de uma solução de DNS com todos os recursos para as redes virtuais, use as zonas de DNS privado do Azure com os servidores DNS gerenciados pelo cliente ou um Resolvedor Privado de DNS do Azure.

Juntamente com a resolução de nomes DNS públicos, o Azure oferece resolução de nome interno para máquinas virtuais e instâncias de função dentro da mesma rede virtual ou serviço de nuvem. Máquinas virtuais e instâncias em um serviço de nuvem compartilham o mesmo sufixo DNS, o que torna o nome do host suficiente por si só para a resolução. No entanto, em redes virtuais de modelo de implantação clássicas, diferentes serviços de nuvem têm sufixos DNS distintos, exigindo que o FQDN resolva nomes em 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. Você pode atribuir nomes DNS a máquinas virtuais e interfaces de rede. Embora a resolução de nomes fornecida pelo Azure não exija nenhuma configuração, ela não é a opção apropriada para todos os cenários de implantação, conforme descrito na tabela anterior.

Note

Ao usar as funções web e de trabalho dos Serviços de Nuvem do Azure, você também pode acessar os endereços IP internos das instâncias de função usando o modelo de implantação clássico do Azure. Para obter mais informações, consulte a referência do modelo de implantação clássico. O endereço se baseia no nome da função e no número da instância.

Features

A resolução de nomes fornecida pelo Azure inclui os seguintes recursos:

  • Você não precisa configurar nada.
  • Você não precisa criar nem gerenciar clusters dos seus servidores DNS devido à alta disponibilidade.
  • Você pode usar o serviço com seus servidores DNS para resolver os nomes do host locais e do Azure.
  • Você pode usar a resolução de nomes entre máquinas virtuais e 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 máquinas virtuais em redes virtuais que usam o modelo de implantação do Resource Manager, sem a necessidade de um FQDN. As redes virtuais no modelo de implantação clássico exigem um FQDN quando você resolve nomes em diferentes serviços de nuvem.
  • Você pode usar nomes do host que descrevem melhor as implantações, em vez de usar nomes gerados automaticamente.

Considerations

Ao usar a resolução de nomes fornecida pelo Azure, considere os seguintes pontos:

  • 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 a partir de outras redes virtuais.
  • O registro manual dos seus registros não é permitido.
  • Não há suporte para o WINS e NetBIOS. Você não pode ver suas máquinas virtuais no Windows Explorer.
  • Os nomes do host precisam ser compatíveis com o DNS. Os nomes devem usar apenas 0 a 9, a a z e um hífen (-). Os nomes não podem começar nem terminar com hifens.
  • O tráfego da consulta DNS é restrita a cada máquina virtual. Essa limitação não deve afetar a maioria dos aplicativos. Se você observar a limitação de solicitações, verifique se o armazenamento em cache do lado do cliente está habilitado. Para saber mais, veja Configuração de cliente DNS.
  • Um nome diferente deve ser usado para cada máquina virtual em uma rede virtual para evitar problemas de resolução de DNS.
  • Somente as máquinas virtuais nos 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 do 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 o DNS reverso

Há suporte para DNS reverso para máquinas virtuais em todas as redes virtuais com base no Resource Manager. O DNS reverso gerenciado pelo Azure, também conhecido como PTR (ponteiro), registros no formato \[vmname\].internal.cloudapp.net são adicionados automaticamente ao DNS quando você inicia uma VM. Eles são removidos quando a VM é 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 de DNS reverso internal.cloudapp.net é gerenciada pelo Azure e não pode ser exibida nem editada diretamente. A pesquisa direta no FQDN com o formato \[vmname\].internal.cloudapp.net é resolvida para o endereço IP atribuído à VM.

Se uma zona de DNS privado do Azure estiver vinculada à rede virtual com um link de rede virtual e o registro automático estiver habilitado nesse link, as consultas de DNS reverso retornarão dois registros. Um registro tem o formato \[vmname\].[privatednszonename] e o outro, \[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 são retornados conforme mostrado anteriormente, a pesquisa direta de um dos FQDN retorna o endereço IP da VM.

As pesquisas de DNS reverso estão limitadas a uma rede virtual específica, mesmo que a rede esteja emparelhada com outras redes virtuais. As consultas DNS inversas para endereços IP de máquinas virtuais localizadas em redes virtuais emparelhadas retornam NXDOMAIN.

Os registros (PTR) de DNS reverso não são armazenados em uma zona de DNS privado de encaminhamento. Os registros DNS reverso são armazenados em uma zona de DNS reverso (in-addr.arpa). A zona de DNS reverso padrão associada a uma rede virtual não é visível nem editável.

Você pode desabilitar a função de DNS reverso em uma rede virtual. Crie sua zona de pesquisa inversa usando as zonas de DNS privado do Azure. Em seguida, vincule essa zona à sua 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 de DNS privado 20.10.in-addr.arpa vazia 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 existe devido a restrições que permitem que apenas uma zona privada seja vinculada se a autoregistração estiver habilitada. Para obter mais informações sobre como criar uma zona de DNS privado e vinculá-la a uma rede virtual, confira o início rápido do DNS privado do Azure.

Note

Como as zonas de DNS privado do Azure são globais, você pode criar uma pesquisa de DNS reverso para abranger várias redes virtuais. Você precisa criar uma zona de DNS privado do Azure para pesquisas inversas (uma zona in-addr.arpa) e vinculá-la às redes virtuais. Você precisa gerenciar manualmente os registros DNS reversos para as máquinas virtuais.

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 a aumentar a resistência a problemas ocorridos na rede, resolvendo consultas de DNS recorrentes a partir de um cache local. Os registros DNS contêm um mecanismo de vida útil, que permite que o cache armazene o registro o maior tempo possível sem afetar a atualização do registro. 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.

Muitos pacotes de cache DNS diferentes estão disponíveis (como dnsmasq). Veja como instalar o dnsmasq nas distribuições mais comuns:

RHEL (usa o NetworkManager)

  1. Instale o pacote dnsmasq com o seguinte comando:

    sudo yum install dnsmasq

  2. Habilite o serviço dnsmasq com o seguinte comando:

    systemctl enable dnsmasq.service

  3. Inicie o serviço dnsmasq com o seguinte comando:

    systemctl start dnsmasq.service

  4. Use um editor de texto para adicionar prepend domain-name-servers 127.0.0.1; a /etc/dhclient-eth0.conf:

  5. Use o seguinte comando para reiniciar o serviço de rede:

    service network restart

Note

O pacote dnsmasq é apenas um dos vários caches DNS disponíveis para o Linux. Antes de usá-lo, verifique a adequação dele às 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. Recomendamos que você altere 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. Observe 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 usadas para adicionar a linha options variam de acordo com a distribuição.

RHEL (usa o NetworkManager)

  1. Use um editor de texto para adicionar a linha RES_OPTIONS="options timeout:1 attempts:5" ao arquivo /etc/sysconfig/network-scripts/ifcfg-eth0.

  2. Use o seguinte comando para reiniciar o serviço NetworkManager:

    systemctl restart NetworkManager.service

Resolução de nome usando seu próprio servidor DNS

Esta seção aborda máquinas virtuais, instâncias de função e aplicativos Web.

Note

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 será fornecida se você quiser usar uma solução de DNS baseada em VM. Os vários benefícios do uso do Resolvedor Privado de DNS do Azure incluem redução de custos, alta disponibilidade interna, escalabilidade e flexibilidade.

Máquinas virtuais 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 os domínios do Windows Server Active Directory para resolver os nomes DNS entre as redes virtuais. Para abordar esses cenários, você pode usar servidores DNS próprios.

Os servidores DNS em uma rede virtual podem encaminhar consultas DNS para os resolvedores recursivos no Azure. Usando esse procedimento, você pode resolver nomes do host nessa 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 máquinas virtuais vejam os recursos locais (por meio do DC) e os nomes de host fornecidos pelo Azure (por meio do encaminhador). O acesso a resolvedores recursivos no Azure é fornecido por meio da IP virtual 168.63.129.16.

Important

Se o Gateway de VPN do Azure for usado nessa configuração, acompanhado de IPs do servidor DNS personalizado em uma rede virtual, o IP do DNS do Azure (168.63.129.16) precisará ser adicionado à lista para manter o serviço sem interrupção.

O encaminhamento de DNS também possibilita a resolução de DNS entre redes virtuais e permite que os computadores locais resolvam nomes do 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.

Duas redes virtuais e uma rede local usam esse método para fazer a resolução de DNS entre redes virtuais, conforme mostrado no diagrama a seguir. Um encaminhador DNS de exemplo está disponível na galeria de Modelos de Início Rápido do Azure e no GitHub.

Note

Uma instância de função pode realizar a resolução de nomes de máquinas virtuais dentro da mesma rede virtual. Ele usa o FQDN, que consiste no nome do host da VM e no sufixo DNS internal.cloudapp.net. 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 máquinas virtuais em outra rede virtual, usando o sufixo FQDN internal.cloudapp.net, precisam usar o método descrito nesta seção (encaminhamento de servidores DNS personalizados entre as duas redes virtuais).

![Diagrama mostrando o DNS entre redes virtuais](./media/virtual-networks-name-resolution-for-virtual machines-and-role-instances/inter-vnet-dns.png).

Quando você usa a resolução de nomes fornecida pelo Azure, o protocolo DHCP do Azure fornece um sufixo DNS interno (.internal.cloudapp.net) para cada VM. Esse sufixo permite a resolução de nomes do host porque os registros de nome do host estão na zona internal.cloudapp.net. Quando você usa sua própria solução de resolução de nomes, esse sufixo não é aplicado às máquinas virtuais porque ele interfere em outras arquiteturas DNS (como cenários unidos ao domínio). Em vez disso, Azure fornece um espaço reservado não funcional (reddog.microsoft.com).

Se necessário, você poderá determinar o sufixo DNS interno usando o PowerShell ou a API.

Para as redes virtuais nos modelos de implantação do Resource Manager, o sufixo está disponível por meio da API REST do adaptador de rede ou por meio do cmdlet do PowerShell Get-AzNetworkInterface e do comando da CLI do Azure az network nic show.

Se o encaminhamento de consultas para o Azure não atender às suas necessidades, forneça uma solução de DNS própria ou implante o Resolvedor Privado de DNS do Azure.

Se você fornecer sua própria solução de DNS, será necessário:

  • Fornecer uma resolução de nomes do host apropriada, por exemplo, por meio do DDNS (DNS dinâmico). Se você usar DDNS, convém desabilitar a limpeza de registro de DNS. As concessões DHCP do Azure são longas e a limpeza 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 o acesso pela Internet para atenuar as ameaças impostas por agentes externos.

Para obter melhor desempenho, quando você usa máquinas virtuais do Azure como servidores DNS, o IPv6 deve ser desabilitado.

Os NSGs (grupos de segurança de rede) funcionam como firewalls para os pontos de extremidade do resolvedor de DNS. Modifique ou substitua as regras de segurança do NSG para permitir o acesso à porta UDP 53 (e, opcionalmente, à porta TCP 53) nos pontos de extremidade do ouvinte de DNS. Depois que os servidores DNS personalizados são definidos em uma rede, o tráfego por meio da porta 53 ignora os NSGs da sub-rede e da NIC.

Important

Se você usar os servidores DNS do Windows como servidores DNS personalizados que encaminham solicitações DNS para os servidores DNS do Azure, aumente o valor de Tempo Limite de Encaminhamento em mais de quatro 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, 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 valores de tempo limite de encaminhamento de três segundos ou menos.

Se isso não for feito, os registros da zona de DNS privado poderão ser resolvidos com endereços IP públicos.

Aplicativos Web

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 máquinas virtuais 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:

  • Caso ainda não tenha feito isso, habilite a integração de rede virtual no aplicativo Web, conforme descrito em Integrar seu aplicativo a uma rede virtual.
  • Para executar a resolução de nomes do aplicativo web vinculado à sua rede virtual (criado usando o Serviço de Aplicativo) para máquinas virtuais em uma rede virtual diferente que não está vinculada à mesma zona privada, use servidores DNS personalizados ou Resolvedores Privados do DNS do Azure em ambas as redes virtuais.

Para usar servidores DNS personalizados:

  • Configure um servidor DNS na rede virtual de destino em uma VM que também possa 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, a fim de vinculá-lo à rede virtual de origem seguindo as instruções descritas em Integrar seu aplicativo a uma rede virtual.

Para usar DNS do Azure Resolvedor Privado, consulte Ruleset links.

Especificar servidores de DNS

Ao usar servidores DNS próprios, você pode especificar vários servidores DNS por rede virtual. Você também pode especificar vários servidores DNS por adaptador de rede (para o Resource Manager) ou por 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.

Note

As propriedades de conexão de rede, como IPs de servidor DNS, não devem ser editadas diretamente em máquinas virtuais. Elas poderão ser apagadas durante a recuperação do serviço quando o adaptador de rede virtual for substituído. Esse cuidado se aplica às máquinas virtuais Windows e Linux.

Ao usar o modelo de implantação do Resource Manager, você poderá especificar servidores DNS para uma rede virtual e um adaptador de rede. Para obter mais informações, confira Gerenciar uma rede virtual e Gerenciar um adaptador de rede.

Se você optar pelo servidor DNS personalizado para a rede virtual, precisará especificar, pelo menos, um endereço IP do servidor DNS. Caso contrário, a rede virtual vai ignorar a configuração e usar o DNS fornecido pelo Azure.

Note

Depois de alterar as configurações de DNS para uma rede virtual implantada ou máquina virtual, renove a concessão de DHCP em todas as máquinas virtuais afetadas na rede virtual para aplicar as novas configurações. Para máquinas virtuais do Windows, execute ipconfig /renew diretamente na VM. Para outros sistemas operacionais, consulte a documentação específica.

Conteúdo relacionado

Modelo de implantação do Azure Resource Manager:

  • Last updated on