Configuring coreDNS to sequentially query upstream servers

In default deployments, coreDNS queries upstream servers in random order. That is if the resolv.conf of your deployment looks like the below:

nameserver 10.0.0.1
nameserver 10.0.0.2
nameserver 10.0.0.3

You can expect coreDNS to query each nameserver roughly 33% of the time. In most deployments, this is the preferred method as it roughly equally load balances requests across the configured nameservers. This serves as a safe starting point, but when one nameserver is located physically closer to the cluster or in the same availability zone, it may be desired to query one nameserver before moving on to others. If this is the case, we can make use of coreDNS's forward plugin. Within the forward plugin configuration, there is a section for policy. By default, this is configured for random.

Let's suppose that we have configured the nameservers in our resolv.conf to be ordered from the closest to the cluster to the furthest. In this case, we would want to use the sequential configuration for our deployment. To make this change, you will need to edit the coreDNS configmap. You can retrieve it with kubectl get cm -o yaml -n kube-system coredns > cm.yaml. The coredns configmap looks like the below:

apiVersion: v1
kind: ConfigMap
data:
  Corefile: |
    .:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      pods insecure
      fallthrough in-addr.arpa ip6.arpa
       ttl 30
    }
    prometheus :9153
    forward . /etc/resolv.conf {
      max_concurrent 1000
    }
    cache 30
    loop
    reload
    loadbalance
}

To enable sequential querying we need to edit the forward section to look like the below:

forward . /etc/resolv.conf {
  max_concurrent 1000
  policy sequential
}

After editing our yaml and reapplying it to the cluster, you should see your coreDNS pods restarting. If you do not, you can force a rollout restart with  kubectl rollout restart deployment -n kube-system coredns.