LINUX.ORG.RU
решено ФорумAdmin

systemd-resolved перестает работать спустя некоторое время

 , ,


0

2

Приветствую. Конфигурация такова: Debian Trixie, в качестве DNS-резолвера установлен systemd-resolved. В качестве resolv.conf создан симлинк вида

/etc/resolv.conf -> /run/systemd/resolve/resolv.conf

содержимое которого по умолчанию:

# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

В конфиге Network Manager указано:

[main]
dns=systemd-resolved

сам NM для надежности собран без поддержки resolvconf. В принципе все работает, resolvectl показывает успешное получение DNS по DHCP, однако спустя некоторое время - эти DNS записи исчезают, и соответственно разрешение имен перестает работать. Перезапуск сервиса systemd-resolved решает проблему, но опять таки не надолго. В логах NM и systemd-resolved абсолютно ничего подозрительного нет, никаких ошибок или даже предупреждений. Просто лог подключения, получения адреса и так далее. В чем ещё может быть причина? Все конфиги resolved дефолтные.

В чем ещё может быть причина?

Видимо в ненуждод, а точнее в его resolved. Вынести к люлям эту поделку и будет счастье.

anc ★★★★★
()
❯ ll /etc/resolv.conf 
lrwxrwxrwx 1 root root 39 2023-05-31 01:20:07 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
~ 
❯ resolvectl 
Global
         Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp14s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.1.1.1
       DNS Servers: 10.1.1.1
     Default Route: yes

Link 3 (wlp15s0)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Debian 13, всё работает нормально.

anonymous
()
Ответ на: комментарий от MagicMirror

Изменил симлинк - то же самое. Работает, но спустя время - перестает. То есть вот такой вывод resolvectl сначала:

Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp5s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.2.3
       DNS Servers: 10.0.2.3
     Default Route: yes

И вот такой спустя минут 10:

Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp5s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Sunderland93 ★★★★★
() автор топика
Ответ на: комментарий от Sunderland93

У меня не networkmanager, но заметил, что при подключении через корпоративный vpn, systemd-resolved забирает DNS, которые дал корпоративный VPN. Затем, через несколько часов, запускается dhclient, который периодически должен обновлять данные интерфейса, и, видимо, перезаписывает данные DNS дефолтными. Соотв-но, теряю доступ к корпоративным ресурсам, хотя к VPN подключен.

Это всё пока моя гипотеза, которую толком не проверил, и ещё не придумал, как это обходить.

Chiffchaff
()
Ответ на: комментарий от Belkrr

Не помогло. По-прежнему никаких ошибок в логе. Я бы мог конечно сослаться, что в той же убунте при аналогичных настройках все работает, но там ещё netplan прикручен, так что может и в нем дело. Я пробовал в конфиге Network Manager указывать разные типы dns и rc-manager, но либо получал вообще нерабочую конфигурацию, либо ту же проблему с пропаданием DNS серверов

Sunderland93 ★★★★★
() автор топика

В /etc/systemd/resolve.conf установил DNS=1.1.1.1 и FallbackDNS=8.8.8.8. В итоге вывод resolvectl status стал выглядить вот так:

Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: uplink
       Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1
       Fallback DNS Servers: 8.8.8.8

Link 2 (enp5s0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
     Default Route: yes
То есть DNS записи из непосредственно интерфейса опять исчезли, но разрашение имен работает. Не знаю можно ли назвать это решением проблемы и будет ли это работать нормально, но вот так

Sunderland93 ★★★★★
() автор топика
Ответ на: комментарий от ALiEN175

До:

; <<>> DiG 9.20.11-1-Debian <<>> ya.ru @10.0.2.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40094
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ya.ru.				IN	A

;; ANSWER SECTION:
ya.ru.			330	IN	A	77.88.55.242
ya.ru.			330	IN	A	77.88.44.242
ya.ru.			330	IN	A	5.255.255.242

;; Query time: 36 msec
;; SERVER: 10.0.2.3#53(10.0.2.3) (UDP)
;; WHEN: Sun Jul 27 22:05:18 +04 2025
;; MSG SIZE  rcvd: 82

После:

; <<>> DiG 9.20.11-1-Debian <<>> ya.ru @10.0.2.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35487
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ya.ru.				IN	A

;; ANSWER SECTION:
ya.ru.			134	IN	A	5.255.255.242
ya.ru.			134	IN	A	77.88.55.242
ya.ru.			134	IN	A	77.88.44.242

;; Query time: 32 msec
;; SERVER: 10.0.2.3#53(10.0.2.3) (UDP)
;; WHEN: Sun Jul 27 22:09:49 +04 2025
;; MSG SIZE  rcvd: 82
Sunderland93 ★★★★★
() автор топика
Ответ на: комментарий от Sunderland93

У меня на arch все работает. При этом вроде в Trixie версии NetworkManager и systemd совпадают.

Из вариантов еще - запустить wireshark и смотреть на dhcp запросы.

Или попробовать проставить фиксированые dns в NetworkManager и посмотреть сбосятся ли они.

Если ничего не поможет - последний выход баг заводить.

Belkrr
()
Ответ на: комментарий от Belkrr

Значит нужен вывод systemctl status

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Sun 2025-07-27 22:49:55 +04; 1min 13s ago
 Invocation: 09dc3404334a49aebdc99ab8364420e3
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://systemd.io/WRITING_NETWORK_CONFIGURATION_MANAGERS
             https://systemd.io/WRITING_RESOLVER_CLIENTS
   Main PID: 380 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 3337)
     Memory: 7.2M (peak: 7.6M)
        CPU: 55ms
     CGroup: /system.slice/systemd-resolved.service
             └─380 /usr/lib/systemd/systemd-resolved

июл 27 22:49:52 qtile-testing systemd[1]: Starting systemd-resolved.service - Network Name Resolution...
июл 27 22:49:52 qtile-testing systemd-resolved[380]: Positive Trust Anchors:
июл 27 22:49:52 qtile-testing systemd-resolved[380]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d0845>
июл 27 22:49:52 qtile-testing systemd-resolved[380]: . IN DS 38696 8 2 683d2d0acb8c9b712a1948b27f7412192>
июл 27 22:49:52 qtile-testing systemd-resolved[380]: Negative trust anchors: home.arpa 10.in-addr.arpa 1>
июл 27 22:49:55 qtile-testing systemd-resolved[380]: Using system hostname 'qtile-testing'.
июл 27 22:49:55 qtile-testing systemd[1]: Started systemd-resolved.service - Network Name Resolution.
июл 27 22:50:07 qtile-testing systemd-resolved[380]: enp0s1: Bus client set DNS server list to: 10.0.2.3
июл 27 22:50:29 qtile-testing systemd-resolved[380]: Clock change detected. Flushing caches.

И первый по подозрению - systemd-networkd

Не установлен

Sunderland93 ★★★★★
() автор топика
Ответ на: комментарий от ALiEN175

После перезагрузки вот так:

Global
           Protocols: +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub
  Current DNS Server: 1.1.1.1
         DNS Servers: 1.1.1.1
Fallback DNS Servers: 8.8.8.8

Link 2 (enp0s1)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.0.2.3
       DNS Servers: 10.0.2.3
     Default Route: yes

Sunderland93 ★★★★★
() автор топика
Ответ на: комментарий от Sunderland93

Не установлен

Установлен, он там вместе с systemd идёт. Как ранее было с sd-resolved/sd-boot, пока не вынесли их отдельно. systemctl status systemd-networkd - проверь, что выключен(или просто процессы посмотри).

Насчёт проблемы - resolved вроде через dbus с внешним миром работает, поэтому можешь попробовать запустить busctl monitor и посмотреть, что там происходит в момент когда dns с линка пропадает.

anonymous
()
Ответ на: комментарий от Sunderland93

Вообще поставить можно, и он нормально работает (как обёртка над networkd может быть удобно). Но да, анон перегрелся, видимо, и у него теперь везде netplan.

anonymous
()
Ответ на: комментарий от anonymous

Никакой дхцп-клиент к делу отношения не имеет, эникей.

Теоретически может иметь. В сети полно обсуждений проблем, вызванных тем, что dhcp* регулярно конфликтуют с настройками, добавляемыми, например, различными VPN соединениями.

Приходится придумывать тонкий баланс между systemd-resolved, dhcp*, и VPN, или действовать ломом типа chattr +i /etc/resolv.conf.

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

Теоретически может иметь.

Нет, не может. Он там увидел «динамическая конфигурация» и триггернулся на это. Вот дхцп это не та динамика, о которой я говорил и для которой нужен nm.

В сети полно обсуждений проблем, вызванных тем, что dhcp* регулярно конфликтуют с настройками, добавляемыми, например, различными VPN соединениями.

Это не относится к случаю resolved - там они именно добавляются, причём не глобально, а на линки. Как посмотреть, что происходит в ОП я написал выше.

anonymous
()
Ответ на: комментарий от anonymous

Вот дхцп это не та динамика, о которой я говорил и для которой нужен nm.

Ну так пиши нормально: «динамическая конфигурация DNS». Потому что изговняканный DHCP-клиентом DNS — классика. BTW, где ты вообще в NM увидел какую-то особенно динамическую конфигурацию DNS?

anonymous
()
Ответ на: комментарий от anonymous

Если нужна предсказуемая конфигурация сети, то на хосте не должно быть: resolvconf, конфигурялок VPN в обход штатных средств, более одного DHCP-клиента.

Каких штатных средств? Все ведь разрабатывают кто в лес, кто по дрова.

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

Chiffchaff
()
Ответ на: комментарий от Chiffchaff

Никакой большой головоломки. systemd-resolved/systemd-networkd как раз и были сделаны, чтобы у тебя всё работало с multiple vpn и различным роутингом в виде публичной и корпоративных сетей с их различными dns-ами. Обмазываться хуками к dhclient, конечно, можно до сих пор, но совершенно не нужно.

Dimez ★★★★★
()
Последнее исправление: Dimez (всего исправлений: 1)
Ответ на: комментарий от anonymous

Ну так пиши нормально: «динамическая конфигурация DNS».

Зачем мне это писать, если это не относится к тому, о чём я говорил?

Потому что изговняканный DHCP-клиентом DNS — классика.

Классика фантазий. Я уже писал выше о том, что к resolved эта классика не относится.

BTW, где ты вообще в NM увидел какую-то особенно динамическую конфигурацию DNS?

Нигде. И никакой особенной конфигурации днс в nm нет.

anonymous
()
Ответ на: комментарий от Chiffchaff

Каких штатных средств?

Которые используются на данном хосте. Неважно, NM, networkd или кучка скриптов.

dhclient

ISC DHCP client? Его надо либо настроить, либо удалить. Иначе он тебе и маршрутов наделает, и resolv.conf перепишет.

Для разрешения имён в соответствии с сетевым интерфейсом удобно использовать resolved. По Docker не могу ничего сказать, но скорее всего тоже несложно решается.

anonymous
()
Ответ на: комментарий от anonymous

Посмотрел через busctl - хз, вроде ничего подозрительного https://nextcloud.sunderland93.ru/s/momCLEp7kG88Yza

Кстати, если это важно - у меня установлен dbus-broker, вместо обычного dbus

Sunderland93 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Ты не поверишь, но именно в нем и оказалось дело! Удалил пакет dhcpcd5 - и все, DNS записи не слетают больше. Судя по всему реально конфликт был с NM. Так что проблема решена, всем спасибо

Sunderland93 ★★★★★
() автор топика
Ответ на: комментарий от Sunderland93

вроде ничего подозрительного

Как минимум есть это:

‣ Type=method_call  Endian=l  Flags=4  Version=1 Cookie=2  Timestamp="Mon 2025-07-28 15:49:32.225069 UTC"
  Sender=:1.5187  Destination=org.freedesktop.resolve1  Path=/org/freedesktop/resolve1  Interface=org.freedesktop.resolve1.Manager  Member=RevertLink
  UniqueName=:1.5187
  MESSAGE "i" {
          INT32 2;
  };

Что конкретно такое revert link искать лень, но названием похоже на искомое. И далее это:

‣ Type=signal  Endian=l  Flags=1  Version=1 Cookie=30  Timestamp="Mon 2025-07-28 15:49:32.225406 UTC"
  Sender=:1.2702  Path=/org/freedesktop/resolve1  Interface=org.freedesktop.DBus.Properties  Member=PropertiesChanged
  UniqueName=:1.2702
  MESSAGE "sa{sv}as" {
          STRING "org.freedesktop.resolve1.Manager";
          ARRAY "{sv}" {
                  DICT_ENTRY "sv" {
                          STRING "DNS";
                          VARIANT "a(iiay)" {
                                  ARRAY "(iiay)" {
                                  };
                          };
                  };
          };
          ARRAY "s" {
          };
  };

Но если решилось без поисков - то не актуально.

anonymous
()