Cross-Tenant Azure App Service Private Endpoint DNS Not Resolving to Private IP

Hi @ Ash B,

Thanks for your response.

The issue is caused by incorrect DNS configuration for App Service Private Endpoint. In cross-tenant scenarios, DNS is not automatically integrated, so you must manually create a Private DNS zone named privatelink.azurewebsites.net in the consumer tenant and add an A record for <appname>.privatelink.azurewebsites.net pointing to the Private Endpoint IP.

The standard App Service hostname resolves via a CNAME chain to this private zone, so without the correct zone and record, DNS queries return NXDOMAIN.

Please follow the Cross-tenant secure access to apps by using private endpoints and verify the configuration.

Ref: Troubleshoot Azure Private Endpoint connectivity problems

Pleaseand “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

The DNS behavior matches a misconfigured or incomplete Private Endpoint DNS setup. For App Service Private Endpoints, DNS must be wired so that the standard hostname (for example, webapp.azurewebsites.net) ultimately resolves to the private endpoint IP via the privatelink zone.

Key points for this scenario:

1. DNS flow for cross-tenant App Service Private Endpoint

From the cross-tenant architecture:

1. The VM queries webapp.azurewebsites.net.
2. Azure public DNS returns a CNAME: webapp.privatelink.azurewebsites.net.
3. A private DNS zone handles webapp.privatelink.azurewebsites.net and returns an A record with the private endpoint IP.
4. The VM connects to the private endpoint IP over HTTPS.

If the VM is still resolving to a public IP or gets Non-existent domain, the private DNS zone for privatelink.azurewebsites.net is either missing, not correctly linked, or doesn’t contain the correct A record.

2. Required DNS configuration in the consumer tenant

For an App Service Private Endpoint in a consumer VNet:

• Create an Azure Private DNS zone for the App Service private endpoint zone, for example:
  • privatelink.azurewebsites.net (or the appropriate regional/private zone for App Service as documented in the Private Endpoint DNS values).
• Link this private DNS zone to the consumer virtual network that hosts the VM.
• Ensure the private DNS zone contains an A record for the private endpoint FQDN (for example, webapp.privatelink.azurewebsites.net) pointing to the private endpoint IP.

From the DNS integration guidance:

• DNS is critical because the service FQDN must resolve to the private endpoint IP instead of the public IP.
• For workloads in a virtual network, use a Private DNS zone linked to that VNet and ensure the A record exists and points to the private endpoint IP.
• Avoid mixing multiple services in the same Private DNS zone; use a zone per like-service private endpoint to prevent record deletion or conflicts.

3. Why Non-existent domain appears

If nslookup for the regional private hostname and short hostname returns Non-existent domain from the VM:

• The VM is using Azure-provided DNS, which only resolves:
  • Names within the same VNet, and
  • Names in linked Private DNS zones.
• If the private DNS zone for privatelink.azurewebsites.net is not correctly linked to the VNet, or the A record is missing, the query will fail and fall back to public DNS, which then returns the public IP or NXDOMAIN depending on the name.

The troubleshooting guidance for private endpoints and virtual networks emphasizes:

• Verify that the private DNS zone exists for the resource type (for example, privatelink.azurewebsites.net for App Service).
• Verify that the private DNS zone is linked to the virtual network.
• Verify that the A record exists and matches the private endpoint IP.

4. Additional steps for cross-tenant scenarios

In cross-tenant architectures:

• Each tenant maintains its own private DNS zone and links it to its own VNets.
• The consumer tenant must have its own private DNS zone for the privatelink domain and link it to the consumer VNet.
• If the VM doesn’t have access to the private DNS zone, Azure public DNS will resolve webapp.privatelink.azurewebsites.net to a public IP, and HTTPS requests to that IP receive 403 Forbidden.

Therefore, in this scenario, the missing piece is typically:

• Ensuring the consumer tenant’s private DNS zone for privatelink.azurewebsites.net is correctly configured and linked, and
• Ensuring the VM’s DNS resolution path actually uses that private DNS zone.

5. Manual records and standard hostname resolution

• The A record for webapp.privatelink.azurewebsites.net must exist in the private DNS zone and point to the private endpoint IP.
• The standard hostname webapp.azurewebsites.net is handled by Azure public DNS, which returns the CNAME to webapp.privatelink.azurewebsites.net. No additional public DNS records should point directly to privatelink.azurewebsites.net.
• The provider can configure a custom domain via a CNAME that references the public azurewebsites.net entry, but that CNAME must not point directly to privatelink.azurewebsites.net.

In a correctly configured setup, the standard App Service hostname resolves to the private endpoint IP via the CNAME chain and the private DNS zone. No extra public records are required beyond what the platform creates.

6. Common pitfalls and limitations

Common issues highlighted in the guidance:

• Overriding a zone that’s actively used to resolve public endpoints without proper DNS forwarding can break resolution.
• Using a single Private DNS zone for multiple different services or private endpoints can cause record deletion and resolution issues.
• Not linking the private DNS zone to the correct VNet, or relying solely on Azure-provided DNS without Private DNS zones, leads to public IP resolution instead of private IP.
• If the user or service doesn’t have access to the private DNS zone, queries resolve to a public IP and receive 403 Forbidden.

Summary of what is likely missing:

• A correctly configured and linked Private DNS zone for the App Service privatelink domain in the consumer tenant, with an A record for the private endpoint FQDN pointing to the private endpoint IP.
• Ensuring the VM’s DNS path uses that private DNS zone so that webapp.azurewebsites.net → CNAME webapp.privatelink.azurewebsites.net → A record (private endpoint IP) works end-to-end.

References:

• Azure Private Endpoint DNS integration Scenarios
• Cross-tenant secure access to apps by using private endpoints
• Troubleshoot Azure Private Endpoint connectivity problems
• Troubleshoot virtual network issues
• Troubleshoot virtual network peering route propagation and sync problems