DNS-Subdomain-Delegierung¶

Ein Weg, workload-Teams die DNS-Einträge für ihre eigenen private endpoints und internen Dienste selbst verwalten zu lassen, ohne bei jeder Änderung ein Ticket an die zentrale IT. Die Idee: Eine Subdomain des internen Namensraums der Organisation wird an Azure delegiert, und jedes Team besitzt darunter eine Zone.

Das Problem¶

Wenn workloads auf die Plattform ziehen, brauchen Teams DNS-Einträge für private endpoints und interne Dienste. Wenn alle Änderungen über ein zentrales DNS-Team laufen:

werden Anfragen zum Engpass und bremsen Deployment-pipelines,
gibt es kein Self-Service,
ist die Zuständigkeit für Zonen unklar,
skaliert der zentrale Ansatz nicht mit der Zahl der workloads.

Wie das bestehende DNS meist aussieht¶

Ein zentraler DNS-Betreiber, der die DNS-Hauptinfrastruktur betreibt.
Möglicherweise ein Netzwerkanbieter mit eigener Namensauflösung.
Active Directory (oder Ähnliches), das den internen Namensraum enthält.
Azure Firewall (oder ein anderer freigegebener DNS-Proxy), der regionales DNS-Forwarding bereitstellt.
Zentrale Private-DNS-Zonen für Azure-Dienste (privatelink.*).
Policies, die Zonen mit den hub-Netzwerken verknüpfen. Siehe DNS-Design.

Empfehlung¶

Eine Subdomain delegieren¶

Wähle eine Subdomain des internen Namensraums, zum Beispiel azure.<organisation-domain>. Der zentrale DNS-Betreiber richtet für diese Subdomain das Forwarding an die Adressen der regionalen DNS-Proxys ein. Alles darunter wird über die Azure-Private-DNS-Zonen aufgelöst.

Zonenbenennung¶

Teams erstellen ihre Private-DNS-Zonen nach einem festen Muster:

<environment>.<workload-id>.azure.<organisation-domain>

Teil	Bedeutung
`<environment>`	Eine von der Organisation definierte Umgebungskennung
`<workload-id>`	Eine von der Organisation definierte workload-Kennung

Beispiele: prod.app1.azure.contoso.example, test.app2.azure.contoso.example.

Teams dürfen unterhalb ihrer Zone Subzonen anlegen, solange sie das Wurzelmuster beibehalten, zum Beispiel pro Region (<region>.prod.app1.azure.contoso.example) oder pro Dienst (api.prod.app1.azure.contoso.example).

Als Code deployen und verwalten¶

Teams deployen die Zonen mit Infrastructure as Code in ihren eigenen Subscriptions.
Teams verwalten die Einträge in den Zonen aus ihren eigenen pipelines.
Die Zonenverknüpfung ist automatisiert mit Azure Policy: Eine neue Private-DNS-Zone wird mit den regionalen hub-Netzwerken verknüpft, sodass die Zone von jedem Spoke aus aufgelöst wird, ohne manuelle Netzwerkverknüpfungen.

Governance¶

Kontrolle	Wie
Die Benennung wird erzwungen	Eine Azure Policy verweigert Private-DNS-Zonen, die dem Muster nicht folgen
Die Verknüpfung ist automatisch	Eine Policy verknüpft neue Zonen mit den hub-Netzwerken
Dokumentation	Teams dokumentieren ihre Zonenstruktur in der workload-Dokumentation, und der Zweck eines Eintrags ergibt sich aus seinem Namen oder ist dokumentiert

Ablauf der Namensauflösung¶

Client or service
  -> upstream DNS resolver
    -> regional DNS proxy
      -> private DNS zone (linked to the hub networks by policy)
        -> record, for example api.prod.app1.azure.contoso.example -> private IP

Konsequenzen¶

Positiv:

Teams ändern ihre DNS-Einträge unabhängig und in ihren pipelines,
die Zuständigkeit ergibt sich aus dem Zonennamen,
das Modell skaliert mit der Zahl der workloads,
Umgebungen sind in getrennten Zonen isoliert,
keine manuellen Netzwerkverknüpfungen.

Negativ:

viele Zonen (mindestens vier pro workload, wenn jede Umgebung eine eigene Zone hat),
die Fehlersuche über workloads hinweg ist schwieriger, wenn DNS verteilt ist.

In MCP¶

Baustein	Status
Zentrale Private-DNS-Zonen für private endpoints und die Policy, die private endpoints dort registriert	Im Produkt: `create_private_dns_zones` und `enable_private_dns_zone_policies` (Feature Flags)
Eine Private-DNS-Zone pro Spoke, verknüpft mit dem Netzwerk des hub-DNS-Resolvers	Im Spoke-JSON: `resourceconfiguration.privatedns` (Spoke-JSON-Referenz)
Die Policy, die das Muster der Zonenbenennung erzwingt, und die Policy, die von Teams erstellte Zonen mit den hub-Netzwerken verknüpft	Soweit diese Dokumentation zeigt, nicht Teil der Produkt-Baseline. Füge sie als benutzerdefinierte Policy-Definitionen und -Zuweisungen hinzu (Policy-Zuweisungen).
Das Forwarding auf Seiten des zentralen DNS-Betreibers	Außerhalb der Plattform: erledigt der DNS-Betreiber