<p>I'm trying to add a custom domain to my AKS cluster. All of the components I'm dealing with are within the same VNET, but the custom DNS Server and AKS Service are in different subnets. I've also like to avoid changing the DNS Server at the VNET level. </p>

<p>I've followed this guide to no avail:</p>

<p><a href="https://learn.microsoft.com/en-us/azure/aks/coredns-custom#use-custom-domains" rel="nofollow noreferrer">https://learn.microsoft.com/en-us/azure/aks/coredns-custom#use-custom-domains</a></p>

<p>I've also found previous answers used a similar setup: </p>

<p><a href="https://stackoverflow.com/questions/55612141/resolve-custom-dns-in-kubernetes-cluster-aks">Resolve custom dns in kubernetes cluster (AKS)</a></p>

<p>but that did not work either. The difference between the two being the coredns plugin that is used to forward the resolving traffic towards a custom resolver.</p>

<p>I've tried both the proxy and forward plugin with the same setup, and both end in the same error</p>

<p><strong>Proxy plugin:</strong></p>

<pre><code>apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: |
    mydomain.com:53 {
        log
        errors
        proxy . [MY DNS SERVER'S IP]
    }
</code></pre>

<p><strong>Forward Plugin:</strong></p>

<pre><code>apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  test.server: |
     mydomain.com:53 {
        log
        errors
        forward . [MY DNS SERVER'S IP]
    }
</code></pre>

<p><strong>Reproduce:</strong></p>

<p>1 VNET</p>

<p>2 Subnets (1 for AKS, 1 for the DNS VM)</p>

<p>Add a name to the DNS VM, and use a configmap to proxy traffic to the custom DNS instead of the node resolvers/VNET DNS</p>

<p><strong>Error:</strong></p>

<p>After applying either of the configmaps above, the coredns pods log this error:</p>

<blockquote>
  <p>2019-11-11T18:41:46.224Z [INFO] 172.28.18.104:47434 - 45605 "A IN
  mydomain.com. udp 55 false 512" REFUSED qr,rd 55 0.001407305s</p>
</blockquote>

<p>Was just missing a few more steps of due diligence. After checking the logs on the DNS VM, I found that the requests were making to the host, but the host was refusing them. The named.conf.options whitelisted a subset of address spaces. After updating those address spaces in named.conf to match the new cloud network we recently moved to, the requests were resolving. </p>

<p>I ended up sticking with the forward plugin as the MS docs outlined.</p>
