Hybrid-DNS braucht einen Resolver? Azure DNS Private Resolver konfigurieren

Veröffentlicht am: 11. August 2026

Azure-Private-DNS-Zonen beantworten Anfragen aus verknüpften virtuellen Netzwerken. Ein lokaler DNS-Server kann Azure-provided DNS jedoch nicht direkt abfragen. Azure-Workloads brauchen außerdem einen kontrollierten Weg, um Anfragen für private lokale Namen an einen lokalen DNS-Server zu senden.

Stelle Azure DNS Private Resolver im CloudTrips-Hub bereit. Er ist ein verwalteter DNS-Proxy; es müssen keine DNS-Server-VMs installiert oder gepatcht werden.

Lokales DNS --Conditional Forwarder--> Inbound Endpoint
                                             |
                                             v
                                  Azure Private DNS Zones

Azure VNet --Forwarding Ruleset--> Outbound Endpoint --> lokales DNS

Die beiden Richtungen verwenden unterschiedliche Komponenten:

Der Inbound Endpoint empfängt DNS-Anfragen, die in Azure eintreffen.
Der Outbound Endpoint sendet passende Azure-Anfragen über ein Forwarding Ruleset an externe DNS-Server.

Dieses Lab stellt nur die Inbound-Richtung bereit. Die Outbound-Richtung wird später erklärt, aber nicht konfiguriert, da CloudTrips keinen lokalen DNS-Server als Ziel für weitergeleitete Anfragen hat.

Dieser Trip baut auf Hub-and-Spoke-Netzwerk erstellen und Privater Dienst braucht einen privaten Namen? Private-DNS-Zone erstellen auf. Behalte das Peering zwischen Hub und Anwendungs-VNet, internal.cloudtrips.dev und WEB02.

Resolver planen

Verwende dieses Design:

Resource group: rg-cloudtrips-network-test-weu
Region: West Europe
Hub VNet: vnet-cloudtrips-hub-test-weu (10.60.0.0/16)
Resolver: dnspr-cloudtrips-test-weu
Inbound subnet: snet-dnspr-inbound (10.60.2.0/28)
Inbound endpoint: in-dnspr-cloudtrips-test-weu

Der Inbound Endpoint benötigt ein dediziertes Subnet mit Delegierung an Microsoft.Network/dnsResolvers. Ein /28 reicht für dieses Lab aus. Platziere weder VMs noch Private Endpoints oder andere Dienste in diesem Subnet.

Azure-DNS-Private-Resolver-Endpoints verursachen Kosten, solange sie bereitgestellt sind. Führe den Cleanup aus, wenn du das Hybrid-DNS-Lab danach nicht benötigst.

Prüfe, ob die geplanten Bereiche frei sind:

az network vnet subnet list \
  --resource-group rg-cloudtrips-network-test-weu \
  --vnet-name vnet-cloudtrips-hub-test-weu \
  --query '[].{name:name,prefix:addressPrefix}' \
  --output table

Wenn sich der Bereich mit einem vorhandenen Subnet überschneidet, stoppe und wähle einen anderen freien /28-Bereich in 10.60.0.0/16.

Dediziertes Subnet erstellen

Öffne Virtual networks > vnet-cloudtrips-hub-test-weu > Subnets und erstelle das Inbound Subnet:

Name: snet-dnspr-inbound
Address range: 10.60.2.0/28
Subnet delegation: Microsoft.Network/dnsResolvers

Der entsprechende CLI-Befehl lautet:

az network vnet subnet create \
  --resource-group rg-cloudtrips-network-test-weu \
  --vnet-name vnet-cloudtrips-hub-test-weu \
  --name snet-dnspr-inbound \
  --address-prefixes 10.60.2.0/28 \
  --delegations Microsoft.Network/dnsResolvers

Verwende entweder die Portal- oder die CLI-Schritte, nicht beide.

Private Resolver erstellen

Suche nach DNS private resolvers, wähle + Create und konfiguriere:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: dnspr-cloudtrips-test-weu
Region: West Europe
Virtual network: vnet-cloudtrips-hub-test-weu

Füge unter Inbound endpoints hinzu:

Endpoint name: in-dnspr-cloudtrips-test-weu
Subnet: snet-dnspr-inbound
IP allocation: Dynamic

Lass Outbound endpoints und Ruleset leer. Sie werden in diesem Lab nicht verwendet, weil kein externer DNS-Server vorhanden ist.

Wähle Review + create > Create. Die Bereitstellung kann mehrere Minuten dauern.

DNS-Private-Resolver-Übersicht mit dem erfolgreichen Inbound Endpoint

Private Zone mit dem Resolver-VNet verknüpfen

Der Inbound Endpoint kann eine private Zone nur auflösen, wenn diese mit dem VNet des Resolvers verknüpft ist. Der vorherige Trip verknüpfte internal.cloudtrips.dev mit dem Anwendungs-VNet. Füge einen zweiten Link zum Hub hinzu.

Öffne Private DNS zones > internal.cloudtrips.dev > Virtual network links > + Add:

Link name: link-cloudtrips-hub-test-weu
Virtual network: vnet-cloudtrips-hub-test-weu
Enable auto registration: Deaktiviert

Dabei werden keine DNS Records dupliziert. Beide verknüpften VNets erhalten Antworten aus derselben privaten Zone.

Private-DNS-Zone mit Links zum Anwendungs-VNet und zum Resolver-Hub-VNet

Inbound Endpoint testen

Lies die dynamisch zugewiesene Inbound-IP:

Die az dns-resolver-Befehle stammen aus einer Azure-CLI-Erweiterung. Installiere oder aktualisiere sie vor der Abfrage:

az extension add --name dns-resolver --upgrade

INBOUND_DNS_IP=$(az dns-resolver inbound-endpoint show \
  --resource-group rg-cloudtrips-network-test-weu \
  --dns-resolver-name dnspr-cloudtrips-test-weu \
  --name in-dnspr-cloudtrips-test-weu \
  --query 'ipConfigurations[0].privateIpAddress' \
  --output tsv)

if [ -n "$INBOUND_DNS_IP" ]; then
  printf 'Resolver inbound IP: %s\n' "$INBOUND_DNS_IP"
else
  printf 'Keine Inbound-IP erhalten. DNS-Test nicht fortsetzen.\n' >&2
fi

Fahre nur fort, wenn der Befehl eine private IP wie 10.60.2.4 ausgibt.

Teste von WEB02. WEB02 kann die Zone bereits über den Private-DNS-Link des Anwendungs-VNets auflösen. Durch die explizite Übergabe von $INBOUND_DNS_IP an nslookup muss jedoch genau diese Abfrage den Resolver- Endpoint verwenden. WEB02 repräsentiert damit einen DNS-Client, der den Hub über VNet-Peering erreichen kann:

if [ -n "$INBOUND_DNS_IP" ]; then
  az vm run-command invoke \
    --resource-group rg-cloudtrips-network-test-weu \
    --name vm-cloudtrips-web02-test-weu \
    --command-id RunShellScript \
    --scripts "nslookup web.internal.cloudtrips.dev $INBOUND_DNS_IP"
else
  printf 'Inbound-DNS-IP ist leer; Test wurde nicht gestartet.\n' >&2
fi

Server oder die erste Address der Antwort muss $INBOUND_DNS_IP sein. Die DNS-Antwort muss außerdem die private IP von WEB01 enthalten. Das beweist den Inbound-Pfad:

WEB02 -> Resolver-Inbound-IP -> verknüpfte Private-DNS-Zone -> private WEB01-IP

WEB02 löst web.internal.cloudtrips.dev über den Resolver-Inbound-Endpoint auf

Konfiguriere in einem echten Hybridnetzwerk auf dem lokalen DNS-Server einen Conditional Forwarder für internal.cloudtrips.dev, der auf INBOUND_DNS_IP zeigt. VPN- oder ExpressRoute-Routing und Sicherheitsregeln müssen UDP und TCP Port 53 zu dieser privaten Adresse erlauben. Veröffentliche die Inbound-IP nicht in Public DNS.

Optionale Outbound-Richtung verstehen

Diese Umgebung hat keinen lokalen DNS-Server. Erstelle deshalb weder Outbound Endpoint noch Outbound Subnet, Forwarding Ruleset oder Forwarding Rule. Sie würden Kosten verursachen, ohne ein Ziel zu haben, das Anfragen beantworten kann.

Füge diese Komponenten erst später hinzu, wenn Azure einen Namespace auflösen muss, der auf einem echten DNS-Server gehostet wird, zum Beispiel:

Rule name: forward-corp
Domain: corp.cloudtrips.dev.
Target DNS server: <echte private IP des lokalen DNS-Servers>
Port: 53
State: Enabled

In diesem zukünftigen Design wird das Ruleset mit dem VNet der DNS-Clients verknüpft. Anfragen für corp.cloudtrips.dev. verlassen Azure über den Outbound Endpoint und erreichen den angegebenen Server auf Port 53. Das Ziel muss über VPN oder ExpressRoute erreichbar sein. Verwende weder 168.63.129.16, einen öffentlichen Resolver noch die eigene Inbound-IP des Resolvers als Ersatz.

Azure-Client-Anfrage für *.corp.cloudtrips.dev
  -> verknüpftes Forwarding Ruleset
  -> Outbound Endpoint
  -> echter lokaler DNS-Server:53

Verstehen, was dieses Lab beweist

Der erfolgreiche nslookup beweist die eingehende Richtung nach Azure. Dieses Lab stellt die Outbound-Richtung nicht bereit und behauptet auch nicht, sie zu testen, da kein echter erreichbarer DNS-Server und externer privater Namespace existiert.

Private Resolver erstellt keine VPN-Verbindung, öffnet Port 53 nicht, hostet keine DNS Records und verändert keinen lokalen DNS-Server automatisch. Dafür bleiben Routing, Firewall, Zonen und DNS-Server getrennt verantwortlich.

Resolver-Lab behalten oder entfernen

Behalte den Resolver nur, wenn spätere Hybrid-DNS-Trips ihn benötigen. Lösche andernfalls Inbound Endpoint, Resolver, privaten Zonen-Link zum Hub und danach das dedizierte Inbound Subnet. Behalte den Link zum Anwendungs-VNet und die private Zone aus dem vorherigen Trip.

Wenn du einer früheren Version dieses Trips gefolgt bist, können außerdem ein Outbound Ruleset, out-dnspr-cloudtrips-test-weu und snet-dnspr-outbound vorhanden sein. Im aktuellen Lab werden sie nicht verwendet. Lösche zuerst alle Forwarding Rules und Ruleset-VNet-Links, danach Ruleset, Outbound Endpoint und Outbound Subnet. Entferne erst anschließend Inbound Endpoint, Resolver, privaten Zonen-Link zum Hub und Inbound Subnet.

Das Portal verhindert das Löschen eines Subnets, solange ein Endpoint es verwendet. Diese Abhängigkeitsreihenfolge schützt die VNet-Konfiguration.