systemd-resolved stub resolver?

[PeterBell]

I have a separate dns server running on my network (dnsmasq), which is able to resolve all of my local addresses. The address of my dns server is promulgated via dhcp.
Since installing v19, my /etc/resolv.conf gets a loopback address inserted as a nameserver, With this in place, none of my local addresses are resolvable. If I hand-edit resolv.conf to change the address to that of my dns server, then everything works as it should but, of course, my edit gets lost after a reboot. The puzzling thing is that, in network settings, the correct dns server address is shown, but this loopback setting seems to override it.

How can I get back to the situation I had with v18, where the dns address promulgated via dhcp was the one in use?

[catweazel]

my edit gets lost after a reboot.

Do any of the suggestions here help?

[PeterBell]

Do any of the suggestions here help?

Thanks for your assistance, but none of those really fix the problem - most of them simply involve hard-coding the dns server address rather than fixing the problem to ensure that the dns server address, provided via dhcp, is used. I have hard-coded as a convenience for now, but I know that it will come back to bite me in the future if/when I change my dns server and have forgotten all about this issue!

[PeterBell]

I have found that similar problems afflict other distros. My preferred solution, now, is to edit the nsswitch.conf file.

Where the default installation seems to create a 'hosts' configuration line in the nsswitch.conf, with the 'dns' entry at the end of the line, it works better, for me, with the 'dns' entry immediately following the 'files' entry, thus:

Code: Select all

hosts:          files dns mdns4_minimal [NOTFOUND=return]

With this change in place, I have been able to remove the hard-coded dns server ip address from resolved.conf.

[rene]

Since installing v19, my /etc/resolv.conf gets a loopback address inserted as a nameserver.

This should not be since 19; for many releases now Ubuntu/Mint, through use of NetworkManager, uses a machine-local copy of dnsmasq on 127.0.1.1 as the main DNS-resolver (i.e., the one in /etc/resolv.conf) with it in turn configured to contact your upstream servers.

The puzzling thing is that, in network settings, the correct dns server address is shown, but this loopback setting seems to override it.

Mmm. Normally said upstream servers are broadcast to the machine-local copy of dnsmasq on D-Bus by your DHCP client -- but if you configured the address of your network-local DNS-server manually, one would expect that NetworkManager would go to the trouble of communicating that one as well. It seemingly not doing so would as far as I'm concerned count as a bug (and maybe that's the Mint 19 specific part/bug: this should as said not be different on 18).

You can in any case take two courses of action. The machine-local copy of dnsmasq is (fairly) useless when you run a network-local one already, so disabling it outright could be the preferred solution: remove dns=dnsmasq from /etc/NetworkManager/NetworkManager.conf.

The other option, and the one which probably ends with what you had in 18 by default/buglessness is adding your network-local server manually as an upstream server to the machine-local copy: place a file e.g. "network-local-server.conf" (only the .conf extension matters namewise) containing, e.g. again, server=192.168.1.123 in /etc/NetworkManager/dnsmasq.d/.

A third possible option is foregoing your network-local server completely. That is, are you aware that you can reach a machine running bonjour/avahi -- such as mint machines by default, apple ones probably and windows ones by choice -- by name as "hostname.local" without needing a DNS server?

[EDIT] By the way, I basically only now notice the title of the post and while I expect that systemd-resolved is not in fact involved on Mint 19 unless you specifically configured it to be, you may want to make sure that indeed you do have a machine-local copy of dnsmasq running, from ps -f -C dnsmasq; I don't have a copy of Mint 19 in front of me. If yes, all of the above is applicable.

[rene]

Having re-read the thread closer I'm now fairly certain that your main issue is that you have named your local machine foo.local. The .local suffix is reserved for mDNS. This was again no different on 18, so although I do see that U18.04/Mint 19 switched to Netplan, it seems we need more explicit information.

[PeterBell]

Thanks for your input!

Since installing v19, my /etc/resolv.conf gets a loopback address inserted as a nameserver.

This should not be since 19; for many releases now Ubuntu/Mint, through use of NetworkManager, uses a machine-local copy of dnsmasq on 127.0.1.1 as the main DNS-resolver (i.e., the one in /etc/resolv.conf) with it in turn configured to contact your upstream servers.

Perhaps - but having been running Mint through many releases, this problem has just shown up on 19. (and is very similar to the problem I have experienced with recent updates to ArchLinux.)

The puzzling thing is that, in network settings, the correct dns server address is shown, but this loopback setting seems to override it.

Mmm. Normally said upstream servers are broadcast to the machine-local copy of dnsmasq on D-Bus by your DHCP client -- but if you configured the address of your network-local DNS-server manually, one would expect that NetworkManager would go to the trouble of communicating that one as well. It seemingly not doing so would as far as I'm concerned count as a bug (and maybe that's the Mint 19 specific part/bug: this should as said not be different on 18).

Yes - I want to use the dns server which is notified via dhcp, but the system was failing to do that, despite the fact that Network Config is showing the correct dns server address. I have never, previously, had to configure the dns server manually.

You can in any case take two courses of action. The machine-local copy of dnsmasq is (fairly) useless when you run a network-local one already, so disabling it outright could be the preferred solution: remove dns=dnsmasq from /etc/NetworkManager/NetworkManager.conf.

dnsmasq is not not running, and does not feature in NetworkManager.conf

The other option, and the one which probably ends with what you had in 18 by default/buglessness is adding your network-local server manually as an upstream server to the machine-local copy: place a file e.g. "network-local-server.conf" (only the .conf extension matters namewise) containing, e.g. again, server=192.168.1.123 in /etc/NetworkManager/dnsmasq.d/.

I am quite certain that the local server was not added manually in previous configurations.

A third possible option is foregoing your network-local server completely. That is, are you aware that you can reach a machine running bonjour/avahi -- such as mint machines by default, apple ones probably and windows ones by choice -- by name as "hostname.local" without needing a DNS server?

Perhaps - but that certainly wouldn't be possible for my proprietary modem/router, photoframe and some other devices on my network.

[EDIT] By the way, I basically only now notice the title of the post and while I expect that systemd-resolved is not in fact involved on Mint 19 unless you specifically configured it to be, you may want to make sure that indeed you do have a machine-local copy of dnsmasq running, from ps -f -C dnsmasq; I don't have a copy of Mint 19 in front of me. If yes, all of the above is applicable.

As stated in my post today, the difference in behaviour seems to be related to a change in nsswitch.conf. Previous versions of this file (both in Mint and in Arch) placed the 'dns' entry earlier in the 'Hosts:' line. Latest versions place 'dns' at the very end of the line.

I'm not sure whether I tested this in Mint but I was very puzzled in Arch that "ping tower" failed to resolve, whereas "drill tower" returned the correct address. So, the default dns server used by drill (and, probably, dig) is different to the default dns server used by ping. This may be loosely connected to the fact that, in Mint, the Network Configuration utility was showing the correct dns server address, but that server was, clearly, not being used by most parts of the system.

[PeterBell]

Having re-read the thread closer I'm now fairly certain that your main issue is that you have named your local machine foo.local. The .local suffix is reserved for mDNS. This was again no different on 18, so although I do see that U18.04/Mint 19 switched to Netplan, it seems we need more explicit information.

Do you mean the name specified in /etc/hostname? I have always avoided having to use a '.local' suffix, and my hostname file uses a simple name:

Code: Select all

peter@Sala:~$ cat /etc/hostname
Sala

[rene]

As stated in my post today, the difference in behaviour seems to be related to a change in nsswitch.conf. Previous versions of this file (both in Mint and in Arch) placed the 'dns' entry earlier in the 'Hosts:' line. Latest versions place 'dns' at the very end of the line.

The thing is that that is not true. The default hosts line in nsswitch.conf for Mint 18, Mint 17 and all other distributions I've used semi-recently is hosts: files mdns4_minimal [NOTFOUND=return] dns, i.e., with "dns" the last entry. This is also how things should be, and the fact that you find behaviour changed when you move "dns" to before mdns4_minimal means that mdns4_minimal believes to be authoritative for the name you requested. As would be the case if said name ends in ".local" and shouldn't otherwise.

Your "tower" example" clearly does not end in .local so is that an actual example, or do your local machine names in fact end in .local? Also, what is the address in /etc/resolv.conf? 127.0.0.53? If yes then it seems that Mint 19 has indeed switched to systemd-resolved rather than local dnsmasq.

Either case, changed nsswitch.conf order making a difference does not make sense unless something's trying to resolve "tower.local" rather than "tower" -- but if that's definitely not you I suppose that could be systemd-resolved aiming to be helpful itself. In that case, does goodness happen even with the original nsswitch.conf "hosts:" order when you in /etc/NetworkManager/NetworkManager.conf add

Code: Select all

[ifupdown]
managed=true

and restart NetworkManager with sudo systemctl restart NetworkManager?

This as per the second answer on https://unix.stackexchange.com/question ... dns-server which disabled resolvconf as well; this may or may not be necessary.

[rene]

Do you mean the name specified in /etc/hostname?

No, sorry, I missed an "s" while typing: wanted to say "local machines", I.e., and also referring to the new reply one up, if you had configured the domain for your local network in your network-local DNS server to be the string "local". That suffix would indeed conflict with mDNS. But your "tower" example" seems to already say you didn't so I'm now as per above suspecting systemd-resolved to just be yet another systemd-paininthebuttd...

[rene]

Also see viewtopic.php?f=157&t=275229&p=1509495#p1509495.

[PeterBell]

Also see viewtopic.php?f=157&t=275229&p=1509495#p1509495.

Thanks.