Microsoft AZ-700: Azure DNS & Namensauflösung — Lernleitfaden

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Teil des Microsoft Azure Network Engineer AZ-700 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Azure DNS: öffentliche Zonen, private Zonen und Abwägungen

Azure bietet sowohl öffentliches DNS-Hosting als auch private DNS-Auflösung, die eng in die virtuelle Netzwerkebene integriert sind. Die Wahl zwischen beiden ist eine Frage des Umfangs, der Kontrolle, der Kosten und des Betriebsaufwands. Öffentliche Azure-DNS-Zonen (gehostet in Azure DNS) eignen sich für ins Internet gerichtete Namen und profitieren von globalen Anycast-Endpunkten, einer vorhersagbaren API-gesteuerten Verwaltung und einer Skalierung pro Abfrage. Private DNS-Zonen ermöglichen es Ihnen, autoritative Zonennamen zu erstellen, die nur in private IP-Adressen innerhalb verknüpfter VNets aufgelöst werden. Sie eliminieren die Notwendigkeit, DNS-VMs für die Namensauflösung innerhalb von Azure zu betreiben und zu warten, und unterstützen die automatische Verwaltung von Einträgen, wenn sie mit bestimmten privaten PaaS-Endpunkten integriert sind. Der Hauptkompromiss ist die Kontrolle: Benutzerdefinierte DNS-Server (Windows DNS, BIND) bieten absolute Flexibilität – bedingte Weiterleitung, erweiterte Richtlinien und AD-integriertes SRV/CNAME-Verhalten – auf Kosten von VM-/Verwaltungsaufwand und der Verantwortung für die Ausfallsicherheit. Bei der Leistung geht es um die Abwägung zwischen Latenz und Kosten: Verwaltete Azure-DNS-Dienste reduzieren den Wartungsaufwand und bieten eine globale Auflösungsgeschwindigkeit für öffentliche Abfragen, während im Hub angesiedelte DNS-Weiterleitungen oder Resolver-Appliances die hybride Leistung verbessern und Richtlinien durchsetzen können, aber die Rechen- und Verfügbarkeitskosten erhöhen. Häufige Fallstricke sind das Vergessen, eine private DNS-Zone mit jedem VNet zu verknüpfen, das eine Auflösung benötigt, das Versäumnis, Delegierungen bei der Migration von Namen von On-Premises nach Azure zu migrieren, und die Erwartung eines automatischen Public-to-Private-Split-Horizon-Verhaltens ohne explizite DNS-Einträge oder Weiterleitung.

• Azure DNS (Öffentlich): globales Anycast, verwaltete API, Abrechnung pro Zone/Abfrage.
• Private DNS-Zonen: VNet-bezogene Auflösung, automatische Erstellung privater Einträge für unterstützte PaaS.
• App Gateway WAF_v2: empfohlen für moderne WAF-Funktionen und das v2-Skalierungsmodell.
• Azure Firewall (Standard/Policy): zentrale DNS-Proxy-Option; verursacht zusätzliche Kosten, zentralisiert aber die Richtlinien.
• Benutzerdefiniertes DNS (VM-basiert): maximale Kontrolle, höhere Betriebs- und Verfügbarkeitskosten.

Private DNS-Zonen, Einträge für private Endpunkte und Benennungsstrategien

Wenn Sie öffentlich gehostete Dienste in private Endpunkte umwandeln oder Server nach Azure migrieren, wird DNS zum Koordinationspunkt. Private Endpunkte registrieren A-Einträge auf NIC-Ebene in privaten DNS-Zonen, die dem öffentlichen FQDN entsprechen müssen, den die Clients verwenden sollen. Das korrekte Muster besteht darin, private Zonen zu erstellen, die den öffentlichen Namespace spiegeln (z. B. contoso.com) oder dienstspezifische privatelink-Zonen (für Plattformdienste) zu verwenden und dann entweder die automatische Registrierung zu aktivieren oder manuelle A/CNAME-Einträge zu erstellen, die den FQDN der privaten IP des Endpunkts zuordnen. Der Geltungsbereich ist wichtig: Die Verknüpfung einer privaten Zone mit einem einzelnen VNet beschränkt die Auflösung auf dieses VNet; Hub-and-Spoke-Designs erfordern die Verknüpfung der Zone mit allen Spokes oder die Verwendung von DNS-Weiterleitung von den Spokes zu einem Hub-Resolver. Eine typische Migrationsfalle ist, das öffentliche DNS auf die alte On-Premises-IP zeigen zu lassen, während Azure-Clients zu einer privaten IP auflösen. Um eine Split-Brain-Verwirrung zu vermeiden, planen Sie saubere Umstellungsschritte – aktualisieren Sie öffentliche Einträge erst, nachdem das private DNS und die Weiterleitung validiert wurden, oder verwenden Sie eine Split-Horizon-Benennung mit einer expliziten privaten Zone für denselben Namen. Zertifikate und Host-Header müssen übereinstimmen: Wenn Sie erwarten, dass Application Gateway End-to-End-TLS zu einem privaten Backend durchführt, stellen Sie sicher, dass der CN/SAN des Backend-Zertifikats mit dem Hostnamen übereinstimmt, den das Gateway als Host-Header sendet; andernfalls wird das Backend-TLS fehlschlagen.

Azure Private Resolver und hybride Namensauflösungsmuster

Azure Private Resolver ermöglicht eine verwaltete, skalierbare DNS-Weiterleitung zwischen Azure VNets und On-Premises-Netzwerken, ohne dass Sie eigene DNS-VMs betreiben müssen. Entwurfsmuster platzieren typischerweise Resolver-Endpunkte in einem Hub-VNet: Eingehende Endpunkte empfangen Abfragen von On-Premises (über VPN/ExpressRoute) für private Azure-Zonen, während ausgehende Endpunkte Azure-Abfragen an On-Premises-DNS-Server für nur interne Namen weiterleiten. Regelsätze für den Resolver definieren die bedingte Weiterleitung für bestimmte Namespaces (z. B. contoso.internal → On-Premises-DNS-IPs) und können mit VNets verknüpft werden. Bei globalen Unternehmenseinsätzen zentralisieren Sie die Regelverwaltung im Hub und peeren oder routen den Datenverkehr von den Spokes zum Hub-Resolver. Abwägungen zwischen Leistung und Kosten umfassen die Bereitstellung mehrerer eingehender Endpunkte über Regionen hinweg für Ausfallsicherheit und Latenz (was die Kosten erhöht) oder die Akzeptanz von Resolver-Endpunkten in einer einzigen Region mit Peering, aber höherer regionenübergreifender Latenz. Häufige Fallstricke: das Nichtaktualisieren von bedingten Weiterleitungen auf On-Premises-Systemen, sodass sie auf die eingehenden IPs des Resolvers zeigen, die Fehlkonfiguration von Regeln für Netzwerksicherheitsgruppen, die DNS TCP/UDP 53 zu den Resolver-Endpunkten blockieren, und die Annahme, dass der von Azure bereitgestellte DNS (168.63.129.16) an On-Premises weiterleitet – für die bedingte Weiterleitung ist eine explizite Konfiguration des Resolvers erforderlich.

• DNS-Ports: 53 UDP und 53 TCP müssen für die typische Auflösung und Zonentransfers erlaubt sein.
• Resolver-Endpunkte: in Hub-VNets bereitstellen; sicherstellen, dass NSG und Firewall eingehendes DNS zulassen.

← Hybride Vernetzung · Alle Domänen · Netzwerksicherheit →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Microsoft durchsuchen →