DNS Subdomain Delegation¶

A way to let workload teams manage the DNS records for their own private endpoints and internal services, without a ticket to central IT for every change. The idea: delegate one subdomain of the organisation's internal namespace to Azure and let each team own a zone below it.

The problem¶

As workloads move to the platform, teams need DNS records for private endpoints and internal services. When all changes go through a central DNS team:

requests become a bottleneck and slow down deployment pipelines,
there is no self-service,
ownership of zones is unclear,
the central approach does not scale with the number of workloads.

What the existing DNS usually looks like¶

A central DNS operator that runs the main DNS infrastructure.
Possibly a network provider with its own resolution.
Active Directory (or similar) that holds the internal namespace.
Azure Firewall (or another approved DNS proxy) that provides regional DNS forwarding.
Central private DNS zones for Azure services (privatelink.*).
Policies that link zones to the hub networks. See DNS design.

Guidance¶

Delegate one subdomain¶

Choose a subdomain of the internal namespace, for example azure.<organisation-domain>. The central DNS operator configures forwarding for that subdomain to the regional DNS proxy addresses. Everything below it is resolved through the Azure private DNS zones.

Zone naming¶

Teams create their private DNS zones using a fixed pattern:

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

Part	Meaning
`<environment>`	An environment identifier defined by the organisation
`<workload-id>`	A workload identifier defined by the organisation

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

Teams may add sub-zones below their zone, as long as they keep the root pattern, for example per region (<region>.prod.app1.azure.contoso.example) or per service (api.prod.app1.azure.contoso.example).

Deploy and manage as code¶

Teams deploy the zones with infrastructure as code in their own subscriptions.
Teams manage the records in the zones from their own pipelines.
Zone linking is automated with Azure Policy: a new private DNS zone is linked to the regional hub networks, so the zone resolves from every spoke without manual network links.

Governance¶

Control	How
Naming is enforced	An Azure Policy denies private DNS zones that do not follow the pattern
Linking is automatic	A policy links new zones to the hub networks
Documentation	Teams document their zone structure in the workload documentation, and the purpose of a record is clear from its name or documented

Resolution flow¶

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

Consequences¶

Positive:

teams change their DNS records independently and in their pipelines,
ownership is clear from the zone name,
the model scales with the number of workloads,
environments are isolated in separate zones,
no manual network links.

Negative:

many zones (at least four per workload if each environment has its own zone),
troubleshooting across workloads is harder when DNS is distributed.

In MCP¶

Piece	Status
Central private DNS zones for private endpoints and the policy that registers private endpoints in them	In the product: `create_private_dns_zones` and `enable_private_dns_zone_policies` (feature flags)
A private DNS zone per spoke, linked to the hub DNS resolver network	In the spoke JSON: `resourceconfiguration.privatedns` (Spoke JSON reference)
The policy that enforces the zone naming pattern and the policy that links team-created zones to the hub networks	Not part of the product baseline as far as these docs show. Add them as custom policy definitions and assignments (Policy assignments).
The forwarding on the central DNS operator's side	Outside the platform: done by the DNS operator