Usar iDNS no Azure Stack Hub
O iDNS é um recurso de rede do Azure Stack Hub que permite que você resolve nomes DNS externos (por exemplo, https://www.bing.com.) ele também permite registrar nomes de rede virtual internos. Ao fazer isso, você pode resolve VMs (máquinas virtuais) 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 o DNS, consulte a Visão geral do DNS do Azure.
O que o iDNS faz?
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 compartilhados para cargas de trabalho de locatário.
- Serviço DNS autoritativo para resolução de nomes e registro de DNS na rede virtual do locatário.
- Serviço DNS recursivo para resolução de nomes de Internet de VMs de locatário. Os locatários não precisam mais especificar entradas DNS personalizadas para resolve nomes da Internet (por exemplo, www.bing.com.)
Você ainda pode trazer seu próprio DNS e usar servidores DNS personalizados. No entanto, usando o iDNS, você pode resolve nomes DNS da Internet e se conectar 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 em que 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 FQDN ( nome de domínio totalmente qualificado ) que pode ser resolvido de qualquer lugar na Internet pública.
O Azure Stack Hub dá suporte apenas ao iDNS para registro de nome interno, portanto, ele não pode fazer o seguinte:
- Criar um registro DNS em uma zona DNS hospedada existente (por exemplo, local.azurestack.external.)
- Criar uma zona DNS (como Contoso.com.)
- Crie um registro em sua própria zona DNS personalizada.
- Suporte à 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, no entanto, em seu próprio compartimento exclusivo definido como um GUID que se correlaciona com a ID da VNET na infraestrutura de SDN em que a VM foi implantada. Os 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 o Rede Virtual, no formato GUID.
Veja a seguir um laboratório simples para demonstrar como isso funciona. Criamos três VMs em uma VNet e outra VM em uma VNet separada:
| VM | vNet | IP Privado | IP público | Rótulo de DNS |
|---|---|---|---|---|
| VM-A1 | VNetA | 10.0.0.5 | 172.31.12.68 | VM-A1-Label.lnv1.cloudapp.azscss.external |
| VM-A2 | VNetA | 10.0.0.6 | 172.31.12.76 | VM-A2-Label.lnv1.cloudapp.azscss.external |
| VM-A3 | VNetA | 10.0.0.7 | 172.31.12.49 | VM-A3-Label.lnv1.cloudapp.azscss.external |
| VM-B1 | VNetB | 10.0.0.4 | 172.31.12.57 | VM-B1-Label.lnv1.cloudapp.azscss.external |
| VNET | GUID | Cadeia de caracteres de sufixo DNS |
|---|---|---|
| VNetA | e71e1db5-0a38-460d-8539-705457a4cf75 | e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local |
| VNetB | e8a6e386-bc7a-43e1-a640-61591b5c76dd | e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local |
Você pode fazer alguns testes de resolução de nomes para entender melhor como o iDNS funciona:
Da VM-A1 (VM do Linux): pesquisando VM-A2. Você pode ver que o sufixo DNS para VNetA é adicionado e o nome é resolvido para 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
A pesquisa de VM-A2-Label sem fornecer o FQDN falha, conforme o 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 resolve VM-B1 (que é de uma VNet diferente) falha, pois esse registro não existe nessa 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 você usar o FQDN para o rótulo DNS, ele será resolvido com êxito:
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
Da VM-A3 (VM do Windows). Observe a diferença entre respostas autoritativas e não autoritativas.
Registros 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
Registros 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
Resumindo, você pode ver no acima que:
- Cada VNet tem sua própria zona, contendo registros A para todos os endereços IP privados, consistindo no nome da VM e no sufixo DNS da VNet (que é 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. Eles são resolvidos como qualquer outro endereço externo.
- Os servidores iDNS são os servidores autoritativos para das próprias zonas DNS internas e também atuam como resolvedores de nomes públicos quando as VMs de locatário tentam se conectar a recursos externos. Se houver uma consulta para um recurso externo, os servidores iDNS encaminharão a solicitação para servidores DNS autoritativos para resolve.
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.