Validate resolv.conf for presence of nameserver entries

[x-coder-L]

Is your feature request related to a problem? Please describe.
We are currently using k3s version 1.28.4 and have encountered an issue. If the /etc/resolv.conf file lacks any nameserver entries, the coredns pod fails to run. However, if the /etc/resolv.conf file is absent, coredns operates correctly.
Describe the solution you'd like

We suggest that if the /etc/resolv.conf file lacks any nameserver entries, the k3s agent should generate a resolv.conf file. This would allow coredns to run properly.
Describe alternatives you've considered

Upon examining the k3s code, we found a section in k3s/pkg/agent/config/config.go that validates the resolv.conf file. We propose adding a check here to validate the presence of nameserver entries in resolv.conf.

k3s/pkg/agent/config/config.go

Line 301 in f099bfa

func isValidResolvConf(resolvConfFile string) bool {

Additional context

[yashvardhan-kukreja]

Hi, I would love to contribute to this one if this gets accepted.
Looks like an interesting issue to work on as my first contribution to k3s :)

[x-coder-L]

I’m glad you’ve taken notice of this issue. I believe we can enhance it together through discussion.
I think this is a small and easy change for this feature.However, I’m uncertain if resolving my problem in the isValidResolvConf function is appropriate.
Additionally, I’m curious as to why k3s generates an agent-resolv.conf under such circumstances. I haven’t found any documentation indicating that k3s will generate a resolv.conf file.

Hi, I would love to contribute to this one if this gets accepted. Looks like an interesting issue to work on as my first contribution to k3s :)

[brandond]

I’m uncertain if resolving my problem in the isValidResolvConf function is appropriate.

I think that's a fine place to do it. As far as k3s is concerned, not having any upstream is just as invalid as having multicast/loopback upstreams.

I’m curious as to why k3s generates an agent-resolv.conf under such circumstances. I haven’t found any documentation indicating that k3s will generate a resolv.conf file.

K3s has always done this, but you're correct that we could probably enhance the documentation to cover the behavior.

As far as why it does it - many hosts use systemd-resolved or another local stub resolver. This does not work within pods, as the loopback address used for the stub is not reachable outside the host network namespace. Using a default upstream (8.8.8.8) in this case provides default behavior that works for most users.

[x-coder-L]

Kindly to ask if there is somebody working for this issue?If not I'm gald to undertake it.

[yashvardhan-kukreja]

I see that you have already raised the PR, so yeah I think you can take it over.
Thanks!

[fmoral2]

fixed here

#10302