<p>I need to know all the hostnames for all the pods in a Deployment in Kubernetes. </p>

<p>Based on <a href="https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/" rel="noreferrer">https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/</a>, I tried: </p>

<pre><code>apiVersion: v1
kind: Service
metadata:
  name: default-subdomain
spec:
  selector:
    name: busybox
  clusterIP: None
  ports:
  - name: foo
    port: 1234
    targetPort: 1234
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox1
  labels:
    name: busybox
spec:
  replicas: 2
  selector:
    matchLabels:
      name: busybox
  template:
    metadata:
      labels:
        name: busybox
    spec:
      hostname: dummy &lt;---- effect of this line 
      subdomain: default-subdomain
      containers:
      - image: busybox
        command:
          - sleep
          - "99999"
        name: busybox
        stdin: true
        tty: true
</code></pre>

<ol>
<li>If I don't add the hostname, no pods are registered with DNS</li>
<li>If I do add the hostname value, there is only one entry in the DNS</li>
</ol>

<p>How can I get every pod in a deployment to be registered, preferably using the pod name, and looked up by fqdn of the pod - e.g. pod_name.subdomin.namespace.svc.cluster.local?</p>

<p>CoreDNS creates A and SRV records <strong>only</strong> for Services. It <a href="https://github.com/coredns/coredns/issues/2409" rel="nofollow noreferrer">doesn't generate pods' A records</a> as you may expect after reading the <a href="https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#coredns-configmap-options" rel="nofollow noreferrer">documentation</a>:</p>
<blockquote>
<p>The <code>pods insecure</code> option is provided for backward compatibility with kube-dns. You can use the <code>pods verified</code> option, which returns an A record only if there exists a pod in same namespace with matching IP. The <code>pods disabled</code> option can be used if you don’t use pod records.</p>
</blockquote>
<p>with the one exception:  if you create a <a href="https://kubernetes.io/docs/concepts/services-networking/service/#headless-services" rel="nofollow noreferrer">Headless service</a> (when you specify <code>ClusterIP: None</code> in the Service spec)</p>
<p>So, here is my example of Headless Service based on your YAML:</p>
<pre><code>NAME                TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
default-subdomain   ClusterIP      None            &lt;none&gt;        1234/TCP       50s
</code></pre>
<p>Here is the list of pods created by the above deployment on my cluster:</p>
<pre><code>NAMESPACE       NAME                                        READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATES
default         busybox1-76745fcdbf-4ppsf                   1/1     Running   0          18s   10.244.1.22   kube-node2-1   &lt;none&gt;           &lt;none&gt;
default         busybox1-76745fcdbf-d76q5                   1/1     Running   0          18s   10.244.1.23   kube-node2-1   &lt;none&gt;           &lt;none&gt;
</code></pre>
<p>In this case, instead of one A and one SRV record for Service's ClusterIP, we have two A and two SRV records with the same name, and IP addresses of Pods which are Endpoints for the Headless Service:</p>
<pre><code>default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.22
_foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 10-244-1-22.default-subdomain.default.svc.cluster.local.
default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.23
_foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 10-244-1-23.default-subdomain.default.svc.cluster.local.
</code></pre>
<p>To resolve SRV records, A records also has been created for both Headless Service endpoints.</p>
<p>If you don't specify specify <code>hostname</code> <strong>and</strong> <code>subdomain</code> for pods, A records will be created with IP addresses as a hostnames:</p>
<pre><code>10-244-1-22.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.22
10-244-1-23.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.23
</code></pre>
<p>But if you are specify both of them you will get these record as follows:</p>
<pre><code>dummy.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.22
dummy.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.23
</code></pre>
<p>SRV records will look as follows in this case (yes, there are still two of them and they are the same):</p>
<pre><code>_foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 dummy.default-subdomain.default.svc.cluster.local.
_foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 dummy.default-subdomain.default.svc.cluster.local.
</code></pre>
<p>CoreDNS server resolve such records in &quot;random&quot; way (IP addresses is changing):</p>
<pre><code>root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.26) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.26) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.26) 56(84) bytes of data.
root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PING
PING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.
</code></pre>
<p>To debug it, I've used zone <a href="https://coredns.io/plugins/transfer/" rel="nofollow noreferrer">transfer plugin</a> of CoreDNS. To enable it you should add <code>transfer to *</code> line to <strong>coredns</strong> ConfigMap. You can replace * with specific IP for security. Example:</p>
<pre><code>$ kubectl get cm coredns -n kube-system -o yaml
apiVersion: v1
data:
 Corefile: |
   .:53 {
       errors
       health
       kubernetes cluster.local in-addr.arpa ip6.arpa {
          transfer to *   &lt;---- enable zone transfer to anyone(don't use in production) (older coredns versions)
          transfer {      &lt;----- ( new syntax for recent coredns versions)
              to *        &lt;----- ( don't use older and newer transfer options in the same config! )
          }               &lt;----- ( and check coredns pods' logs to ensure it applied correctly )
          pods insecure
          upstream
          fallthrough in-addr.arpa ip6.arpa
       }
       prometheus :9153
       forward . /etc/resolv.conf
       cache 30
       loop
       reload
       loadbalance
   }
kind: ConfigMap
metadata:
 creationTimestamp: &quot;2019-05-07T15:44:02Z&quot;
 name: coredns
 namespace: kube-system
 resourceVersion: &quot;9166&quot;
 selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
 uid: f0646569-70de-11e9-9af0-42010a9c0015 
</code></pre>
<p>After that you'll be able to list all DNS records from <code>cluster.local</code> zone using the following command:</p>
<pre><code>dig -t AXFR cluster.local any
</code></pre>
<p>More information can be found here:</p>
<ul>
<li><a href="https://github.com/coredns/coredns/pull/1259" rel="nofollow noreferrer">support for zone transfer for kubernetes #1259</a></li>
<li><a href="https://github.com/coredns/coredns/issues/660" rel="nofollow noreferrer">Feature request: support zone transfers in Kubernetes middleware #660</a></li>
</ul>
