1

By running a dig command for a service in my kubernetes cluster, coredns just gives service name but not the IP. Does anyone know why this is happening?

Divya Myntra
  • 21
  • 4
  • 1
    Needs details or clarity from where you are running command and what you want?. `kubectl get svc -n kube-system` may directly provide the details or IP of coreDNS if exposed any how. – Harsh Manvar Jan 25 '21 at 04:20
  • 1
    kubectl exec -ti busybox nslookup myservicename.... this is the command i am using and busybox is the pod i am running in.... it doesn't give IP but just the name – Divya Myntra Jan 25 '21 at 05:13
  • 1
    Attach an output of nslookup is helpful. – Kun Li Jan 25 '21 at 10:18
  • Please update your question with resources requested by users Harsh Manvar and Kun Li. Also please add the result of: `$ kubectl describe service svc-name-you-are-trying-to-query`. – Dawid Kruk Jan 25 '21 at 15:24

1 Answers1

0

This is related with how dig utility and DNS work.

Note that when you run:

dig <your-service-name>

you're asking your CoreDNS literally about this particular string and simple service name isn't even a valid domain name. Just take a look at the following example:

root@python-client:/# dig my-release-mysql

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> my-release-mysql
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27445
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;my-release-mysql.              IN      A

;; AUTHORITY SECTION:
.                       86399   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2021012500 1800 900 604800 86400

;; Query time: 19 msec
;; SERVER: 10.3.240.10#53(10.3.240.10)
;; WHEN: Mon Jan 25 16:22:12 UTC 2021
;; MSG SIZE  rcvd: 120

As you can see it doesn't even contain "ANSWER" section (ANSWER: 0) and if you take a closer look at the "QUESTION" section:

;; QUESTION SECTION:
;my-release-mysql.              IN      A

you'll notice that dig asks CoreDNS for A record for my-release-mysql., which, as I already mentioned, isn't even a valid domain name.

Note that CoreDNS doesn't keep any records for my-release-mysql. so when you ask it about such "domain", it doesn't know anything about it.

If you ask instead for A record for a valid fully quallified domain name (FQDN), you'll get the expected response:

root@python-client:/# dig my-release-mysql.default.svc.cluster.local

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> my-release-mysql.default.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47573
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;my-release-mysql.default.svc.cluster.local. IN A

;; ANSWER SECTION:
my-release-mysql.default.svc.cluster.local. 30 IN A 10.3.244.87

;; Query time: 0 msec
;; SERVER: 10.3.240.10#53(10.3.240.10)
;; WHEN: Mon Jan 25 15:59:55 UTC 2021
;; MSG SIZE  rcvd: 76

Again, take a closer look at both "QUESTION" and "ANSWER" sections:

;; QUESTION SECTION:
;my-release-mysql.default.svc.cluster.local. IN A

;; ANSWER SECTION:
my-release-mysql.default.svc.cluster.local. 30 IN A 10.3.244.87

As you can see, when we ask CoreDNS in QUESTION SECTION for an A record for my-release-mysql.default.svc.cluster.local. which happens to be a valid FQDN (unlike my-release-mysql.) that this DNS server keeps records for, we get correct response in our ANSWER SECTION.

Note that dig utility doesn't use entries in your /etc/resolv.conf which may look as follows:

root@python-client:/# cat /etc/resolv.conf
nameserver 10.3.240.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

but instead, it queries the DNS server about the raw string my-release-mysql..

Tools like host or nslookup, unlike dig, leverage the content of /etc/resolv.conf when doing DNS lookup. So instead of asking CoreDNS about raw my-release-mysql, default.svc.cluster.local suffix is added and such query is sent to CoreDNS e.g.:

root@python-client:/# host my-release-mysql
my-release-mysql.default.svc.cluster.local has address 10.3.244.87

Note, that although we give my-release-mysql as an argument for our host command, it matches it with the first entry in the search section of our /etc/resolv.conf file, which happens to be default.svc.cluster.local and queries the DNS server not about my-release-mysql but about a fully quallified domain name my-release-mysql.default.svc.cluster.local for which it keeps records.

Same thing with nslookup tool:

root@python-client:/# nslookup my-release-mysql
Server:         10.3.240.10
Address:        10.3.240.10#53

Name:   my-release-mysql.default.svc.cluster.local
Address: 10.3.244.87
mario
  • 9,858
  • 1
  • 26
  • 42