Linux mint systemd resolved

Linux Mint Forums

Forum rules
Before you post please read how to get help. Topics in this forum are automatically closed 6 months after creation.

systemd-resolved stub resolver?

Post by PeterBell » Sat Jul 07, 2018 12:35 am

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?

Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.

catweazel Level 19
Posts: 9763 Joined: Fri Oct 12, 2012 9:44 pm Location: Australian Antarctic Territory

Re: systemd-resolved stub resolver?

Post by catweazel » Sat Jul 07, 2018 1:16 am

«There is, ultimately, only one truth — cogito, ergo sum — everything else is an assumption.» — Me, my swansong.

Re: systemd-resolved stub resolver?

Post by PeterBell » Sat Jul 07, 2018 10:44 am

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!

Re: systemd-resolved stub resolver?

Post by PeterBell » Mon Aug 06, 2018 6:03 am

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:

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.

Re: systemd-resolved stub resolver?

Post by rene » Mon Aug 06, 2018 7:02 am

PeterBell wrote: ⤴ Sat Jul 07, 2018 12:35 am 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.

PeterBell wrote: ⤴ Sat Jul 07, 2018 12:35 am 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.

Re: systemd-resolved stub resolver?

Post by rene » Mon Aug 06, 2018 8:23 am

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.

Re: systemd-resolved stub resolver?

Post by PeterBell » Mon Aug 06, 2018 8:43 am

PeterBell wrote: ⤴ Sat Jul 07, 2018 12:35 am 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.)

PeterBell wrote: ⤴ Sat Jul 07, 2018 12:35 am 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.

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?

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.

Источник

Как настроить локальный DNS-сервер на Linux?

Если у вашего домашнего или офисного интернет-провайдера медленные серверы имен или ваш сервер выполняет много операций поиска, то вам нужен локальный кеширующий DNS-сервер.

Как мне поможет локальный DNS-сервер?

Кеширующий DNS-сервер работает, выполняя все DNS-запросы, которые обрабатывает ваша система, а затем сохраняя или кэшируя результаты в памяти. Как только результаты кэшируются в памяти, каждый раз, когда вы делаете повторный запрос для домена, результат будет почти мгновенно получен из памяти.

Локальный DNS-сервер не только поможет в вашем доме или офисе, но и на вашем сервере. Если у вас есть приложение, которое выполняет множество операций поиска DNS, например, почтовый сервер, на котором запущено антиспамовое программное обеспечение, оно получит повышение скорости от локального кэширующего DNS-сервера.

Наконец, утилита systemd-resolved поддерживает самые последние, безопасные стандарты DNS DNSSEC и DNSoverTLS или DoT. Они помогают защитить вас и сохранить вашу конфиденциальность в Интернете.

Какой локальный кеширующий DNQS мы будем использовать?

Локальный кеширующий DNS-сервер, который мы включим и настроим в этом руководстве, это systemd-resolved. Данный инструмент является частью Systemd набора инструментов управления системой. Если ваша система использует systemd , и почти все основные дистрибутивы Linux используются, то у вас уже будет установлен systemd-resolved , но он не будет работать. Большинство дистрибутивов не используют systemd-resolved, даже если он присутствует.

systemd-resolved работает, запустив небольшой локальный кеширующий DNS-сервер, который мы настроим для запуска при загрузке. Затем мы перенастроим остальную часть системы, чтобы направлять их DNS-запросы в DNS-систему с локальным кэшированием.

1. Как проверить, используете ли вы уже systemd-resolved?

В некоторых дистрибутивах Linux по умолчанию уже используется systemd-resolved, например Ubuntu 19.04.

Если вы уже запустили systemd-resolved, вам не нужно включать его или настраивать систему для его использования. Однако вам может потребоваться убедиться, что инструменты управления сетью, такие как NetworkManager, настроены правильно, поскольку они могут игнорировать конфигурацию сети системы.

Прежде чем перейти к следующему разделу, выполните следующую команду, чтобы проверить, запущен ли уже systemd-resolved:

Если вы получили сообщение:

$ resolvectl status Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found.

Вы не используете systemd-resolved и должны перейти к следующему разделу. Если вместо этого вы видите вывод, который начинается примерно так:

Global LLMNR setting: yes MulticastDNS setting: yes DNSOverTLS setting: opportunistic DNSSEC setting: allow-downgrade DNSSEC supported: no Current DNS Server: 1.1.1.1 DNS Servers: 1.1.1.1 1.0.0.1

Тогда вы уже используете systemd-resolved и вам не нужно его включать.

2. Включение и настройка systemd-resolved

Нам не нужно устанавливать systemd-resolved как часть systemd. Все, что нам нужно сделать, — это запустить его, чтобы запустить сервер кэширования DNS, а затем включить его при загрузке.

Запустите следующую команду в терминале от имени пользователя sudo для запуска systemd-resolved:

$ sudo systemctl start systemd-resolved.service

Затем выполните следующую команду, чтобы запустить systemd-resolved при загрузке системы:

Источник