ping: bad address, Running in k8s.

[XtremeOwnageDotCom]

root@linuxserver-image-0:/# cat /etc/resolv.conf
search somewhere.svc.cluster.local svc.cluster.local cluster.local local.mydomain.com
nameserver 10.152.183.10
options ndots:5

root@linuxserver-image-0:/# nslookup google.com
Server:         10.152.183.10
Address:        10.152.183.10:53

Non-authoritative answer:
Name:   google.com
Address: [multiple results omitted. works fine.]

Non-authoritative answer:
Name:   google.com
Address: [multiple results omitted. works fine.]

root@linuxserver-image-0:/# ping google.com
ping: bad address 'google.com'

Modifying /etc/resolv.conf, changing ndots:1, to ndots:1, makes everything work somewhat normally.

root@linuxserver-image-0:/# vi /etc/resolv.conf
root@linuxserver-image-0:/# ping google.com
PING google.com (74.125.198.100): 56 data bytes
64 bytes from 74.125.198.100: seq=0 ttl=104 time=26.945 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 26.945/26.945/26.945 ms

There are tons of somewhat related tickets on this one, most, however, have the opposite issue where nslookup doesn't work, but, ping does work.

There are tons of upstream tickets in say, linuxserver.io repos, referencing these closed tickets.

However, there isn't a published work-around for this issue, nor, is there much of a paper-trail as to where/who/when this issue will be resolved.

[XtremeOwnageDotCom]

For, a work-around, for others who will inevitably come across this issue.... I did find this:

https://pracucci.com/kubernetes-dns-resolution-ndots-options-and-why-it-may-affect-application-performances.html

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: dns-example
spec:
  containers:
    - name: test
      image: nginx
  dnsConfig:
    options:
      - name: ndots
        value: "1"

Also, here. https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config

[wglambert]

Duplicate of https://github.com/docker-library/busybox/issues/48

It needs to be addressed upstream -- we simply package what they provide.

There was this original bug from 2018 https://bugs.busybox.net/show_bug.cgi?id=11161 which was a continuing issue leading to this newer bug report https://bugs.busybox.net/show_bug.cgi?id=14671

[XtremeOwnageDotCom]

https://sourceware.org/bugzilla/buglist.cgi?quicksearch=dns

After finding a bug-tracker, rather curious to even know what to look for, so these issues can be properly linked back to something upstream, instead of having countless tickets on various repos all pointing the finger at each other.