Ability to set ndots in /etc/resolv.conf about bottlerocket HOT 6 OPEN

Thanks for the request @joesteffee! We'll look into it.

The man page is telling me the default value is 1 - does this value not work well in your setup? (You mentioned 5)

from bottlerocket.

Thanks for the request @joesteffee! We'll look into it.

The man page is telling me the default value is 1 - does this value not work well in your setup? (You mentioned 5)

AWS EKS defaults this to 5. The default in linux is 1, the default recommended for coredns is 3.

from bottlerocket.

@joesteffee out of curiosity - where does EKS set this?

Starting with aws-k8s-1.28, the distro as a whole has started moving away from wicked towards systemd-networkd/resolved. That means for the short term we are supporting both, but need to be cognizant about taking on new settings that explicitly work for systemd-resolved in the longer term.

I had some time to research this a little bit and came across this systemd issue, and more specifically this comment where @poettering explains the rationale behind systemd-resolved not supporting ndots-like functionality.

I haven't had time to go digging, but I'd be curious what other distros that use systemd-resolved do for this particular setting.

from bottlerocket.

Regardless of what resolver the host distro uses, kubelet will pass a modified resolv.conf into containers that use the overlay network. If they're using glibc they will understand and respect the ndots option.

As I understand it, this request is to be able to configure kubelet's behavior.

from bottlerocket.

Regardless of what resolver the host distro uses, kubelet will pass a modified resolv.conf into containers that use the overlay network. If they're using glibc they will understand and respect the ndots option.

As I understand it, this request is to be able to configure kubelet's behavior.

I'm not 100% sure where the configuration is coming from initially (VPC DHCP maybe?) but if you look at /etc/resolv.conf on any EKS node using bottlerocket it has ndots:5 set by default. Its my understanding that the /etc/resolv.conf on the host is inherited when it is injected into pod overlay networks, as modifying the /etc/resolv.conf ndots setting on the host causes the new setting to be present in containers.

We have worked around this issue for now by setting up node-local DNS caching: https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/ So, we have a caching DNS server (local-dns) sitting in front of our caching DNS servers (coredns), which then sits in front of our VPC-level caching DNS servers provided by AWS. All because every local domain lookup was driving us over rate limits set by AWS due to all the NXDOMAIN responses that should never have been made to begin with.

Here's a clearer example of what is happening:
lookup: github.com
causes lookups on:

• github.com.svc.cluster.local: NXDOMAIN
• github.com.cluster.local: NXDOMAIN
• github.com

As you can see, every external domain uses at least 3x as many DNS requests (or more if additional search domains are used) to resolve as is necessary, impacting performance and potentially hitting limits imposed by upstream DNS servers. A more desireable behavior is to try the local resolvers last, as controlled by the ndots setting.

from bottlerocket.

It looks like many people end up using https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config to configure pods to have dnsConfig set with lower ndots if they aren't using . terminated queries. Something like:

spec:
  dnsConfig
    options:
      - name: ndots
        value: "2"
      - name: edns0

This works for each pod but doesn't set it for the entire node. I haven't found anything that let's one set ndots for the node and it seems most use dnsConfig to change this on specific pods. I think most setups configure CoreDNS at the cluster level.

Its my understanding that the /etc/resolv.conf on the host is inherited when it is injected into pod overlay networks, as modifying the /etc/resolv.conf ndots setting on the host causes the new setting to be present in containers.

I don't believe this is how it works on Bottlerocket since ndots isn't set by default on the node, so this appears to be coming in from the cluster or kubelet. I haven't been able to pinpoint this so far but wanted to share what I've found so far.

I do think it would be useful for users to specify these settings since it looks like you can specify a /etc/resolv.conf file explicitly to kubelet with the --resolv-conf flag: https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/. It seems useful to be able to provide a way to override this but I don't believe you can do this today in Bottlerocket.

I did notice that systemd-resolved is called out as a known issue here: https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues so we might need to see if that logic is kicking in and causing additional difficulties.

from bottlerocket.