Verwenden von iDNS im Azure Stack Hub
iDNS- ist ein Azure Stack Hub-Netzwerkfeature, mit dem Sie externe DNS-Namen auflösen können (z. B. https://www.bing.com.) Außerdem können Sie interne virtuelle Netzwerknamen registrieren. Auf diese Weise können Sie virtuelle Computer (VMs) im selben virtuellen Netzwerk anhand des Namens und nicht anhand der IP-Adresse auflösen. Dieser Ansatz entfernt die Notwendigkeit, benutzerdefinierte DNS-Servereinträge bereitzustellen. Weitere Informationen zu DNS finden Sie im Azure DNS Overview.
Was macht iDNS?
Mit iDNS im Azure Stack Hub erhalten Sie die folgenden Funktionen, ohne benutzerdefinierte DNS-Servereinträge angeben zu müssen:
- Gemeinsame DNS-Namenauflösungsdienste für Mandantenworkloads.
- Autoritativer DNS-Dienst für namensauflösung und DNS-Registrierung innerhalb des virtuellen Mandantennetzwerks.
- Rekursiver DNS-Dienst für die Auflösung von Internetnamen von Mandanten-VMs. Mandanten müssen keine benutzerdefinierten DNS-Einträge zum Auflösen von Internetnamen (z. B. www.bing.com.) mehr angeben.
Sie können weiterhin Ihr eigenes DNS mitbringen und benutzerdefinierte DNS-Server verwenden. Mithilfe von iDNS können Sie jedoch Internet-DNS-Namen auflösen und eine Verbindung mit anderen virtuellen Computern im selben virtuellen Netzwerk herstellen, ohne benutzerdefinierte DNS-Einträge erstellen zu müssen.
Was macht iDNS nicht?
iDNS ermöglicht es Ihnen nicht, einen DNS-Eintrag für einen Namen zu erstellen, der von außerhalb des virtuellen Netzwerks aufgelöst werden kann.
In Azure haben Sie die Möglichkeit, eine DNS-Namensbezeichnung anzugeben, die einer öffentlichen IP-Adresse zugeordnet ist. Sie können die Bezeichnung (Präfix) auswählen, aber Azure wählt das Suffix aus, das auf der Region basiert, in der Sie die öffentliche IP-Adresse erstellen.
Wie die vorherige Abbildung zeigt, erstellt Azure einen "A"-Eintrag in DNS für die unter der Zone westus.cloudapp.azure.comangegebene DNS-Namensbezeichnung. Das Präfix und das Suffix werden kombiniert, um einen vollqualifizierten Domänennamen (FQDN) zu erstellen, der von überall im öffentlichen Internet aufgelöst werden kann.
Azure Stack Hub unterstützt nur iDNS für die Registrierung interner Namen, sodass die folgenden Aktionen nicht ausgeführt werden können:
- Erstellen eines DNS-Eintrags unter einer vorhandenen gehosteten DNS-Zone (z. B. local.azurestack.external.)
- Erstellen einer DNS-Zone (z. B. Contoso.com.)
- Erstellen Sie einen Eintrag unter Ihrer eigenen benutzerdefinierten DNS-Zone.
- Unterstützen Sie den Kauf von Domänennamen.
Demo zur Funktionsweise von iDNS
Alle Hostnamen für VMs in virtuellen Netzwerken werden als DNS-Ressourceneinträge unter derselben Zone gespeichert, jedoch unter ihrem eigenen eindeutigen Abteil, der als GUID definiert ist, die mit der VNET-ID in der SDN-Infrastruktur korreliert, für die die VM bereitgestellt wurde. Vollqualifizierte Domänennamen (Fully Qualified Domain Names, FQDNs) für Mandanten-VMs bestehen aus dem Computernamen und der DNS-Suffixzeichenfolge für das virtuelle Netzwerk im GUID-Format.
Im Folgenden sehen Sie ein einfaches Labor, um zu veranschaulichen, wie das funktioniert. Wir haben 3 VMs auf einem VNet und einem anderen virtuellen Computer in einem separaten VNet erstellt:
| VM | vNet | Private IP-Adresse | Öffentliche IP | DNS-Bezeichnung |
|---|---|---|---|---|
| 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 | DNS-Suffixzeichenfolge |
|---|---|---|
| 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 |
Sie können einige Namensauflösungstests durchführen, um die Funktionsweise von iDNS besser zu verstehen:
Von VM-A1 (Linux-VM): Bei der Suche nach VM-A2 sehen Sie, dass das DNS-Suffix für VNetA hinzugefügt und der Name in die private IP-Adresse aufgelöst wird.
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
Das Abfragen der VM-A2-Label ohne Bereitstellung des FQDN schlägt erwartungsgemäß fehl.
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
Wenn Sie den FQDN für die DNS-Bezeichnung angeben, wird der Name in die öffentliche IP-Adresse aufgelöst:
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
Wenn Sie versuchen, VM-B1 (aus einem anderen VNet) zu beheben, tritt ein Fehler auf, da dieser Datensatz in dieser Zone nicht vorhanden ist.
carlos@caalcobi-vm4:~$ nslookup VM-B1
Server: 127.0.0.53
Address: 127.0.0.53#53
** server can't find VM-B1: SERVFAIL
Die Verwendung des FQDN für VM-B1 hilft nicht, da dieser Datensatz aus einer anderen Zone stammt.
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
Wenn Sie den FQDN für die DNS-Bezeichnung verwenden, wird sie erfolgreich aufgelöst:
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
Von VM-A3 (Windows-VM). Beachten Sie den Unterschied zwischen autorisierenden und nicht autorisierenden Antworten.
Interne Datensätze:
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
Externe Datensätze:
> 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
Kurz gesagt, aus dem Obigen können Sie erkennen, dass:
- Jedes VNet verfügt über eine eigene Zone, die A-Einträge für alle privaten IP-Adressen enthält, bestehend aus dem VM-Namen und dem DNS-Suffix des VNet (die GUID).
- <vmname>.<vnetGUID>.internal.<region>.<stackinternalFQDN>
- Dies erfolgt automatisch
- Wenn Sie öffentliche IP-Adressen verwenden, können Sie auch DNS-Bezeichnungen dafür erstellen. Diese werden wie jede andere externe Adresse aufgelöst.
- iDNS-Server sind die autoritativen Server für ihre internen DNS-Zonen und fungieren auch als Resolver für öffentliche Namen, wenn Mandanten-VMs versuchen, eine Verbindung mit externen Ressourcen herzustellen. Wenn eine Abfrage für eine externe Ressource vorhanden ist, leiten iDNS-Server die Anforderung an autorisierende DNS-Server weiter, um dies zu beheben.
Wie Sie aus den Laborergebnissen sehen können, haben Sie die Kontrolle darüber, welche IP-Adresse verwendet wird. Wenn Sie den VM-Namen verwenden, erhalten Sie die private IP-Adresse und wenn Sie die DNS-Bezeichnung verwenden, erhalten Sie die öffentliche IP-Adresse.