Azure policy deployment

Question

Policy deployment having issue with private dns zone mapping

Configure Azure PaaS services to use private DNS zones

Answer 1

Hi @K, Niranjan ,

When working with Azure PaaS services, Private Endpoints, and Private DNS Zones, a Policy deployment issue typically stems from a misalignment between your centralised Azure Policy definitions (like ⁠DeployIfNotExists⁠ or ⁠Modify⁠) and the way your private endpoint resources or network topologies are being provisioned.

If your Azure Policy is failing to map or create DNS records for your Private Endpoints, it is usually caused by one of these common root causes:

1. Permissions or RBAC Issues on the Managed Identity The ⁠DeployIfNotExists⁠ (DINE) policy utilizes a Managed Identity to create the Network/privateDnsZones/dnsZoneGroups resource. Issue: The policy's managed identity lacks the Private DNS Zone Contributor or Network Contributor role over the central resource group where your Private DNS Zones live. Fix: Go to your Azure Policy Assignment, check its Identity tab, and verify that the assignment has been granted proper RBAC permissions at the scope of your central DNS zones.
2. Conflicting "Integrate with Private DNS" Settings during Manual Creation Issue: If user manually creates a Private Endpoint via the Azure Portal and selects "Yes" to Integrate with private DNS zone, the portal will attempt to create a local Private DNS Zone in that same resource group. If an Azure Policy is set up to Deny local zone creation (forcing everything to use a central hub zone), the deployment will fail. Fix: When manually deploying Private Endpoints under strict governance, always select "No" to Integrate with private DNS zone. Let the background ⁠DeployIfNotExists⁠ policy step in post-deployment to handle the centralized mapping.

To properly route traffic to PaaS services securely without passing over the public internet, use the following architectural workflow:

Step 1: Create the Central Private DNS Zones

Azure requires specific zone naming conventions for its CNAME redirection mechanism to work. 

1. In your hub or identity subscription, create a Private DNS Zone.
2. Match the name precisely to the service type. Common examples include:

Azure Blob Storage: ⁠privatelink.blob.core.windows.net⁠

Azure SQL Database: ⁠privatelink.database.windows.net⁠

Azure Key Vault: ⁠privatelink.vaultcore.azure.net⁠

Step 2: Link the Private DNS Zone to Your VNets

A Private DNS Zone is completely isolated until it is explicitly associated with a virtual network.

1. Navigate to your created Private DNS Zone.
2. Under Settings, select Virtual network links.
3. Click + Add, select your target Virtual Network (where your client VMs, AKS clusters, or App Services reside), and save.

Step 3: Deploy the PaaS Private Endpoint

1. Go to your PaaS resource (e.g., your Storage Account).
2. Select Networking > Private endpoint connections > + Private Endpoint.
3. Choose the target VNet and Subnet where the endpoint's private IP should be allocated.
4. Under Configuration, if you are letting a central Azure Policy handle it, toggle Integrate with private DNS zone to No. If configuring manually without a policy, select Yes and point it to the central zone created in Step 1.

Step 4: Configure the ⁠dnsZoneGroups⁠

The ⁠dnsZoneGroup⁠ is a sub-resource of the Private Endpoint that links it directly to the Private DNS Zone, instructing Azure to automatically populate and maintain the ⁠A⁠ record.

Once configured it would be as in the below format.

{

"type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",

"apiVersion": "2023-11-01",

"name": "[concat(parameters('privateEndpointName'), '/default')]",

"properties": {

"privateDnsZoneConfigs": [

  {

    "name": "config1",

    "properties": {

      "privateDnsZoneId": "[parameters('privateDnsZoneResourceId')]"

    }

  }

]

}

}

To confirm that your mapping issue is resolved, spin up a test machine inside your linked Virtual Network and run a command-line DNS lookup:

nslookup myserver.database.windows.net

Answer 2

For reliable private DNS zone mapping with the “Configure Azure PaaS services to use private DNS zones” initiative, the platform configuration and policies must be aligned so that DNS integration is handled centrally and automatically.

Key checks and configuration steps:

1. Ensure central private DNS zones exist

• Create the required Private Link DNS zones in a central connectivity subscription, for example:
  • privatelink.blob.core.windows.net for Storage (blob)
  • privatelink.documents.azure.com for Cosmos DB (SQL)
• These zones must be created before assigning the policies.
• Reference: Azure private endpoint DNS configuration.

2. Deny application subscriptions from creating privatelink zones

• Use a custom policy that denies Microsoft.Network/privateDnsZones when the zone name starts with privatelink.
• This forces all Private Link DNS to be hosted centrally and ensures the portal “Integrate with private DNS zone” option is set to No when app teams create private endpoints. If they select Yes, the policy should deny the deployment.

3. Configure DeployIfNotExists policies for DNS zone groups There are two main patterns:

• Policy based on groupId only (for services like Storage):
  • Triggers when a Microsoft.Network/privateEndpoints resource is created with a specific groupId (for example, blob for Storage).
  • The policy deploys a privateDnsZoneGroup child resource on the private endpoint.
  • The privateDnsZoneGroup links the private endpoint to the central private DNS zone resource ID, for example:
    • /subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net
• Policy based on groupId + privateLinkServiceId (for services like Cosmos DB):
  • Triggers when both groupId (for example, SQL) and privateLinkServiceId (contains Microsoft.DocumentDb/databaseAccounts) match.
  • Deploys a privateDnsZoneGroup linked to the appropriate zone, for example:
    • /subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.documents.azure.com

If private DNS zone mapping is failing, verify that:

• The policy rule correctly matches the groupId and, where used, privateLinkServiceId for the target service.
• The parameter for the private DNS zone resource ID points to an existing zone in the central subscription.

4. Assign correct roles to the policy’s managed identity

• For each DeployIfNotExists policy assignment, a managed identity is created.
• Assign Private DNS Zone Contributor to this managed identity on the subscription or resource group that hosts the private DNS zones.
• Also ensure the roleDefinition required by the policy is assigned as per the remediation guidance.
• Without these permissions, the policy can detect the private endpoint but cannot create/update DNS records.

5. Verify policy assignment scope

• Assign the initiative or individual policies at the management group or subscription scope that contains the application teams’ subscriptions.
• Ensure the assignments target the subscriptions where private endpoints are created, and that the parameters (like DNS zone resource IDs) are set correctly.

6. Validate the application owner workflow

• When app teams create PaaS resources:
  • Public endpoints must be denied by policy (for example, Storage networkAcls.defaultAction must be Deny).
  • When creating private endpoints, they must set Integrate with private DNS zone to No; otherwise, the policy should block the deployment.
• After the private endpoint is created:
  • Within a few minutes, the DeployIfNotExists policy should run and deploy the privateDnsZoneGroup.
  • The central DNS zone should show an A record for the private endpoint FQDN with the correct private IP.

7. Troubleshooting mapping issues If DNS zone mapping is not happening:

• Check the Activity log on the private endpoint and its resource group for DeployIfNotExists operations and failures.
• Confirm the managed identity has Private DNS Zone Contributor on the central DNS zone’s subscription/resource group.
• Verify the private endpoint’s groupId and privateLinkServiceId values match the policy conditions.
• Confirm the private DNS zone resource IDs in the policy parameters are correct and the zones exist.

When all of the above are correctly configured, private DNS zone mapping for Azure PaaS services via the “Configure Azure PaaS services to use private DNS zones” initiative will be automatic and consistent across subscriptions.

---

References:

• Private Link and DNS integration at scale