3 ms·

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 whate

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.
    - iso1631 5y ago
      > DHCP will provide a nameserver and search domain for the network you connect to No, it may provide a nameserevr which I may or may not want to use. > which will resolve domains in that search domain properly It may, or may not, provide a search domain. Chances are I'll be using that domain server for all domains, or I'll choose to use my preferred server (4222, 9999 etc) My vpn on my laptop doesn't even use dhcp so not sure how that would apply. > FWIW, I don't think having a local network (with eg. a NAS drive on it) and connecting to another (VPN) is so uncommon. Bridging networks, generally not a good thing.
      - necovek 5y ago
        That's not bridging networks: you are instead connected to multiple networks simultaneously, whereas in bridging, you make one network over multiple interfaces. As for your configuration, it seems you are connecting to a bunch of misconfigured networks if you want to use your own prefered servers.

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.
  - iso1631 5y ago
    > DHCP will provide a nameserver and search domain for the network you connect to No, it may provide a nameserevr which I may or may not want to use. > which will resolve domains in that search domain properly It may, or may not, provide a search domain. Chances are I'll be using that domain server for all domains, or I'll choose to use my preferred server (4222, 9999 etc) My vpn on my laptop doesn't even use dhcp so not sure how that would apply. > FWIW, I don't think having a local network (with eg. a NAS drive on it) and connecting to another (VPN) is so uncommon. Bridging networks, generally not a good thing.
    - necovek 5y ago
      That's not bridging networks: you are instead connected to multiple networks simultaneously, whereas in bridging, you make one network over multiple interfaces. As for your configuration, it seems you are connecting to a bunch of misconfigured networks if you want to use your own prefered servers.