Entwerfen einer hybriden Domain Name System-Lösung mit Azure

Diese Referenzarchitektur veranschaulicht den Entwurf einer DNS-Hybridlösung (Domain Name System) zum Auflösen von Namen für Workloads, die lokal und in Microsoft Azure gehostet werden. Diese Architektur eignet sich für Benutzer und andere Systeme, die sich über lokale Netzwerke und das öffentliche Internet verbinden.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Die Architektur umfasst die folgenden Komponenten:

• Lokales Netzwerk. Das lokale Netzwerk ist ein einzelnes Rechenzentrum, das über eine Azure ExpressRoute- oder VPN-Verbindung (virtuelles privates Netzwerk) mit Azure verbunden ist. In diesem Szenario umfasst das lokale Netzwerk die folgenden Komponenten:
  • DNS-Server: Bei diesen Servern handelt es sich um zwei Server, auf denen der DNS-Dienst installiert ist und die zum Auflösen/Weiterleiten eingesetzt werden. Sie werden für alle Computer innerhalb des lokalen Netzwerks als DNS-Server verwendet. Für sämtliche Endpunkte in Azure und in der lokalen Umgebung müssen Einträge auf diesen Servern erstellt werden.
  • Gateway: Das Gateway ist entweder eine ExpressRoute-Verbindung oder ein VPN-Gerät, über das eine Verbindung mit Azure hergestellt wird.
• Hubabonnement: Das Hubabonnement ist ein Azure-Abonnement, das zum Hosten von Konnektivitäts-, Verwaltungs- und Netzwerkressourcen eingesetzt wird, die für mehrere in Azure gehostete Workloads gemeinsam genutzt werden. Diese Ressourcen lassen sich in mehrere Abonnements untergliedern, wie im Thema zur Unternehmensarchitektur beschrieben.

  Hinweis

  Das virtuelle Hubnetzwerk kann durch einen vWAN-Hub (virtuelles Wide Area Network) ersetzt werden. Bei dieser Konfiguration müssten die DNS-Server in einem anderen virtuellen Azure-Netzwerk (VNET) gehostet werden. In der Unternehmensarchitektur wird dieses VNET in einem eigenen Abonnement verwaltet, das als Identitätsabonnement bezeichnet wird.

  • Azure Bastion-Subnetz: Der Azure Bastion-Dienst im virtuellen Hubnetzwerk wird zu Wartungszwecken für das Remoting mit virtuellen Computern in den Hub-and-Spoke-VNETs über das öffentliche Internet verwendet.
  • Subnetz des privaten Endpunkts: Im Subnetz des privaten Endpunkts werden private Endpunkte für in Azure gehostete Workloads in VNETs gehostet, für die kein Peering mit dem Hub konfiguriert ist. Bei dieser Art von getrennten VNETs muss berücksichtigt werden, dass für die zugehörigen IP-Adressen Konflikte mit anderen IP-Adressen auftreten können, die in Azure und lokal verwendet werden.
  • Gatewaysubnetz. Das Gatewaysubnetz wird zum Hosten des Azure-VPN- oder ExpressRoute-Gateways verwendet, mit dem Konnektivität zum lokalen Rechenzentrum bereitgestellt wird.
  • Subnetz für gemeinsame Dienste: Im Subnetz für gemeinsame Dienste werden Dienste gehostet, die für mehrere Azure-Workloads gemeinsam verwendet werden. In diesem Szenario hostet dieses Subnetz virtuelle Computer unter Windows oder Linux, die auch als DNS-Server verwendet werden. Diese DNS-Server hosten dieselben DNS-Zonen wie die lokalen Server.
• Verbundenes Abonnement: Das verbundene Abonnement ist eine Sammlung von Workloads, für die ein virtuelles Netzwerk und Konnektivität zum lokalen Netzwerk erforderlich ist.
  • VNET-Peering: Diese Komponente ist eine Peering-Verbindung zum Hub-VNET. Mit dieser Verbindung wird Konnektivität zwischen dem lokalen Netzwerk und dem Spoke über das Hub-VNET implementiert.
  • Standardsubnetz: Das Standardsubnetz enthält eine Beispielworkload.
    • web-vmss: Diese Beispiel-VM-Skalierungsgruppe hostet eine Workload in Azure, auf die über das lokale Netzwerk, Azure und das öffentliche Internet zugegriffen werden kann.
    • Lastenausgleich: Das Lastenausgleichsmodul ermöglicht Zugriff auf eine Workload, die von einer Reihe von VMs gehostet wird. Um in Azure und aus dem lokalen Rechenzentrum auf die Workload zuzugreifen, muss die IP-Adresse dieses Lastenausgleichsmoduls im Standardsubnetz verwendet werden.
  • Application Gateway-Subnetz: Dieses Subnetz ist das erforderliche Subnetz für den Azure Application Gateway-Dienst.
    • Application Gateway: Mit Application Gateway können Benutzer über das öffentliche Internet auf die Beispielworkload im Standardsubnetz zugreifen.
    • wkld1-pip: Diese Adresse ist die öffentliche IP-Adresse, die verwendet wird, um über das öffentliche Internet auf die Beispielworkload zuzugreifen.
• Getrenntes Abonnement: Das getrennte Abonnement ist eine Sammlung von Workloads, die keine Konnektivität zum lokalen Rechenzentrum benötigen und den Private Link-Dienst nutzen.
  • PLSSubnet: Das Subnetz des Private Link-Diensts (PLSSubnet) umfasst eine oder mehrere Ressourcen des Private Link-Diensts, die Konnektivität zu Workloads bieten, die im verbundenen Abonnement gehostet werden.
  • Standardsubnetz: Das Standardsubnetz enthält eine Beispielworkload.
    • web-vmss: Diese Beispiel-VM-Skalierungsgruppe hostet eine Workload in Azure, auf die über das lokale Netzwerk, Azure und das öffentliche Internet zugegriffen werden kann.
    • Lastenausgleich: Das Lastenausgleichsmodul ermöglicht Zugriff auf eine Workload, die von einer Reihe von VMs gehostet wird. Dieses Lastenausgleichsmodul ist mit dem Private Link-Dienst verbunden, um Benutzern über Azure und das lokale Rechenzentrum Zugriff zu ermöglichen.
  • Application Gateway-Subnetz: Dieses Subnetz ist das erforderliche Subnetz für den Application Gateway-Dienst.
    • Application Gateway: Mit Application Gateway können Benutzer über das öffentliche Internet auf die Beispielworkload im Standardsubnetz zugreifen.
    • wkld2-pip: Diese Adresse ist die öffentliche IP-Adresse, die verwendet wird, um über das öffentliche Internet auf die Beispielworkload zuzugreifen.
  • Azure Bastion-Subnetz: Der Azure Bastion-Dienst im getrennten virtuellen Netzwerk wird zu Wartungszwecken für das Remoting mit VMs in den Hub-and-Spoke-VNETs über das öffentliche Internet verwendet.

Komponenten

• Virtuelles Netzwerk. Azure Virtual Network (VNET) ist der grundlegende Baustein für Ihr privates Netzwerk in Azure. Mit VNET können zahlreiche Arten von Azure-Ressourcen (beispielsweise virtuelle Azure-Computer) sicher untereinander sowie mit dem Internet und mit lokalen Netzwerken kommunizieren.

• Azure Bastion. Azure Bastion ist ein vollständig verwalteter Dienst, der sichereren und nahtloseren Zugriff auf virtuelle Computer (VMs) per RDP (Remotedesktopprotokoll) und SSH (Secure Shell-Protokoll) ohne jegliche Verfügbarkeit über öffentliche IP-Adressen bietet.

• VPN Gateway. VPN Gateway sendet verschlüsselten Datenverkehr zwischen einem virtuellen Azure-Netzwerk und einem lokalen Standort über das öffentliche Internet. Ein VPN-Gateway kann aber auch verwendet werden, um verschlüsselten Datenverkehr zwischen virtuellen Azure-Netzwerken über das Microsoft-Netzwerk zu senden. Ein VPN-Gateway ist eine spezifische Art eines Gateways für ein virtuelles Netzwerk.

• Private Link. Azure Private Link stellt eine private Verbindung zwischen einem virtuellen Netzwerk und Azure-PaaS-Diensten (Platform-as-a-Service), kundeneigenen Diensten oder Diensten von Microsoft-Partnern her. Dadurch wird die Netzwerkarchitektur vereinfacht und die Verbindung zwischen Endpunkten in Azure wird geschützt, indem die Offenlegung von Daten im öffentlichen Internet verhindert wird.

• Application Gateway. Azure Application Gateway ist ein Lastenausgleich für Webdatenverkehr, mit dem Sie eingehenden Datenverkehr für Ihre Webanwendungen verwalten können. Herkömmliche Lastenausgleichsmodule sind auf der Transportschicht (OSI-Schicht 4 – TCP und UDP) aktiv und leiten Datenverkehr basierend auf der IP-Quelladresse und dem dazugehörigen Port an eine IP-Zieladresse und an den entsprechenden Port weiter.

Empfehlungen

Die folgenden Empfehlungen gelten für die meisten Szenarios. Sofern Sie keine besonderen Anforderungen haben, die Vorrang haben, sollten Sie diese Empfehlungen befolgen.

Erweitern von AD DS auf Azure (optional)

Verwenden Sie integrierte DNS-Zonen in AD DS, um DNS-Einträge für Ihr lokales Rechenzentrum und Azure zu hosten. In diesem Szenario sind zwei Arten von AD DS-DNS-Servern vorhanden: ein lokaler Server und ein Server im Hub-VNET.

Es wird empfohlen, Ihre AD DS-Domäne auf Azure zu erweitern. Darüber hinaus empfiehlt es sich, die Hub-and-Spoke-VNETs für die Verwendung der AD DS-DNS-Server im Hub-VNET für alle VMs in Azure zu konfigurieren.

Konfigurieren eines Split Brain-DNS

Stellen Sie sicher, dass ein Split Brain-DNS implementiert ist, damit Azure-Systeme, lokale Benutzer und Internetbenutzer basierend auf den Ressourcen, über die sie eine Verbindung herstellen, auf Workloads zugreifen können.

Sowohl für verbundene als auch für getrennte Workloads gelten Empfehlungen für die folgenden Komponenten für die DNS-Auflösung:

• Azure DNS-Zonen für Internetbenutzer.
• DNS-Server für lokale Benutzer und Azure-Systeme.
• Private DNS-Zonen in Azure für die Auflösung zwischen Azure-VNETs.

Zur Veranschaulichung dieser Split Brain-Empfehlung gehen wir von folgendem Beispiel aus: Sie verfügen über Workload 1, für die der vollqualifizierte Domänenname (FQDN) wkld1.contoso.com verwendet wird.

In diesem Szenario müssen Internetbenutzer diesen Namen in die öffentliche IP-Adresse auflösen, die Application Gateway über Wkld1-pip verfügbar macht. Diese Lösung wird erreicht, indem ein Adresseintrag (A-Eintrag) in Azure DNS für das verbundene Abonnement erstellt wird.

Lokale Benutzer müssen den Namen in die interne IP-Adresse für das Lastenausgleichsmodul im verbundenen Abonnement auflösen. Diese Lösung wird erreicht, indem ein A-Eintrag auf den DNS-Servern im Hubabonnement erstellt wird.

Azure-Systeme können den Namen in eine interne IP-Adresse für das Lastenausgleichsmodul im verbundenen Abonnement auflösen, indem sie entweder einen A-Eintrag auf dem DNS-Server des Hubabonnements erstellen oder private DNS-Zonen verwenden. Bei Verwendung von privaten DNS-Zonen erstellen Sie entweder manuell einen A-Eintrag in der privaten DNS-Zone, oder aktivieren Sie die automatische Registrierung.

Verwenden von privaten DNS-Zonen für Private Link-Verbindungen

In unserem Szenario wird Workload 2 in einem getrennten Abonnement gehostet. Lokale Benutzer und verbundene Azure-Systeme greifen über einen privaten Endpunkt im Hub-VNET auf diese Workload zu. Es gibt jedoch eine dritte Verbindungsmöglichkeit für diese Workload: Azure-Systeme im selben VNET wie Workload 2.

Für ein besseres Verständnis der DNS-Empfehlungen für Workload 2 werden die einzelnen Empfehlungen nachfolgend anhand des FQDN wkld2.contoso.com erläutert.

In diesem Szenario müssen Internetbenutzer den Namen in die öffentliche IP-Adresse auflösen, die Application Gateway über Wkld2-pip verfügbar macht. Diese Lösung wird erreicht, indem in Azure DNS ein A-Eintrag für das verbundene Abonnement erstellt wird.

Lokale Benutzer und Azure-Systeme, die mit dem Hub-VNET und den Spoke-VNETs verbunden sind, müssen den Namen in die interne IP-Adresse für den privaten Endpunkt im Hub-VNET auflösen. Diese Lösung wird erreicht, indem ein A-Eintrag auf den DNS-Servern im Hubabonnement erstellt wird.

Azure-Systeme innerhalb desselben VNETs wie Workload 2 müssen den Namen in die IP-Adresse des Lastenausgleichsmoduls im getrennten Abonnement auflösen. Diese Lösung wird erreicht, indem in diesem Abonnement eine private DNS-Zone in Azure DNS verwendet wird.

Azure-Systeme in anderen VNETs können die IP-Adresse von Workload 2 ebenfalls auflösen, wenn Sie diese VNETs mit einer privaten DNS-Zone verknüpfen, die den A-Eintrag für Workload 2 hostet.

Aktivieren der automatischen Registrierung

Wenn Sie eine VNET-Verbindung mit einer privaten DNS-Zone konfigurieren, können Sie optional die automatische Registrierung für alle virtuellen Computer konfigurieren.

Bei Verwendung von AD DS-DNS-Servern können konfigurierte Windows-VMs dynamische Updates für Windows-Computer nutzen, damit Ihre eigenen DNS-Einträge auf den AD DS-DNS-Servern immer aktuell sind. Es wird empfohlen, dynamische Updates zu aktivieren und die DNS-Server so zu konfigurieren, dass nur sichere Updates zulässig sind.

Linux-VMs bieten keine Unterstützung für sichere dynamische Updates. Verwenden Sie für lokale Linux-Computer DHCP (Dynamic Host Configuration-Protokoll), um DNS-Einträge für die AD DS-DNS-Server zu registrieren.

Für Linux-VMs in Azure verwenden Sie einen automatisierten Prozess.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Skalierbarkeit

• Sie sollten pro Azure-Region und lokalem Rechenzentrum die Verwendung von mindestens zwei DNS-Servern in Betracht ziehen.
• Eine entsprechende Konfiguration ist im vorherigen Szenario beschrieben, in dem DNS-Server lokal und im virtuellen Hubnetzwerk implementiert sind.

Verfügbarkeit

• Gehen Sie bei der Platzierung von DNS-Servern sorgfältig vor. Wie bei den Überlegungen zur Skalierbarkeit beschrieben, sollten DNS-Server in der Nähe von Benutzern und Systemen platziert werden, die darauf zugreifen müssen.
  • In der Azure-Region: Jede Azure-Region verfügt über ein eigenes Hub-VNET oder einen eigenen vWAN-Hub. Stellen Sie Ihre DNS-Server in diesem VNET bzw. Hub bereit.
  • Im lokalen Rechenzentrum: Sie sollten zudem über zwei DNS-Server pro lokalem Rechenzentrum für Benutzer und Systeme an diesen Standorten verfügen.
  • Für isolierte (getrennte) Workloads hosten Sie eine private DNS-Zone und eine öffentliche DNS-Zone für jedes Abonnement, um Split Brain-DNS-Einträge zu verwalten.

Verwaltbarkeit

• Überlegen Sie, ob DNS-Einträge für PaaS-Dienste (Platform-as-a-Service) erforderlich sind.
• Darüber hinaus sollte die DNS-Auflösung für PaaS-Dienste berücksichtigt werden, die einen privaten Endpunkt nutzen. Verwenden Sie zu diesem Zweck eine private DNS-Zone, und nutzen Sie Ihre DevOps-Pipeline, um Einträge auf den DNS-Servern zu erstellen.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

• Wenn DNSSEC verwendet werden muss, bedenken Sie, dass Azure DNS diese Standards derzeit nicht unterstützt.
• Zur DNSSEC-Validierung stellen Sie einen benutzerdefinierten DNS-Server bereit, und aktivieren Sie die DNSSEC-Validierung.
• Azure DDoS Protection, kombiniert mit bewährten Methoden für den Anwendungsentwurf, bietet erweiterte Features zur DDoS-Risikominderung, um besser vor DDoS-Angriffen zu schützen. Sie sollten Azure DDOS Protection in allen virtuellen Umkreisnetzwerken aktivieren.

DevOps

• Automatisieren Sie die Konfiguration dieser Architektur, indem Sie Azure Resource Manager-Vorlagen zur Konfiguration aller Ressourcen kombinieren. Sowohl private als auch öffentliche DNS-Zonen unterstützen die vollständige Verwaltung über die Azure CLI sowie über PowerShell und .NET- oder REST-API.
• Wenn Sie eine CI/CD-Pipeline (Continuous Integration/Continuous Development) für die Bereitstellung und Verwaltung von Workloads in Azure und lokalen Umgebungen verwenden, können Sie auch die automatische Registrierung von DNS-Einträgen konfigurieren.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

• Die Kosten von Azure DNS-Zonen basieren auf der Anzahl von DNS-Zonen, die in Azure gehostet werden, sowie auf der Anzahl von empfangenen DNS-Abfragen.
• Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln. Preismodelle für Azure DNS sind hier erläutert.
• Das Abrechnungsmodell für Azure ExpressRoute basiert entweder auf einem Volumentarif mit Abrechnung pro Gigabyte ausgehender Datenübertragungen oder auf einer Datenflatrate mit monatlicher Gebühr, in der sämtliche Datenübertragungen eingeschlossen sind.
• Wenn Sie anstelle von ExpressRoute ein VPN verwenden, hängen die Kosten von der SKU des virtuellen Netzwerkgateways ab, und die Abrechnung erfolgt pro Stunde.

Nächste Schritte

Erfahren Sie mehr über die Komponententechnologien:

• Was ist Azure DNS?
• Was ist Azure Virtual Network?
• Was ist Azure ExpressRoute?
• Was ist Azure Bastion?

Zugehörige Ressourcen

Erkunden Sie die verwandten Architekturen:

• Azure Enterprise Cloud-Dateifreigabe
• N-schichtige Anwendung mit Apache Cassandra
• Mehrinstanzenfähige SaaS-Anwendungen in Azure
• Erweitern eines lokalen Netzwerks per ExpressRoute