Konfigurieren der DNS-Namensauflösung für virtuelle Azure-Netzwerke

Virtuelle Azure-Netzwerke unterstützen mehrere Methoden zur Namensauflösung für Infrastruktur als ein Service (IaaS), Plattform als ein Service (PaaS) und Hybridlösungen. Um die Kommunikation zwischen virtuellen Computern und anderen Ressourcen in einem virtuellen Netzwerk zu ermöglichen, benötigen Sie eine ordnungsgemäße DNS-Konfiguration. Die Verwendung von leicht zu merkenden und konsistenten Namen vereinfacht den Kommunikationsprozess, anstatt sich auf IP-Adressen zu verlassen.

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:

• Azure-Zonen für Privates DNS
• Von Azure bereitgestellte Namensauflösung
• Namensauflösung mit einem eigenen DNS-Server (Domain Name System) (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 folgende Tabelle werden die Szenarien und entsprechenden Lösungen für die Namensauflösung dargestellt.

Azure Privates DNS-Zonen sind die bevorzugte Lösung und bieten Ihnen Flexibilität bei der Verwaltung Ihrer DNS-Zonen und -Einträge. Weitere Informationen finden Sie unter Verwenden von Azure DNS für private Domänen.

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 Privates DNS-Zonen mit vom Kunden verwalteten DNS-Servern oder Azure DNS Private Resolver einsetzen.

Neben der Auflösung öffentlicher DNS-Namen bietet Azure interne Namensauflösung für virtuelle Computer und Rolleninstanzen innerhalb desselben virtuellen Netzwerks oder Clouddiensts. Virtuelle Maschinen und Instanzen in einem Clouddienst verwenden dasselbe DNS-Suffix, sodass der Hostname allein zur Auflösung ausreicht. In virtuellen Netzwerken des klassischen Bereitstellungsmodells weisen unterschiedliche Clouddienste jedoch unterschiedliche DNS-Suffixe auf, sodass der FQDN Namen über Clouddienste hinweg auflösen muss.

In virtuellen Netzwerken, die mithilfe des Azure Resource Manager-Bereitstellungsmodells bereitgestellt werden, ist das DNS-Suffix auf allen virtuellen Computern innerhalb eines virtuellen Netzwerks konsistent, sodass der FQDN nicht benötigt wird. Sie können DNS-Namen sowohl virtuellen Computern als auch Netzwerkschnittstellen zuweisen. 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:

• Sie brauchen nichts zu konfigurieren.
• Aufgrund der Hochverfügbarkeit müssen Sie keine Cluster Ihrer eigenen DNS-Server erstellen und 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 virtuellen Computern und Rolleninstanzen innerhalb desselben Clouddiensts verwenden, ohne dass ein FQDN erforderlich ist.
• Sie können die Namensauflösung zwischen virtuellen Computern in virtuellen Netzwerken verwenden, die das Ressourcen-Manager-Bereitstellungsmodell verwenden, ohne dass ein FQDN erforderlich ist. Virtuelle Netzwerke im klassischen Bereitstellungsmodell erfordern einen FQDN, wenn Sie Namen in verschiedenen Clouddiensten auflösen.
• Sie können Hostnamen verwenden, die Ihre Bereitstellungen am besten beschreiben, und müssen nicht mit automatisch generierten Namen arbeiten.

Considerations

Berücksichtigen Sie bei Verwendung der von Azure bereitgestellten Namensauflösung die folgenden 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 in anderen virtuellen Netzwerken nicht aufgelöst werden.
• Die manuelle Registrierung Ihrer eigenen Datensätze ist nicht zulässig.
• WINS und NetBIOS werden nicht unterstützt. Ihre virtuellen Computer werden im Windows-Explorer nicht angezeigt.
• Hostnamen müssen DNS-kompatibel sein. Namen dürfen nur 0 bis 9, a bis z und einen Bindestrich (-) enthalten. Die Namen dürfen nicht mit einem Bindestrich 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 Sie eine Anforderungsbegrenzung feststellen, stellen Sie sicher, dass das clientseitige Zwischenspeichern aktiviert ist. Weitere Informationen finden Sie unter DNS-Clientkonfiguration.
• Für jeden virtuellen Computer in einem virtuellen Netzwerk muss ein anderer Name verwendet werden, um DNS-Lösungsprobleme 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 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 virtuelle Computer wird in allen virtuellen Netzwerken unterstützt, die auf dem Ressourcen-Manager basieren. In Azure verwaltetes Reverse-DNS, auch als Zeiger (PTR) bezeichnet, werden Einträge im Format \[vmname\].internal.cloudapp.net automatisch zum DNS hinzugefügt, wenn Sie einen virtuellen Computer starten. Sie werden entfernt, wenn der virtuelle Computer beendet (seine Zuordnung aufgehoben) wird. Sehen Sie sich folgendes Beispiel an:

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 nicht direkt angezeigt oder bearbeitet werden. Forward-Lookup für den FQDN im Format \[vmname\].internal.cloudapp.net wird in die IP-Adresse aufgelöst, die dem virtuellen Computer zugewiesen ist.

Wird eine Azure Privates 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 weist das Format \[vmname\].[privatednszonename] auf, und der andere hat das Format \[vmname\].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 des virtuellen Computers zurück.

Reverse-DNS-Nachschlagevorgänge sind auf ein bestimmtes virtuelles Netzwerk festgelegt, auch wenn das Netzwerk mit anderen virtuellen Netzwerken verknüpft ist. Reverse-DNS-Abfragen für IP-Adressen virtueller Maschinen, die sich in gekoppelten virtuellen Netzwerken befinden, geben NXDOMAIN zurück.

Reverse-DNS-Einträge (PTR) werden nicht in einer privaten Forward-DNS-Zone gespeichert. Reverse DNS-Einträge werden in einer Reverse-DNS-Zone (in-addr.arpa) gespeichert. Die Reverse-DNS-Standardzone, die einem virtuellen Netzwerk zugeordnet ist, kann weder angezeigt noch bearbeitet werden.

Sie können die Reverse-DNS-Funktion in einem virtuellen Netzwerk deaktivieren. Erstellen Sie mithilfe von Azure Privates DNS-Zonen ihre eigene Reverse-Lookup-Zone. Verknüpfen Sie diese Zone dann mit Ihrem virtuellen Netzwerk. Wenn der IP-Adressraum des virtuellen Netzwerks z. B. „10.20.0.0/16“ lautet, können Sie eine leere private DNS-Zone namens 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, sofern Sie diese Einträge nicht manuell erstellen.

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 besteht aufgrund von Einschränkungen , mit denen nur eine private Zone verknüpft werden kann, wenn die automatische Registrierung aktiviert ist. Weitere Informationen zum Erstellen einer privaten DNS-Zone und Verknüpfen der Zone mit einem virtuellen Netzwerk finden Sie unter Schnellstart: Azure Privates DNS.

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 Eintrag möglichst lange speichern kann, ohne die Aktualität der Einträge zu beeinträchtigen. Das clientseitige Zwischenspeichern ist daher für die 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.

Viele verschiedene DNS-Zwischenspeicherungspakete sind verfügbar (z. B. dnsmasq). So installieren Sie dnsmasq für die gängigsten Distributionen:

sudo apt-get install dnsmasq

Clientseitige Wiederholungsversuche

DNS ist in erster Linie ein User Datagram Protocol (UDP). 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 Angaben für die Wiederholungsversuche in fünf Wiederholungsversuche in Intervallen von je einer Sekunde zu ändern.

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

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 optionsvariieren je nach Distribution:

Namensauflösung mithilfe eines eigenen DNS-Servers.

In diesem Abschnitt werden virtuelle Computer, Rolleninstanzen und 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 Windows Server Active Directory-Domänen möglicherweise DNS-Namen zwischen virtuellen Netzwerken auflösen. Um diese Szenarien abzudecken, können Sie Ihre eigenen DNS-Server verwenden.

DNS-Server in einem virtuellen Netzwerk können DNS-Abfragen an die rekursiven Resolver in Azure weiterleiten. Mithilfe dieses Verfahrens 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 Weiterleitungsabfragen können virtuelle Maschinen sowohl Ihre lokalen Ressourcen (über den DC) als auch von Azure bereitgestellte Hostnamen (über den Forwarder) anzeigen. 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 einen 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.

Zwei virtuelle Netzwerke und ein lokales Netzwerk verwenden diese Methode, um die DNS-Auflösung zwischen virtuellen Netzwerken auszuführen, wie im folgenden Diagramm dargestellt. 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 das Azure Dynamic Host Configuration Protocol (DHCP) jedem virtuellen Computer ein internes DNS-Suffix (.internal.cloudapp.net) bereit. Dieses Suffix ermöglicht die Auflösung von Hostnamen, weil sich die Hostnamenseinträge in der Zone internal.cloudapp.net befinden. Wenn Sie Ihre eigene Lösung für die Namensauflösung verwenden, wird dieses Suffix nicht für virtuelle Computer bereitgestellt, da sie andere DNS-Architekturen (z. B. domänenverbundene Szenarien) beeinträchtigt. Stattdessen stellt Azure einen Platzhalter für eine nicht funktionsfähige Komponente (reddog.microsoft.com) bereit.

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

Für virtuelle Netzwerke in 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 dynamisches DNS (DDNS). Bei Verwendung von DDNS müssen Sie möglicherweise die DNS-Eintragsbereinigung deaktivieren. Die Azure DHCP-Leases sind 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.
• Schützen Sie sich vor einem Zugriff aus dem Internet, um mögliche Bedrohungen durch externe Agents zu minimieren.

Wenn Sie virtuelle Azure-Computer als DNS-Server verwenden, sollte IPv6 deaktiviert werden, um eine optimale Leistung zu erzielen.

Netzwerksicherheitsgruppen (Network Security Groups, NSGs) fungieren als Firewalls für Ihre DNS-Konfliktlöserendpunkte. Ändern Sie Ihre NSG-Sicherheitsregeln, oder setzen Sie diese außer Kraft, um den Zugriff für UDP-Port 53 (und optional TCP-Port 53) auf Ihre DNS-Listenerendpunkte zuzulassen. Nachdem benutzerdefinierte DNS-Server in einem Netzwerk festgelegt wurden, umgeht der Datenverkehr über Port 53 die NSGs des Subnetzes und der NIC.

Web-Apps

Angenommen, Sie müssen die Namensauflösung von Ihrer Web-App aus, die mithilfe von App Service erstellt wurde und mit einem virtuellen Netzwerk verbunden ist, für Virtual Machines 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:

• Sofern noch nicht geschehen, aktivieren Sie die Integration virtueller Netzwerke für Ihre Web-App, wie unter Integrieren Ihrer App in ein virtuelles Netzwerk beschrieben.
• Verwenden Sie benutzerdefinierte DNS-Server oder azure DNS Private Resolvers in beiden virtuellen Netzwerken, um die Namensauflösung von Ihrer mit dem virtuellen Netzwerk verknüpften Web-App (erstellt mit App Service) auf virtuellen Computern in einem anderen virtuellen Netzwerk auszuführen, das nicht mit derselben privaten Zone verknüpft ist.

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.

Informationen zur Verwendung Azure DNS privaten Resolvers finden Sie unter Ruleset-Links.

Angeben von DNS-Servern

Wenn Sie eigene DNS-Server verwenden, können Sie für jedes virtuelle Netzwerk mehrere DNS-Server angeben. Sie können auch mehrere DNS-Server pro Netzwerkschnittstelle (für 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 Resource Manager-Bereitstellungsmodell verwenden, können Sie DNS-Server für ein virtuelles Netzwerk und eine Netzwerkschnittstelle angeben. Weitere Informationen finden Sie unter Verwalten eines virtuellen Netzwerks und Verwalten einer Netzwerkschnittstelle.

Wenn Sie sich für einen benutzerdefinierten DNS-Server für Ihr virtuelles Netzwerk entscheiden, müssen Sie mindestens eine DNS-Server-IP-Adresse angeben. Andernfalls ignoriert das virtuelle Netzwerk die Konfiguration und verwendet stattdessen von Azure bereitgestelltes DNS.

Verwandte Inhalte

Azure Resource Manager-Bereitstellungsmodell:

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