DNS-subdomeindelegatie¶

Een manier om workload teams de DNS-records voor hun eigen private endpoints en interne services zelf te laten beheren, zonder een ticket naar de centrale IT voor elke wijziging. Het idee: delegeer één subdomein van de interne namespace van de organisatie aan Azure en laat elk team eigenaar zijn van een zone daaronder.

Het probleem¶

Naarmate workloads naar het platform verhuizen, hebben teams DNS-records nodig voor private endpoints en interne services. Als alle wijzigingen via een centraal DNS-team lopen:

worden aanvragen een bottleneck en vertragen ze deployment-pipelines,
is er geen self-service,
is het eigenaarschap van zones onduidelijk,
schaalt de centrale aanpak niet mee met het aantal workloads.

Hoe de bestaande DNS er meestal uitziet¶

Een centrale DNS-operator die de hoofd-DNS-infrastructuur beheert.
Mogelijk een netwerkprovider met eigen resolutie.
Active Directory (of vergelijkbaar) dat de interne namespace bevat.
Azure Firewall (of een andere goedgekeurde DNS-proxy) die regionale DNS-forwarding biedt.
Centrale private DNS zones voor Azure-services (privatelink.*).
Policies die zones aan de hubnetwerken koppelen. Zie DNS-ontwerp.

Richtlijn¶

Delegeer één subdomein¶

Kies een subdomein van de interne namespace, bijvoorbeeld azure.<organisation-domain>. De centrale DNS-operator configureert forwarding voor dat subdomein naar de adressen van de regionale DNS-proxy. Alles daaronder wordt opgelost via de private DNS zones van Azure.

Naamgeving van zones¶

Teams maken hun private DNS zones aan volgens een vast patroon:

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

Onderdeel	Betekenis
`<environment>`	Een omgevings-ID zoals door de organisatie gedefinieerd
`<workload-id>`	Een workload-ID zoals door de organisatie gedefinieerd

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

Teams mogen subzones onder hun zone toevoegen, zolang ze het rootpatroon behouden, bijvoorbeeld per regio (<region>.prod.app1.azure.contoso.example) of per service (api.prod.app1.azure.contoso.example).

Deployen en beheren als code¶

Teams deployen de zones met infrastructure as code in hun eigen subscriptions.
Teams beheren de records in de zones vanuit hun eigen pipelines.
Zone-koppeling is geautomatiseerd met Azure Policy: een nieuwe private DNS zone wordt gekoppeld aan de regionale hubnetwerken, zodat de zone vanuit elke spoke wordt opgelost zonder handmatige netwerkkoppelingen.

Governance¶

Maatregel	Hoe
Naamgeving wordt afgedwongen	Een Azure Policy weigert private DNS zones die het patroon niet volgen
Koppeling is automatisch	Een policy koppelt nieuwe zones aan de hubnetwerken
Documentatie	Teams documenteren hun zonestructuur in de workloaddocumentatie, en het doel van een record is duidelijk uit de naam of gedocumenteerd

Resolutiestroom¶

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

Gevolgen¶

Positief:

teams wijzigen hun DNS-records zelfstandig en in hun pipelines,
het eigenaarschap is duidelijk uit de zonenaam,
het model schaalt mee met het aantal workloads,
omgevingen zijn geïsoleerd in aparte zones,
geen handmatige netwerkkoppelingen.

Negatief:

veel zones (minimaal vier per workload als elke omgeving een eigen zone heeft),
troubleshooting over workloads heen is moeilijker als DNS is gedistribueerd.

In MCP¶

Onderdeel	Status
Centrale private DNS zones voor private endpoints en de policy die private endpoints daarin registreert	In het product: `create_private_dns_zones` en `enable_private_dns_zone_policies` (feature flags)
Een private DNS zone per spoke, gekoppeld aan het DNS resolver-netwerk van de hub	In de spoke-JSON: `resourceconfiguration.privatedns` (Spoke JSON-referentie)
De policy die het zonenaampatroon afdwingt en de policy die door teams aangemaakte zones aan de hubnetwerken koppelt	Voor zover deze documentatie laat zien geen onderdeel van de productbaseline. Voeg ze toe als custom policy-definities en -toewijzingen (Policytoewijzingen).
De forwarding aan de kant van de centrale DNS-operator	Buiten het platform: wordt door de DNS-operator gedaan