Azure Kubernetes Service (AKS) / Azure DNS Private Resolver / VNet Peering: AKS cannot connect to resources in the peered VNet

Le Van Khoa 1 Reputation point
2026-07-24T04:16:26.9866667+00:00

Service Azure Kubernetes Service (AKS), Azure DNS Private Resolver, Azure Virtual Network Peering

Scenario On the VNet that contains our AKS cluster, the custom DNS setting points to the inbound endpoint of an Azure DNS Private Resolver, which is deployed in a VNet under a different subscription. That VNet is connected to the AKS VNet via VNet peering. In this setup, we are trying to connect from AKS nodes/pods to a resource located in the peered VNet.

Result AKS nodes/pods cannot connect to the resource in the peered VNet. Other regular VMs in the same VNet as AKS can connect to the same peered VNet without any issue.

Environment

  • VNet containing AKS: custom DNS set to the inbound endpoint of an Azure DNS Private Resolver (deployed in a VNet under a different subscription)
  • Connection path: via VNet peering

Troubleshooting steps already taken We confirmed that other VMs in the AKS VNet can successfully connect to the peered VNet. Only AKS nodes/pods fail to make the same connection. We have not been able to identify the root cause so far.

Question Could you help us identify the root cause and the resolution needed so that AKS can successfully connect to resources in the peered VNet?

Azure Kubernetes Service
Azure Kubernetes Service

An Azure service that provides serverless Kubernetes, an integrated continuous integration and continuous delivery experience, and enterprise-grade security and governance.


2 answers

Sort by: Most helpful
  1. SUNOJ KUMAR YELURU 18,416 Reputation points MVP Volunteer Moderator
    2026-07-25T04:34:26.55+00:00

    Hello @Le Van Khoa,

    Thank you for using Q & A forum.

    The Azure DNS Private Resolver must be accessible from the AKS subnet and properly linked to both VNets involved in the peering. You can verify this by checking the resolver’s configuration and ensuring it can resolve the names of resources in the peered VNet. Use commands like nslookup <hostname> to test DNS resolution from AKS nodes/pods.

    Next, the network security groups (NSGs) associated with both the AKS VNet and the peered VNet. Make sure there are no NSG rules blocking traffic from AKS to the resources in the peered VNet. Sometimes, specific rules may inadvertently restrict access, leading to connectivity failures. You can review the NSG rules in the Azure portal to ensure that the necessary ports and protocols are allowed.

    Lastly, remember that VNet peering allows for network-layer connectivity but does not automatically enable DNS name resolution. If the DNS settings are not configured correctly, AKS nodes/pods may struggle to resolve the private DNS names of resources in the peered VNet. Review the DNS configurations and ensure they are set up to facilitate name resolution across the peered VNets. Following these steps should help in diagnosing and resolving the connectivity issue.


    If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.

    Was this answer helpful?

    0 comments No comments

  2. Sina Salam 31,216 Reputation points Volunteer Moderator
    2026-07-24T11:47:01.21+00:00

    Hello Le Van Khoa,

    Welcome to the Microsoft Q&A and thank you for posting your questions here.

    I understand that your AKS pods/nodes cannot connect to resources in the peered VNet, while ordinary VMs in the same AKS VNet can connect successfully.

    The issue is that AKS traffic does not necessarily use the same source IP path as the working VM. Depending on the AKS network mode, traffic from pods to a peered VNet may appear as the AKS node subnet IP or as the pod subnet IP. Therefore, the target-side NSG, firewall, route table, private endpoint rules, or application allowlist must allow the actual AKS source, not only the subnet used by the successful test VM. - https://learn.microsoft.com/en-us/azure/aks/concepts-network-azure-cni-overlay, and https://learn.microsoft.com/en-us/azure/aks/concepts-network-cni-overview gives more insight.

    What you can do to fix is to:

    • Confirm the AKS network mode and identify whether the target should allow the AKS node subnet or pod subnet.
    • Test DNS resolution from inside a pod, not only from a VM.
    • If DNS fails, configure AKS CoreDNS to forward the private DNS zone to the Azure DNS Private Resolver inbound endpoint.
    • If DNS resolves but connectivity fails, allow the AKS node subnet, and the pod subnet if using flat Azure CNI, on the target NSG/firewall/private endpoint path.
    • Validate effective routes and NSG rules on the AKS node NIC and target-side subnet.
    • Escalate to Azure Support via Azure portal or Priority Customer Support only if the configuration is correct and packet/DNS evidence shows platform-side failure.

    After allowing the correct AKS source subnet and ensuring CoreDNS forwards the private namespace to the Azure DNS Private Resolver inbound endpoint, the AKS pods should resolve the private FQDN and connect to the private resource through the peered VNet without needing public access or unnecessary architecture changes. Azure DNS Private Resolver supports forwarding queries through inbound endpoints, and AKS CoreDNS customization is the supported way to add custom DNS forwarding for pods. - https://learn.microsoft.com/en-us/azure/dns/private-resolver-endpoints-rulesets, https://learn.microsoft.com/en-us/azure/dns/dns-private-resolver-overview, and https://learn.microsoft.com/en-us/azure/aks/coredns-custom.

    Use the associated resource links above and below for more reading and steps:

    I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.


    Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.