Usar o iDNS no Azure Stack Hub

O iDNS é um recurso de rede do Azure Stack Hub que permite resolver nomes DNS externos (por exemplo, https://www.bing.com.) Ele também permite que você registre nomes de redes virtuais internas. Ao fazer isso, você pode resolver máquinas virtuais (VMs) na mesma rede virtual por nome em vez de endereço IP. Essa abordagem elimina a necessidade de fornecer entradas de servidor DNS personalizadas. Para obter mais informações sobre DNS, consulte Visão geral do DNS do Azure.

O que faz o iDNS?

Com o iDNS no Azure Stack Hub, você obtém os seguintes recursos, sem precisar especificar entradas personalizadas do servidor DNS:

• Serviços de resolução de nomes DNS partilhados para cargas de trabalho de cliente.
• Serviço DNS autoritativo para resolução de nomes e registo DNS na rede virtual do inquilino.
• Serviço DNS recursivo para a resolução de nomes da internet por parte de VMs alugadas. Os locatários não precisam mais especificar entradas DNS personalizadas para resolver nomes da Internet (por exemplo, www.bing.com.)

Você ainda pode trazer seu próprio DNS e usar servidores DNS personalizados. No entanto, usando iDNS, você pode resolver nomes DNS da Internet e conectar-se a outras VMs na mesma rede virtual sem precisar criar entradas DNS personalizadas.

O que o iDNS não faz?

O iDNS não permite que você crie um registro DNS para um nome que possa ser resolvido de fora da rede virtual.

No Azure, você tem a opção de especificar um rótulo de nome DNS associado a um endereço IP público. Você pode escolher o rótulo (prefixo), mas o Azure escolhe o sufixo, que se baseia na região na qual você cria o endereço IP público.

Como mostra a imagem anterior, o Azure criará um registro "A" no DNS para o rótulo de nome DNS especificado na zona westus.cloudapp.azure.com. O prefixo e o sufixo são combinados para compor um nome de domínio totalmente qualificado (FQDN) que pode ser resolvido de qualquer lugar na Internet pública.

O Azure Stack Hub suporta apenas iDNS para registo de nomes internos, pelo que não pode fazer o seguinte:

• Crie um registro DNS em uma zona DNS hospedada existente (por exemplo, local.azurestack.external.)
• Crie uma zona DNS (como Contoso.com.)
• Crie um registo na sua própria zona DNS personalizada.
• Apoie a compra de nomes de domínio.

Demonstração de como o iDNS funciona

Todos os nomes de host para VMs em Redes Virtuais são armazenados como Registros de Recursos DNS na mesma zona, porém em seu próprio compartimento exclusivo definido como um GUID que se correlaciona com a ID da VNET na infraestrutura SDN contra a qual a VM foi implantada. FQDNs (Nomes de Domínio Totalmente Qualificados) da VM do Locatário consistem no nome do computador e na cadeia de caracteres de sufixo DNS para a Rede Virtual, no formato GUID.

A seguir está um laboratório simples para demonstrar como isso funciona. Criamos 3 VMs em uma VNet e outra VM em uma VNet separada:

Você pode fazer alguns testes de resolução de nomes para entender melhor como o iDNS funciona:

A partir de VM-A1 (Linux VM): Ao procurar VM-A2, pode-se ver que o sufixo DNS para VNetA é adicionado e o nome é resolvido para o endereço IP privado:

carlos@VM-A1:~$ nslookup VM-A2
Server:         127.0.0.53
Address:        127.0.0.53#53
 
Non-authoritative answer:
Name:   VM-A2.e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local
Address: 10.0.0.6

Consultar a VM-A2-Label sem fornecer o FQDN falha, como esperado.

carlos@VM-A1:~$ nslookup VM-A2-Label
Server:         127.0.0.53
Address:        127.0.0.53#53
 
** server can't find VM-A2-Label: SERVFAIL

Se você fornecer o FQDN para o rótulo DNS, o nome será resolvido para o IP público:

carlos@VM-A1:~$ nslookup VM-A2-Label.lnv1.cloudapp.azscss.external
Server:         127.0.0.53
Address:        127.0.0.53#53
 
Non-authoritative answer:
Name:   VM-A2-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.76

A tentativa de resolver VM-B1 (que é de uma VNet diferente) falha porque este registo não existe nesta zona.

carlos@caalcobi-vm4:~$ nslookup VM-B1
Server:         127.0.0.53
Address:        127.0.0.53#53
 
** server can't find VM-B1: SERVFAIL

Usar o FQDN para VM-B1 não ajuda, pois esse registro é de uma zona diferente.

carlos@VM-A1:~$ nslookup VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local
Server:         127.0.0.53
Address:        127.0.0.53#53
 
** server can't find VM-B1.e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local: SERVFAIL

Se utilizar o FQDN como rótulo do DNS, a resolução será bem-sucedida.

carlos@VM-A1:~$ nslookup VM-B1-Label.lnv1.cloudapp.azscss.external
Server:         127.0.0.53
Address:        127.0.0.53#53
 
Non-authoritative answer:
Name:   VM-B1-Label.lnv1.cloudapp.azscss.external
Address: 172.31.12.57

De VM-A3 (máquina virtual do Windows). Observe a diferença entre respostas autorizadas e não autorizadas.

Registos internos:

C:\Users\carlos>nslookup
Default Server:  UnKnown
Address:  168.63.129.16
 
> VM-A2
Server:  UnKnown
Address:  168.63.129.16
 
Name:    VM-A2.e71e1db5-0a38-460d-8539-705457ª4cf75.internal.lnv1.azurestack.local
Address:  10.0.0.6

Registos externos:

> VM-A2-Label.lnv1.cloudapp.azscss.external
Server:  UnKnown
Address:  168.63.129.16
 
Non-authoritative answer:
Name:    VM-A2-Label.lnv1.cloudapp.azscss.external
Address:  172.31.12.76

Em suma, você pode ver acima que:

• Cada VNet tem a sua própria zona, contendo registos A para todos os endereços IP privados, que consistem no nome da VM e no sufixo DNS da VNet (que é o seu GUID).
  • <vmname>.<vnetGUID.internal>.<região>.<stackinternalFQDN>
  • Isso é feito automaticamente
• Se você usar endereços IP públicos, também poderá criar rótulos DNS para eles. Estes são resolvidos como qualquer outro endereço externo.
• Os servidores iDNS são os servidores autoritativos para suas zonas DNS internas e também atuam como um resolvedor para nomes públicos quando VMs locatárias tentam se conectar a recursos externos. Se houver uma consulta para um recurso externo, os servidores iDNS encaminham a solicitação para servidores DNS autoritativos para resolver.

Como você pode ver nos resultados do laboratório, você tem controle sobre qual IP é usado. Se você usar o nome da VM, obterá o endereço IP privado e, se usar o rótulo DNS, obterá o endereço IP público.

Próximos passos

Usando o DNS no Azure Stack Hub