Прикладной уровень: что нужно для полноценной работы?

Повторение: systemctl enable --now systemd-networkd

• Для того, чтобы в машине включился net.ipv6.conf.all.forwarding:

/etc/systemd/networkd.conf:

[Network]
IPv6Forwarding=yes

DNS

TODO dig с sed-ом заменить на nslookup

Проблема адресации vs. именование:

• человеческая: как запомнить произвольный IP
• топологическая: IP-адрес согласован с топологией/маршрутизацией в сети, а имя должно зависеть от его хозяина
• административная: у большого хозяина много совсем разных адресов, и наоборот, два похожих адреса могут принадлежать разным хозяевам

Вариант решения: /etc/hosts

• Например:

  [root@srv ~]# cat /etc/hosts
  ::1       localhost
  2a00:f480:8:4f0::1        srv.class.altlinux.org srv
  2a00:f480:8:4f0::2        client.class.altlinux.org client

Чуть менее ручной вариант: локальный анонс соответствия собственного имени IP-адресу

• Например, с помощью avahi — см. далее

Масштабируемое решение: DNS

• Домены и поддомены. Корневые серверы DNS

• Рекурсивные и прямые запросы

  • Эскалация по известным DNS-серверам до корневого сервера
  • Деэскалация до прямого ответственного за домен
  • Ограничение на рекурсивные запросы (только своим клиентам, например)

• Прямое и обратное преобразование

• Использование dig: -t и -x

• DNS как иерархическая БД:

  • Типы записей (SOA, NS, A, AAAA, MX, PTR, CNAME, SRV, SVCB, TXT) Типы_ресурсных_записей_DNS

    • В TXT можно хранить что угодно (base64 чего угодно как минимум)

    • Более того, во всей базе можно хранить что угодно: см. со слайда 7

  • Авторитетный DNS сервер отвечает только за содержимое собственного домена:
    • Имена → IP-адреса (в рамках домена)
    • IP-адреса → имена (в рамках делегированного диапазона адресов)
      • Могут не совпадать / не иметь обратного резолвинга
      • Топологическая природа поддомена обратного резолвинга:

        [root@srv ~]# dig -x 2a00:f480::3 | sed -nE '/A[B-Z]+ SECTION:/,/^$/p'
        ;; ANSWER SECTION:
        3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.4.f.0.0.a.2.ip6.arpa. 7037 IN PTR cmc.msu.net.
        
        [root@srv ~]# dig -t SOA 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.4.f.0.0.a.2.ip6.arpa. | sed -nE '/A[B-Z]+ SECTION:/,/^$/p'
        ;; AUTHORITY SECTION:
        0.8.4.f.0.0.a.2.ip6.arpa. 899   IN      SOA     ns.msu.net. noc.msu.net. 2019120600 10800 900 864000 86400

    • Адреса DNS-серверов всех прямых поддоменов
• Неавторитетное кеширование и авторитетное дублирование (ускорение и повышение надёжности)
• Локальное присутствие популярных узлов как ускоритель другого типа

  • rfc7706 — зеркалирование корневых зон у провайдера (TODO: Obsoleted by RFC 8806)

  • AS112

  • 8.8.8.8, 1.1.1.1, 9.9.9.9 и им подобных

Поддержка в ОС

TODO Можно ли доверять VBox-овому DNS вида …::3 при условии, что дальше ipv6 работает

TODO Настроить выделенную виртуалку, которая ходит к 10.0.2.3:53 от VBox-а на eth0, а отдаёт на fe80::3%eth1

Статическая таблица резолвинга: /etc/resolv.conf

• API входит в glibc, т. е. есть почти всегда

• проблема динамической перегенерации; resolvconf (в образе эта служба насильно остановлена)

Множественные пространства имён и /etc/nsswitch.conf

Динамическая таблица резолвинга и systemd-resolved

• resolved может работать мелким кеширующим DNS-ретранслятором (например, он слушает на IPv4-адресе 127.0.0.53:53)

• обновление статической таблицы
• Использование:

  [root@srv ~]# systemctl enable --now systemd-resolved
  [root@srv ~]# resolvectl
  …
  [root@srv ~]# resolvectl query ww.ru
  …
  [root@srv ~]# ss -ltpn
  …
  [root@srv ~]# dig ww.ru @127.0.0.53
  …

• enable --now — это одновременно и старт сервиса, и пометка о его постоянном старте при будущих загрузках

Если пользоваться resolved, вместо файла /etc/resolv.conf надо подкладывать символьную ссылку на генерат, который resolved сам контролирует:

[root@srv ~]# ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
[root@srv ~]# ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Apr 13 19:22 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

• В ALT (и в образе) есть сервис altlinux-simpleresolv.service, который переписывает /etc/resolv.conf при каждом обновлении /run/systemd/resolve/resolv.conf (при соблюдении некоторых условий)

DNS-серверы: Крупные (обслуживают корневые DNS-сервера)

• BIND (Internet Systems Consortium): B, C, E, F, G, I, K, M

• NSD (NLnet_Labs): A, D, E, H, J, K

• KNOT: B, K, L

(Кстати, все три сервера — open source)

• Cloudflare — F

• Verisign ATLAS — J

Мелкие:

• Dnsmasq (он же и DHCP), см. лекцию 2022 года)

• Встроенный в resolved (😄)

• …тысячи их

Настройка systemd-resolved как мелкого DNS-сервера

Вообще-то systemd-resolved предназначен для отслеживания пространств имён. Но его можно заставить работать DNS-сервером!

Файл /etc/systemd/resolved.conf:

[Resolve]
DNSStubListener=no
DNSStubListenerExtra=::

• Поведение по умолчанию — слушать только на 127.0.0.53:53 — надо отключить, иначе на нуль-адрес нельзя забиндиться

• Умеет ходить в /etc/hosts

• Умеет рассказывать нужную информацию systemd-networkd (разберёмся дальше)

Всё, что мы напишем в /etc/hosts, можно опросить у DNS:

• Можно добавить адрес srv и попробовать dig srv @::1 — должно заработать.

Чтобы стандартный механизм /etc/nsswitch.conf ходил сразу к resolved (а не по 53 порту), надо использовать nss-resolve.html

Автоматическая настройка на клиенте

Настройка маршрутизатора systemd-networkd

В сообщениях RA можно указывать опции RDNSS и DNSSL — соответственно адрес резолвера и search domains.

Пример (всё, кроме DNS, уже было в прошлой главе)

[root@router ~]# /etc/systemd/network/55-prefix-downstream.network
[Match]
Name=eth1 # куда будут уходить RA

[Network]
IPv6SendRA=yes
# It is expected that the host is acting as a router. So, usually it is not
# necessary to receive Router Advertisement from other hosts in the downstream network.
#IPv6AcceptRA=no

[IPv6SendRA]
DNS=_link_local # указать наш LL-адрес на интерфейсе, по которому уйдёт RA

[IPv6Prefix]
Prefix=2001:db8:b:cc::/64
# Значения флагов по умолчанию:
#OnLink=yes
#AddressAutoconfiguration=yes

Или явный маршрут, или Assign=yes.

Настройка клиента systemd-networkd

<унесена в предыдущую главу>

В едином контексте управления (Samba, etc.) можно при появлении адреса динамически обновлять DNS-зону, создавая связь между FQDN машины и адресом.

• rfc3007

• Запросы в виде сообщений с DNS-записями

• Всё это обмазано асимметричным шифрованием: SIG(0) (в документации BIND)

  • Публичные ключи узлов можно хранить прямо в зоне, в соответствующей записи

• nsupdate из состава bind-utils

  • получает по текстовому протоколу команды, сама общается с сервером

Анонсирование служб

• Multicast DNS — произвольное преобразование имён

  • Порт 5353

• DNS Service Discovery — анонс и обнаружение сервисов

  • DNS rfc2782: _service._proto.name TTL class SRV priority weight port target

    • dig -t srv _imaps._tcp.gmail.com

    • resolvectl service _imaps._tcp gmail.com

  • ⇒ можно применять в других системах преобразования пространств имён, например, в mDNS и т. п.

systemd-resolved и mDNS

systemd-resolved умеет в DNS-SD + mDNS

• MulticastDNS=yes в /etc/systemd/resolved.conf

• MulticastDNS=yes в соответствующем .network-файле (секция [Network])

Можно анонсировать, например, ssh:

[root@srv ~]# cat /etc/systemd/dnssd/sshd.dnssd 
[Service]
Name=%H
Type=_ssh._tcp
Port=22

И тогда: resolvectl service srv._ssh._tcp.local

Avahi

Zeroconf как идея и Avahi как реализация конкретно mDNS/DNS-SD

На соседней виртуалке (на основной этим уже занимается resolved)

• активируем сервис

• avahi-browse -alt (-alr) и avahi-publish

  • Пример: /etc/avahi/services/ssh.service

• Проблема семантики анонсов

• libnss-mdns для nsswitch

• Посмотреть tcpdump анонса

Д/З

TODO