Freigeben über

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

  • Artikel

Sie können Azure nutzen, um Infrastructure-as-a-Service (IaaS), Plattform-as-a-Service (PaaS) und Hybridlösungen zu hosten. Um die Kommunikation zwischen den VMs und anderen Ressourcen zu erleichtern, die in einem virtuellen Netzwerk bereitgestellt werden, kann es notwendig sein, ihnen zu erlauben, miteinander zu kommunizieren. 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 folgende Tabelle werden die Szenarien und entsprechenden Lösungen für die Namensauflösung dargestellt:

Azure Private 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 das entsprechende DNS-Suffix automatisch auf Ihre virtuellen Computer angewendet. Für alle anderen Optionen müssen Sie entweder vollqualifizierte Domänennamen (Fully Qualified Domain Names, FQDNs) 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 Azure Private 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 der 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 Azure Private DNS-Zonen, von Azure bereitgestellte Namensauflösung, Azure DNS Private Resolver oder Namensauflösung mit einem eigenen DNS-Server Nicht zutreffend
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 Private DNS-Zonen 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. 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).

Hinweis

Wenn Sie Clouddienstweb- und Workerrollen verwenden, können Sie über die REST-API für die Azure-Dienstverwaltung auf die internen IP-Adressen von Rolleninstanzen 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:

  • 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 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 Resource 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.

Überlegungen

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 aus 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 nicht im Windows-Explorer 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 VMs wird in allen auf Resource Manager basierenden virtuellen Netzwerken unterstützt. 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. 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 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 Private 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. Siehe folgendes Beispiel:

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-Lookups sind auf ein bestimmtes virtuelles Netzwerk begrenzt, selbst bei Peerings mit anderen virtuellen Netzwerken. Reverse DNS-Abfragen für IP-Adressen von virtuellen Computern, die sich in virtuellen Peernetzwerken 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 Private 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 ist auf die Beschränkung zurückzuführen, dass eine private Zone nur 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 Private DNS.

Hinweis

Weil es sich bei Azure DNS Private-Zonen um globale Zonen handelt, können Sie einen Reverse-DNS-Lookup erstellen, der mehrere virtuelle Netzwerke umfasst. Sie müssen eine Azure Private DNS-Zone für Reverse-Lookup-Vorgänge (eine Zone in-addr.arpa) erstellen und dann mit den virtuellen Netzwerken verknüpfen. 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 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:

RHEL (verwendet NetworkManager)

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

    sudo yum install dnsmasq

  2. Aktivieren 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; zu /etc/dhclient-eth0.confhinzuzufü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, ob es sich für Ihre besonderen Bedürfnisse eignet und ob kein anderer Cache installiert ist.

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:

RHEL (verwendet NetworkManager)

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

  2. Führen Sie den folgenden Befehl aus, um den Dienst NetworkManager 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. Zu den vielen Vorteilen der Verwendung von Azure DNS Private Resolver gehören Kostenreduzierung, integrierte 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 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 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 Azure VPN Gateway in diesem Setup zusammen mit benutzerdefinierten DNS-Server-IP-Adressen in einem virtuellen Netzwerk verwendet wird, muss die Azure DNS-IP-Adresse (168.63.129.16) der Liste hinzugefügt werden, um einen störungsfreien Dienst aufrechtzuerhalten.

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.

Hinweis

Eine Rolleninstanz kann die Namensauflösung von virtuellen Computern innerhalb des gleichen virtuellen Netzwerks ausführen. Dabei wird der FQDN verwendet, 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).

Diagramm: DNS zwischen virtuellen Netzwerken.

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 eine eigene Lösung für die Namensauflösung verwenden, wird dieses Suffix nicht an virtuelle Computer weitergegeben, weil es mit anderen DNS-Architekturen in Konflikt gerät (z. B. in Szenarien 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 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, sollten Sie für eine optimale Leistung IPv6 deaktivieren.

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.

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 vier 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 drei 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:

  • 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.
  • Wenn Sie die Namensauflösung für Ihre (mit App Service erstellte) mit dem virtuellen Netzwerk verknüpften Web-App 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, 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.

Hinweis

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

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.

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. Geben Sie für virtuelle Computer, die das Windows-Betriebssystem ausführen, ipconfig /renew direkt in den virtuellen Computer ein. Die Schritte unterscheiden sich je nach Betriebssystem. Weitere Informationen finden Sie in der jeweiligen Dokumentation für Ihren Betriebssystemtyp.

Zugehöriger Inhalt

Azure Resource Manager-Bereitstellungsmodell: