Privater Dienst braucht einen privaten Namen? Private-DNS-Zone erstellen

Veröffentlicht am: 11. August 2026

Private IP-Adressen sind schwer zu merken und können sich beim Ersetzen von Ressourcen ändern. Public DNS ist außerdem der falsche Ort für Namen, die nur innerhalb eines privaten Netzwerks verwendet werden sollen.

Erstelle die Azure-Private-DNS-Zone internal.cloudtrips.dev, verknüpfe sie mit dem CloudTrips-VNet und erstelle diesen privaten Anwendungsnamen:

web.internal.cloudtrips.dev

WEB02 im verknüpften VNet
    |
    | fragt Azure-provided DNS
    v
Private-DNS-Zone internal.cloudtrips.dev
    |
    `-- web A Record -> private IP von WEB01

Diese Zone ist privat. Sie benötigt weder eine Internet-Domainregistrierung noch NS Records bei Vercel oder eine Delegierung von cloudtrips.dev.

Dieser Trip baut auf App braucht ein privates Netzwerk? VNet erstellen und Mehrere Server brauchen eine Adresse? Load Balancer erstellen auf. Behalte vnet-cloudtrips-test-weu sowie die virtuellen Maschinen WEB01 und WEB02.

Public und Private DNS verstehen

Die Public-DNS-Zone aus dem vorherigen Trip und diese private Zone lösen unterschiedliche Probleme:

Eigenschaft	Public-DNS-Zone	Private-DNS-Zone
Standort des Resolvers	Internet	Verknüpfte Azure-VNets
Typische Antwort	Öffentlicher Endpunkt	Private IP-Adresse
Parent-Delegierung	Erforderlich	Nicht erforderlich
VNet Link	Nicht verwendet	Erforderlich

Das Erstellen der privaten Zone allein reicht nicht. Ein Virtual Network Link macht sie für Clients in einem ausgewählten VNet sichtbar. Der Link verbindet keine Netzwerke und erlaubt keinen Datenverkehr durch eine NSG. Er stellt lediglich die DNS-Auflösung dieser Zone bereit.

Vorhandene private Adressen lesen

Lies die aktuellen privaten IP-Adressen, statt feste Werte anzunehmen:

WEB01_IP=$(az vm list-ip-addresses \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web01-test-weu \
  --query '[0].virtualMachine.network.privateIpAddresses[0]' \
  --output tsv)

WEB02_IP=$(az vm list-ip-addresses \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu \
  --query '[0].virtualMachine.network.privateIpAddresses[0]' \
  --output tsv)

printf 'WEB01: %s\nWEB02: %s\n' "$WEB01_IP" "$WEB02_IP"

Die Werte sollten aus snet-app stammen, beispielsweise 10.20.1.x.

Private-DNS-Zone erstellen

Suche im Azure-Portal nach Private DNS zones, wähle + Create und konfiguriere:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: internal.cloudtrips.dev

Wähle Review + create > Create und öffne danach die Zone. Azure erstellt automatisch einen SOA Record. Anders als bei einer Public-DNS-Zone müssen ihre Nameserver nicht zu einem öffentlichen DNS-Anbieter kopiert werden.

Azure-Portal-Seite zum Erstellen der Private-DNS-Zone internal.cloudtrips.dev

Der entsprechende CLI-Befehl lautet:

az network private-dns zone create \
  --resource-group rg-cloudtrips-network-test-weu \
  --name internal.cloudtrips.dev

Zone mit dem VNet verknüpfen

Öffne in internal.cloudtrips.dev Settings > Virtual network links und wähle + Add. Konfiguriere:

Link name: link-cloudtrips-test-weu
Subscription: CloudTrips TEST
Virtual network: vnet-cloudtrips-test-weu
Enable auto registration: Deaktiviert

Lass die automatische Registrierung deaktiviert. Dieser Trip erstellt einen gezielten Anwendungs-Record. Auto-Registration ist nützlich, wenn Azure VM-Records automatisch erstellen und entfernen soll. Sie kann aber Namen für alle unterstützten VMs im verknüpften VNet hinzufügen und wird für Private-Endpoint-Zonen nicht benötigt.

Wähle OK und warte, bis der Linkstatus Completed lautet.

Private-DNS-VNet-Link zwischen internal.cloudtrips.dev und vnet-cloudtrips-test-weu mit deaktivierter automatischer Registrierung

Der entsprechende CLI-Befehl liest zuerst die VNet-Ressourcen-ID und erstellt danach den Link:

VNET_ID=$(az network vnet show \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vnet-cloudtrips-test-weu \
  --query id \
  --output tsv)

az network private-dns link vnet create \
  --resource-group rg-cloudtrips-network-test-weu \
  --zone-name internal.cloudtrips.dev \
  --name link-cloudtrips-test-weu \
  --virtual-network "$VNET_ID" \
  --registration-enabled false

Privaten A Record erstellen

Kehre zur Zonenübersicht zurück und wähle + Record set. Konfiguriere:

Name: web
Type: A
TTL: 300
IP address: der zuvor gelesene WEB01_IP-Wert

Wähle OK. Der vollständige Name lautet web.internal.cloudtrips.dev; die Antwort ist die private IP von WEB01.

Private-DNS-Zone mit dem web A Record für die private IP-Adresse von WEB01

Erstelle denselben Record mit der CLI:

az network private-dns record-set a create \
  --resource-group rg-cloudtrips-network-test-weu \
  --zone-name internal.cloudtrips.dev \
  --name web \
  --ttl 300

az network private-dns record-set a add-record \
  --resource-group rg-cloudtrips-network-test-weu \
  --zone-name internal.cloudtrips.dev \
  --record-set-name web \
  --ipv4-address "$WEB01_IP"

Verwende entweder die Portal-Schritte oder die CLI-Befehle, nicht beide. Sonst versuchst du, dieselben Ressourcen zweimal zu erstellen.

Auflösung aus dem verknüpften VNet prüfen

Dein Mac befindet sich außerhalb des verknüpften VNets. Ein lokaler dig ist daher kein gültiger positiver Test. Führe die Abfrage mit Azure VM Run Command auf WEB02 aus:

az vm run-command invoke \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu \
  --command-id RunShellScript \
  --scripts "getent ahostsv4 web.internal.cloudtrips.dev"

Die Ausgabe sollte den in WEB01_IP gespeicherten Wert enthalten.

WEB02-Run-Command-Ausgabe mit der Auflösung von web.internal.cloudtrips.dev zur privaten IP von WEB01

Beweise nun, dass der Name für die Anwendung und nicht nur für DNS funktioniert:

az vm run-command invoke \
  --resource-group rg-cloudtrips-network-test-weu \
  --name vm-cloudtrips-web02-test-weu \
  --command-id RunShellScript \
  --scripts "curl --silent --show-error http://web.internal.cloudtrips.dev/"

Die Antwort sollte enthalten:

CloudTrips response from WEB01

WEB02-Run-Command-Ausgabe mit der HTTP-Antwort von WEB01 über dessen privaten DNS-Namen

Dieses Ergebnis beweist drei getrennte Dinge: WEB02 sieht die verknüpfte private Zone, der web Record wird zu WEB01 aufgelöst und die Netzwerkrichtlinie erlaubt HTTP von WEB02 zu WEB01. DNS-Auflösung allein garantiert nicht, dass die Verbindung erlaubt ist.

Bestätigen, dass der Name privat ist

Führe auf deinem Mac aus:

dig web.internal.cloudtrips.dev A +short

Es wird keine öffentliche Antwort erwartet. Das ist die beabsichtigte Sicherheitsgrenze und kein Fehler: Azure-provided DNS stellt die Private-DNS-Zone nur verknüpften VNets und angebundenen Netzwerken mit einem passenden DNS-Forwarding-Design bereit.

Lokales Terminal ohne öffentliche DNS-Antwort für web.internal.cloudtrips.dev

Private-DNS-Lab behalten oder entfernen

Behalte Zone, VNet Link und Record für spätere Private-Endpoint- und Hybrid-DNS-Trips. Die Zone selbst veröffentlicht WEB01 nicht im Internet.

Wenn du nur dieses Lab entfernen möchtest, lösche zuerst den VNet Link und danach internal.cloudtrips.dev. Lösche weder das VNet noch die virtuellen Maschinen, da andere Networking-Trips sie verwenden.

az network private-dns link vnet delete \
  --resource-group rg-cloudtrips-network-test-weu \
  --zone-name internal.cloudtrips.dev \
  --name link-cloudtrips-test-weu \
  --yes

az network private-dns zone delete \
  --resource-group rg-cloudtrips-network-test-weu \
  --name internal.cloudtrips.dev \
  --yes