Namensauflösung für Ressourcen in virtuellen Azure-Netzwerken

Azure kann zum Hosten von IaaS-, PaaS- und Hybridlösungen verwendet werden. Um die Kommunikation zwischen den VMs und anderen Ressourcen zu erleichtern, die in einem virtuellen Netzwerk bereitgestellt werden, kann es erforderlich sein, ihnen die Kommunikation untereinander zu ermöglichen. Die Verwendung von Namen, die leicht zu merken sind und sich nicht ändern, vereinfacht den Kommunikationsprozess im Vergleich zur Nutzung von IP-Adressen.

Wenn in einem virtuellen Netzwerk bereitgestellte Ressourcen Domänennamen in interne IP-Adressen auflösen müssen, können sie eine dieser vier Methoden verwenden:

• Private Azure DNS-Zonen

• Von Azure bereitgestellte Namensauflösung

• Namensauflösung mit einem eigenen DNS-Server (dieser kann Abfragen an die von Azure bereitgestellten DNS-Server weiterleiten)

• Azure DNS Private Resolver

Welche Art der Namensauflösung Sie verwenden, hängt davon ab, wie die Ressourcen miteinander kommunizieren müssen. In der folgenden Tabelle sind die Szenarien und entsprechenden Lösungen für die Namensauflösung aufgeführt:

Von Azure bereitgestellte Namensauflösung

Die von Azure bereitgestellte Namensauflösung bietet nur grundlegende autoritative DNS-Funktionen. Azure verwaltet die DNS-Zonennamen und -Einträge, wenn Sie das von Azure bereitgestellte DNS verwenden. Sie können die DNS-Zonennamen oder den Lebenszyklus von DNS-Einträgen nicht steuern. Wenn Sie eine voll ausgestattete DNS-Lösung für Ihre virtuellen Netzwerke benötigen, können Sie Azure DNS Private Zones mit vom Kunden verwalteten DNS-Servern oder Azure DNS Private Resolver einsetzen.

Zusammen mit der Auflösung des öffentlichen DNS-Namens bietet Azure die Auflösung interner Namen für virtuelle Computer und Rolleninstanzen, die sich innerhalb des gleichen virtuellen Netzwerks oder Clouddiensts befinden. Virtuelle Computer und Instanzen in einem Clouddienst verwenden das gleiche DNS-Suffix gemeinsam, sodass der Hostname allein ausreichend ist. In virtuellen Netzwerken, die mit dem klassischen Bereitstellungsmodell bereitgestellt werden, weisen verschiedene Clouddienste jedoch unterschiedliche DNS-Suffixe auf. In diesem Fall benötigen Sie den FQDN zum Auflösen von Namen zwischen verschiedenen Clouddiensten. In virtuellen Netzwerken, die mit dem Azure Resource Manager-Bereitstellungsmodell bereitgestellt werden, ist das DNS-Suffix aller virtuellen Computer in einem virtuellen Netzwerk einheitlich, sodass der FQDN nicht benötigt wird. DNS-Namen können virtuellen Computern und Netzwerkschnittstellen zugewiesen werden. Obwohl für die von Azure durchgeführte Namensauflösung keine Konfiguration erforderlich ist, ist sie nicht für alle Bereitstellungsszenarien die beste Lösung (siehe vorherige Tabelle).

Features

Die von Azure bereitgestellte Namensauflösung umfasst die folgenden Features:

• Einfache Bedienung. Es ist keine Konfiguration erforderlich.

• Hochverfügbarkeit. Sie müssen Cluster Ihrer eigenen DNS-Server weder erstellen noch verwalten.

• Sie können den Dienst mit Ihren eigenen DNS-Servern zum Auflösen von lokalen und Azure-Hostnamen verwenden.

• Sie können die Namensauflösung zwischen VMs und Rolleninstanzen im gleichen Clouddienst verwenden, ohne dass ein FQDN erforderlich ist.

• Sie können die Namensauflösung zwischen virtuellen Computern in virtuellen Netzwerken verwenden, die das Azure Resource Manager-Bereitstellungsmodell verwenden, ohne dass ein FQDN erforderlich ist. Virtuelle Netzwerke im klassischen Bereitstellungsmodell erfordern beim Auflösen von Namen in verschiedenen Clouddiensten einen FQDN.

• Sie können Hostnamen verwenden, die Ihre Bereitstellungen am besten beschreiben, und müssen nicht mit automatisch generierten Namen arbeiten.

Überlegungen

Wenn Sie die von Azure bereitgestellte Namensauflösung verwenden, beachten Sie folgende Punkte:

• Das von Azure erstellte DNS-Suffix kann nicht geändert werden.

• DNS-Lookup ist auf ein virtuelles Netzwerk begrenzt. DNS-Namen, die für ein virtuelles Netzwerk erstellt wurden, können aus anderen virtuellen Netzwerken nicht aufgelöst werden.

• Sie können keine eigenen Einträge manuell registrieren.

• WINS und NetBIOS werden nicht unterstützt. Ihre virtuellen Computer werden nicht im Windows-Explorer angezeigt.

• Hostnamen müssen DNS-kompatibel sein. Für die Namen dürfen nur die Zeichen 0 bis 9, a bis z und „-“ verwendet werden, zudem dürfen sie nicht mit „-“ beginnen oder enden.

• Der DNS-Abfragedatenverkehr wird für den jeweiligen virtuellen Computer gedrosselt. Die Drosselung sollte auf die meisten Anwendungen keine Auswirkungen haben. Wenn eine Drosselung der Anforderungen festgestellt wird, stellen Sie sicher, dass clientseitiges Zwischenspeichern aktiviert ist. Weitere Informationen finden Sie unter DNS-Clientkonfiguration.

• Verwenden Sie einen anderen Namen für jeden virtuellen Computer in einem virtuellen Netzwerk, um Probleme mit der DNS-Auflösung zu vermeiden.

• Nur virtuelle Computer in den ersten 180 Clouddiensten werden für jedes virtuelle Netzwerk in einem klassischen Bereitstellungsmodell registriert. Diese Begrenzung gilt nicht für virtuelle Netzwerke in Azure Resource Manager.

• Die IP-Adresse für Azure DNS für DNS lautet 168.63.129.16. Diese Adresse ist eine statische IP-Adresse, die sich nicht ändert.

Überlegungen zu Reverse-DNS

Reverse-DNS für VMs wird in allen auf Azure Resource Manager basierenden virtuellen Netzwerken unterstützt. Von Azure verwaltete Reverse-DNS-Einträge (PTR) im Format [VM-Name].internal.cloudapp.net werden dem DNS beim Starten einer VM automatisch hinzugefügt und beim Beenden (Aufheben der Zuordnung) entfernt. Siehe folgendes Beispiel:

C:\>nslookup -type=ptr 10.11.0.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.0.11.10.in-addr.arpa  name = myeastspokevm1.internal.cloudapp.net

Die Reverse-DNS-Zone internal.cloudapp.net wird von Azure verwaltet und kann weder direkt angezeigt noch bearbeitet werden. Forward-Lookup für den FQDN im Format [VM-Name].internal.cloudapp.net wird in die IP-Adresse aufgelöst, die der VM zugewiesen ist.

Wird eine private Azure DNS-Zone über eine Verknüpfung des virtuellen Netzwerks, für die automatische Registrierung aktiviert ist, mit dem virtuellen Netzwerk verknüpft, werden bei Reverse-DNS-Abfragen zwei Einträge zurückgegeben. Ein Eintrag hat das Format [VM-Name].[Name der privaten DNS-Zone], der andere das Format [VM-Name].internal.cloudapp.net. Sehen Sie sich folgendes Beispiel an:

C:\>nslookup -type=ptr 10.20.2.4
Server:  UnKnown
Address:  168.63.129.16

Non-authoritative answer:
4.2.20.10.in-addr.arpa  name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa  name = mywestvm1.azure.contoso.com

Werden wie oben dargestellt zwei PTR-Einträge zurückgegeben, gibt das Forward-Lookup für beide FQDN die IP-Adresse der VM zurück.

Reverse-DNS-Lookups sind auf ein bestimmtes virtuelles Netzwerk begrenzt. Dies gilt auch bei Peerings mit anderen virtuellen Netzwerken. Reverse-DNS-Abfragen für IP-Adressen von VMs, die sich in virtuellen Netzwerken mit Peering befinden, geben NXDOMAIN zurück.

Wenn Sie die Reverse-DNS-Funktion in einem virtuellen Netzwerk deaktivieren möchten, können Sie hierfür mit Azure DNS Private Zones eine eigene Reverse-Lookup-Zone erstellen und diese mit Ihrem virtuellen Netzwerk verknüpfen. Wenn der IP-Adressraum des virtuellen Netzwerks z. B. „10.20.0.0/16“ lautet, können Sie eine leere private DNS-Zone mit dem Namen 20.10.in-addr.arpa erstellen und diese mit dem virtuellen Netzwerk verknüpfen. Diese Zone setzt die standardmäßigen Reverse-Lookupzonen für das virtuelle Netzwerk außer Kraft. Diese Zone ist leer. Reverse-DNS gibt NXDOMAIN zurück, es sei denn, Sie erstellen diese Einträge manuell.

Automatische Registrierung von PTR-Einträgen wird nicht unterstützt. Wenn Sie Einträge erstellen möchten, geben Sie diese manuell ein. Sie müssen automatische Registrierung im virtuellen Netzwerk deaktivieren, wenn sie für andere Zonen aktiviert ist. Diese Einschränkung ist auf Restriktionen zurückzuführen, die bei aktivierter automatischer Registrierung nur die Verknüpfung einer privaten Zone erlauben. Weitere Informationen zum Erstellen einer privaten DNS-Zone und Verknüpfen der Zone mit einem virtuellen Netzwerk finden Sie unter Schnellstart: Erstellen einer privaten Azure DNS-Zone im Azure-Portal.

DNS-Clientkonfiguration

Dieser Abschnitt behandelt clientseitiges Zwischenspeichern und clientseitige Wiederholungsversuche.

Clientseitiges Caching

Nicht alle DNS-Abfragen müssen über das Netzwerk gesendet werden. Clientseitiges Zwischenspeichern kann die Latenz verringern und die Flexibilität bei Netzwerkproblemen verbessern, indem sich wiederholende DNS-Abfragen aus einem lokalen Cache aufgelöst werden. DNS-Einträge enthalten einen TTL-Mechanismus (Time-To-Live), damit der Cache den Datensatz so lange wie möglich speichern kann, ohne die Aktualität der Datensätze zu beeinträchtigen. Daher ist das clientseitige Zwischenspeichern in den meisten Situationen geeignet.

Der DNS-Standardclient von Windows verfügt über einen integrierten DNS-Cache. Einige Linux-Distributionen bieten standardmäßig keine Zwischenspeicherung. Wenn Sie feststellen, dass noch kein lokaler Cache vorhanden ist, fügen Sie jedem virtuellen Linux-Computer einen DNS-Cache hinzu.

Es sind viele unterschiedliche Pakete für die DNS-Zwischenspeicherung verfügbar (z. B. dnsmasq). So installieren Sie dnsmasq für die gängigsten Distributionen:

Clientseitige Wiederholungsversuche

DNS ist in erster Linie ein UDP-Protokoll. Da das UDP-Protokoll keine Nachrichtenübermittlung garantiert, wird die Wiederholungslogik im DNS-Protokoll selbst behandelt. Jeder DNS-Client (Betriebssystem) kann je nach Vorliebe des Erstellers eine unterschiedliche Wiederholungslogik aufweisen:

• Windows-Betriebssysteme starten nach einer Sekunde einen Wiederholungsversuch und dann erneut nach weiteren zwei Sekunden, vier Sekunden und weiteren vier Sekunden.
• Das standardmäßige Linux-Setup führt nach fünf Sekunden einen Wiederholungsversuch aus. Es wird empfohlen, die Wiederholungsversuchspezifikationen in fünf Wiederholungsversuche in Intervallen von einer Sekunde zu ändern.

Überprüfen Sie die aktuellen Einstellungen auf einem virtuellen Linux-Computer mit cat /etc/resolv.conf. Sehen Sie sich beispielsweise die Zeile options an:

options timeout:1 attempts:5

Die Datei „resolv.conf“ wird automatisch generiert und darf nicht bearbeitet werden. Die entsprechenden Schritte zum Hinzufügen der Zeile options variieren je nach Distribution:

Namensauflösung mithilfe eines eigenen DNS-Servers.

In diesem Abschnitt werden virtuelle Computer, Rolleninstanzen sowie Web-Apps behandelt.

Virtuelle Computer und Rolleninstanzen

Ihre Namensauflösungsanforderungen gehen möglicherweise über die von Azure bereitgestellten Features hinaus. Beispielsweise müssen Sie für die Verwendung von Microsoft Windows Server Active Directory-Domänen möglicherweise DNS-Namen zwischen virtuellen Netzwerken auflösen. Für diese Szenarios ermöglicht Ihnen Azure die Nutzung eigener DNS-Server.

DNS-Server in einem virtuellen Netzwerk können DNS-Abfragen an die rekursiven Resolver in Azure weiterleiten. Mit diesem Verfahren können Sie Hostnamen innerhalb dieses virtuellen Netzwerks auflösen. Beispielsweise kann ein in Azure ausgeführter Domänencontroller (DC) auf DNS-Abfragen für die eigenen Domänen antworten und alle anderen Abfragen an Azure weiterleiten. Durch das Weiterleiten von Abfragen sind sowohl Ihre lokalen Ressourcen (über den DC) als auch die von Azure bereitgestellten Hostnamen (über die Weiterleitung) für die virtuellen Computer sichtbar. Der Zugriff auf die rekursiven Resolver in Azure wird über die virtuelle IP-Adresse 168.63.129.16 bereitgestellt.

Durch die DNS-Weiterleitung wird außerdem eine DNS-Auflösung zwischen virtuellen Netzwerken ermöglicht, sodass die lokalen Computer von Azure bereitgestellte Hostnamen auflösen können. Um den Hostnamen eines virtuellen Computers aufzulösen, muss sich die DNS-Server-VM im selben virtuellen Netzwerk befinden und zur Weiterleitung von Abfragen für Hostnamen an Azure konfiguriert sein. Da jedes virtuelle Netzwerk ein eigenes DNS-Suffix verwendet, können Sie mithilfe von Regeln für die bedingte Weiterleitung DNS-Abfragen zur Auflösung an das richtige virtuelle Netzwerk senden. In der folgenden Abbildung sind zwei virtuelle Netzwerke und ein lokales Netzwerk dargestellt, in dem eine DNS-Auflösung zwischen virtuellen Netzwerken mithilfe dieser Methode ausgeführt wird. Ein Beispiel für eine DNS-Weiterleitung steht im Azure-Katalog mit Schnellstartvorlagen und auf GitHub zur Verfügung.

Wenn Sie die von Azure bereitgestellte Namensauflösung verwenden, stellt Azure DHCP (Dynamic Host Configuration Protocol) ein internes DNS-Suffix (.internal.cloudapp.net) für jeden virtuellen Computer bereit. Dieses Suffix ermöglicht die Auflösung von Hostnamen, weil sich die Einträge für die Hostnamen in der Zone internal.cloudapp.net befinden. Wenn Sie eine eigene Lösung für die Namensauflösung verwenden, wird dieses Suffix nicht für die virtuellen Computer bereitgestellt, weil es Konflikte mit anderen DNS-Architekturen verursacht (z. B. in Szenarios mit Domäneneinbindung). Stattdessen stellt Azure einen nicht funktionsfähigen Platzhalter bereit (reddog.microsoft.com).

Bei Bedarf kann das interne DNS-Suffix mithilfe von PowerShell oder der API ermittelt werden:

• Für virtuelle Netzwerke in Azure Resource Manager-Bereitstellungsmodellen ist das Suffix über die Netzwerkschnittstellen-REST-API, das PowerShell-Cmdlet Get-AzNetworkInterface und den Azure CLI-Befehl az network nic show verfügbar.

Wenn die Abfrageweiterleitung an Azure nicht Ihren Anforderungen entspricht, stellen Sie eine eigene DNS-Lösung oder Azure DNS Private Resolver bereit.

Eine eigene DNS-Lösung muss die folgenden Anforderungen erfüllen:

• Bereitstellung einer geeigneten Hostnamensauflösung, z.B. über DDNS. Bei Verwendung von DDNS muss möglicherweise die DNS-Eintragsbereinigung deaktiviert werden. Die Azure DHCP-Leases sind sehr lange gültig, und die DNS-Einträge werden durch eine Bereinigung möglicherweise zu früh entfernt.

• Bereitstellung einer geeigneten rekursiven Lösung, um eine Auflösung externer Domänennamen zu ermöglichen.

• Möglichkeit zum Zugriff (TCP und UDP auf Port 53) von den Clients, die Dienste beziehen, und für den Internetzugriff.

• Schutz vor einem Zugriff aus dem Internet, um mögliche Bedrohungen durch externe Agents zu minimieren.

Web-Apps

Angenommen, Sie müssen Namensauflösung aus Ihrer Web-App, die mithilfe von App Service erstellt wurde und mit einem virtuellen Netzwerk verbunden ist, für virtuelle Computer im gleichen virtuellen Netzwerk ausführen. Zusätzlich zur Einrichtung eines benutzerdefinierten DNS-Servers mit DNS-Weiterleitung, die Abfragen an Azure weiterleitet (virtuelle IP-Adresse 168.63.129.16), führen Sie die folgenden Schritte aus:

Aktivieren Sie die Integration virtueller Netzwerke für Ihre Web-App (falls noch nicht geschehen), wie unter Integrieren Ihrer App in ein virtuelles Netzwerk beschrieben wird.

Wenn Sie die Namensauflösung für Ihre (mit App Service erstellte) Web-App mit VNET-Verknüpfung mit virtuellen Computern ausführen möchten, die sich in einem virtuellen Netzwerk ohne Verknüpfung mit der gleichen privaten Zone befinden, verwenden Sie für beide virtuellen Netzwerke DNS-Server oder Azure DNS Private Resolver.

Führen Sie folgende Schritte aus, um DNS-Server zu nutzen:

• Richten Sie einen DNS-Server im virtuellen Zielnetzwerk auf einem virtuellen Computer ein, der auch Abfragen an den rekursiven Resolver in Azure (virtuelle IP-Adresse 168.63.129.16) weiterleiten kann. Ein Beispiel für eine DNS-Weiterleitung steht im Azure-Katalog mit Schnellstartvorlagen und auf GitHub zur Verfügung.

• Richten Sie eine DNS-Weiterleitung im virtuellen Quellnetzwerk auf einem virtuellen Computer ein. Konfigurieren Sie diese DNS-Weiterleitung für das Weiterleiten von Abfragen an den DNS-Server in Ihrem virtuellen Zielnetzwerk.

• Konfigurieren Sie den DNS-Quellserver in den Einstellungen für Ihr virtuelles Quellnetzwerk.

• Aktivieren Sie die Integration virtueller Netzwerke für Ihre Web-App, um eine Verknüpfung mit dem virtuellen Quellnetzwerk herzustellen. Befolgen Sie dazu die Anweisungen unter Integrieren Ihrer App in ein virtuelles Netzwerk.

Weitere Informationen zur Nutzung von Azure DNS Private Resolver finden Sie unter Regelsatzverknüpfungen.

Angeben von DNS-Servern

Wenn Sie eigene DNS-Server verwenden, bietet Azure die Möglichkeit, für jedes virtuelle Netzwerk mehrere DNS-Server anzugeben. Sie können auch mehrere DNS-Server pro Netzwerkschnittstelle (für Azure Resource Manager) oder pro Clouddienst (für das klassische Bereitstellungsmodell) angeben. Die für einen Clouddienst oder eine Netzwerkschnittstelle angegebenen DNS-Server besitzen Vorrang vor den für das virtuelle Netzwerk angegebenen DNS-Servern.

Wenn Sie das Azure Resource Manager-Bereitstellungsmodell verwenden, können Sie DNS-Server für ein virtuelles Netzwerk und eine Netzwerkschnittstelle angeben. Weitere Informationen finden Sie unter Erstellen, Ändern oder Löschen eines virtuellen Netzwerks und Erstellen, Ändern oder Löschen von Netzwerkschnittstellen.

Nächste Schritte

Azure Resource Manager-Bereitstellungsmodell:

• Erstellen, Ändern oder Löschen eines virtuellen Netzwerks

• Erstellen, Ändern oder Löschen von Netzwerkschnittstellen