Compartilhar via

Resolução de nomes para recursos em redes virtuais do Azure

  • Artigo

Você pode usar o Azure para hospedar soluções de IaaS (infraestrutura como serviço), PaaS (plataforma como serviço) e híbridas. Para facilitar a comunicação entre as VMs (máquinas virtuais) 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:

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.

Observação

Se você usar o DNS fornecido pelo Azure, o sufixo DNS apropriado será aplicado automaticamente às suas VMs. Para todas as outras opções, use FQDNs (nomes de domínio totalmente qualificados) ou aplique manualmente o sufixo DNS apropriado às suas VMs.

Cenário Solução Sufixo DNS
Resolução de nomes entre as VMs localizadas na mesma rede virtual ou nas 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 VMs em diferentes redes virtuais ou instâncias de função em serviços de nuvem diversos. 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 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 de 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 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 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 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.

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. As VMs e as instâncias de um serviço de nuvem usam o mesmo sufixo DNS, por isso, o nome do host por si só é suficiente. Porém, nas redes virtuais implantadas com o modelo de implantação clássico, cada serviço de nuvem tem um sufixo DNS distinto. Nessa situação, você precisa do FQDN para resolver nomes entre diferentes serviços de nuvem.

Nas redes virtuais implantadas com o modelo de implantação do Azure Resource Manager, o sufixo DNS é consistente em todas as VMs de uma rede virtual. Portanto, o FQDN não é necessário. Você pode atribuir nomes DNS a VMs e adaptadores 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.

Observação

Ao usar funções Web e de trabalho nos Serviços de Nuvem do Azure, você também pode acessar os endereços IP internos das instâncias de função usando a API REST do Gerenciamento de Serviços do Azure. Para saber mais, confira Referência de API REST do 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:

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

Considerações

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 de outras redes virtuais.
  • O registro manual dos seus registros não é permitido.
  • Não há suporte para o WINS e NetBIOS. Não será possível ver as VMs 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 VM. 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 precisa ser usado para cada VM de 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 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 o DNS reverso para VMs em todas as redes virtuais baseadas no Azure 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 têm como escopo uma rede virtual específica, mesmo que ela esteja emparelhada com outras redes virtuais. As consultas de DNS reverso para endereços IP de VMs 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 se deve às restrições que permitem que apenas uma zona privada seja vinculada se o registro automático estiver habilitado. 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.

Observação

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. Será necessário gerenciar manualmente os registros de DNS reverso das 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 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

Observação

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

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

Observação

Uma instância de função pode executar a resolução de nomes de máquinas virtuais na 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 VMs em outra rede virtual (FQDN usando o sufixo internal.cloudapp.net) precisam usar o método descrito nesta seção (encaminhamento de servidores DNS personalizados entre as duas redes virtuais).

Diagrama que mostra o DNS entre redes virtuais.

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ê usar sua 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ê 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 melhor desempenho, quando você usar as VMs do Azure como servidores DNS, o IPv6 deverá 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 da porta 53 ignora os NSGs da sub-rede.

Importante

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 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:

  • 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.
  • Se for necessário executar a resolução de nomes do aplicativo Web (criado com o Serviço de Aplicativo) vinculado à rede virtual para VMs em uma rede virtual diferente que não está vinculada à mesma zona privada, use servidores DNS personalizados ou resolvedores privados de DNS do Azure nas duas 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 um Resolvedor Privado de DNS do Azure, confira Links do conjunto de regras.

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.

Observação

As propriedades de conexão de rede, como IPs do servidor DNS, não devem ser editadas diretamente nas VMs. Elas poderão ser apagadas durante a recuperação do serviço quando o adaptador de rede virtual for substituído. Essa advertência se aplica às VMs do Windows e do 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.

Observação

Se você alterar as configurações de DNS para uma rede virtual ou VM que já está implantada, precisará executar uma renovação de concessão DHCP em todas as VMs afetadas na rede virtual para que as novas configurações de DNS entrem em vigor. Para as VMs que executam o sistema operacional Windows, insira ipconfig /renew diretamente na VM. As etapas variam dependendo do sistema operacional. Confira a documentação relevante para seu tipo de sistema operacional.

Conteúdo relacionado

Modelo de implantação do Azure Resource Manager: