Systemd-resolved - resolve.conf - ndots 5 - search domain

Rancher
1

@superseb i hope you have an idea for this issue:

env:

  • ubuntu 18.04 lts server
  • kernel 5.3.0-46-generic
  • custom rancher cluster
  • docker version: 19.03.5

issue: dns name resolution fails
where: inside pod (container)
when:

if the /etc/resolv.conf inside the container contains:

nameserver 10.43.0.10
search xyz.svc.cluster.local svc.cluster.local cluster.local example.com —> if i remove the example.com, everything is fine
options ndots:5 —> if this is set 1, everything is fine

AND if the /etc/resolv.conf --> /run/systemd/resolve/stub-resolv.conf (systemd-resolved) of the NODE contains:

nameserver 127.0.0.53
options edns0
search example.com –> if i remove this line on the node, then everything works fine inside the container although ndots is set to 5. this search domain comes over dhcp and i cant force systemd-resolved to ignore it and not to set it.

my workaround at the moment is a custom /etc/resolv.conf which contains only:
nameserver 8.8.8.8

maybe the issue has something to do with: https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues

" Systemd-resolved moves and replaces /etc/resolv.conf with a stub file that can cause a fatal forwarding loop when resolving names in upstream servers."

i checked the entrypoint.sh inside the kubelet container, it contains also based on https://raw.githubusercontent.com/rancher/rke-tools/master/entrypoint.sh this part:

# Check if no other or additional resolv-conf is passed (default is configured as /etc/resolv.conf)
if echo "$@" | grep -q -- --resolv-conf=/etc/resolv.conf; then
    # Check if host is running `system-resolved`
    if pgrep -f systemd-resolved > /dev/null; then
        # Check if the resolv.conf with the actual nameservers is present
        if [ -f /run/systemd/resolve/resolv.conf ]; then
            RESOLVCONF="--resolv-conf=/run/systemd/resolve/resolv.conf"
        fi
    fi
fi

I was not sure, if a “docker restart kubelet” would trigger the entrypoint.sh again.
After the restart, i checked again the /etc/resolv.conf inside the kubelet container. It contains again the content of the /etc/resolv.conf of the host but not the content of /run/systemd/resolve/resolv.conf.

I hope you have an idea.

Best regards
Masi