Nslookup does not work in latest busybox image #48
Comments
|
Seems to be a kubernetes configuration issue Not able to reproduce the issue through Docker standalone $ docker run --rm -dit --name busybox busybox:latest
$ docker exec -it busybox sh
# ping google.com
PING google.com (172.217.11.174): 56 data bytes
64 bytes from 172.217.11.174: seq=0 ttl=53 time=14.993 ms
64 bytes from 172.217.11.174: seq=1 ttl=53 time=14.598 ms
64 bytes from 172.217.11.174: seq=2 ttl=53 time=14.039 ms
^C
# nslookup github.com
Server: 8.8.8.8
Address 1: 8.8.8.8 google-public-dns-a.google.com
Name: github.com
Address 1: 192.30.255.112 lb-192-30-255-112-sea.github.com
Address 2: 192.30.255.113 lb-192-30-255-113-sea.github.com
# nslookup google.com
Server: 8.8.8.8
Address 1: 8.8.8.8 google-public-dns-a.google.com
Name: google.com
Address 1: 2607:f8b0:4007:804::200e lax28s15-in-x0e.1e100.net
Address 2: 216.58.219.14 lax17s03-in-f14.1e100.netKubernetes with $ kubectl exec busybox-7cc555b5d6-2mmcr ping google.com
PING google.com (172.217.11.174): 56 data bytes
64 bytes from 172.217.11.174: seq=0 ttl=54 time=13.444 ms
64 bytes from 172.217.11.174: seq=1 ttl=54 time=14.249 ms
64 bytes from 172.217.11.174: seq=2 ttl=54 time=20.149 ms
^C
$ kubectl exec busybox-7cc555b5d6-2mmcr nslookup google.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8:53
Non-authoritative answer:
Name: google.com
Address: 172.217.11.174
*** Can't find google.com: No answer
$ kubectl exec busybox-7cc555b5d6-2mmcr nslookup kubernetes.default 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8:53
** server can't find kubernetes.default: NXDOMAIN
*** Can't find kubernetes.default: No answer
$ kubectl exec busybox-7cc555b5d6-2mmcr nslookup kubernetes.default
Server: 127.0.0.53
Address: 127.0.0.53:53
** server can't find kubernetes.default: NXDOMAIN
*** Can't find kubernetes.default: No answerThis seems to be the most relevant issue I found kubernetes/kubernetes#33798 |
wglambert
added
the
question
|
This reminds me of the fun we had back in #9, but that doesn't seem related. 😞 |
|
I have a kubernetes cluster monitoring test that continually deploys a busybox pod in a cluster and verifies DNS resolution within the pod by executing kubectl exec nslookup. It started failing right when I downloaded the latest busybox image. Installing a busybox pod with the previous version 1.28 of the image nslookup works. All signs point to a change in this latest version that is causing the failure. |
|
Unfortunately, that only narrows it down to somewhere in the sea of |
|
Something in here seems most likely: $ git log --oneline 1_28_4...1_29_1 -- networking/nslookup.c
2f7738e47 nslookup: placate "warning: unused variable i"
c72499584 nslookup: simplify make_ptr
71e4b3f48 nslookup: get rid of query::rlen field
58e43a4c4 nslookup: move array of queries to "globals"
4b6091f92 nslookup: accept lowercase -type=soa, document query types
6cdc3195a nslookup: change -stats to -debug (it's a bug in bind that it accepts -s)
d4461ef9f nslookup: rework option parsing
a980109c6 nslookup: smaller qtypes[] array
2cf75b3c8 nslookup: process replies immediately, do not store them
4e73c0f65 nslookup: fix output corruption for "nslookup 1.2.3.4"
cf950cd3e nslookup: more closely resemble output format of bind-utils-9.11.3
71e016d80 nslookup: shrink send_queries()
db93b21ec nslookup: use xmalloc_sockaddr2dotted() instead of homegrown function
55bc8e882 nslookup: usee bbox network functions instead of opne-coded mess
0dd3be8c0 nslookup: add openwrt / lede version |
|
/label bug |
|
Anyone filed an issue with upstream yet? Or done more digging to figure
out exactly which upstream change caused it? The only change was the
BusyBox version bump, no uclibc update, buildroot update, etc, so this is
firmly an upstream bug and one specially BusyBox upstream.
|
|
Same issue here. Reverting to 1.28 fixed the issue for me. |
|
How does this relate to #27? Are they the same issue? |
|
From what I can tell, the new resolver in BusyBox's |
|
Thanks tianon. How will this be addressed? |
|
It needs to be addressed upstream -- we simply package what they provide.
|
|
@djsly Try using I've added my findings here: https://bugs.busybox.net/show_bug.cgi?id=11161#c4 |
|
As a suggestion, would it be possible to regress the :latest tag to point to 1.8.x until upstream is resolved? |
|
See this issue: |
|
Given that the upstream change was intentional and is a reflection of upstream, I'm not comfortable changing |
|
For some people it’s still difficult to admit a mistake. Being aggressive and brave with new changes is one thing, breaking stuff that worked before is another one, especially these days when a lot of people are using “:latest” by default - introducing a BC and calling that was on purpose is just far from wise. Please read more about semantic versioning as well. |
|
Hi @tianon - I can understand that you don't want to have a regression on :latest, but there is a surprising amount of fallout from this simple issue because so many people and documentation out there use busybox:latest as the "Hello, World" example. Temporarily changing the tag would help mitigate that pain and these unintended consequences. Cheers, |
Version `1.28.4` of busybox does the `nslookup` correctly as described in the tutorial, the `latest` does not. So it needs to be set explicitely. Fixes kelseyhightower#356. Also see docker-library/busybox#48.
|
tried 1.33, this issue is still there |
|
Same happens on 1.33.1. For comparison, the image gcr.io/kubernetes-e2e-test-images/dnsutils:1.3, used in Kubernetes documentation DNS troubleshooting example still works as expected. As metioned by @blodone. Any chance on getting it fixed soon? |
|
Just use 1.27, the package in that version has always worked |
This comment has been minimized.
This comment has been minimized.
Changes where done with these commands: reprec 'image: busybox(?!:)' 'image: busybox:1.28' */docs */examples reprec -- '--image=busybox(?!:)' '--image=busybox:1.28' */docs */examples Related issues: docker-library/busybox#48 kubernetes/kubernetes#66924
|
kubernetes/kubernetes#66924 (comment) It's very infrequent hit. I ran nslookup by updating
Below shell script I used to calculate this result. echo 'while(true); do
nslookup -timeout=2 kubernetes > /dev/null 2>&1
result=$?
if [ "$result" == "0" ]; then
echo "$(date +%s) : $result : pass" >> /tmp/nslookup_status
elif [ "$result" == "1" ]; then
echo "$(date +%s) : $result : fail" >> /tmp/nslookup_status
else
echo "$(date +%s) : $result : fail" >> /tmp/nslookup_status
fi
done' > nslookup_status.sh
chmod +x nslookup_status.sh
./nslookup_status.sh &busybox-pod.yaml apiVersion: v1
kind: Pod
metadata:
name: "busybox1"
spec:
containers:
- image: busybox
name: busybox
command: [ "sleep","6000"]
dnsConfig:
options:
- name: ndots
value: "7"busybox Image hash : |
|
Just for the records, I opened a new issue at the bugtracker of busybox: https://bugs.busybox.net/show_bug.cgi?id=14671 |
|
Encountered the same issue in busybox:1.35. |
There is a bug related to nslookup in busybox (docker-library/busybox#48). nslookup doesn't return 0 when one of the hostname+domain suffix failed to resolve. The suffix are listed in /etc/resolve.conf. e.g. default.svc.cluster.local svc.cluster.local cluster.local Also checking DNS doesn't mean service is up. wait4x will try to make connection and valid the servie is up and running.
|
1.34.1 is not stable, does not work most time, sometimes works: 1.34.1 works once in my tests: 1.36.0 works fine: |
|
Same issue on BusyBox v1.36.1. / # busybox | head -1
BusyBox v1.36.1 (2023-05-18 22:34:17 UTC) multi-call binary.
/ # nslookup kubernetes.default
Server: 172.16.0.10
Address: 172.16.0.10:53
** server can't find kubernetes.default: NXDOMAIN
** server can't find kubernetes.default: NXDOMAIN
/ # wget -O- kubernetes.default
Connecting to kubernetes.default (172.16.0.1:80) |
|
@BSWANG nslookup doesn't use host file to resolve and only use DNS server. |
|
any update? I decide to used alpine: |
|
|
I have a workaround for the moment, if you want nslookup in your pods : add the package bind-tools or add the package in the docker image and it works |
|
I was really breaking my head why PQDNs (aka kubernetes.default) aren't being resolved by nslookup in my debugging pod. |
and others
I deployed a kubernetes image using the latest version of busybox image.
After the pod was successfully deployed I tried to run
kubectl exec busybox nslookup kubernetes.default
The nslookup command no longer works.
shenoyk-m01:image-pipeline shenoyk$ kubectl exec busybox nslookup kubernetes.default
Server: 10.0.0.10
Address: 10.0.0.10:53
** server can't find kubernetes.default: NXDOMAIN
*** Can't find kubernetes.default: No answer
The same command works when specifying busybox:1.28 version for the image. Nslookup started failing with the latest version
busybox.yaml is below.
apiVersion: v1
kind: Pod
metadata:
name: busybox
namespace: default
spec:
containers:
command:
imagePullPolicy: Always
name: busybox
restartPolicy: Always
The text was updated successfully, but these errors were encountered: