0

ping can resolve hostname, while dig is unable to resolve the same hostname?

I'm experiencing a strange issue, where ping is able to resolve some DNS hostname, while dig cannot.

I've tried to dig +search to use the search entries in /etc/resolv.conf, or dig @<nameserver> to set the nameserver explicitly, but that didn't help.

How can I understand why ping resolves the hostnames, while dig is unable?

kube@ctf-k8s-deploy-647d66b697-lxqkl:~$ cat /etc/resolv.conf
nameserver 100.64.0.10
search default.svc.cluster.local svc.cluster.local cluster.local eu-central-1.compute.internal
options ndots:5
kube@ctf-k8s-deploy-647d66b697-lxqkl:~$ dig +search ctf-k8s-deploy-647d66b697-lxqkl

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> +search ctf-k8s-deploy-647d66b697-lxqkl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52708
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ctf-k8s-deploy-647d66b697-lxqkl. IN    A

;; Query time: 0 msec
;; SERVER: 100.64.0.10#53(100.64.0.10)
;; WHEN: Mon Mar 23 14:46:46 UTC 2020
;; MSG SIZE  rcvd: 60

kube@ctf-k8s-deploy-647d66b697-lxqkl:~$ dig @100.64.0.10 +search ctf-k8s-deploy-647d66b697-lxqkl

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @100.64.0.10 +search ctf-k8s-deploy-647d66b697-lxqkl
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47568
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ctf-k8s-deploy-647d66b697-lxqkl. IN    A

;; Query time: 0 msec
;; SERVER: 100.64.0.10#53(100.64.0.10)
;; WHEN: Mon Mar 23 14:46:53 UTC 2020
;; MSG SIZE  rcvd: 60

kube@ctf-k8s-deploy-647d66b697-lxqkl:~$ ping ctf-k8s-deploy-647d66b697-lxqkl
PING ctf-k8s-deploy-647d66b697-lxqkl (100.96.1.8) 56(84) bytes of data.
64 bytes from ctf-k8s-deploy-647d66b697-lxqkl (100.96.1.8): icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from ctf-k8s-deploy-647d66b697-lxqkl (100.96.1.8): icmp_seq=2 ttl=64 time=0.019 ms
64 bytes from ctf-k8s-deploy-647d66b697-lxqkl (100.96.1.8): icmp_seq=3 ttl=64 time=0.021 ms
^C
--- ctf-k8s-deploy-647d66b697-lxqkl ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 40ms
rtt min/avg/max/mdev = 0.019/0.019/0.021/0.005 ms

Update:

/etc/hosts:

kube@ctf1-deploy1-89b48b46-zkqld:~$ cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
100.96.3.22     ctf1-deploy1-89b48b46-zkqld

/etc/resolv.conf:

kube@ctf1-deploy1-89b48b46-zkqld:~$ cat /etc/resolv.conf
nameserver 100.64.0.10
search ctf1-ns.svc.cluster.local svc.cluster.local cluster.local eu-central-1.compute.internal
options ndots:5
0

Ping and dig use different mechanism to resolve IP addresses. While ping gets configuration from the line which is seems like hosts: files dns in /etc/nsswitch.conf file and dig uses the name server configured in /etc/resolv.conf because dig queries only DNS Server. So your problem can be an issue about DNS Servers which are define in /etc/hosts file.

There is another clarification

| improve this answer | |
  • Thank you @Ozerov. In my case /etc/nsswith.conf doesn't exist, but /etc/nsswitch.conf does. Furthermore, there is no nameserver in /etc/hosts, but only in /etc/resolv.conf. Can you say what hosts: files dns means? – Shuzheng Mar 24 at 9:25
  • my bad,I have edited name it is just /etc/nsswitch.conf. files point to the use of /etc/hosts and dns means the use of Domain Name Service. if files comes first, it means that system will try to find ip address in /etc/hosts file. If dns comes first then domain lookup will consult DNS before any other services or files. Can you provide an output of cat /etc/hosts ? – Ozerov Mar 24 at 12:07
  • I've added /etc/hosts. Are you sure, you are not confusing /etc/hosts with /etc/resolv.conf, where the DNS server is listed? – Shuzheng Mar 24 at 12:21
  • Sorry again, dig checks the /etc/resolv.conf file. And the problem must be in your /etc/resolv.conf file because search ... line should be defined first and nameserver 100.64.0.10 should be defined after that. Can you try it? – Ozerov Mar 24 at 14:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.