Azure Function App Private Endpoint DNS Resolution Issue Across Subscriptions/Regions

Question

I'm troubleshooting a DNS resolution issue between two Azure Function Apps communicating over a Private Endpoint.

Current Architecture

Source (Caller)

• Source Function App
• Uses VNet Integration
• Calls a Function App hosted in a different subscription

Target

• Function App: func-targetfunctionapp
• Exposed through an Azure Private Endpoint
• Private Endpoint IP: 10.0.7.16I'm troubleshooting a DNS resolution issue between two Azure Function Apps communicating over a Private Endpoint.

  Current Architecture

  Source (Caller)
  • Source Function App
  • Uses VNet Integration
  • Calls a Function App hosted in a different subscription
  Target
  • Function App: func-targetfunctionapp
  • Exposed through an Azure Private Endpoint
  • Private Endpoint IP: 10.0.7.16

My current understanding is:

1. The Private Endpoint and DNS records appear to exist.
2. DNS resolution from the caller fails.
3. The caller VNet may already be linked to a different privatelink.azurewebsites.net zone.
4. There may be multiple privatelink.azurewebsites.net zones across subscriptions/resource groups/regions (PPE and EastUS2).
5. The A record for the target Function App may exist in one DNS zone, while the source VNet is linked to a different zone with the same namespace.
6. Azure prevents linking the VNet to another zone with the same namespace, resulting in the overlapping namespace error.

Questions

1. Does this diagnosis sound correct?
2. In a multi-region/multi-subscription setup, what is the recommended approach when multiple Private Endpoints require the privatelink.azurewebsites.net namespace?
3. How can I determine which privatelink.azurewebsites.net zone my source VNet is currently resolving against?
4. Is there a supported pattern for sharing a single privatelink.azurewebsites.net zone across subscriptions and regions, or should records from multiple Private Endpoints be consolidated into one shared zone?

Any guidance would be appreciated.My current understanding is:

1. The Private Endpoint and DNS records appear to exist.
2. DNS resolution from the caller fails.
3. The caller VNet may already be linked to a different privatelink.azurewebsites.net zone.
4. There may be multiple privatelink.azurewebsites.net zones across subscriptions/resource groups/regions (PPE and EastUS2).
5. The A record for the target Function App may exist in one DNS zone, while the source VNet is linked to a different zone with the same namespace.
6. Azure prevents linking the VNet to another zone with the same namespace, resulting in the overlapping namespace error.

Questions

1. Does this diagnosis sound correct?
2. In a multi-region/multi-subscription setup, what is the recommended approach when multiple Private Endpoints require the privatelink.azurewebsites.net namespace?
3. How can I determine which privatelink.azurewebsites.net zone my source VNet is currently resolving against?
4. Is there a supported pattern for sharing a single privatelink.azurewebsites.net zone across subscriptions and regions, or should records from multiple Private Endpoints be consolidated into one shared zone?

Any guidance would be appreciated.

Answer 1

Hi @Chaitra Shivanand Kulkarni (INFOSYS LIMITED) ,

This does sound like a DNS-zone / DNS-linking issue rather than a Private Endpoint connectivity issue especially since you mentioned the Private Endpoint exists and DNS records appear to be present, but the caller can’t resolve.

1. Confirm the caller resolves the correct private name to the private endpoint IP

For App Service / Function Apps using Private Endpoint, the client must resolve the app hostname (for example in the privatelink.azurewebsites.net namespace) to the private IP assigned to the private endpoint.

A quick built-in style test mentioned in the docs is:

• Use nameresolver to test name resolution to a private IP: nameresolver mywebapp.<AppServiceDefaultDomainSuffix>
• If name resolution fails (or resolves to the public address), private connectivity won’t work.

2. Ensure the Private DNS zone is available to the source VNet doing the lookup

The Private Endpoint name resolution relies on Private DNS zones. If the VNet where the caller app is integrated doesn’t have the right zone/records available (or can’t reach Azure DNS / the configured DNS server), the caller will fail with name-resolution-style errors (for example: “remote name could not be resolved”).

So the “multiple privatelink.azurewebsites.net zones” suspicion often maps to:

• the caller VNet being linked to a different private DNS zone instance than the one containing the correct A record
• or the DNS server in the VNet not having the right records

How this maps to your specific questions

1. “Does this diagnosis sound correct?”

Yes, your diagnosis is directionally correct: when you have multiple private endpoints that rely on the same DNS namespace (privatelink.azurewebsites.net), misalignment between:

• the A record(s) for privatelink.azurewebsites.net
• and the Private DNS zone association/linking from the caller VNet

can cause DNS resolution failure even when the Private Endpoint and DNS records exist somewhere.

2. Recommended approach for multi-region/multi-subscription with privatelink.azurewebsites.net

• use Private DNS zone(s) such that the VNet hosting the caller can resolve the private endpoint FQDN to the private IP
• and ensure DNS records exist in the zone that the caller actually uses

Where it gets tricky in multi-region/subscription is which DNS zone instance the caller VNet is using for privatelink.azurewebsites.net. The docs provided don’t explicitly describe a “single shared zone across subscriptions/regions” mechanism for privatelink.azurewebsites.net, but the operational requirement is consistent: the caller must be able to resolve the name to the private IP via the DNS it uses.

3. How to determine which privatelink.azurewebsites.net zone the source VNet is resolving against?

• From a VM / environment in the caller side VNet, verify resolution:
  • nslookup <private-endpoint-fqdn>
• Or use the nameresolver test to confirm it resolves to the private IP (as described above).
• If you’re using a custom DNS server instead of Azure DNS, ensure forwarding/config is correct so that the DNS server can resolve the Private DNS zone records.

4. Is there a supported pattern to share one privatelink.azurewebsites.net zone across subscriptions/regions, or consolidate records?

The App Service / Function Apps Private Link DNS, you should use the private DNS zone privatelink.azurewebsites.net and that with Private DNS zone groups, records are automatically added to the Private DNS zone.

However, do not explicitly confirm whether Microsoft supports a “single zone shared across subscriptions/regions” as a general pattern. So for your forum answer, you can frame it as:

• “There must be a Private DNS zone configuration that the caller VNet can query successfully, and records must land in the zone that the caller uses.”
• If you operate custom DNS, you’ll need DNS entries/forwarding so the caller can resolve to the private IP.

Extra workaround to validate DNS (App settings guidance)

If you’re in the specific scenario where a webapp/app with Private Endpoint calls another app privately and resolution fails because the integrated VNet DNS doesn’t have the zone, the docs suggest forcing Azure DNS for name resolution by setting:

• WEBSITE_DNS_SERVER to 168.63.129.16 (Azure DNS server)

This takes precedence over the VNet DNS server configuration and can confirm whether DNS availability is the blocker.

Hope this helps!

---

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.

Answer 2

1. The diagnosis is partially correct.

• DNS is critical for Private Endpoint connectivity; the FQDN must resolve to the Private Endpoint IP from the caller VNet.
• If the caller VNet is linked to a Private DNS zone privatelink.azurewebsites.net that does not contain the A record for func-targetfunctionapp, name resolution will fail.
• Azure Private DNS does not allow the same VNet to be linked to multiple zones with the same namespace (privatelink.azurewebsites.net), which matches the overlapping namespace behavior described.
• However, guidance explicitly warns against putting records for multiple services in the same DNS zone when those zones are already linked to a single Azure service Private Endpoint. Each Private Endpoint of like services should have its own zone to avoid A‑record deletion and resolution issues.

So the core idea (wrong zone linked / missing A record) is correct, but the recommended pattern is not to share a single zone for multiple Private Endpoints of the same service.

2. Recommended approach for multi‑region/multi‑subscription with privatelink.azurewebsites.net:

• Use Private DNS Zones for Private Endpoint DNS, and link them to the relevant VNets.
• Follow the documented guidance:
  • Do not override a zone that is actively used for public endpoints unless DNS forwarding to public DNS is configured.
  • Do not associate an existing Private DNS Zone that is already linked to a single Azure service with two different Azure service Private Endpoints; this can cause deletion of the initial A record and resolution issues.
  • Create a DNS zone for each Private Endpoint of like services and avoid placing records for multiple services in the same DNS zone.
• In hub‑and‑spoke or multi‑region architectures, centralize DNS resolution using Azure Private DNS and, optionally, Azure DNS Private Resolver:
  • Deploy regional Private Endpoints for the PaaS instance in each region where clients exist.
  • Enable Private Link and Private DNS zones per region.
  • Maintain the Private Link DNS record sets per region (currently manual lifecycle).
  • For on‑premises or cross‑region access, use DNS forwarding (for example, conditional forwarders) to the Azure Private DNS zones that host privatelink.azurewebsites.net.

3. Determining which privatelink.azurewebsites.net zone the source VNet is resolving against:

• Check the VNet’s DNS configuration:
  • In the VNet settings, under DNS servers, determine whether Azure‑provided DNS or custom DNS is used.
  • If Azure DNS is used, resolution for Private Endpoints comes from Private DNS zones linked to that VNet.
• Inspect Private DNS zone links:
  • For each privatelink.azurewebsites.net Private DNS zone, check its Virtual network links and see whether the source VNet is listed.
  • The zone that has a link to the source VNet is the one used for resolution when Azure‑provided DNS is in use.
• For custom DNS scenarios:
  • Review custom DNS settings and conditional forwarders to see which Private DNS zone (and subscription/region) is being queried for privatelink.azurewebsites.net.

4. Pattern for sharing privatelink.azurewebsites.net across subscriptions/regions:

• A supported pattern is to centralize DNS in a hub VNet and share Private DNS zones across subscriptions and VNets:
  • Create the privatelink.azurewebsites.net Private DNS zone in a central subscription.
  • Link multiple VNets (from different subscriptions/regions) to this zone.
  • Use Azure DNS Private Resolver and DNS forwarding rulesets in hub‑and‑spoke architectures to allow on‑premises and other VNets to resolve Private Link FQDNs.
• However, the documented best practice for Private Endpoints of like services is:
  • Create a DNS zone per Private Endpoint of like services.
  • Do not place records for multiple services in the same DNS zone.

In practice, this means:

• Use central/shared Private DNS zones and VNet links for name resolution across subscriptions/regions.
• Within that design, avoid associating a single Private DNS zone that is already linked to one Private Endpoint with additional Private Endpoints of the same service in a way that causes record conflicts or deletions.
• Ensure that the zone linked to the caller VNet contains the correct A record for func-targetfunctionapp pointing to 10.0.7.16.

---

References:

• Azure Private Endpoint private DNS zone values
• Azure Private Endpoint DNS integration Scenarios
• Private Link and DNS integration at scale
• Troubleshoot Azure Private Endpoint connectivity problems
• Troubleshoot connection to a project with a private endpoint (classic)
• Configure and verify DNS Name Resolution for Microsoft Purview private endpoints