<p>For configuring a multicluster Isito with replicated control planes, one of the requirements is to configure the k8s coredns service in the kube-system namespace, to forward zone &quot;global&quot; to the IP of the &quot;istiocoredns&quot; service deployed in the istio-system namespace. Like <a href="https://istio.io/latest/docs/setup/install/multicluster/gateways/#setup-dns" rel="nofollow noreferrer">this:</a></p>
<pre><code>    global:53 {
        errors
        cache 30
        forward . $(kubectl get svc -n istio-system istiocoredns -o jsonpath={.spec.clusterIP}):53
    }
</code></pre>
<p>In the example the use that command expansion to get the IP of the istiocoredns ClusterIP type of service.</p>
<p>As that is a non static IP and could be modified, I am looking for a way to use something more dynamic and change aware. Using the istiocoredns service FQDN name would be great, but coredns documentation is not mentioning anything about it.</p>
<p>Is there any coredns plugin or workaround this?</p>
<p>Thank you.</p>

carrotcakeslayer
<blockquote>
<p>Is there any coredns plugin or workaround this?</p>
</blockquote>
<p>There is <a href="https://github.com/istio-ecosystem/istio-coredns-plugin" rel="nofollow noreferrer">istio coredns plugin</a>, but as mentioned in the <a href="https://github.com/istio-ecosystem/istio-coredns-plugin#usage" rel="nofollow noreferrer">usage section</a> they set here the IP of the coredns anyway.</p>
<blockquote>
<p>Update the kube-dns config map to point to this coredns service as the upstream DNS service for the *.global domain. You will have to find out the cluster IP of coredns service and update the config map (or write a controller for this purpose!).</p>
</blockquote>
<pre><code>apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {&quot;global&quot;: [&quot;10.2.3.4&quot;]}
</code></pre>
<p>But here's some interesting information</p>
<blockquote>
<p>UPDATE: This plugin is no longer necessary as of Istio 1.8. DNS is built into the istio agent in the sidecar. Sidecar DNS is enabled by default in the preview profile. You can also enable it manually by setting the following config in the istio operator</p>
</blockquote>
<pre><code>  meshConfig:
    defaultConfig:
      proxyMetadata:
        ISTIO_META_DNS_CAPTURE: &quot;true&quot;
        ISTIO_META_PROXY_XDS_VIA_AGENT: &quot;true&quot;
</code></pre>
<p>You can find more information about it <a href="https://preliminary.istio.io/latest/docs/ops/deployment/deployment-models/#dns-with-multiple-clusters" rel="nofollow noreferrer">here</a>.</p>
<blockquote>
<p>There are a few efforts in progress that will help simplify the DNS story:</p>
<p>Istio will soon support DNS interception for all workloads with a sidecar proxy. This will allow Istio to perform DNS lookup on behalf of the application.</p>
<p><a href="https://github.com/istio-ecosystem/admiral" rel="nofollow noreferrer">Admiral</a> is an Istio community project that provides a number of multicluster capabilities, including automatic creation of service DNS entries.</p>
<p><a href="https://github.com/kubernetes/enhancements/tree/master/keps/sig-multicluster/1645-multi-cluster-services-api" rel="nofollow noreferrer">Kubernetes Multi-Cluster Services</a> is a Kubernetes Enhancement Proposal (KEP) that defines an API for exporting services to multiple clusters. This effectively pushes the responsibility of service visibility and DNS resolution for the entire clusterset onto Kubernetes. There is also work in progress to build layers of MCS support into Istio, which would allow Istio to work with any cloud vendor MCS controller or even act as the MCS controller for the entire mesh.</p>
<p>While Admiral is available today, the Istio and Kubernetes communities are actively building more general solutions into their platforms. Stay tuned!</p>
</blockquote>
<hr />
<p>There is <a href="https://preliminary.istio.io/latest/blog/2020/dns-proxy/" rel="nofollow noreferrer">article</a> about that in 1.8 prelim docs.</p>
