Partilhar via


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

Você pode usar o Azure para hospedar infraestrutura como serviço (IaaS), plataforma como serviço (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:

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.

As zonas DNS Privadas 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 VMs. 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 VMs.

Scenario 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 DNS Privadas 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 DNS Privadas 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. Encaminhe 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 DNS Privadas 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 DNS privadas do Azure com servidores DNS geridos pelo cliente ou o 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 VMs em uma rede virtual, portanto, o FQDN não é necessário. Você pode atribuir nomes DNS 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 opção apropriada para todos os cenários de implantação, conforme descrito na tabela anterior.

Nota

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 a API REST do 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:

  • Você não precisa configurar nada.
  • Você não precisa criar e gerenciar clusters de seus próprios servidores DNS devido à alta disponibilidade.
  • 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 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 de host que melhor descrevam suas implantações, em vez de trabalhar com nomes gerados automaticamente.

Considerações

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

  • 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 é permitido o registo manual dos 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 a 9, a a z e um hífen (-). Os nomes não podem começar ou terminar com um hífen.
  • O tráfego de consulta DNS é limitado para cada VM. A limitação não deve afetar a maioria dos aplicativos. Se você observar a limitação de solicitações, verifique se o cache do lado do cliente está habilitado. Para obter mais informações, consulte Configuração do cliente DNS.
  • Um nome diferente deve ser usado para cada VM 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 Gestor de Recursos.
  • 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 é suportado em todas as redes virtuais baseadas no Resource Manager. DNS reverso gerenciado pelo Azure, também conhecido como ponteiro (PTR), os registros de formulário \[vmname\].internal.cloudapp.net são adicionados automaticamente ao DNS quando você inicia uma VM. Eles são 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 internal.cloudapp.net zona DNS reversa é gerenciada pelo Azure e não pode ser exibida ou editada diretamente. A pesquisa direta no FQDN do formulário \[vmname\].internal.cloudapp.net é resolvida para o endereço IP atribuído à VM.

Se uma zona DNS Privada 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 registo é da forma \[vmname\].[privatednszonename] e o outro é da forma \[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 rede virtual específica, mesmo que ela esteja emparelhada com outras redes virtuais. Consultas DNS reversas para endereços IP de VMs localizadas em redes virtuais emparelhadas retornam NXDOMAIN.

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 rede virtual não é visível ou editável.

Você pode desativar a função DNS reversa em uma rede virtual. Crie sua própria zona de pesquisa inversa usando zonas DNS Privadas do Azure. Em seguida, vincule 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 20.10.in-addr.arpa DNS privada vazia 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 quiser 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. Para obter informações sobre como criar uma zona DNS privada e vinculá-la a uma rede virtual, consulte o Guia de início rápido do DNS Privado do Azure.

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. Você precisa criar uma zona DNS Privada do Azure para pesquisas inversas (uma in-addr.arpa zona) e, em seguida, vinculá-la às redes virtuais. Você precisa 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 de tempo de vida, que permite que o cache armazene o registro pelo 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 integrado. 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.

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

RHEL (usa NetworkManager)

  1. Instale o dnsmasq pacote com o seguinte comando:

    sudo yum install dnsmasq
    
  2. Habilite o dnsmasq serviço com o seguinte comando:

    systemctl enable dnsmasq.service
    
  3. Inicie o dnsmasq serviço 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
    

Nota

O dnsmasq pacote é 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 UDP (User Datagram Protocol). 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 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. Veja a options linha, por exemplo:

options timeout:1 attempts:5

O resolv.conf arquivo é gerado automaticamente e não deve ser editado. As etapas específicas para adicionar a linha variam de acordo com a options distribuição.

RHEL (usa 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 NetworkManager serviço:

    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ê quiser usar uma solução de DNS baseada em VM. Os muitos benefícios de usar o Azure DNS Private Resolver 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 domínios do Ative Directory do Windows Server para resolver nomes DNS entre redes virtuais. Para cobrir esses cenários, você pode usar seus próprios servidores DNS.

Os servidores DNS dentro de uma rede virtual podem encaminhar consultas DNS para os resolvedores recursivos no Azure. Usando este procedimento, você pode resolver 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 do Azure for usado nessa configuração junto com IPs de servidor DNS personalizados em uma rede virtual, o IP DNS do Azure (168.63.129.16) deverá 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.

Duas redes virtuais e uma rede local usam esse método para fazer a resolução DNS entre redes virtuais, conforme mostrado no diagrama a seguir. 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 usa o FQDN, que consiste no nome do host da VM e no sufixo internal.cloudapp.net DNS. 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 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 nome de host porque os registros de nome de internal.cloudapp.net host estão na zona. Quando você usa sua própria solução de resolução de nomes, esse sufixo não é fornecido para VMs porque interfere com outras arquiteturas DNS (como cenários de ingresso em 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 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 o Resolvedor Privado de DNS do Azure.

Se você fornecer sua própria solução de DNS, ela precisará:

  • Forneça a resolução apropriada do nome do host, via DNS dinâmico (DDNS), por exemplo. Se você usa DDNS, talvez seja necessário desativar a eliminação de registros 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.
  • Esteja protegido contra o acesso da Internet para mitigar ameaças representadas por agentes externos.

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

Os NSGs (grupos de segurança de rede) atuam como firewalls para os pontos de extremidade do resolvedor de DNS. Modifique ou substitua 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. Depois que os servidores DNS personalizados são definidos em uma rede, o tráfego através da porta 53 ignora os NSGs da sub-rede.

Importante

Se você usar 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 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, 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 valores de tempo limite de encaminhamento de três segundos ou menos.

Se isso não for feito, os registros de 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:

  • Se ainda não o fez, habilite a integração de rede virtual para seu aplicativo Web, conforme descrito em Integrar seu aplicativo a uma rede virtual.
  • Se você precisar executar a resolução de nomes do seu aplicativo Web vinculado à rede virtual (criado usando o Serviço de Aplicativo) para VMs em uma rede virtual diferente que não esteja vinculada à mesma zona privada, use servidores DNS personalizados ou Resolvedores Privados de DNS do Azure em ambas as redes virtuais.

Para usar servidores DNS personalizados:

  • Configure um servidor DNS em sua rede virtual de destino em uma VM que também pode 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 vincule à rede virtual de origem seguindo as instruções em Integrar seu aplicativo a uma rede virtual.

Para usar o Resolvedor Privado de DNS do Azure, consulte Links do conjunto de regras.

Especificar servidores DNS

Ao usar seus próprios servidores DNS, você pode especificar vários servidores DNS por rede virtual. Você também pode especificar vários servidores DNS por interface de rede (para o Gerenciador de Recursos) ou por serviço de nuvem (para o modelo de implantaçã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. Eles podem ser apagados durante a recuperação do serviço quando o adaptador de rede virtual é substituído. Esse cuidado se aplica a VMs Windows e Linux.

Ao usar o modelo de implantação do Gerenciador de Recursos, você pode especificar servidores DNS para uma rede virtual e uma interface de rede. Para obter mais informações, consulte Gerenciar uma rede virtual e Gerenciar uma interface de rede.

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 VM 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, insira ipconfig /renew diretamente na VM. As etapas variam dependendo do sistema operacional. Consulte a documentação relevante para o seu tipo de SO.

Modelo de implantação do Azure Resource Manager: