DNS-Sicherheit und private Namensauflösung

In diesem Artikel wird erläutert, wie Sie DNS für Azure Netzwerke mit privaten DNS-Zonen, Azure DNS Private Resolver und DNS-Sicherheitskontrollen entwerfen. Es umfasst Auflösungsmuster für private Namen, hybride DNS-Weiterleitung, Private Endpoint DNS-Integration und DNS-Layer-Bedrohungsschutz.

Inhalt dieses Artikels

DNS ist die Grundlage der Netzwerkkonnektivität: Jede Verbindung beginnt mit einer Namensauflösungsabfrage. In Azure bestimmt das DNS-Design, wie Workloads einander über virtuelle Netzwerke hinweg finden, wie On-Premises-Systeme in Azure gehostete Namen auflösen und wie Private Endpunkte unter ihren vollqualifizierten Domänennamen (FQDNs) erreichbar werden. Über die Auflösung hinaus ist DNS auch eine Angriffsfläche. DNS-Tunneling, Exfiltration und Abfragen zu schädlichen Domänen stellen echte Bedrohungen dar, die Sicherheitskontrollen auf DNS-Ebene erfordern.

In diesem Artikel werden drei DNS-Bedenken behandelt:

Auflösung privater Namen: Wie virtuelle Computer, Container und Plattformdienste Namen innerhalb Azure auflösen, ohne DNS-Abfragen für das öffentliche Internet verfügbar zu machen.
Hybride DNS-Weiterleitung: Wie On-Premises-Netzwerke private Azure-Namen auflösen und wie Azure-Workloads On-Premises-Namen auflösen.
DNS-Sicherheit: Blockieren bösartiger DNS-Abfragen, Verhindern von DNS-Exfiltration und Aktivieren der FQDN-basierten Netzwerkfilterung.

Wer diesen Artikel benötigt

Lesen Sie diesen Artikel, wenn Sie:

Stellen Sie private Endpunkte bereit (sofern dies auf Ihr Szenario zutrifft) und sorgen Sie dafür, dass Workloads privatelink.* DNS-Zonen korrekt auflösen.
Betreiben Sie Hybridumgebungen, in denen lokale Systeme private Azure-Namen auflösen müssen (oder umgekehrt).
Verwenden Sie Azure Firewall und benötigen Sie FQDN-basierte Filterung in Netzwerkregeln.
Sie möchten DNS-Abfragen an bekannte schädliche Domänen auf der Auflösungsebene blockieren.
Verwalten Sie Multi-VNet-Umgebungen, in denen die zentrale DNS-Auflösung Vorgänge vereinfacht.
Planen der DNS-Architektur für Hub-Spoke-Topologien mit gemeinsamen Diensten.

Heben und Verschieben des Fokus: Vorhandenes DNS-Benennungsverhalten während der Migration beibehalten. Verwenden Sie die bidirektionale Weiterleitung zwischen lokalem DNS und Azure, konfigurieren Sie bedingte Weiterleitungen für die Split-Horizon-Namensauflösung, und hosten Sie private Azure-Namen in privaten DNS-Zonen, damit Anwendungen ihre aktuelle DNS-Konfiguration beibehalten.

Modernisierungsfokus: Zentralisieren Sie die Namensauflösung, während Sie Ihre Workloads auf eine neue Plattform umstellen. Verwenden Sie Azure DNS Private Resolver mit Weiterleitungsregelnets für die Hybridauflösung, integrieren Sie Privates DNS Zonen in private Endpunkte für PaaS-Dienste, und aktivieren Sie den Azure Firewall DNS-Proxy, sodass FQDN-basierte Regeln und DNS-Auflösung einen einzelnen zwischengespeicherten Pfad teilen.

Cloud-übergreifender Fokus: Planen Sie die DNS-Umstellung cloudübergreifend vor der Migration der Workloads. Verwenden Sie Azure DNS Private Resolver zur cloudübergreifenden Namensauflösung, richten Sie die bedingte Weiterleitung mit AWS Route 53 Resolver oder Google Cloud DNS ein, und senken Sie vor der Umstellung die TTL-Werte, um das Risiko veralteter Cache-Einträge zu verringern.

Azure Dienste und Features

In der folgenden Tabelle werden die Azure Dienste und Features beschrieben, die an der DNS-Sicherheit und der Auflösung privater Namen beteiligt sind.

Dienst / Funktion	Purpose	Schlüsselfunktion	Wann verwenden?
Azure DNS (öffentliche Zonen)	Autoritatives Hosting für öffentliche Domänennamen	Globales Anycast-Netzwerk, Azure RBAC-Integration, Aliaseinträge für Azure Ressourcen	Sie besitzen eine öffentliche Domäne und möchten DNS-Einträge in Azure mit hoher Verfügbarkeit hosten.
Azure Privates DNS-Zonen	Namensauflösung in virtuellen Netzwerken ohne öffentliche Sichtbarkeit	VNet-Verknüpfung, automatische Registrierung von VM-Hostnamen, Privatelink-Zonenhosting	Interne Namensauflösung für Azure Workloads. Erforderlich für die Dns-Integration des privaten Endpunkts.
Azure DNS Private Resolver	DNS-Weiterleitung zwischen Azure und externen Netzwerken	Eingehender Endpunkt (on-premises → Auflösung in Azure), ausgehender Endpunkt (Azure → On-premises-Weiterleitung), Weiterleitungsregelsätze	Hybridumgebungen, die bidirektionale DNS-Auflösung benötigen, ohne benutzerdefinierte DNS-VMs bereitzustellen.
Azure Firewall DNS-Proxy	Zentrale DNS-Abfangung für FQDN-Filterung	Speichert DNS-Antworten zwischen, ermöglicht FQDN-basierte Netzwerkregeln und stellt einen einzigen DNS-Endpunkt für Spoke-VNets bereit.	Sie stellen Azure Firewall bereit und benötigen FQDN-Filterung in Netzwerkregeln. Erforderlich für eine konsistente FQDN-Auflösung.
DNS-Sicherheitsrichtlinie	Bedrohungsschutz auf der DNS-Ebene	Blockiert die Auflösung bekannter bösartiger Domänen mit Microsoft Threat Intelligence-Feed	Sie möchten verhindern, dass Workloads eine Verbindung mit Befehls- und Steuerungs- oder Schadsoftwareverteilungsdomänen herstellen.

Privates DNS Zonenkonzepte

Privates DNS Zonen bieten eine Namensauflösung für verknüpfte virtuelle Netzwerke, ohne Datensätze im Internet verfügbar zu machen. Wichtige Verhaltensweisen:

VNet-Verknüpfung: Sie können eine private DNS-Zone mit mehreren VNets verknüpfen. Alle Ressourcen in verknüpften VNets können Datensätze in der Zone auflösen.
Automatische Registrierung: Wenn diese Option auf einem VNet-Link aktiviert ist, erstellt Azure automatisch A-Einträge für virtuelle Computer, die in diesem VNet bereitgestellt werden. Azure entfernt Datensätze, wenn Sie virtuelle Computer verlagern oder löschen. Die automatische Registrierung funktioniert nur für VMs (nur primäre NIC). Ein VNet kann sich automatisch nur für eine private DNS-Zone registrieren, Sie können jedoch mehrere VNets mit derselben Zone verknüpfen.
DNS des privaten Endpunkts: Azure Dienste, privatelink.blob.core.windows.net auf die über private Endpunkte zugegriffen wird, erfordern bestimmte PRIVATELINK-DNS-Zonen (z. B. für Azure Blob Storage). Ohne die richtige Zone lösen Clients die öffentliche IP anstelle der privaten Endpunktadresse auf.

DNS Private Resolver-Architektur

Azure DNS Private Resolver ersetzt die Notwendigkeit von benutzerdefinierten virtuellen DNS-Computern in Hybridweiterleitungsszenarien. Das folgende Diagramm zeigt den hybriden DNS-Auflösungsfluss von on-premises über Azure DNS Private Resolver zu einer IP-Adresse des privaten Endpunkts.

Der Resolver verwendet zwei Endpunkttypen:

