<p>Here are steps to reproduce:</p>

<pre><code>minikube start
kubectl run nginx --image=nginx
kubectl expose deployment nginx --port=80 --type=ClusterIP

kubectl run -i --tty --rm alpine --image=alpine --restart=Never -- sh
apk add --no-cache bind-tools
</code></pre>

<p>Now let's try to query kibe-dns for <code>nginx</code> service</p>

<p>with <code>nslookup</code>:</p>

<pre><code>/ # nslookup nginx.default 10.96.0.10
Server:     10.96.0.10
Address:    10.96.0.10#53

Name:   nginx.default.svc.cluster.local
Address: 10.97.239.175
</code></pre>

<p>and with <code>dig</code>:</p>

<pre><code>dig nginx.default @10.96.0.10 any

; &lt;&lt;&gt;&gt; DiG 9.11.3 &lt;&lt;&gt;&gt; nginx.default @10.96.0.10 any
;; global options: +cmd
;; Got answer:
;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 46414
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nginx.default.         IN  ANY

;; Query time: 279 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Sun Jun 03 15:31:15 UTC 2018
;; MSG SIZE  rcvd: 42
</code></pre>

<p>Nothing changes if I replace name <code>nginx.default</code> with just <code>nginx</code>.</p>

<p>minikube version: v0.27.0,
k8s version: 1.10.0</p>

Kirill
<h2>Answer</h2>
<p>Dig does not complete the query by default with the search path. The search path is set in <code>/etc/resolv.conf</code>. The <code>+search</code> flag enables the search path completion.</p>
<h4>From the Man Pages</h4>
<blockquote>
<p><strong>+[no]search</strong><br />
Use [do not use] the search list defined by the searchlist or domain directive in resolv.conf (if any). The search list is not used by default.</p>
</blockquote>
<p><a href="https://linux.die.net/man/1/dig" rel="noreferrer">https://linux.die.net/man/1/dig</a></p>
<h2>Demonstration</h2>
<p><em>I have created a scenario for katacoda which goes through the same example interactively <a href="https://www.katacoda.com/bluebrown/scenarios/kubernetes-dns" rel="noreferrer">https://www.katacoda.com/bluebrown/scenarios/kubernetes-dns</a></em></p>
<p>First create and expose a pod, then start another pod interactively with dnsutils installed, from which DNS queries can be made.</p>
<pre class="lang-bash prettyprint-override"><code>kubectl create namespace dev
kubectl run my-app --image nginx --namespace dev --port 80
kubectl expose pod my-app --namespace dev
kubectl run dnsutils --namespace dev --image=bluebrown/netutils --rm -ti
</code></pre>
<p>Nslookup resolves the service OK</p>
<pre class="lang-bash prettyprint-override"><code>$ nslookup my-app
...
Name:   my-app.dev.svc.cluster.local
Address: 10.43.52.98
</code></pre>
<p>But dig didn't get an <em>answer</em>, why?</p>
<pre class="lang-bash prettyprint-override"><code>$ dig my-app
...
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
</code></pre>
<p>In order to understand why dig doesn't find the service, let's take a look at <code>/etc/resolv.conf</code></p>
<pre class="lang-bash prettyprint-override"><code>$ cat /etc/resolv.conf
search dev.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.43.0.10
options ndots:5
</code></pre>
<p>This file contains a line with the following format.</p>
<pre class="lang-bash prettyprint-override"><code>search &lt;namespace&gt;.svc.cluster.local svc.cluster.local cluster.local
</code></pre>
<p>That means, when providing an incomplete part of the fully qualified domain name (FQDN), this file can be used to complete the query. However, dig doesn't do it by default. We can use the <code>+search</code> flag in order to enable it.</p>
<pre class="lang-bash prettyprint-override"><code>dig +search my-app
...
;; QUESTION SECTION:
;my-app.dev.svc.cluster.local.  IN      A

;; ANSWER SECTION:
my-app.dev.svc.cluster.local. 5 IN      A       10.43.52.98
</code></pre>
<p>Now the service-name has been correctly resolved. You can also see how the query has been completed with the search path by comparing the question section of this command with the previous one without <code>+search</code> flag.</p>
<p>We can get the same service without <code>+search</code> flag when using the FQDN. The <code>+short</code> flag isn't required, but it will reduce the output to only the IP address.</p>
<pre class="lang-bash prettyprint-override"><code>$ dig +short my-app.dev.svc.cluster.local
10.43.52.98
</code></pre>
<p>However, the benefit of using the <code>search</code> method it that queries will automatically resolve to resources within the same namespace. This can be useful to apply the same configuration to different environments, such as production and development.</p>
<p>The same way the search entry in <code>resolv.conf</code> completes the query with the default name space, it will complete any part of the FQDN from left to right. So in the below example, it will resolve to the local cluster.</p>
<pre class="lang-bash prettyprint-override"><code>$ dig +short +search my-app.dev
10.43.52.98
</code></pre>
