Utilizar o iDNS no Azure Stack Hub
O iDNS é uma funcionalidade de rede do Azure Stack Hub que lhe permite resolver nomes DNS externos (por exemplo, https://www.bing.com.) também lhe permite registar nomes de rede virtual internos. Ao fazê-lo, pode resolver máquinas virtuais (VMs) na mesma rede virtual por nome e não por endereço IP. Esta abordagem elimina a necessidade de fornecer entradas de servidor DNS personalizadas. Para obter mais informações sobre o DNS, veja Descrição Geral do DNS do Azure.
O que faz o iDNS?
Com o iDNS no Azure Stack Hub, obtém as seguintes capacidades, sem ter de especificar entradas personalizadas do servidor DNS:
- Serviços de resolução de nomes DNS partilhados para cargas de trabalho de inquilino.
- Serviço DNS autoritativo para resolução de nomes e registo DNS na rede virtual do inquilino.
- Serviço DNS recursivo para resolução de nomes da Internet a partir de VMs de inquilino. Os inquilinos já não precisam de especificar entradas DNS personalizadas para resolver nomes da Internet (por exemplo, www.bing.com.)
Ainda pode trazer o seu próprio DNS e utilizar servidores DNS personalizados. No entanto, ao utilizar o iDNS, pode resolver nomes DNS da Internet e ligar a outras VMs na mesma rede virtual sem ter de criar entradas DNS personalizadas.
O que não faz o iDNS?
O iDNS não lhe permite criar um registo DNS para um nome que possa ser resolvido fora da rede virtual.
No Azure, tem a opção de especificar uma etiqueta de nome DNS associada a um endereço IP público. Pode escolher a etiqueta (prefixo), mas o Azure escolhe o sufixo, que se baseia na região em que cria o endereço IP público.
Como mostra a imagem anterior, o Azure criará um registo "A" no DNS para a etiqueta de nome DNS especificada na zona westus.cloudapp.azure.com. O prefixo e o sufixo são combinados para compor um nome de domínio completamente qualificado (FQDN) que pode ser resolvido a partir de qualquer lugar na Internet pública.
O Azure Stack Hub só suporta iDNS para registo de nomes internos, pelo que não pode fazer as seguintes ações:
- Criar um registo DNS numa zona DNS alojada existente (por exemplo, local.azurestack.external.)
- Criar uma zona DNS (como Contoso.com.)
- Crie um registo na sua própria zona DNS personalizada.
- Suporte para a compra de nomes de domínio.
Demonstração de como funciona o iDNS
Todos os nomes de anfitrião para VMs em Redes Virtuais são armazenados como Registos de Recursos DNS na mesma zona, no entanto, no seu próprio compartimento exclusivo definido como um GUID que se correlaciona com o ID da VNET na infraestrutura de SDN na qual a VM foi implementada. Os Nomes de Domínio Completamente Qualificados (FQDNs) da VM do Inquilino consistem no nome do computador e na cadeia de sufixo DNS para o Rede Virtual, no formato GUID.
Segue-se um laboratório simples para demonstrar como isto funciona. Criámos 3 VMs numa VNet e noutra VM numa VNet separada:
| VM | vNet | IP privado | IP público | Etiqueta 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 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 |
Pode fazer alguns testes de resolução de nomes para compreender melhor como funciona o iDNS:
A partir da VM-A1 (VM do Linux): a procurar a VM-A2. Pode ver que o sufixo DNS para VNetA foi 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
Procurar VM-A2-Label sem fornecer o FQDN falha, conforme 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 fornecer o FQDN para a etiqueta 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
Tentar resolver a 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
A utilização do FQDN para VM-B1 não ajuda, uma vez que este registo é 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 para a etiqueta DNS, este 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
A partir da VM-A3 (VM do Windows). Repare na diferença entre respostas autoritárias e não autoritativas.
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, pode ver a partir do acima que:
- Cada VNet tem a sua própria zona, que contém registos A para todos os endereços IP privados, que consistem no nome da VM e no sufixo DNS da VNet (que é o respetivo GUID).
- <vmname>.<vnetGUID.internal>.<região>.<stackinternalFQDN>
- Isto é feito automaticamente
- Se utilizar endereços IP públicos, também pode criar etiquetas DNS para os mesmos. Estes são resolvidos como qualquer outro endereço externo.
- Os servidores iDNS são os servidores autoritativos das respetivas zonas DNS internas e também funcionam como uma resolução para nomes públicos quando as VMs de inquilino tentam ligar-se a recursos externos. Se existir uma consulta para um recurso externo, os servidores iDNS reencaminham o pedido para servidores DNS autoritativos para resolver.
Como pode ver nos resultados do laboratório, tem controlo sobre o IP que é utilizado. Se utilizar o nome da VM, obterá o endereço IP privado e, se utilizar a etiqueta DNS, obterá o endereço IP público.
Passos seguintes
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários