Что такое “сферы” ссылок в systemd-resolved?

Question 1

При попытке исправить проблему с DNS в ModemManager от NetworkManager на Ubuntu, я столкнулся с этой разницей в выводе systemd-resolve --status при подключении. (ping IP работает, ручное редактирование /etc/resolv.conf исправляет проблему, а установка FallbackDNS также решает проблему, но все это имеет побочные эффекты.

Работающая установка – модем PPP (Ubuntu 17.10)

Link 3 (wwp0s20u6)
      Текущие области: DNS LLMNR/IPv4 LLMNR/IPv6
       Настройка LLMNR: да
Настройка MulticastDNS: нет
      Настройка DNSSEC: нет
    Поддержка DNSSEC: нет
         DNS-серверы: 198.142.0.51
                      211.29.132.12

Неисправная установка – модем PPP (то же оборудование – Lubuntu 17.04)

Link 2 (wwp0s20u6)
      Текущие области: LLMNR/IPv4 LLMNR/IPv6
       Настройка LLMNR: да
Настройка MulticastDNS: нет
      Настройка DNSSEC: нет
    Поддержка DNSSEC: нет

Это обе версии Ubuntu и идентичное оборудование. Конфигурации сетевых подключений в /etc/NetworkManager/system-connections также идентичны.

На соединениях с DHCP, таких как Ethernet и Wi-Fi адаптеры, область DNS добавляется к ссылке, и DNS работает правильно на обеих машинах. например:

Неисправная установка – работающий Wi-Fi адаптер

Link 3 (wlan0)
      Текущие области: DNS LLMNR/IPv4 LLMNR/IPv6
       Настройка LLMNR: да
Настройка MulticastDNS: нет
      Настройка DNSSEC: нет
    Поддержка DNSSEC: нет
         DNS-серверы: 192.168.0.1

Итак, я предполагаю, что проблема не в systemd-resolved самом по себе, а в чем-то, что говорит systemd-resolved, что он должен искать DNS.

Что такое “Scopes” в systemd?

Почему одна машина назначает область “DNS”, а другая нет?

Question 2

systemd-resolve – это интерфейс для сервиса systemd-resolved, который описывает себя как “менеджер разрешения сетевых имен”. systemd-resolved.service настраивается в /etc/systemd/resolved.conf. Этот файл может содержать опцию DNS=, которая должна иметь в качестве значения список адресов DNS-серверов. Если эта опция отсутствует, используется /etc/resolv.conf.

/etc/resolv.conf в свою очередь может быть символической ссылкой на /run/systemd/resolve/resolv.conf, который поддерживается самим systemd-resolved, или /etc/resolv.conf может быть создан каким-либо другим приложением независимо от systemd-resolved.

Моя догадка заключается в том, что на вашем Lubuntu не хватает записи DNS= в /etc/systemd/resolved.conf, а /etc/resolv.conf отсутствует или не содержит записей DNS-серверов.

LLMNR (RFC 4794) расшифровывается как “Link-Local Multicast Name Resolution” и является альтернативой DNS для разрешения имен. LLMNR не имеет центральной службы, но каждый хост отвечает собственными адресами, когда запрос на соответствующее имя отправляется как многоадресный датаграмм по локальной сети. Как следует из названия, LLMNR ограничен локальной сетью; он имеет область link-local. Конкурирующим протоколом LLMNR является Multicast DNS (RFC 6762).

Question 3

У меня был тот же вопрос.
Теперь используется resolvectl вместо systemd-resolve.
resolvectl – это клиент для демона systemd-resolved.
resolvectl дает такой же вывод, как systemd-resolve.
Что касается “Текущие области:”. Она может содержать
три слова “DNS”, “mDNS”, “LLMNR”.

“Текущие области:” находятся внутри секции для каждого интерфейса.
“Текущие области:” не существует в глобальной секции.

Если у нас есть “Текущие области: mDNS” в секции “Link 2 (enp3s0)”, это означает, что systemd-resolved будет принимать
mDNS трафик на интерфейсе enp0s3 и отвечать. Четко сказано, что трафик является

  IP 224.0.0.251 UDP 5353

Также это означает, что systemd-resolved будет делать mDNS запросы через интерфейс enp0s3 в сеть.

Если у нас есть “Текущие области: DNS”, это означает, что мы указали DNS-серверы для интерфейса в этой секции. Например

  Link 3 (wlp2s0)
  Текущие области: DNS
  DNS-серверы: 8.8.8.8 8.8.4.4 192.168.211.142

Что это фактически значит на практике? Это довольно сложно.
Чтобы сделать объяснение более простым и ясным, предположим, что у нас есть только один интерфейс на компьютере.
systemd-resolved всегда имеет общую секцию и секцию для каждого интерфейса.

Слово “DNS” в строке “Текущие области:” имеет совершенно
другой смысл, чем слово “mDNS”. Прежде всего, это не означает, что systemd-resolved будет отвечать на DNS-запросы, поступающие на интерфейс enp0s3. Во-вторых, systemd-resolved будет делать DNS-запросы через enp0s3 независимо от того, есть ли “DNS” в строке или нет.

Хорошо. Мы можем указать DNS-сервер в общей секции (через /etc/systemd/resolved.conf или через /etc/systemd/resolved.conf.d/*.conf) например так

$ cat /etc/systemd/resolved.conf/global.conf

[Resolve]
DNS=1.1.1.1
FallbackDNS=8.8.8.8

Это даст

Общий
  Текущий DNS-сервер: 1.1.1.1
         DNS-серверы: 1.1.1.1
Резервные DNS-серверы: 8.8.8.8

Также мы можем указать DNS-сервер в секции для интерфейса
с помощью утилиты resolvectl (к сожалению, невозможно
установить IP DNS для интерфейса через конфигурационные файлы systemd-resolved, это можно сделать через конфигурационные файлы systemd-networkd, но это другая история)

# resolvectl dns enp0s3 12.12.12.12

это даст вывод

Link 2 (enp0s3)
Текущие области: DNS
  DNS-серверы: 12.12.12.12

Когда мы устанавливаем DNS для интерфейса, мы включаем “DNS” в строке “Текущие области:”

Итак, у нас есть вывод (я даю укороченный вывод, чтобы снизить
решительность)

Общий
   ...
    Текущий DNS-сервер: 8.8.8.8
  
Link 2 (enp0s3)
...
Текущие области: DNS
   DNS-серверы: 12.12.12.12

Что происходит, если мы делаем DNS-запрос

# resolvectl query -y gmail.com

Будет ли он использовать 12.12.12.12 или 8.8.8.8 или, может быть, оба.
На самом деле это зависит от трех параметров:

Какова строка “DNS Domain” в общей секции?
Какова строка “DNS Domain”
в секции для интерфейса?
Что означает слово “DefaultRoute” в
секции для интерфейса?

В этом конкретном случае

Общий
...
Текущий DNS-сервер: 8.8.8.8
         DNS Domain ~.  <======

Link 2 (enp0s3)
...
    Текущие области: DNS
         Протоколы: +DefaultRoute  <======
Текущий DNS-сервер: 12.12.12.12
        DNS Domain: co.uk  <========

Если запрос “bbc.co.uk”, он будет разрешен через 12.12.12.12
Если запрос “bbc”, он будет преобразован в “bbc.co.uk”
и разрешен через 12.12.12.12
Если запрос “gogle.com”, он будет разрешен через 8.8.8.8

Если вы измените DNS Domain: на

 DNS Domain:"~."

или

DNS Domain:""

в одной из секций
или измените DefaultRoute на

-DefaultRoute

используемый DNS-сервер или серверы будут совершенно другими. Я предлагаю
изменить и проверить через

# tcpdump udp  -n -i enp0s3

Общее правило – запрос будет отправлен на DNS-серверы каждой секции (включая общую секцию), где у нас совпадает “DNS Domain:” с доменом запроса,
если у нас нет такого совпадения – запрос будет отправлен через DNS-сервер в общей секции и на DNS-сервер в секции с флагом +DefaultRoute. “DNS Domain: ~.” означает “каждый домен”

Я думаю, что systemd-resolved имеет неуклюжую, запутанную логику работы и большую, но плохую документацию.

Что касается значения “LLMNR” в Scopes. Я не проводил никаких исследований.

Question 4

Что такое “Scopes” в systemd?

Код и документация systemd-resolve к сожалению непоследовательны в терминах “Scope” и “Protocol”, используя их несколько взаимозаменяемо, даже когда смысл немного отличается.

На заметку, на момент systemd 256, systemd-resolve --status сообщает следующее для ссылки:

Link 4 (wlp2s0)
    Текущие области: DNS LLMNR/IPv4 LLMNR/IPv6
         Протоколы: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Текущий DNS-сервер: 1.1.1.2
       DNS-серверы: 1.1.1.2 1.0.0.2 2606:4700:4700::1112 2606:4700:4700::1002
        DNS Domain: home

Согласно systemd-resolve --status от ОП, похоже, что в то время флаги конфигурации “Протоколы” сообщались отдельно, а не в одной строке.

Значение строк “Текущая область” и “Протоколы” скрыто в документации интерфейса D-Bus systemd-resolved resolve1:

Последние [Протоколы] раскрывают то, что настроено для использования на интерфейсе, первые [Текущие области] раскрывают то, что фактически используется на интерфейсе, принимая во внимание возможности интерфейса.

Что касается “Областей”, также отмечается, что “любой интерфейс, который включен и имеет IP-адрес, подходит для DNS” и аналогичным образом для LLMNR и mDNS, когда интерфейс поддерживает мультикаст.

systemd-resolve HOSTNAME будет сообщать ‘scope’, используемую, но называет это протоколом (resolvectl.c: print_source()), например:

% systemd-resolve google.com
google.com: 2404:6800:4006:804::200e           -- link: wlp2s0
            142.250.204.14                     -- link: wlp2s0

-- Информация получена через протокол DNS за 11.6мс.
-- Данные не аутентифицированы: нет; Данные были получены через локальный или зашифрованный транспорт: нет
-- Данные из: сети

Почему одна машина назначает область “DNS”, а другая нет?

Ссылка, которая не сообщает DNS в своем списке “Текущие области”, будет либо недоступна, либо не иметь “IP-адреса, подходящего для DNS”. Например, для локального Ethernet-интерфейса, который не подключен:

Link 2 (enp1s0f0)
    Текущие области: нет
         Протоколы: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported

Что такое “сферы” ссылок в systemd-resolved?

Вопрос или проблема

Ответ или решение

Что такое Link "Scopes"?

Почему на одном устройстве указано "DNS", а на другом – нет?

Итог