Why nslookup can't resolv short name?

[docker-library]

Why nslookup can't resolv short name?

[aberres]

I am seeing the behavior with uclibc and glibc on a Google Kubernetes instance.

Shouldn't nslookup return with 1 as well if the lookup failed?

I stumbled upon the problem when playing with init containers as described in the Kubernetes documentation: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
Due to this issue, the examples in the documentation do not work at all.

[tianon]

From what I can tell, the new resolver in BusyBox's nslookup doesn't support DNS search domains at all, which seems like a pretty hefty regression.

[tianon]

I can't seem to reproduce with any of our three variants. 😞

$ docker network create test
32024cd09daca748f8254468f4f00893afc2e1173c378919b1f378ed719f1618
$ docker run -dit --name nginx --network test nginx:alpine
7feaf1f0b4f3d421603bbb984854b753c7cbc6b581dd0a304d3b8fccf8c6604b
$ docker run -it --rm --network test busybox:uclibc nslookup nginx
Server:    127.0.0.11
Address 1: 127.0.0.11

Name:      nginx
Address 1: 172.22.0.2 nginx.test
$ docker run -it --rm --network test busybox:glibc nslookup nginx
Server:    127.0.0.11
Address 1: 127.0.0.11

Name:      nginx
Address 1: 172.22.0.2 nginx.test
$ docker run -it --rm --network test busybox:musl nslookup nginx
nslookup: can't resolve '(null)'

Name:      nginx
Address 1: 172.22.0.2 nginx.test

[likunbyl]

Thank you, tianon

With busybox:glibc, I can resolve the short name too:

$ kubectl exec busybox1 -- nslookup kubernetes                                 
Server:    192.168.192.10
Address 1: 192.168.192.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 192.168.192.1 kubernetes.default.svc.cluster.local

busybox1 is based on busybox:glibc

With busybox:lastest, I can't

$ kubectl exec busybox -- nslookup kubernetes                                            
nslookup: can't resolve 'kubernetes'
Server:    192.168.192.10
Address 1: 192.168.192.10 kube-dns.kube-system.svc.cluster.local

busybox is based on busybox:latest

[tianon]

Ah, it's not specific to short names, but DNS search paths; here's a better example for reproducing:

$ docker network create --internal test
66b1bf0bf05cec6d32c171cc601b6ee160bb94de670b0c61a0a15ae267302d06

$ docker run -dit --name nginx.domain --network test nginx:alpine
448e9b11cfb336464494c615be81db3058431f623eb9416507f5f46e19b2455c

$ docker run -it --rm --network test --dns-search domain busybox:glibc nslookup nginx
Server:    127.0.0.11
Address 1: 127.0.0.11

Name:      nginx
Address 1: 172.22.0.2 nginx.domain.test

$ docker run -it --rm --network test --dns-search domain busybox:uclibc nslookup nginx
Server:    127.0.0.11
Address 1: 127.0.0.11

nslookup: can't resolve 'nginx'

$ docker run -it --rm --network test --dns-search domain busybox:musl nslookup nginx
nslookup: can't resolve '(null)'

nslookup: can't resolve 'nginx'

(busybox:uclibc is busybox:latest)

😞

Not sure where to start digging on this one. 😕

[vcunat]

The implementation is broken with non-glibc, reportedly due to fiddling with its internals: https://dev.openwrt.org/ticket/18333 and https://bugs.busybox.net/show_bug.cgi?id=675

[wglambert]

Seems only uclibc is broken now

$ docker network create --internal test
d0f3b32461787a7d830cb7f73504db08a563dddbe1a93079bcd7b4034f7736de

$ docker run -dit --name nginx --network test nginx:alpine
bb795c7ddcee2043f1e4c6ce41d292af6e8497c29e80777f267864145052b345

$ docker run -it --rm --network test --dns-search domain busybox:glibc nslookup nginx
Server:         127.0.0.11
Address:        127.0.0.11:53

Non-authoritative answer:

Non-authoritative answer:
Name:   nginx
Address: 172.22.0.2

$ docker run -it --rm --network test --dns-search domain busybox:uclibc nslookup nginx
Server:         127.0.0.11
Address:        127.0.0.11:53

Non-authoritative answer:

*** Can't find nginx: No answer

$ docker run -it --rm --network test --dns-search domain busybox:musl nslookup nginx
Server:         127.0.0.11
Address:        127.0.0.11:53

Non-authoritative answer:

Non-authoritative answer:
Name:   nginx
Address: 172.22.0.2

[tianon]

How does this relate to #48? Are they the same issue?

[tianon]

(See https://bugs.busybox.net/show_bug.cgi?id=11161 for where this is filed upstream.)

I'm going to close this in favor of #48, where there's been slightly more recent discussion. 👍