<p>I have a <strong>Private AKS cluster</strong> deployed in a VNET on Azure. Once I deployed it, a private endpoint and a private DNS zone were created by default therefore making the cluster accessible from VM's which are part of the same VNET. (<em>I have a VM deployed in the same VNET as the AKS cluster and &quot;kubectl&quot; commands work in it.</em>)</p>
<p>My requirement is that I want to perform the &quot;kubectl&quot; commands from my local machine (connected to my home network) and also connected to the VPN which connects to the VNET.</p>
<p>My machine can talk to resources within the VNET but cannot seem to resolve the FQDN of the private cluster.</p>
<p>I read somewhere that having a DNS forwarder setup in the same VNET can help resolve the DNS queries made from the local machine which can then be resolved by Azure DNS. Is this the way to go about this? Or is there a better way to solve this problem?</p>
<p>It would really help if someone could give me an action plan to follow to solve this problem.</p>

<p>The better way to perform the &quot;kubectl&quot; commands from your local machine to your private AKS cluster is to use <a href="https://learn.microsoft.com/en-us/azure/aks/private-clusters#aks-run-command-preview" rel="nofollow noreferrer">AKS Run Command (Preview)</a>. This feature allows you to remotely invoke commands in an AKS cluster through the AKS API. This feature provides an API that allows you to, for example, execute just-in-time commands from a remote laptop for a private cluster. Before using it, you need to enable the <code>RunCommandPreview</code> feature flag on your subscription and install <code>aks-preview</code> extension locally. However, there is a limitation that <strong>AKS-RunCommand does not work on clusters with AKS managed AAD and Private link enabled</strong>.</p>
<p>In this case, If you want to resolve the FQDN of the private cluster from your on-premise network, you could select to use either the hosts file locally(used for testing) or use your DNS forwarder to override the DNS resolution for a private link resource like <a href="https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-dns#on-premises-workloads-using-a-dns-forwarder" rel="nofollow noreferrer">this</a>.</p>
<p>The DNS forwarder will be responsible for all the DNS queries via a server-level forwarder to the Azure-provided DNS <code>168.63.129.16</code>.You can provision IaaS Windows VM with DNS role or Linux VM with bind configured as a DNS forwarder. <a href="https://azure.microsoft.com/en-us/resources/templates/301-dns-forwarder/" rel="nofollow noreferrer">This template</a> shows how to create a DNS server that forwards queries to Azure's internal DNS servers for Linux VM. Refer to <a href="https://anktsrkr.github.io/post/resolve-azure-internal-dns-from-your-on-prem-network/" rel="nofollow noreferrer">this</a> for DNS forwarder on Windows VM.</p>
<p>If there is an internal DNS server in your on-premise network. The on-premises DNS solution needs to forward DNS traffic to Azure DNS via a conditional forwarder for your public DNS zones(e.g. <code>{region}.azmk8s.io</code>). The conditional forwarder references the DNS forwarder deployed in Azure. You could read <a href="https://bloggerz.cloud/2020/12/18/azure-private-link-and-dns/" rel="nofollow noreferrer">this blog</a> about DNS configuration sections for more details.</p>
