DNS-Design¶

Die Namensauflösung entscheidet, ob Verkehr zu einem PaaS-Dienst im privaten Netzwerk bleibt oder über das Internet läuft. Diese Seite erklärt das DNS-Design der Plattform und die Stolperfallen bei der Anbindung an ein On-Premises-DNS. Die Einstellungen stehen unter Feature Flags (Private-DNS-Zonen, Private DNS Resolver).

Komponenten¶

Komponente	Rolle
Spoke virtual network	Nutzt einen benutzerdefinierten DNS-Server: den hub-DNS-Server seiner Region (die Spoke-Einstellung `dnsServerOverwrite` ist standardmäßig leer, siehe Spoke-JSON-Referenz)
hub-DNS-Einstiegspunkt	Typischerweise die Azure Firewall als DNS Proxy. Sie leitet Anfragen an den Resolver weiter.
Azure Private DNS Resolver	Inbound Endpoint: nimmt Anfragen von der firewall und von On-Premises entgegen. Outbound Endpoint: leitet Anfragen für ausgewählte Domänen (zum Beispiel eine interne Active-Directory-Domäne) an DNS-Server an anderer Stelle weiter.
Zentrale Private-DNS-Zonen	Eine Zone pro Private-Link-Dienst (zum Beispiel `privatelink.blob.core.windows.net`). Eine Azure-Policy-initiative registriert darin die Einträge der private endpoints.
On-Premises-DNS	Domain Controller oder andere DNS-Server. Sie beantworten den internen Namensraum und leiten Azure-Namen mit Conditional Forwardern an den Inbound Endpoint des Resolvers weiter.
Öffentliches DNS	Wird außerhalb der Plattform verwaltet, vom Registrar oder DNS-Anbieter

Auflösungspfade¶

flowchart LR
    vm["VM in a spoke"] --> fw["Hub firewall (DNS proxy)"]
    fw --> in["Private DNS Resolver (inbound)"]
    in --> pz["Central private DNS zones"]
    out["Private DNS Resolver (outbound)"] -- "forwarding rule" --> ad["Internal DNS / AD servers"]
    in --> out
    onprem["On-premises client"] --> opdns["On-premises DNS"]
    opdns -- "conditional forwarder" --> in

Von	Nach	Pfad
Spoke	Ein Name in einer Private-DNS-Zone (private endpoint)	DNS-Einstellung des Spokes, firewall-DNS-Proxy, Inbound Endpoint des Resolvers, Private-DNS-Zone
Spoke	Eine interne Domäne, die On-Premises oder auf Domain Controllern in Azure gehostet wird	Derselbe Pfad, danach schickt eine Forwarding-Regel auf dem Resolver die Anfrage über den Outbound Endpoint hinaus
On-Premises	Die interne Domäne	Wird vom On-Premises-DNS beantwortet
On-Premises	Ein Name in einer Azure-Private-DNS-Zone	Ein Conditional Forwarder auf dem On-Premises-DNS schickt die Anfrage über die VPN- oder ExpressRoute-Verbindung an den Inbound Endpoint des Resolvers

Wie ein Name eines private endpoints aufgelöst wird¶

Eine Ressource im virtual network sucht example.azurewebsites.net auf.
Das von Azure bereitgestellte DNS (168.63.129.16) erkennt, dass Private Link für den Dienst aktiviert ist, und liefert einen CNAME auf example.privatelink.azurewebsites.net.
Die Private-DNS-Zone privatelink.azurewebsites.net ist mit dem Netzwerk verknüpft und enthält einen A-Eintrag mit der privaten IP-Adresse des private endpoints.
Die Ressource verbindet sich mit dieser privaten IP. Der Verkehr bleibt im Azure-Backbone.

Damit On-Premises-Clients die private IP erhalten, muss ihr DNS die Anfrage an den Resolver weiterleiten. Ohne das erhalten sie die öffentliche IP, und der Verkehr läuft über das Internet.

Conditional Forwarding aktivieren: in der richtigen Reihenfolge¶

Das Einschalten von Conditional Forwarding ändert, wohin der On-Premises-Verkehr geht. Bestehende Workloads, die einen PaaS-Dienst heute über seine öffentliche Adresse erreichen, beginnen, die private IP-Adresse zu verwenden. Erlauben die firewalls das nicht, funktionieren sie nicht mehr.

Liste die Private-DNS-Zonen auf, die du weiterleiten wirst. Lege pro Zone einen Conditional Forwarder auf den On-Premises-DNS-Servern an, der auf den Inbound Endpoint des Resolvers zeigt.
Erlaube zuerst den Verkehr von On-Premises zu den Adressen der private endpoints, in der On-Premises-firewall und in der Azure Firewall.
Stelle sicher, dass jeder Standort, der die DNS-Server nutzt, private Konnektivität zu Azure hat. Ein entfernter Standort oder eine Tochtergesellschaft ohne Private Link würde eine private IP erhalten, die er nicht erreichen kann. Aktiviere das Forwarding für diese, nachdem die Verbindung steht.
Aktiviere die Forwarder, eine Zone nach der anderen, und teste.

Runbook zum Hinzufügen einer Forwarding-Regel: DNS Conditional Forwarder.

Stolperfallen¶

Stolperfalle	Was passiert	Was zu tun ist
Split DNS: Dieselbe Zone existiert im internen und im öffentlichen DNS	Ein Eintrag, der nur in der öffentlichen Zone existiert, kann im Netzwerk nicht aufgelöst werden, weil das interne DNS für die ganze Zone autoritativ ist und name not found zurückgibt	Lege jeden Eintrag an beiden Orten an oder vermeide es, dieselbe Zone an beiden Orten zu hosten
Manuelle Verwaltung der Einträge	Langsam, fehleranfällig, und nur wenige Personen können es	Verwalte Einträge als Code in einem Repository oder delegiere eine Subdomain an die Teams (DNS-Subdomain-Delegation)
Unklare Ownership	Niemand weiß, wem eine Zone gehört	Benenne Zonen nach Workload und Umgebung

Gegen deine Konfiguration prüfen

Diese Seite beschreibt das übliche Design. Prüfe, welche Adresse die Spokes als DNS-Server verwenden und ob der firewall-DNS-Proxy in deiner Plattformkonfiguration aktiviert ist (virtual_network_dns_servers, firewall_policy_dns.proxy_enabled).