k3s can not resolve DNS resolution

[Kracozebr]

Environmental Info:
k3s version v1.24.4+k3s1 (c3f830e)
go version go1.18.1

Node(s) CPU architecture, OS, and Version:
Linux ubuntu 4.9.253-tegra #1 SMP PREEMPT Sun Apr 17 02:37:44 PDT 2022 aarch64 aarch64 aarch64 GNU/Linux

Cluster Configuration:
1 server
Describe the bug:
k3s can not resolve DNS resolution

Steps To Reproduce:
curl -sfL https://get.k3s.io | sh -s - server --write-kubeconfig-mode 644 --cluster-init

Check if dns resolutions works as follows

kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup kubernetes.default

Expected behavior:
Expect to be smth like that:

Server:    10.0.0.10
Address 1: 10.0.0.10

Name:      kubernetes.default
Address 1: 10.0.0.1

Actual behavior:
But get:

If you don't see a command prompt, try pressing enter.
Address 1: 10.43.0.10

nslookup: can't resolve 'kubernetes.default'
pod "busybox" deleted
pod default/busybox terminated (Error)

Additional context / logs:
Check the coredns logs

for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done

[WARNING] No files matching import glob pattern: /etc/coredns/custom/*.server
.:53
[WARNING] No files matching import glob pattern: /etc/coredns/custom/*.server
[INFO] plugin/reload: Running configuration SHA512 = b941b080e5322f6519009bb49349462c7ddb6317425b0f6a83e5451175b720703949e3f3b454a24e77f3ffe57fd5e9c6130e528a5a1dd00d9000e4afd6c1108d
CoreDNS-1.9.1
linux/arm64, go1.17.8, 4b597f8
[ERROR] plugin/errors: 2 4454268915698512202.3377740739522558627. HINFO: read udp 10.42.0.4:57689->8.8.8.8:53: i/o timeout
[ERROR] plugin/errors: 2 4454268915698512202.3377740739522558627. HINFO: read udp 10.42.0.4:53306->8.8.8.8:53: i/o timeout
[ERROR] plugin/errors: 2 4454268915698512202.3377740739522558627. HINFO: read udp 10.42.0.4:38198->8.8.8.8:53: i/o timeout
[ERROR] plugin/errors: 2 4454268915698512202.3377740739522558627. HINFO: read udp 10.42.0.4:34448->8.8.8.8:53: i/o timeout
[ERROR] plugin/errors: 2 4454268915698512202.3377740739522558627. HINFO: read udp 10.42.0.4:39717->8.8.8.8:53: i/o timeout
[ERROR] plugin/errors: 2 4454268915698512202.3377740739522558627. HINFO: read udp 10.42.0.4:54180->8.8.8.8:53: i/o timeout
[ERROR] plugin/errors: 2 4454268915698512202.3377740739522558627. HINFO: read udp 10.42.0.4:35919->8.8.8.8:53: i/o timeout
[ERROR] plugin/errors: 2 4454268915698512202.3377740739522558627. HINFO: read udp 10.42.0.4:38218->8.8.8.8:53: i/o timeout
[ERROR] plugin/errors: 2 4454268915698512202.3377740739522558627. HINFO: read udp 10.42.0.4:40765->8.8.8.8:53: i/o timeout
[WARNING] No files matching import glob pattern: /etc/coredns/custom/*.server
[ERROR] plugin/errors: 2 4454268915698512202.3377740739522558627. HINFO: read udp 10.42.0.4:45094->8.8.8.8:53: i/o timeout
[WARNING] No files matching import glob pattern: /etc/coredns/custom/*.server
[WARNING] No files matching import glob pattern: /etc/coredns/custom/*.server

[roryl23]

I was also getting DNS timeouts with a fresh install of k3s v1.24.6+k3s1, Ubuntu 22.04.1 LTS, kernel 5.15.0-48-generic, with and without Traefik/CoreDNS. The solution for me was removing docker from the node and rebooting. I also found that I could reinstall docker afterward and DNS was still working, for what that's worth.

[Kracozebr]

Hi, I found workaround. When installing k3s I used flag flannel-backend=ipsec

curl -sfL https://get.k3s.io | sh -s - server --write-kubeconfig-mode 644 --flannel-backend=ipsec

By default it uses --flannel-backend=vxlan I've tried --flannel-backend=host-gw
But for me works well flannel-backend=ipsec
You can try different flannel-backand see more options https://rancher.com/docs/k3s/latest/en/installation/network-options/

[stale]

This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 180 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions.