Usare iDNS nell'hub di Azure Stack
iDNS è una funzionalità di rete dell'hub di Azure Stack che consente di risolvere i nomi DNS esterni, https://www.bing.com.) ad esempio consente anche di registrare nomi di rete virtuale interni. In questo modo, è possibile risolvere le macchine virtuali (VM) nella stessa rete virtuale in base al nome anziché all'indirizzo IP. Questo approccio rimuove la necessità di fornire voci personalizzate del server DNS. Per altre informazioni su DNS, vedere Panoramica di DNS di Azure.
Che cosa fa iDNS?
Con iDNS nell'hub di Azure Stack si ottengono le funzionalità seguenti, senza dover specificare voci personalizzate del server DNS:
- Servizi di risoluzione dei nomi DNS condivisi per i carichi di lavoro del tenant.
- Servizio DNS autorevole per la risoluzione dei nomi e la registrazione DNS all'interno della rete virtuale del tenant.
- Servizio DNS ricorsivo per la risoluzione dei nomi Internet dalle macchine virtuali tenant. I tenant non devono più specificare voci DNS personalizzate per risolvere i nomi Internet, ad esempio www.bing.com.
È comunque possibile usare un DNS personalizzato e usare server DNS personalizzati. Tuttavia, usando iDNS, è possibile risolvere i nomi DNS Internet e connettersi ad altre macchine virtuali nella stessa rete virtuale senza dover creare voci DNS personalizzate.
Cosa non fa iDNS?
iDNS non consente di creare un record DNS per un nome che può essere risolto dall'esterno della rete virtuale.
In Azure è possibile specificare un'etichetta del nome DNS associata a un indirizzo IP pubblico. È possibile scegliere l'etichetta (prefisso), ma Azure sceglie il suffisso, che si basa sull'area in cui si crea l'indirizzo IP pubblico.
Come illustrato nell'immagine precedente, Azure creerà un record "A" in DNS per l'etichetta del nome DNS specificata nella zona westus.cloudapp.azure.com. Il prefisso e il suffisso vengono combinati per comporre un nome di dominio completo (FQDN) che può essere risolto da qualsiasi punto della rete Internet pubblica.
L'hub di Azure Stack supporta solo iDNS per la registrazione dei nomi interni, quindi non può eseguire le operazioni seguenti:
- Creare un record DNS in una zona DNS ospitata esistente , ad esempio local.azurestack.external.
- Creare una zona DNS, ad esempio Contoso.com.
- Creare un record nella propria zona DNS personalizzata.
- Supportare l'acquisto di nomi di dominio.
Dimostrazione del funzionamento di iDNS
Tutti i nomi host per le macchine virtuali nelle reti virtuali vengono archiviati come record di risorse DNS nella stessa zona, ma nel proprio raggruppamento univoco definito come GUID correlato all'ID rete virtuale nell'infrastruttura SDN in cui è stata distribuita la macchina virtuale. I nomi di dominio completi (FQDN) della macchina virtuale tenant sono costituiti dal nome del computer e dalla stringa di suffisso DNS per il Rete virtuale, in formato GUID.
Di seguito è riportato un semplice lab per illustrare il funzionamento di questa operazione. Sono state create 3 macchine virtuali in una rete virtuale e in un'altra macchina virtuale in una rete virtuale separata:
| VM | Rete virtuale | IP privato | IP pubblico | Etichetta 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 | Rete virtualeB | 10.0.0.4 | 172.31.12.57 | VM-B1-Label.lnv1.cloudapp.azscss.external |
| VNet | GUID | Stringa suffisso DNS |
|---|---|---|
| VNetA | e71e1db5-0a38-460d-8539-705457a4cf755 | e71e1db5-0a38-460d-8539-705457a4cf75.internal.lnv1.azurestack.local |
| Rete virtualeB | e8a6e386-bc7a-43e1-a640-61591b5c76dd | e8a6e386-bc7a-43e1-a640-61591b5c76dd.internal.lnv1.azurestack.local |
È possibile eseguire alcuni test di risoluzione dei nomi per comprendere meglio il funzionamento di iDNS:
Da VM-A1 (VM Linux): ricerca di VM-A2. È possibile notare che viene aggiunto il suffisso DNS per VNetA e che il nome viene risolto nell'indirizzo IP privato:
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
La ricerca di VM-A2-Label senza fornire il nome di dominio completo ha esito negativo, come previsto:
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 si specifica il nome di dominio completo per l'etichetta DNS, il nome viene risolto nell'indirizzo IP pubblico:
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
Il tentativo di risolvere VM-B1 (proveniente da una rete virtuale diversa) ha esito negativo perché questo record non esiste in questa 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
L'uso del nome di dominio completo per VM-B1 non è utile perché questo record proviene da una zona diversa.
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 si usa il nome di dominio completo per l'etichetta DNS, viene risolto correttamente:
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 Windows). Si noti la differenza tra risposte autorevoli e non autorevoli.
Record interni:
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
Record esterni:
> 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
In breve, è possibile vedere dall'esempio precedente:
- Ogni rete virtuale ha una propria zona, contenente i record A per tutti gli indirizzi IP privati, costituiti dal nome della macchina virtuale e dal suffisso DNS della rete virtuale ,ovvero il relativo GUID.
- <vmname>.<vnetGUID.internal>.<area> geografica.<stackinternalFQDN>
- Questa operazione viene eseguita automaticamente
- Se si usano indirizzi IP pubblici, è anche possibile creare etichette DNS per tali indirizzi. Questi vengono risolti come qualsiasi altro indirizzo esterno.
- I server iDNS sono i server autorevoli per le zone DNS interne e fungono anche da sistema di risoluzione per i nomi pubblici quando le macchine virtuali tenant tentano di connettersi a risorse esterne. Se è presente una query per una risorsa esterna, i server iDNS inoltrano la richiesta ai server DNS autorevoli da risolvere.
Come si può vedere dai risultati del lab, si ha il controllo sull'indirizzo IP usato. Se si usa il nome della macchina virtuale, si otterrà l'indirizzo IP privato e se si usa l'etichetta DNS si ottiene l'indirizzo IP pubblico.
Passaggi successivi
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per