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

  • Artikel

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die sich dem End-of-Life-Status (EOL) nähert. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im CentOS-Leitfaden für das Lebensende.

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:

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:

Hinweis

Private Azure 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.

Hinweis

Wenn Sie von Azure bereitgestelltes DNS verwenden, wird Ihren virtuellen Computern das entsprechende DNS-Suffix automatisch zugewiesen. Für alle anderen Optionen müssen Sie entweder vollqualifizierte Domänennamen (Fully Qualified Domain Names, FQDN) verwenden oder Ihren virtuellen Computern das entsprechende DNS-Suffix manuell zuweisen.

Szenario Lösung DNS-Suffix
Namensauflösung zwischen virtuellen Computern im gleichen virtuellen Netzwerk oder Azure Cloud Services-Rolleninstanzen im gleichen Clouddienst. Private Azure DNS-Zonen oder von Azure bereitgestellte Namensauflösung Hostname oder FQDN
Namensauflösung zwischen virtuellen Computern in verschiedenen virtuellen Netzwerken oder Rolleninstanzen in unterschiedlichen Clouddiensten. Private Azure DNS-Zonen, Azure DNS Private Resolver oder vom Kunden verwaltete DNS-Server, die Abfragen zwischen virtuellen Netzwerken zur Auflösung durch Azure weiterleiten (DNS-Proxy). Siehe Namensauflösung mithilfe eines eigenen DNS-Servers. Nur FQDN
Namensauflösung aus einem Azure App Service (Web-App, Funktion oder Bot) mithilfe von Integration virtueller Netzwerke in Rolleninstanzen oder virtuelle Computer im gleichen virtuellen Netzwerk. Azure DNS Private Resolver oder vom Kunden verwaltete DNS-Server, die Abfragen zwischen virtuellen Netzwerken zur Auflösung durch Azure weiterleiten (DNS-Proxy). Siehe Namensauflösung mithilfe eines eigenen DNS-Servers. Nur FQDN
Namensauflösung aus App Service-Web-Apps in virtuelle Computer im gleichen virtuellen Netzwerk. Azure DNS Private Resolver oder vom Kunden verwaltete DNS-Server, die Abfragen zwischen virtuellen Netzwerken zur Auflösung durch Azure weiterleiten (DNS-Proxy). Siehe Namensauflösung mithilfe eines eigenen DNS-Servers. Nur FQDN
Namensauflösung aus App Service-Web-Apps in einem virtuellen Netzwerk in virtuelle Computer in einem anderen virtuellen Netzwerk. Azure DNS Private Resolver oder vom Kunden verwaltete DNS-Server, die Abfragen zwischen virtuellen Netzwerken zur Auflösung durch Azure weiterleiten (DNS-Proxy). Siehe Namensauflösung mithilfe eines eigenen DNS-Servers. Nur FQDN
Auflösung lokaler Computer- und Dienstnamen von VMs oder Rolleninstanzen in Azure. Azure DNS Private Resolver oder vom Kunden verwaltete DNS-Server (z. B. lokale Domänencontroller, lokale schreibgeschützte Domänencontroller oder ein sekundärer DNS-Server, der mithilfe von Zonenübertragungen synchronisiert wird). Siehe Namensauflösung mithilfe eines eigenen DNS-Servers. Nur FQDN
Auflösung von Azure-Hostnamen von lokalen Computern Weiterleiten von Abfragen an einen vom Kunden verwalteten DNS-Proxyserver im zugehörigen virtuellen Netzwerk. Der Proxyserver leitet Abfragen zur Auflösung an Azure weiter. Siehe Namensauflösung mithilfe eines eigenen DNS-Servers. Nur FQDN
Reverse-DNS für interne IPs Private Azure DNS-Zonen, von Azure bereitgestellte Namensauflösung, Azure DNS Private Resolver oder Namensauflösung mit einem eigenen DNS-Server. Nicht verfügbar
Namensauflösung zwischen virtuellen Computern oder Rolleninstanzen in unterschiedlichen Clouddiensten, nicht in einem virtuellen Netzwerk Nicht zutreffend Die Konnektivität zwischen virtuellen Computern und Rolleninstanzen in verschiedenen Clouddiensten wird außerhalb eines virtuellen Netzwerks nicht unterstützt. Nicht verfügbar

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).

Hinweis

Bei Verwendung von Clouddienstweb- und Workerrollen können Sie auf die internen IP-Adressen von Rolleninstanzen über die REST-API für die Azure-Dienstverwaltung zugreifen. Weitere Informationen finden Sie unter Referenz zur REST-API der Dienstverwaltung. Die Adresse basiert auf dem Rollennamen und der Instanznummer.

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 beim Starten einer VM automatisch hinzugefügt und beim Beenden (Aufheben der Zuordnung) entfernt. 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 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.

Hinweis

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.

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.

Hinweis

Da es sich bei Azure DNS Private Zones um globale Zonen handelt, können Sie einen Reverse-DNS-Lookup erstellen, der mehrere virtuelle Netzwerke umfasst. Erstellen Sie hierfür eine private Azure DNS-Zone für Reverse-Lookups (mit dem Namen in-addr.arpa), und verknüpfen Sie diese mit den virtuellen Netzwerken. Die Reverse-DNS-Einträge für die virtuellen Computer müssen Sie manuell verwalten.

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:

CentOS (verwendet NetworkManager):

  1. Installieren Sie das dnsmasq-Paket mit dem folgenden Befehl:

    sudo yum install dnsmasq

  2. Installieren Sie den dnsmasq-Dienst mit dem folgenden Befehl:

    systemctl enable dnsmasq.service

  3. Starten Sie den dnsmasq-Dienst mit dem folgenden Befehl:

    systemctl start dnsmasq.service

  4. Verwenden Sie einen Text-Editor, um prepend domain-name-servers 127.0.0.1;der Datei /etc/dhclient-eth0.conf hinzuzufügen:

  5. Verwenden Sie den folgenden Befehl, um den Netzwerkdienst neu zu starten:

    service network restart

Hinweis

Das dnsmasq-Paket ist nur einer der vielen DNS-Caches, die für Linux verfügbar sind. Bevor Sie es nutzen, überprüfen Sie dessen Eignung für Ihre besonderen Bedürfnisse und außerdem, ob kein anderer Cache installiert ist.

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:

CentOS (verwendet NetworkManager):

  1. Verwenden Sie einen Text-Editor, um die Zeile RES_OPTIONS="options timeout:1 attempts:5" der Datei /etc/sysconfig/network-scripts/ifcfg-eth0 hinzuzufügen.

  2. Verwenden Sie den folgenden Befehl, um den NetworkManager-Dienst neu zu starten:

    systemctl restart NetworkManager.service

Namensauflösung mithilfe eines eigenen DNS-Servers.

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

Hinweis

Mit Azure DNS Private Resolver müssen auch keine VM-basierten DNS-Server in einem virtuellen Netzwerk mehr verwendet werden. Der folgende Abschnitt wird bereitgestellt, wenn Sie eine VM-basierte DNS-Lösung verwenden möchten. Es gibt jedoch viele Vorteile bei der Verwendung von Azure DNS Private Resolver, einschließlich Kostenreduzierung, integrierter Hochverfügbarkeit, Skalierbarkeit und Flexibilität.

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 vielleicht 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.

Wichtig

Wenn VPN Gateway in dieser Einrichtung zusammen mit benutzerdefinierten DNS-Server-IP-Adressen im VNet verwendet wird, muss die Azure DNS-IP-Adresse (168.63.129.16) der Liste hinzugefügt werden, um einen unterbrechungsfreien Dienst zu gewährleisten.

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.

Hinweis

Eine Rolleninstanz kann die Namensauflösung von virtuellen Computern innerhalb des gleichen virtuellen Netzwerks ausführen. Diese erfolgt mithilfe des FQDN, der aus dem Hostnamen des virtuellen Computers und dem DNS-Suffix internal.cloudapp.net besteht. In diesem Fall ist die Namensauflösung jedoch nur erfolgreich, wenn für die Rolleninstanz der Namen des virtuellen Computers im Rollenschema (CSCFG-Datei) definiert ist. <Role name="<role-name>" vmName="<vm-name>">

Rolleninstanzen, die eine Namensauflösung virtueller Computer in einem anderen virtuellen Netzwerk ausführen müssen (FQDN mit dem Suffix internal.cloudapp.net), müssen diese mit der in diesem Abschnitt beschriebenen Methode vornehmen (über benutzerdefinierte DNS-Server, die für eine Weiterleitung zwischen den beiden virtuellen Netzwerken sorgen).

Abbildung der DNS-Auflösung zwischen virtuellen Netzwerken

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:

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.

Hinweis

  • Wenn Sie virtuelle Azure-Computer als DNS-Server verwenden, sollten Sie für eine optimale Leistung IPv6 deaktivieren.
  • NSGs fungieren als Firewalls für Ihre DNS-Resolverendpunkte. Sie sollten Ihre NSG-Sicherheitsregeln ändern oder außer Kraft setzen, um den Zugriff für UDP-Port 53 (und optional TCP-Port 53) auf Ihre DNS-Listenerendpunkte zuzulassen. Sobald benutzerdefinierte DNS-Server in einem Netzwerk festgelegt sind, umgeht der Datenverkehr über Port 53 die NSGs des Subnetzes.

Wichtig

Wenn Sie Windows DNS-Server als benutzerdefinierte DNS-Server verwenden, um DNS-Anforderungen an Azure DNS-Server weiterzuleiten, stellen Sie sicher, dass Sie den Timeoutwert für die Weiterleitung um mehr als 4 Sekunden erhöhen, damit Azure Recursive DNS-Server ordnungsgemäße Rekursionsvorgänge ausführen können.

Weitere Informationen zu diesem Problem finden Sie unter Timeouts zur Auflösung von Weiterleitungen und bedingten Weiterleitungen.

Diese Empfehlung kann auch auf andere DNS-Serverplattformen mit dem Timeoutwert der Weiterleitung von maximal 3 Sekunden angewendet werden.

Andernfalls kann dies dazu führen, dass private DNS-Zoneneinträge mit öffentlichen IP-Adressen aufgelöst werden.

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.

Hinweis

Netzwerkverbindungseigenschaften wie die IP-Adressen von DNS-Servern sollten nicht direkt auf VMs bearbeitet werden. Dies liegt daran, dass sie während der Dienstreparatur gelöscht werden können, wenn der virtuelle Netzwerkadapter ersetzt wird. Dies gilt für Windows- und Linux-VMs.

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.

Hinweis

Wenn Sie sich für den 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 das von Azure bereitgestellte DNS.

Hinweis

Wenn Sie die DNS-Einstellungen für ein virtuelles Netzwerk oder einen virtuellen Computer ändern, das bzw. der schon bereitgestellt wurde, müssen Sie für alle betroffenen virtuellen Computer im virtuellen Netzwerk die DHCP-Leasedauer verlängern, damit die neuen DNS-Einstellungen wirksam werden. Bei virtuellen Computern, auf denen das Windows-Betriebssystem ausgeführt wird, können Sie dazu ipconfig /renew direkt auf dem virtuellen Computer eingeben. Die Schritte unterscheiden sich je nach Betriebssystem. Weitere Informationen finden Sie in der jeweiligen Dokumentation für Ihren Betriebssystemtyp.

Nächste Schritte

Azure Resource Manager-Bereitstellungsmodell: