Live data from Hacker News

The Sisyphean Task of DNS Client Config on Linux

tailscale.com

11–20 of 86 posts

Re: The Sisyphean Task of DNS Client Config on Linux

#11
post #10
post #6

Earlier quoted context omitted.

It’s probably omitted as nsswitch doesn’t affect DNS client configuration. It affects which sources are consulted to lookup a name (including maybe asking DNS), but it doesn’t configure things like which DNS servers to ask or what options to set. > The Name Service Switch (NSS) configuration file, /etc/nsswitch.conf, is used by the GNU C Library and certain other applications to determine the sources from which to ob…

nsswitch.conf is what tells it whether to use the traditional nss_dns (the thing that looks at /etc/resolv.conf), or whether to use the newer nss_resolve (the thing that talks to systemd-resolved). So yeah, if the article is contrasting resolv.conf vs systemd-resolved, nsswitch.conf is how you select which of those approaches is used.

The article focussed on how /etc/resolv.conf is being managed and populated. That’s not affected by nsswitch.

I only addressed why nsswitch was likely not mentioned, not that it doesn’t serve a purpose.

Re: The Sisyphean Task of DNS Client Config on Linux

#12
post #8

I recommend the series "Anatomy of a Linux DNS lookup"[0]. Everything you never wanted to know. https://zwischenzugs.com/2018/06/08/anatomy-of-a-linux-dns-l...

That appears to have been written prior to systemd-resolved becoming enabled by default on many distros.

Re: The Sisyphean Task of DNS Client Config on Linux

#13
Tailscale is awesome, you should use it for everything.

This Linux DNS stuff drives us batty at Fly.io. We run user containers as Firecracker VMs; users belong to "organizations", and organizations share a private IPv6 network. We do DNS for that private network under the fake "internal" TLD, so if you have an app "phoenix-frontend" and another app "rabbitmq-cluster", they can see each other at "phoenix-frontend.internal" and "rabbitmq-cluster.internal".

What you'd want in a perfect work is an option in `/etc/resolv.conf` that sends `.internal` to a special nameserver, and everything else to a normal nameserver. But as far as I can tell, there's no way to take a bare Linux VM that can accept an arbitrary container and set that capability up.

So instead, we end up (by default; you could override) serving _all_ customer DNS, and our `.internal` server has to forward recursive queries to things that aren't `.internal` somewhere else. This sucks; we shouldn't have to be inline for arbitrary customer DNS.

If there's a clean way to resolve this, so that the VM itself can just send `.internal` queries to us, and everything else to `1.1.1.1` or `8.8.8.8` or whatever the customer's container had, I would _love_ to hear it. I've come pretty close to breaking out preload in anger over this problem.

Re: The Sisyphean Task of DNS Client Config on Linux

#15
post #7

If you are just trying to use curl or some other straightforward small application - this is enough. But running Kubernetes, docker, or some other container system? This mess is much more deep... For example: there are known issues with systemd-resolved & Kubernetes (at least on Ubuntu that defaults to systemd-resolved) https://kubernetes.io/docs/tasks/administer-cluster/dns-debu...

FYI, if you don't bother opening the link, systemd-resolv sets the /etc/resolv.conf to have only 127.0.0.1 as a DNS server. You can see how things get bad when the CoreDNS pod tries to get the "upstream" DNS servers from the host /etc/resolv.conf

Re: The Sisyphean Task of DNS Client Config on Linux

#16
post #13

Tailscale is awesome, you should use it for everything. This Linux DNS stuff drives us batty at Fly.io. We run user containers as Firecracker VMs; users belong to "organizations", and organizations share a private IPv6 network. We do DNS for that private network under the fake "internal" TLD, so if you have an app "phoenix-frontend" and another app "rabbitmq-cluster", they can see each other at "phoenix-frontend.inte…

Couldn't you run dnsmasq, unbound, or some other configurable resolver on the localhost? Though that's probably already what's done with the internal smart resolver.

Re: The Sisyphean Task of DNS Client Config on Linux

#17
post #13

Tailscale is awesome, you should use it for everything. This Linux DNS stuff drives us batty at Fly.io. We run user containers as Firecracker VMs; users belong to "organizations", and organizations share a private IPv6 network. We do DNS for that private network under the fake "internal" TLD, so if you have an app "phoenix-frontend" and another app "rabbitmq-cluster", they can see each other at "phoenix-frontend.inte…

systemd-resolved can do this, though I haven't played with it too much yet.

Here's a random post I just found: https://gist.github.com/brasey/fa2277a6d7242cdf4e4b7c720d42b...

(Ha, I did the thing where I read the comments before the post, and the post describes how to do this. So what's still missing?)

Re: The Sisyphean Task of DNS Client Config on Linux

#19

Ok, now let's talk about how messed up the same thing is in Mac OS. Hint: it is waaay worse

Dave, one of the authors of these posts, has been regularly documenting on Twitter his struggles with DNS on all the platforms.

If you like sports, it is like watching a basketball game, with three teams and Dave as the play by play announcer.

I'm a linux user, so I'm always cheering when OSX or Windows "loses" but then very quickly Dave will, paraphrasing say: "And, OSX hits a deep 3 pointer..." ("And, OSX does this right, and Linux sucks").

But, it is great theater and very informative. On Dave's recommendation, I switched to systemd-resolved, and it is working flawlessly for me (with my own wireguard setup, not using Tailscale yet).

Re: The Sisyphean Task of DNS Client Config on Linux

#20
post #5

Earlier quoted context omitted.

one reason resolv.conf is/was so sticky is that gethostbyname (and friends) is a libc thing and pretty low-level

Problem is, modern browsers do things differently yet again. So the insanity continues, just on different levels.

browsers are operating systems in user space. They will continue to replace kernel parts.
Post reply on HN