Eingehender Endpunkt: Stellt eine IP-Adresse bereit, auf die lokale DNS-Server als bedingte Weiterleitung abzielen können. Azure DNS löst An diese IP gesendete Abfragen (einschließlich verknüpfter Privates DNS Zonen) auf. Erfordert ein dediziertes Subnetz, das an Microsoft.Network/dnsResolvers delegiert wird.
Ausgehender Endpunkt: Ermöglicht Azure Workloads die Weiterleitung von DNS-Abfragen an lokale DNS-Server, andere Cloudanbieter oder externe Resolver. Erfordert außerdem ein dediziertes Subnetz. Weiterleitungsregeln, die an den ausgehenden Endpunkt angefügt sind, definieren, welche Domänensuffixe weitergeleitet werden sollen und welche DNS-Zielserver verwendet werden sollen.

Important

Für eingehende und ausgehende Endpunkte ist jeweils ein eigenes dediziertes Subnetz erforderlich. Sie können keine anderen Ressourcen in diesen Subnetzen bereitstellen. Ein VNet, das mit einem Weiterleitungsregelsatz verknüpft ist, muss nicht per Peering mit dem Resolver-VNet verbunden sein. Regelsatzverknüpfungen funktionieren unabhängig von VNet-Peering.

Wie man auswählt

Verwenden Sie die folgende Entscheidungsstruktur, um die richtigen DNS-Komponenten für Ihre Umgebung auszuwählen.

Entscheidungsbaum

Verwenden Sie private Endpunkte?
- Ja → Bereitstellen von Privates DNS Zonen mit den entsprechenden privatelink.* Zonennamen. Verknüpfen Sie Zonen mit VNets, die private Endpunktadressen auflösen müssen.
Müssen lokale Systeme Azure privaten Namen auflösen?
- Ja → DNS Private Resolver mit einem eingehenden Endpunkt bereitstellen. Konfigurieren Sie lokale DNS-Server mit bedingten Weiterleitungen, die auf die eingehende Endpunkt-IP verweisen.
Müssen Azure Workloads lokale Namen auflösen?
- Ja → Dns Private Resolver mit einem ausgehenden Endpunkt bereitstellen. Weiterleitungsregelsätze für lokale Domänensuffixe erstellen (z. B. corp.contoso.com).
Stellen Sie Azure Firewall bereit und benötigen FQDN-Filterung in Netzwerkregeln?
- Ja → Aktivieren des Firewall-DNS-Proxys. Konfigurieren Sie die Spoke-VMs so, dass sie die private IP-Adresse der Firewall als DNS-Server verwenden.
Möchten Sie DNS-Abfragen für bekannte schädliche Domänen blockieren?
- Ja → Aktivieren der DNS-Sicherheitsrichtlinie mit Microsoft Threat Intelligence-Feed auf den Ziel-VNets.

Allgemeine Muster

Muster	Komponenten	Anwendungsfall
Nur Auflösung des privaten Endpunkts	Privates DNS Zonen + VNet-Links	Ausschließlich in der Cloud ausgeführte Workloads, die über private Endpunkte auf PaaS-Dienste zugreifen. Keine Hybridkonnektivität.
Hybride bidirektionale Auflösung	Privates DNS Zonen + DNS Private Resolver (eingehend + ausgehend)	Die lokale Umgebung löst private Azure-Namen auf; Azure löst lokale Active Directory-Namen auf.
Zentrales Hub-DNS	DNS Private Resolver im Hub-VNet + mit den Spoke-VNets verknüpfte Weiterleitungsregelsätze	Hub-Spoke-Topologie, in der alle DNS-Auflösungsrouten über den Hub zur zentralisierten Protokollierung und Steuerung geleitet werden.
Firewall-vermitteltes DNS	Azure Firewall DNS-Proxy + Privates DNS Zonen	Umgebungen, die Firewall für die FQDN-Filterung verwenden. Firewall fängt DNS ab und ermöglicht eine konsistente FQDN-to-IP-Auflösung für Netzwerkregeln.
Vollständiger Sicherheitsstapel	Alle vorherigen Optionen sowie DNS-Sicherheitsrichtlinie	Unternehmensumgebungen, die hybride Auflösung, FQDN-Filterung und DNS-Layer-Bedrohungsschutz erfordern.

Beispiele für private Endpunkt-DNS-Zonen

In der folgenden Tabelle sind allgemeine Azure Dienste und die erforderlichen Privates DNS Zonennamen aufgeführt.

