<p><strong>The ndots problem</strong></p>

<p>I have a Kubernetes cluster (running on openstack) and a separate cluster of VMs running on the same openstack tenancy. I needed to be able to resolve services running in the VM cluster from the kubernetes cluster.</p>

<ol>
<li>I set up ipvs "loadbalancer"</li>
<li>On this loadbalancer I connected eth1 to vm cluster, eth0 to kubernetes cluster</li>
<li>set up static routes (on host VMs) to supply route to this LB, masquerade rules on LB, allowed ip addresses on LB via opensatck etc</li>
<li>I then set my DNS server in the VM cluster as a <code>StubDomain</code> of <code>kube-dns</code> as per <a href="https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/" rel="nofollow noreferrer">Kubernetes docs</a></li>
</ol>

<p>nslookup of a service in the VM cluster now worked from kubernetes cluster but resolution was taking on avg 8 seconds. I tried alternating and combining <code>StubDomain</code> with <code>UpstreamNameserver</code> but the results were the same.</p>

<p>After much googling I discovered the <a href="https://rsmitty.github.io/KubeDNS-Tweaks/" rel="nofollow noreferrer">ndots problem</a>. Instead of modifying it I  removed <code>ndots:5</code> from the pod doing the lookup configuration and nslookup is now much quicker operating at acceptable speed.  </p>

<p>My question is what is the side-effect/trade-off to removing the ndots configuration altogether? My application seems to be working well now and no obvious side-effects yet.</p>

<p>Thanks</p>

<p>There are no side effects. You just make one DNS query for a FQDN with is set Ndots:0. The whole ndots is like a secret agent trying to mess up your requests.</p>
