3 ms·

Before networkmanager and systemd, pretty much every tool used gethostbyname, which used standard nsswitch which tended to be hosts, then resolv.conf resolv.co

Before networkmanager and systemd, pretty much every tool used gethostbyname, which used standard nsswitch which tended to be hosts, then resolv.conf resolv.conf would use the first one, and then timeout and use the next one Nice and simple. The quote "simply turn off systemd-resolved" Is usually the answer, but it's a constant uphill battle to fix broken behaviour. Of course Pottering doesn't care.

iso1631 5y ago
And straight away it's a downvote. Pottering, in that thread, literally says "I have the suspicion that this going to negatively affect about as many people as it positively affects..." https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu https://askubuntu.com/questions/907246/how-to-disable-system... is a "good" solution to the problem in ubuntu
necovek 5y ago
To be honest, systemd-resolved actually for the first time provides an option of a solution for this use-case. Properly configured, without CNAMEs involved, it would just do the right thing. Relying on resolv.conf meant using the first one unless it times out, which makes it impossible for me to connect to two private networks with their own hostname resolution, if a hostname resolves in both but to different addresses.
- iso1631 5y ago
  But how can you do that unless you are saying "map this .foo.com to resolver A, and map .bar.com to resolver B". You have an option to install dnsmasq or whatever resolver you want for that very unusual use case without installing tons of more bloated demons on machines that simply don't need it. 99% of linux machines are not laptops connecting to multiple networks with private DNS servers, they have static network configurations, or a single network connection with dhcp. Of the rest, most are laptops, and sure you want some form of gui selection to choose your wireless network, and maybe even set up your vpns, but that's such a rare case. Also remember that private DNS servers are on the way out now on a desktop, with DoH being embedded at the browser layer, so this tiny use case will shrink even more. by all means have a "yum install dns-multipathd" or whatever as a resolver to solve this problem on the 1 in a thousand machines it helps on, but why have any software installed and listening on port 53 by default? Seems a needless security risk to me
  - necovek 5y ago
    > But how can you do that unless you are saying "map this .foo.com to resolver A, and map .bar.com to resolver B". That's exactly what systemd-resolved does for you when properly configured. The linked issue is about something.foo.com resolving to blah.bar.com and then that hitting resolver B, and Poettering correctly notes how it might cause issues for some while it fixes issues for others. Now, whether I think systemd and the ecosystem is too complicated? Sure it is, and that means it's a guaranteed pile of bugs. But I also believe the goals are admirable, and it is up to everyone to decide whether they are willing to live through the bugs (thus helping improve it) or not, relying on more traditional tools. I am not sure how DoH is going to interact with local network DNS as I haven't looked into it, but if browsers are unable to figure it out the right way, I'll for sure disable it.
    - iso1631 5y ago
      So that's nothing to do with the network you're connected to, but do do with things like search domains. The unix way has always to be provide an optional daemon (like dnsmasq, other daemons are available) to do unusual setups like this. It's not to do with networking, it's a higher level than that. I might wand .google.com to resolve via 8.8.8.8 but normal domains to resolve via 1.1.1.1 -- both of which might be via the same gateway, or perhaps via a different gateway on the same subnet, or perhaps a different interface entirely. Maybe I want .blah.com to connect via DoT but others to not. Perhaps my routing protocol changes the gateway I use to reach the servers I want. None of that should be of any concern to the DNS forwarder
      - necovek 5y ago
        DHCP will provide a nameserver and search domain for the network you connect to, which will resolve domains in that search domain properly. There is nothing special about that. With systemd-resolved, the right thing happens out of the box. Without it, you've got to do something arbitrary like you describe. It's ok to dislike systemd (there are plenty reasons to do so), but if you won't acknowledge things it does well, it's hard to take you seriously. FWIW, I don't think having a local network (with eg. a NAS drive on it) and connecting to another (VPN) is so uncommon.
rconti 5y ago
"Disable networkmanager, uninstall network manager, delete networkmanager, nuke networkmanager from orbit" was always my 4 step process for making things work right for ages. (and all 4 steps were always somehow necessary, because it would always come back from the dead).
Spivak 5y ago
I think you have the pieces all jumbled. Every tool still uses gethostbyname which uses the glibc NSS machinery. The only thing systemd did was add a few NSS modules that could (and are) configured in /etc/nsswitch.conf. You probably have the 'resolve' and 'myhostname' modules. The module that reads /etc/resolv.conf is the 'dns' module. The behavior of the 'dns' module is terrible. If you have three servers listed and the first one is unavailable then every. single. dns. request. must wait for the first server to time out then try the second one. Also if you have three servers listed and server 3 happens to be the fastest you'll never know because even if the first two servers are down and you finally use it there are two timeouts in between you and that speed. And since there's only one resolv.conf if you're connected to a split-tunnel VPN you get to choose whether to send all your DNS requests over the tunnel or none of them. systemd-resolved actually does the right thing in (almost) all of these cases. Built-in kernel IPSec still trips it up because systemd-resolved's view of the world is mapping DNS configuration to interfaces and since kernel IPSec is a policy VPN blah blah nevermind -- it has memory so it can remember if servers are down, and it used to send requests to all listed servers to find the fastest one and prefer it before people complained, and split-tunnel VPNs work! The "feature" of "merging" DNS zones by relying on query order is pants on head broken as soon as your first DNS server is unreliable or if your first server doesn't return a strict superset of all subsequent servers. If you have internal names both over your VPN and on your local network then no matter what order you pick one of them will be unresolveable.
- iso1631 5y ago
  And if I want to install a forwarder like dnsmasq or resolvd I've always been able to do that. A lot of the problem that people have with systemd is the forcing of it by the distros.

iso1631 5y ago

And straight away it's a downvote. Pottering, in that thread, literally says "I have the suspicion that this going to negatively affect about as many people as it positively affects..." https://askubuntu.com/questions/907246/how-to-disable-systemd-resolved-in-ubuntu https://askubuntu.com/questions/907246/how-to-disable-system... is a "good" solution to the problem in ubuntu

necovek 5y ago

To be honest, systemd-resolved actually for the first time provides an option of a solution for this use-case. Properly configured, without CNAMEs involved, it would just do the right thing. Relying on resolv.conf meant using the first one unless it times out, which makes it impossible for me to connect to two private networks with their own hostname resolution, if a hostname resolves in both but to different addresses.

iso1631 5y ago
But how can you do that unless you are saying "map this .foo.com to resolver A, and map .bar.com to resolver B". You have an option to install dnsmasq or whatever resolver you want for that very unusual use case without installing tons of more bloated demons on machines that simply don't need it. 99% of linux machines are not laptops connecting to multiple networks with private DNS servers, they have static network configurations, or a single network connection with dhcp. Of the rest, most are laptops, and sure you want some form of gui selection to choose your wireless network, and maybe even set up your vpns, but that's such a rare case. Also remember that private DNS servers are on the way out now on a desktop, with DoH being embedded at the browser layer, so this tiny use case will shrink even more. by all means have a "yum install dns-multipathd" or whatever as a resolver to solve this problem on the 1 in a thousand machines it helps on, but why have any software installed and listening on port 53 by default? Seems a needless security risk to me
- necovek 5y ago
  > But how can you do that unless you are saying "map this .foo.com to resolver A, and map .bar.com to resolver B". That's exactly what systemd-resolved does for you when properly configured. The linked issue is about something.foo.com resolving to blah.bar.com and then that hitting resolver B, and Poettering correctly notes how it might cause issues for some while it fixes issues for others. Now, whether I think systemd and the ecosystem is too complicated? Sure it is, and that means it's a guaranteed pile of bugs. But I also believe the goals are admirable, and it is up to everyone to decide whether they are willing to live through the bugs (thus helping improve it) or not, relying on more traditional tools. I am not sure how DoH is going to interact with local network DNS as I haven't looked into it, but if browsers are unable to figure it out the right way, I'll for sure disable it.
  - iso1631 5y ago
    So that's nothing to do with the network you're connected to, but do do with things like search domains. The unix way has always to be provide an optional daemon (like dnsmasq, other daemons are available) to do unusual setups like this. It's not to do with networking, it's a higher level than that. I might wand .google.com to resolve via 8.8.8.8 but normal domains to resolve via 1.1.1.1 -- both of which might be via the same gateway, or perhaps via a different gateway on the same subnet, or perhaps a different interface entirely. Maybe I want .blah.com to connect via DoT but others to not. Perhaps my routing protocol changes the gateway I use to reach the servers I want. None of that should be of any concern to the DNS forwarder
    - necovek 5y ago
      DHCP will provide a nameserver and search domain for the network you connect to, which will resolve domains in that search domain properly. There is nothing special about that. With systemd-resolved, the right thing happens out of the box. Without it, you've got to do something arbitrary like you describe. It's ok to dislike systemd (there are plenty reasons to do so), but if you won't acknowledge things it does well, it's hard to take you seriously. FWIW, I don't think having a local network (with eg. a NAS drive on it) and connecting to another (VPN) is so uncommon.

rconti 5y ago

"Disable networkmanager, uninstall network manager, delete networkmanager, nuke networkmanager from orbit" was always my 4 step process for making things work right for ages. (and all 4 steps were always somehow necessary, because it would always come back from the dead).

Spivak 5y ago

I think you have the pieces all jumbled. Every tool still uses gethostbyname which uses the glibc NSS machinery. The only thing systemd did was add a few NSS modules that could (and are) configured in /etc/nsswitch.conf. You probably have the 'resolve' and 'myhostname' modules. The module that reads /etc/resolv.conf is the 'dns' module. The behavior of the 'dns' module is terrible. If you have three servers listed and the first one is unavailable then every. single. dns. request. must wait for the first server to time out then try the second one. Also if you have three servers listed and server 3 happens to be the fastest you'll never know because even if the first two servers are down and you finally use it there are two timeouts in between you and that speed. And since there's only one resolv.conf if you're connected to a split-tunnel VPN you get to choose whether to send all your DNS requests over the tunnel or none of them. systemd-resolved actually does the right thing in (almost) all of these cases. Built-in kernel IPSec still trips it up because systemd-resolved's view of the world is mapping DNS configuration to interfaces and since kernel IPSec is a policy VPN blah blah nevermind -- it has memory so it can remember if servers are down, and it used to send requests to all listed servers to find the fastest one and prefer it before people complained, and split-tunnel VPNs work! The "feature" of "merging" DNS zones by relying on query order is pants on head broken as soon as your first DNS server is unreliable or if your first server doesn't return a strict superset of all subsequent servers. If you have internal names both over your VPN and on your local network then no matter what order you pick one of them will be unresolveable.

iso1631 5y ago
And if I want to install a forwarder like dnsmasq or resolvd I've always been able to do that. A lot of the problem that people have with systemd is the forcing of it by the distros.