Azure-Dienst	Name der privaten DNS-Zone
Azure Blob Storage (Speicherdienst von Azure für unstrukturierte Daten)	`privatelink.blob.core.windows.net`
Azure SQL-Datenbank	`privatelink.database.windows.net`
Azure Key Vault (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel)	`privatelink.vaultcore.azure.net`
Azure Files	`privatelink.file.core.windows.net`
Azure Container Registry (Registrierungsdienst für Container von Azure)	`privatelink.azurecr.io`
Azure Cosmos DB (SQL-API)	`privatelink.documents.azure.com`

Note

Die vollständige Liste der Privates DNS Zonennamen für alle Azure Dienste finden Sie unter Azure Konfiguration des privaten Endpunkt-DNS.

Voraussetzungen

Bevor Sie die DNS-Sicherheit und private Namensauflösung implementieren, stellen Sie sicher, dass Sie folgendes haben:

Ein virtuelles Netzwerk: Alle DNS-Features funktionieren innerhalb oder in virtuellen Netzwerken. Unter "Virtuelle Netzwerke und Subnetze " finden Sie grundlegende Anleitungen. (F1)
Netzwerkkonnektivität für Hybridszenarien: Die Inbound-Endpunkte des DNS Private Resolver erfordern eine Netzwerkerreichbarkeit aus der lokalen Umgebung (über ExpressRoute oder VPN) zum Resolver-VNet.
Dedizierte Subnetze für DNS Private Resolver: Jeder Endpunkt (eingehend und ausgehend) erfordert ein eigenes Subnetz, das an delegiert wird Microsoft.Network/dnsResolvers. Planen Sie für jedes Endpunktsubnetz mindestens ein /28-Subnetz ein.
Bereitgestellte private Endpunkte (bei Verwendung von Privatelink-Zonen): Privates DNS Zonen für privatelink.* Namen geben nur einen Wert an, wenn private Endpunkte vorhanden sind. Anleitungen zur Bereitstellung finden Sie unter Private PaaS-Zugriff mit privaten Endpunkten . (C5)
Azure Firewall bereitgestellt (bei Verwendung von DNS-Proxy): Für das DNS-Proxyfeature ist eine vorhandene Azure Firewall Instanz erforderlich. Siehe Azure Firewall und Verkehrskontrollen. (S1)
Berechtigungen: Rolle „DNS-Zonenmitwirkender“ zum Verwalten von privaten DNS-Zonen. Netzwerkmitwirkender für die Bereitstellung des DNS Private Resolver.

Sicherheitsüberlegungen

DNS führt bestimmte Angriffsvektoren ein, die dedizierte Steuerelemente erfordern. In den folgenden Abschnitten werden Exfiltrationsrisiken, Bedrohungsintelligenz-basierte Blockierung, Firewall-DNS-Proxyverhalten und DNSSEC-Einschränkungen behandelt.

DNS-Exfiltrationsrisiken

Durch DNS-Tunneling werden Daten in DNS-Abfragen codiert, um Informationen über ein andernfalls uneingeschränktes Protokoll zu exfiltrieren. Da die meisten Netzwerke ausgehendes DNS (UDP/TCP 53) zulassen, verwenden Angreifer DNS als verdeckten Kanal. Mindern Sie dieses Risiko durch:

Aktivieren des DNS-Proxys von Azure Firewall und Weiterleiten des gesamten DNS-Datenverkehrs über die Firewall. Die Firewall protokolliert alle DNS-Abfragen, wodurch Tunneling über Analysen erkannt werden kann.
Anwenden einer DNS-Sicherheitsrichtlinie zum Blockieren der Auflösung von Domänen, die bekannten Exfiltrationstools und Befehls- und Steuerungsinfrastrukturen zugeordnet sind.
Überwachen von DNS-Abfragemustern in Azure Monitor auf Anomalien wie ungewöhnlich lange Unterdomänenbezeichnungen, hohe Abfragevolumes zu einer einzelnen Domäne oder Abfragen zu kürzlich registrierten Domänen.

DNS-Sicherheitsrichtlinie

DNS-Sicherheitsrichtlinie mit Microsoft Threat Intelligence blockiert die DNS-Auflösung bekannter bösartiger Domänen auf VNet-Ebene. Wenn eine Workload versucht, eine vom Microsoft Security Response Center (MSRC) gekennzeichnete Domäne aufzulösen, blockiert die Richtlinie die Auflösung, bevor überhaupt eine Netzwerkverbindung hergestellt wird. Dieses Steuerelement funktioniert unabhängig von Azure Firewall und erfordert keine Änderungen an einzelnen Workloadkonfigurationen.

Wichtige Merkmale:

Verwendet Microsoft Threat Intelligence-Feed, der aus MSRC stammt.
Arbeitet auf der DNS-Auflösungsebene: blockiert die Abfrage, nicht den Datenverkehr.
Pro VNet angewendet: Aktivieren Sie auf allen VNets, die Workloads enthalten, die auf das Internet zugreifen.
Im Unterschied zur Firewall-FQDN-Filterung blockieren DNS-Sicherheitsrichtlinien bösartige Domänen weltweit, ohne dass die Bereitstellung einer Firewall erforderlich ist.

Firewall-DNS-Proxy und FQDN-Filterung

Azure Firewall DNS-Proxy ist für die FQDN-basierte Filterung in Netzwerkregeln erforderlich. Ohne DNS-Proxy können DNS-Anforderungen von Client-VMs zu unterschiedlichen Zeiten aufgelöst werden als die Auflösung der Firewall, was zu inkonsistenten IP-zu-FQDN-Zuordnungen und Regelkonflikten führt.

Wenn Sie DNS-Proxy aktivieren:

Konfigurieren Sie die Spoke-VMs so, dass sie die private IP-Adresse der Firewall als DNS-Server verwenden.
Die Firewall löst Abfragen im Auftrag von Clients und speichert Ergebnisse zwischen (positiver Cache bis zu 1 Stunde, negativer Cache bis zu 30 Minuten).
FQDN–to-IP Zuordnungen werden alle 15 Sekunden aktualisiert. Die Firewall entfernt veraltete Einträge nach 15 Minuten.
Anwendungsregeln (L7) verwenden Server Name Indication (SNI) für den FQDN-Abgleich und erfordern keinen DNS-Proxy. Netzwerkregeln (L4) erfordern einen DNS-Proxy für die FQDN-Auflösung.
Die FQDN-Filterung in Netzwerkregeln unterstützt nur genaue Domänen-Übereinstimmungen. Wildcardmuster werden in FQDNs für Netzwerkregeln nicht unterstützt. Verwenden Sie Anwendungsregeln für den FQDN-Abgleich mit Wildcards.

Note

Wenn alle konfigurierten upstream-DNS-Server nicht mehr verfügbar sind, fällt Azure Firewall DNS-Proxy nicht auf einen alternativen Resolver zurück. Die DNS-Auflösung schlägt fehl, bis mindestens ein Upstream-Server wieder verfügbar ist. Planen Sie die DNS-Serverredundanz in Ihrer Upstreamkonfiguration.

Caution

Wenn Sie DEN DNS-Proxy aktivieren, jedoch keine Client-VMs für die Verwendung der Firewall als DNS-Server konfigurieren, funktionieren FQDN-basierte Netzwerkregeln nicht ordnungsgemäß. Clients und Firewall lösen möglicherweise unterschiedliche IPs für denselben FQDN auf, was zu unerwarteten Datenverkehrsverlusten führt.

DNSSEC-Einschränkungen

Azure DNS unterstützt derzeit keine DNSSEC-Überprüfung für private Zonen. Öffentliche Zonen, die in Azure DNS gehostet werden, unterstützen die DNSSEC-Signatur für autoritative Antworten, aber rekursive Auflösung in Azure virtuellen Netzwerken führt keine DNSSEC-Überprüfung durch. Wenn Ihre Sicherheitsanforderungen die DNSSEC-Überprüfung erfordern, bewerten Sie die Überprüfung mithilfe eines benutzerdefinierten DNS-Resolvers, der die Überprüfung auf Anwendungsebene unterstützt oder implementiert.

Überlegungen zum Entwurf

Schwerpunkt des DNS-Designs für Lift-and-Shift

Konfigurieren Sie bidirektionale DNS-Weiterleitung zwischen lokalen DNS-Servern und Azure DNS Private Resolver.
Verwenden Sie bedingte Weiterleiter, damit lokale Abfragen für in Azure gehostete Namen in Azure aufgelöst werden und Abfragen aus Azure für lokale Namen über Ihre vorhandene DNS-Infrastruktur aufgelöst werden.
Erstellen Sie private DNS-Zonen für alle Azure-Dienste, die von migrierten Workloads verwendet werden, insbesondere für Dienste mit privaten Endpunkten.
Beibehalten des Anwendungs-DNS-Verhaltens während der Migration mithilfe von Aliaseinträgen oder CNAME-Zuordnungen, anstatt die Clientlösereinstellungen zu ändern.

Modernisieren des DNS-Designfokus

Zentralisieren Sie die DNS-Auflösung im Hub, indem Sie Azure DNS Private Resolver mit Weiterleitungsregelsätzen verwenden, die von allen Spoke-virtuellen Netzwerken gemeinsam genutzt werden.
Verknüpfen Sie private DNS-Zonen für jeden durch private Endpunkte unterstützten PaaS-Dienst, damit migrierte Workloads Private-Link-Namen automatisch auflösen.
Aktivieren Sie den Azure Firewall DNS-Proxy, sodass FQDN-basierte Netzwerkregeln und Workload-DNS-Auflösung einen konsistenten, zwischengespeicherten Auflösungspfad verwenden.
Verwenden Sie die automatische Registrierung und Azure RBAC für private DNS-Zonen, um die manuelle Verwaltung von DNS-Einträgen bei der Einführung von Infrastructure-as-Code zu reduzieren.

Schwerpunkt des cloudübergreifenden DNS-Designs

Verwenden Sie Azure DNS Private Resolver als Weiterleitungssteuerungspunkt für die cloudübergreifende Namensauflösung.
Konfigurieren Sie die bedingte Weiterleitung zwischen Azure Private DNS, AWS Route 53 Resolver und Google Cloud DNS für jeden privaten Namespace, der umgebungsübergreifend aufgelöst werden muss.
Planen Sie die DNS-Umschaltung in Phasen: TTL-Werte senken, Weiterleitungspfade validieren, CNAME- oder A-Einträge ändern und die Latenz von DNS-Abfragen sowie das Cacheverhalten überwachen.
Wenden Sie DNSSEC auf autorisierende Zonen an, in denen die verbundenen Plattformen sie unterstützen, und dokumentieren Sie, wo private Auflösungspfade DNSSEC nicht überprüfen.

Privater PaaS-Zugriff mit privaten Endpunkten: Bereitstellen privater Endpunkte und Konfigurieren von DNS-Zonen für private Verknüpfungen.
Azure Firewall und Datenverkehrsüberprüfung: Firewall-DNS-Proxykonfiguration und FQDN-Filterung.
Virtuelle Netzwerke und Subnetze: VNet-Grundlagen, einschließlich Subnetzplanung für DNS-Resolver-Endpunkte.
Hub-Spoke-Netzwerktopologie: Zentrale DNS-Auflösung in Hub-Spoke-Architekturen.
Entwurfsphasen auf einen Blick: Phasenbasierte Zusammenfassung über Planungs-, Konnektivitäts-, Sicherheits- und Betriebsentscheidungen hinweg.

Weitere Informationen

Nächste Schritte

Tip

Auf eigene Faust erkunden? Kehren Sie zum Übersichtsnavigator zurück, um Ihren nächsten Artikel nach Funktion zu finden.

Als Nächstes in Ihrer Lift-and-Shift-Reise:

Steuern des ausgehenden Internetdatenverkehrs: Zentralisieren Sie die gesamte ausgehende Kommunikation über Azure Firewall und deaktivieren Sie den standardmäßigen ausgehenden Zugriff.

Als Nächstes in Ihrer Modernisierungsreise:

Einrichten der Produktionsüberwachung: Aktivieren Sie Network Watcher und Netzwerk-Leistungsmonitor für die Produktionsbereitschaft ab dem ersten Tag.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Sichern Sie Ihren cloudübergreifenden Transitpfad: Stellen Sie Azure Firewall in Ihrem sicheren virtuellen Hub bereit, um den gesamten cloudübergreifenden, verzweigten und internetgebundenen Datenverkehr zu prüfen.

Feedback

War diese Seite hilfreich?

Last updated on 2026-07-01