Unbound и systemd-resolved. Вообще для чего нужен локальный DNS резолвер в линуксе и особенно в убунте.
Немного нубский вопрос — но зачем нужен локальнй резолвер в линуксе? Разве все приложения когда резолвят адрес обращаются вначале к 127.0.0.53:53 Или тот же самый браузер сразу лезет на указанный в сетевых настройках адрес?
Как работает если используется SNAT или MASQURADE
Также как лучше и разумнее всего поменять резолвер если используется Unbound.
Или это все появилось только в SystemD и до этого резолвилось все по другому — файл host и если нет то dns который указан в сети? Или это networkmanager виноват?
glorsh66
24.03.22 19:49:17 MSK
- Ответить на это сообщение
- Ссылка
Локально? Для кеширования.
Я пользуюсь kresd, работает хорошо, но у него есть и свои заморочки.
imul ★★★★★
( 24.03.22 21:27:47 MSK )
- Ответить на это сообщение
- Ссылка
Часть политики централизации же. Ну и удобство как-никак. Я лично всегда выпиливаю systemd-resolved. Тут выбор не большой, либо ты сам занимаешься dns, либо доверяешься кому-то.
Anoxemian ★★★★★
( 24.03.22 21:41:59 MSK )
- Ответить на это сообщение
- Ссылка
systemd-resolved правильнее всего выключать штатным для него способом, выключая DNSSTubListener создав в /etc/systemd/resolved.conf.d/ файлик, например, unbound.conf c содержимым
[Resolve] DNS=127.0.0.1 DNSStubListener=no сделав новый симлинк на resolv.conf
sudo mv /etc/resolv.conf /etc/resolv.conf.backup sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf и перезапустив systemd-resolved
P.S. и да, использовать надо IMHO не локальный резолвер на каждом тазике, а централизованный для всей сети (домашней, офисной, etc) И не unbound, а blocky или даже adguardHome. последний умеет в DoH/DoT/DNSCrypt апстримы, умеет резолвить (не)нужные рекламные хосты и трекеры в блэкхол или в 127.0.0.1, что резко сокращает количество рекламы. Unbound тоже умеет, в принципе, с изолентингом, костылингом, скриптингом и зачем?
mgdz
( 25.03.22 06:37:23 MSK )
- Ответить на это сообщение
- Показать ответ
- Ссылка
Ответ на: комментарий от mgdz 25.03.22 06:37:23 MSK
пишитинг более понятинг
Shushundr ★★☆
( 25.03.22 08:02:15 MSK )
- Ответить на это сообщение
- Ссылка
Локальный резолвер нужен для того, чтобы снизить обращение к DNS-серверам, сэкономить время (не ждать, пока от DNS-сервера поступит ответ) и количество обращений к DNS-серверам в целом.
В Ubuntu это systemd-resloved
Настроить DNS в systemd-resloved можно через этот файл (необходимо будет создать самому):
vodka@vodka-PC:/tmp/firefox_autoupdate$ cat /etc/systemd/resolved.conf.d/resolved.conf DNS=192.168.1.1 8.8.8.8 FallbackDNS=8.8.8.8 1.1.1.1 #Domains= #DNSSEC=no #DNSOverTLS=no MulticastDNS=yes LLMNR=yes Cache=no-negative #CacheFromLocalhost=no DNSStubListener=yes #DNSStubListenerExtra= ReadEtcHosts=yes #ResolveUnicastSingleLabel=no Для корректной работы необходимо, чтобы resolv.conf смотрел вот на этот файл:
vodka@vodka-PC:/tmp/firefox_autoupdate$ ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 37 мар 21 13:19 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf rm /etc/resolv.conf ls -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf Далее включить systemd-resolved:
systemctl enable --now systemd-resolved Только в этом случае будет работать systemd-resolved. Содержимое resolv.conf должен выглядеть вот так (оно само формируется с помощью systemd-resolved):
vodka@vodka-PC:/tmp/firefox_autoupdate$ ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 37 мар 21 13:19 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf vodka@vodka-PC:/tmp/firefox_autoupdate$ cat /run/systemd/resolve/stub-resolv.conf nameserver 127.0.0.53 options edns0 trust-ad search . Собственно, видно, что используется локальный DNS-сервер (nameserver 127.0.0.53)
vodka@vodka-PC:/tmp/firefox_autoupdate$ systemd-resolve --statistics DNSSEC supported by current servers: no Transactions Current Transactions: 0 Total Transactions: 19442 Cache Current Cache Size: 146 Cache Hits: 9376 Cache Misses: 10136 DNSSEC Verdicts Secure: 0 Insecure: 0 Bogus: 0 Indeterminate: 0 Ну и другие опции команды systemd-resolved или resolvedctl
Также обратите внимание, что у браузеров тоже есть свой локальный DNS-кеш. Можно его выключить при наличии своего локального DNS-сервера в случае systemd-resloved: https://www.reddit.com/r/firefox/comments/oia26o/how_to_disable_dns_cache_fully/
iljuase ★★★
( 26.03.22 15:33:50 MSK )
Последнее исправление: iljuase 26.03.22 15:35:44 MSK (всего исправлений: 2)
- Ответить на это сообщение
- Ссылка
systemd-resolved (Русский)
Состояние перевода: На этой странице представлен перевод статьи systemd-resolved. Дата последней синхронизации: 11 июля 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.
systemd-resolved — служба systemd, выполняющая разрешение сетевых имён для локальных приложений посредством D-Bus, NSS-службы resolve (см. nss-resolve(8) ) или локальной слушающей DNS-заглушки на адресе 127.0.0.53 . Подробнее об использовании см. systemd-resolved(8) .
Установка
systemd-resolved входит в пакет systemd , который установлен по умолчанию.
Настройка
Настройки распознавателя можно изменить в файле /etc/systemd/resolved.conf и/или с помощью drop-in-файлов с суффиксом .conf в каталоге /etc/systemd/resolved.conf.d/ . См. resolved.conf(5) .
Для запуска systemd-resolved запустите и включите службу systemd-resolved.service .
Совет: Чтобы лучше понимать контекст выборов и переключателей, включите для systemd-resolved сохранение подробной отладочной информации по инструкции в статье systemd#Диагностика службы.
DNS
systemd-resolved может выполнять разрешение доменных имён четырьмя различными способами. Все четыре режима работы подробно описаны в руководстве systemd-resolved(8) § /ETC/RESOLV.CONF . Наиболее часто используются следующие два:
-
С файлом DNS-заглушки systemd — файл /run/systemd/resolve/stub-resolv.conf содержит указание использовать локальную заглушку (local stub) на адресе 127.0.0.53 в качестве единственного DNS-сервера, а также список доменов для поиска. Это рекомендуемый режим работы. Файл /etc/resolv.conf стоит заменить символической ссылкой на файл заглушки, чтобы все процессы использовали последний при разрешения имён:
# ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
Примечание: systemd-resolved определяет режим работы автоматически в зависимости от того, является ли /etc/resolv.conf символической ссылкой на файл заглушки или содержит адреса серверов.
Выбор DNS-серверов
Совет: Узнать, какие серверы systemd-resolved использует в данный момент, можно командой resolvectl status .
Автоматически
systemd-resolved работает «из коробки» с сетевыми менеджерами, использующими файл /etc/resolv.conf . Никаких дополнительных настроек не требуется, поскольку systemd-resolved будет автоматически обнаружен при переходе по символической ссылке /etc/resolv.conf . Во всяком случае, это работает для systemd-networkd и NetworkManager.
Тем не менее, если какой-то DHCP- или VPN-клиент настраивает сервера имён и домены поиска с помощью resolvconf (список использующих resolvconf программ приведён в статье openresolv#Пользователи), то необходимо дополнительно установить пакет systemd-resolvconf , который предоставляет символическую ссылку /usr/bin/resolvconf .
- systemd-resolved имеет ограниченный resolvconf-интерфейс и может не работать с некоторыми клиентами, подробнее см. resolvectl(1) § COMPATIBILITY WITH RESOLVCONF(8) .
- systemd-resolvconf работает только при запущенном systemd-resolved.service . Если вы не используете systemd-resolved, убедитесь, что пакет systemd-resolvconf удалён, иначе он может создать проблемы с некоторыми сетевыми программами, которые проверяют наличие исполняемого файла /usr/bin/resolvconf .
Вручную
В режиме локальной DNS-заглушки можно назначить произвольные DNS-серверы, указав их в файле resolved.conf(5) :
/etc/systemd/resolved.conf.d/dns_servers.conf
[Resolve] DNS=192.168.35.1 fd7b:d0bd:7a6e::1 Domains=~.
- Если не указать в файле resolved.conf(5) опцию Domains=~. , то systemd-resolved может использовать DNS-серверы из настроек отдельных сетевых интерфейсов, если параметр Domains=~. в них есть.
- Данная опция не повлияет на запросы доменных имён, которые совпадают с каким-то более точным поисковым доменом из настроек интерфейса — разрешение таких имён будет выполняться посредством соответствующих «интерфейсных» DNS-серверов.
Подробнее о настройках для сетевых интерфейсов см. systemd-networkd#Файлы network.
Резерв
Если systemd-resolved не получает адреса DNS-серверов от сетевого менеджера и никакие сервера не были настроены вручную, то он использует специальные зарезервированные DNS-адреса. Таким образом, разрешение доменных имён работает всегда.
Примечание: В качестве резервных используются следующие сервера: Cloudflare, Quad9 (без фильтрации и DNSSEC) и Google; сервера и их порядок определены в файле PKGBUILD пакета systemd.
Изменить адреса можно с помощью параметра FallbackDNS= в файле resolved.conf(5) , например:
/etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve] FallbackDNS=127.0.0.1 ::1
Чтобы полностью отключить функциональность резервных DNS-серверов, задайте параметр FallbackDNS без указания адреса:
/etc/systemd/resolved.conf.d/fallback_dns.conf
[Resolve] FallbackDNS=
DNSSEC
Проверка DNSSEC настраивается параметром DNSSEC= в файле resolved.conf(5) .
- DNSSEC=allow-downgrade — проверка выполняется только в том случае, если опрашиваемый сервер её поддерживает.
- DNSSEC=true — проверка выполняется всегда; если сервер не поддерживает DNSSEC, то разрешение доменных имён работать не будет. Пример:
/etc/systemd/resolved.conf.d/dnssec.conf
[Resolve] DNSSEC=true
- Если ваш DNS-сервер не поддерживает DNSSEC и вы испытываете проблемы в стандартном (используется по умолчанию) allow-downgrade-режиме (см. systemd issue 10579), попробуйте полностью отключить DNSSEC в systemd-resolved параметром DNSSEC=false .
- systemd-resolved может отключить DNSSEC после нескольких неудачных попыток выполнить проверку. Если задано значение DNSSEC=true , то разрешение имён вообще перестанет работать. См. systemd issue 9867.
Проверьте, работает ли DNSSEC, отправив запрос к домену с неправильной подписью:
$ resolvectl query sigfail.verteiltesysteme.net
sigfail.verteiltesysteme.net: resolve call failed: DNSSEC validation failed: invalid
Затем проверьте домен, подпись которого в порядке:
$ resolvectl query sigok.verteiltesysteme.net
sigok.verteiltesysteme.net: 134.91.78.139 -- Information acquired via protocol DNS in 266.3ms. -- Data is authenticated: yes
DNS over TLS
Важно: В systemd до версии 245.2-2 systemd-resolved проверяет сертификат DNS-сервера только в том случае, если он был выдан для IP-адреса сервера (что встречается довольно редко). Сертификаты без IP-адреса не проверяются, что открывает возможность для атаки «человек-посередине». См. systemd issue 9397.
DNS over TLS по умолчанию не работает. Чтобы его включить, задайте параметр DNSOverTLS= в разделе [Resolve] файла resolved.conf(5) . Чтобы включить проверку сертификата DNS вашего провайдера, добавьте соответствующее имя хоста в параметр DNS= в формате ip_адрес#имя_хоста . Например:
/etc/systemd/resolved.conf.d/dns_over_tls.conf
[Resolve] DNS=9.9.9.9#dns.quad9.net DNSOverTLS=yes
Примечание: DNS-сервер должен тоже поддерживать DNS over TLS, иначе он просто не будет отвечать на запросы.
С помощью ngrep можно проверить, работает ли DNS over TLS. В этом режиме для DNS-запросов используется порт 853 (вместо стандартного 53). По этой причине при разрешении имени с DoT команда ngrep port 53 не выдаст ничего, а команда ngrep port 853 выведет зашифрованные данные.
Wireshark позволяет более подробно изучить пакеты запросов и ответов DNS over TLS. Установить Wireshark можно с пакетами wireshark-cli и wireshark-qt .
mDNS
systemd-resolved может работать в режиме multicast DNS, причём и как распознаватель (resolver), так и как передатчик (responder).
Распознаватель выполняет разрешение имени хоста по схеме «имя_хоста.local»
mDNS будет работать для конкретного соединения только в том случае, если он включён одновременно и в глобальных настройках systemd-resolved (параметр MulticastDNS= в resolved.conf(5) ), и в настройках сетевого менеджера для данного соединения. systemd-resolved по умолчанию работает как mDNS-передатчик, но systemd-networkd и NetworkManager [1] требуют дополнительных настроек, чтобы включить этот режим для соединений:
- Для systemd-networkd — задайте параметр MulticastDNS= в разделе [Network] , а также Multicast=yes в разделе [Link] . См. systemd.network(5) .
- Для NetworkManager — задайте параметр mdns= в разделе [connection] . См. nm-settings(5) . Также необходимо включить режим mDNS для каждого сетевого интерфейса, на котором он будет использоваться: systemd-resolve —set-mdns=yes —interface=имя_интерфейса .
Примечание: Если в системе установлен Avahi, отключите или замаскируйте службы avahi-daemon.service и avahi-daemon.socket , чтобы предотвратить конфликты с systemd-resolved.
Совет: Можно задать общие настройки для всех соединений NetworkManager. Создайте файл настроек в каталоге /etc/NetworkManager/conf.d/ и задайте параметр connection.mdns= в разделе [connection] . См. NetworkManager.conf(5) .
Если вы планируете использовать mDNS при работающем межсетевом экране, не забудьте открыть UDP-порт 5353 .
LLMNR
LLMNR будет работать для конкретного соединения только в том случае, если он включён одновременно и в глобальных настройках systemd-resolved (параметр LLMNR= в resolved.conf(5) ), и в настройках сетевого менеджера для данного соединения. systemd-resolved по умолчанию работает как LLMNR-передатчик, но systemd-networkd и NetworkManager [2] требуют дополнительных настроек, чтобы включить этот режим для соединений:
- Для systemd-networkd — задайте параметр LLMNR= в разделе [Network] . См. systemd.network(5) .
- Для NetworkManager — задайте параметр llmnr= в разделе [connection] . См. nm-settings(5) .
Совет: Можно задать общие настройки для всех соединений NetworkManager. Создайте файл настроек в каталоге /etc/NetworkManager/conf.d/ и задайте параметр connection.llmnr= в разделе [connection] . См. NetworkManager.conf(5) .
Если вы планируете использовать LLMNR при работающем межсетевом экране, не забудьте открыть UDP- и TCP-порт 5355 .
Запросы
С помощью утилиты resolvectl можно отправлять запросы к DNS-серверам, а также к mDNS- или LLMNR-хостам.
Например, DNS-запрос выглядит следующим образом:
$ resolvectl query archlinux.org
archlinux.org: 2a01:4f8:172:1d86::1 138.201.81.199 -- Information acquired via protocol DNS in 48.4ms. -- Data is authenticated: no
Решение проблем
systemd-resolved не ищет в локальном домене
Иногда systemd-resolved не может выполнить поиск в локальном домене при передаче ему только имени хоста. При этом возможна ситуация, когда с формальной точки зрения всё в порядке — в соответствующем .network-файле systemd-networkd присутствуют параметры UseDomains=yes или Domains=[список_доменов] , в результате чего в файле resolv.conf , как и положено, появилась строка search [список_доменов] . Запустите networkctl status или resolvectl status , чтобы убедиться, что домены для поиска в самом деле были обнаружены и собраны.
- Отключите LLMNR, чтобы systemd-resolved начал присоединять DNS-суффиксы.
- Отредактируйте базу данных hosts в файле /etc/nsswitch.conf (например, удалите опцию [!UNAVAIL=return] после службы resolve ).
- Перейдите на использование полных доменных имён.
- Используйте файл /etc/hosts для разрешения имён.
- Используйте службу dns из библиотеки glibc вместо resolve из systemd.
systemd-resolved не выполняет разрешение имён без суффикса
Чтобы systemd-resolved выполнял разршение частичных доменных имён, добавьте параметр ResolveUnicastSingleLabel=yes в /etc/systemd/resolved.conf .
Важно: Имена, состоящие из одной метки (label), будут направляться на глобальные DNS-сервера, которые вы, вполне вероятно, не контролируете. Это поведение не соответствует стандартам и может создать риски безопасности и приватности. Подробнее см. resolved.conf(5) .
Судя по всему, это работает только с отключённым LLMNR ( LLMNR=no ).
Если вы используете systemd-networkd, то можно использовать в качестве поискового домен, предоставленный DHCP-сервером или IPv6 Router Advertisement. По умолчанию эта возможность отключена; для включения добавьте следующие строки в .network-файл сетевого интерфейса:
[DHCPv4] UseDomains=true [IPv6AcceptRA] UseDomains=yes
Проверить домены для всех интерфейсов можно командой:
$ resolvectl domain
Смотрите также
- Francisco Ros о разрешении доменных имён с systemd-resolved
- Больше примеров в руководстве resolvectl(1) § EXAMPLES
Настройка systemd-resolved для локального кэширования DNS в Debian 10
systemd-resolved — это сервис systemd для локального резолвинга DNS запросов. По сути это локальный мини DNS-сервер с поддержкой кеширования, DNSSEC и DNSOverTLS. При включенном кешировании он позволяет ускорить резолвинг DNS запросов, особенно при включенном DNSSEC.
Он полезен для уменьшения задержек резолвинга при использовании нестабильных интернет-провайдеров и при недолгих падениях DNS серверов (в пределах TTL DNS записей доменов, к которым идут запросы). Также не помешает на серверах, где идет много запросов на резолвинг имен (почтовые сервера, сервера мониторинга, сервера с большим количеством задач с запросом данных с удаленных источников).
Установка и настройка systemd-resolved
В статье настройка производится на Debian 10, но будет актуальна и для других дистрибутивов с systemd (возможно с некоторыми поправками).
Этот сервис в Debian 10 уже идет из коробки вместе с systemd (как и на многих других дистрибутивах с предустановленным systemd). Устанавливать его не нужно. И по умолчанию он обычно отключен.
Для того, чтобы резолвинг DNS в софте шел через systemd-resolved, необходимо установить libnss-resolve , плагин для механизма NSS (GNU Name Service Switch):
apt install libnss-resolve
Открываем конфиг systemd-resolved ( /etc/systemd/resolved.conf ). По умолчанию все значения закомментированы и используются дефолтные значения:
[Resolve] #DNS= #FallbackDNS= #Domains= #LLMNR=yes #MulticastDNS=yes #DNSSEC=allow-downgrade #DNSOverTLS=no #Cache=yes #DNSStubListener=yes #ReadEtcHosts=yes
Приводим конфиг примерно к такому виду:
[Resolve] DNS=8.8.8.8 8.8.4.4 1.1.1.1 1.0.0.1 FallbackDNS=80.80.80.80 80.80.81.81 64.6.64.6 64.6.65.6 #Domains= #LLMNR=yes #MulticastDNS=yes DNSSEC=no DNSOverTLS=no Cache=yes #DNSStubListener=yes #ReadEtcHosts=yes
- DNS — список основных IPv4 и IPv6 адресов DNS серверов, разделенных пробелами;
- FallbackDNS — список запасных IPv4 и IPv6 адресов DNS серверов, разделенных пробелами (будут использоваться, если основные окажутся недоступными).
DNSSEC и DNSOverTLS включаем при необходимости.
Подробнее о них и информацию по настройке остальных параметров можно посмотреть в доке:
man resolved.conf
systemctl start systemd-resolved
Проверяем статус сервиса:
systemctl status systemd-resolved
Сервис запустился и работает.
Добавляем в автозапуск при старте системы:
systemctl enable systemd-resolved
Проверить текущие настройки резолвера можно командой:
resolvectl status
Проверка кеша DNS запросов
Для проверки работы кеша можно перевести сервис в режим отладки и проверить в журнале сервиса его работу. Для этого необходимо прописать нужный параметр в файл юнита. Чтобы не трогать его напрямую, добавим параметр через drop in юнит (дополнительный юнит, который подключается в основной и добавляет/изменяет его параметры):
systemctl edit systemd-resolved
Вставляем туда следующее:
[Service] Environment=SYSTEMD_LOG_LEVEL=debug
Сохраняем и выходим. Юнит будет автоматически перезапущен.
Открываем журнал сервиса в живом режиме:
journalctl -f -u systemd-resolved
И ждем появления информации.
Вот пример двух запросов резолвинга домена:
Looking up RR for play.google.com IN A. Looking up RR for play.google.com IN AAAA. Cache miss for play.google.com IN A Transaction 41663 for scope dns on */*. Added positive unauthenticated cache entry for play.google.com IN A 268s on eth0/INET/213.133.100.100 Transaction 41663 for on scope dns on */* now complete with from network (unsigned). . Looking up RR for play.google.com IN A. Looking up RR for play.google.com IN AAAA. Positive cache hit for play.google.com IN A Transaction 53685 for on scope dns on */* now complete with from cache (unsigned).
На примере выше при первом запросе идет поиск домена. Домен в кеше не найден ( Cache miss ). Далее идет добавление полученной информации в кеш ( Added positive unauthenticated cache entry ). Тут же можно увидеть, с какого интерфейса и с какого DNS сервера взята информация о домене. При следующем запросе уже используется информация из кеша ( Positive cache hit ).
Кеш будет использоваться, пока не истечет время жизни записи в DNS (TTL).
Looking up RR for play.google.com IN A. Looking up RR for play.google.com IN AAAA. Removing cache entry for play.google.com IN A (expired 1s ago) Cache miss for play.google.com IN A Transaction 41663 for scope dns on */*. Added positive unauthenticated cache entry for play.google.com IN A 268s on eth0/INET/213.133.100.100 Transaction 41663 for on scope dns on */* now complete with from network (unsigned).
На примере выше при запросе резолвер увидел, что время жизни записи истекло, удалил значение из кеша ( Removing cache entry ), запросил свежие данные с DNS сервера и добавил их в кеш.
Статистику по кешу можно посмотреть командой:
systemd-resolve --statistics
Если вдруг Вам нужно сбросить весь кеш резолвера, то это можно сделать командой:
systemd-resolve --flush-caches
Для отключения дебага проще всего воспользоваться следующей командой:
systemctl revert systemd-resolved
Резолвинг прямых DNS запросов
Приложения, которые не используют библиотечные вызовы, а обращаются к DNS серверам напрямую (ping и прочие), не будут использовать systemd-resolved. Они будут брать днс сервера из файла /etc/resolv.conf .
Можно оставить как есть, но есть еще 2 варианта:
- Создать ссылку на /run/systemd/resolve/resolv.conf , который генерируется автоматически при изменении конфига systemd-resolved. В этом случае не нужно будет менять адреса DNS серверов в двух местах. Кеш прямых запросов в этом случае не будет работать.
- Направить все прямые DNS запросы на адрес резолвера ( 127.0.0.53 ). В этом случае будет работать кеш запросов, но нужно будет следить за тем, чтобы сервис systemd-resolved всегда был активен.
1 вариант
Забекапим стандартный resolv.conf :
mv /etc/resolv.conf /etc/resolv.conf.bkp
И в место него создадим ссылку на /run/systemd/resolve/resolv.conf :
ln -s /run/systemd/resolve/resolv.conf /etc/
Теперь софт, использующий прямые DNS запросы, будет использовать те DNS сервера, которые указаны в конфиге systemd-resolved.
2 вариант
Перед этим убедитесь, что systemd-resolved запущен и слушает адрес 127.0.0.53 на 53 порту:
netstat -anp | grep 127.0.0.53:53
Забекапим стандартный resolv.conf :
mv /etc/resolv.conf /etc/resolv.conf.bkp
И создадим новый:
echo 'nameserver 127.0.0.53' > /etc/resolv.conf
В этом случае все DNS запросы будут проходить через резолвер. Но если вдруг systemd-resolved упадет, то резолвинг не будет работать вообще. Поэтому нужно его мониторить на важных серверах.
Приложение Ж. Совместная работа systemd-resolved и dnsmasq
При установке ECSS-10 вместе с ecss-node устанавливается пакет ecss-dns-env. Он нужен для установки и конфигурации DNS-сервера dnsmasq. Кроме этого предполагается, что в системе запущен и работает штатный systemd-resolved.
В разделе приведена информация о совместной работе этих служб DNS.
Systemd-resolved
Systemd-resolved — служба systemd, выполняющая разрешение сетевых имён для локальных приложений в Ubuntu, и реализует идею так называемого split dns. То есть каждому линку в системе, будь то bond, vlan, физический интерфейс(кромe локальной петли) может быть назначен свой DNS-сервер и домен для поиска.
Если нужно определить несколько разных DNS-серверов, каждый из которых разрешает разные доменные имена одному линку, то тут systemd-resolved является не лучшим выбором. Однако это не говорит о том, что добиться результата, когда мы имеем несколько разных DNS серверов невозможно. Кроме настройки DNS-серверов для каждого отдельного интерфейса можно указать глобально DNS-сервер(серверы) и домен поиска, и это будет учитываться.
Если сетевых интерфейсов несколько, то как правило, они смотрят в разные сети. В этих сетях может быть свой DNS-сервер. Подключаясь к нему, мы получаем список DNS-серверов и домены для поиска. Поэтому при попытке подключиться к нужному домену, мы обратимся сразу к нужному DNS.
Для sytemd-resolved есть две разновидности доменов — домены маршрутизации и домены поиска. Домены поиска имеют дополнительную функцию, состоящую в том, что к запрашиваемым именам добавляется суффикс домена поиска перед разрешением имен. Например, при разрешении домена «gitlab» поиск будет выполняться как «gitlab.eltex.loc» если домен поиска «eltex.loc». Если указан только домен маршрутизации «~eltex.loc», то поиск выполнится только при указании полного имени «gitlab.eltex.loc». Существует также глобальный домен маршрутизации «~.»
Dnsmasq
Dnsmasq может быть использован в качестве альтернативного DNS-сервера, может быть установлен и сконфигурирован отдельно с заменой systemd-resolved. В статье есть пример, как настроить несколько DNS-серверов. Но с такой конфигурацией серверы DNS, указанные в netplan будут проигнорированы.
С другой стороны, в dnsmasq есть все что нужно — он позволяет кэшировать запросы, задавать несколько DNS-серверов, добавлять свои домены через conf.d. Но по факту от dnsmasq нужно только последнее и это работает. А все остальное уже реализует systemd-resolved.
Совместная работа
Dnsmasq может быть использован не только как альтернативный сервер для всей системы. Он может сосуществовать вместе с systemd-resolved. В ECSS-10 в качестве nameserver используется адрес 127.0.0.53, но он является «заглушкой», предоставляемой systemd. Эта заглушка(local stub) проксирует DNS запросы вышестоящим службам разрешения сетевых имён, настроенных в systemd-resolved. Он сам выбирает как работать с ними, в том числе кешируя запросы.
Файл /etc/resolv.conf в этом случае является символической ссылкой на /run/systemd/resolve/stub-resolv.conf, которую формирует systemd-resolved. Так же по пути /run/systemd/resolve/resolv.conf находится конфигурация уже с настоящими DNS-серверами.
При установке ecss-dns-env в dnsmasq создается конфигурация, в которой прописывается адрес 127.0.0.1. Systemd-resovled работает на 127.0.0.53. Так же при установке добавляется конфигурационный файл sytemd-resolved по пути /etc/systemd/resolved.conf.d/ecss.conf с DNS сервером 127.0.0.1 (dnsmasq) и доменом поиска ecss. Таким образом systemd знает о dnsmasq и при поиске домена ecss будет адресовать запросы именно к нему.
Примеры
Включение отладочного лога systemd-resolved
Чтобы видеть куда отправляются запросы, можно включить отладочный лог для systemd-resolved. Для этого нужно выполнить следующие шаги:
1. Открыть конфигурационный файл systemd-resolved:
sudo systemctl edit systemd-resolved.service
2. Добавить в него следующие строчки:
[Service] Environment=SYSTEMD_LOG_LEVEL=debug
3. Перезапустить сервис:
sudo systemctl restart systemd-resolved.service
4. Запустить просмотр лога в реальном времени:
journalctl -u systemd-resolved -f
Примеры работы при различных схемах
Ниже приведены примеры сценариев работы различных настройках netplan . Во всех примерах используются bond для одного интерфейса, отключается DHCP на интерфейсах, а адреса задаются статические. Никаких дополнительных правок конфигурационных файлов не требуется.
Nameservers для двух vlan-ов
Конфигурация netplan
В netplan прописываются два vlan, один смотрит в корпоративную сеть, другой во внешнюю. Конфигурация сделана так, чтобы для разрешения доменов из корпоративной сети использовался DNS сервер 172.16.0.250, а для внешней 8.8.8.8.
network: version: 2 renderer: networkd ethernets: eth0: dhcp4: no bonds: control: interfaces: - eth0 addresses: - 192.168.121.202/24 gateway4: 192.168.121.1 vlans: vlan2: id: 2 link: control addresses: - 192.168.121.2/24 nameservers: addresses: - 172.16.0.250 - 172.16.0.100 search: - eltex.loc - ngn.eltex.loc vlan3: id: 3 link: control addresses: - 172.17.0.3/24 nameservers: addresses: - 8.8.8.8 # Голбальный домен поиска search: - ~*
Применить настройки:
sudo netplan apply sudo systemctl restart systemd-networkd.service systemd-resolved.service
Статус system-resolved:
$ systemd-resolve --status Global DNS Servers: 127.0.0.1 DNS Domain: ecss DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa 168.192.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa corp d.f.ip6.arpa home internal intranet lan local private test Link 5 (vlan3) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 8.8.8.8 DNS Domain: ~. Link 4 (vlan2) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 172.16.0.250 172.16.0.100 DNS Domain: eltex.loc ngn.eltex.loc Link 3 (control) Current Scopes: none LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no Link 2 (eth0) Current Scopes: none LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no
Проверка работы dig-ом:
Запрос домена red.eltex.loc
$ dig red.eltex.loc
Ответ:
; > DiG 9.11.3-1ubuntu1.17-Ubuntu > red.eltex.loc ;; global options: +cmd ;; Got answer: ;; ->>HEADERЛог:
May 11 09:34:54 ecss1 systemd-resolved[1554]: Got DNS stub UDP query packet for id 51692 May 11 09:34:54 ecss1 systemd-resolved[1554]: Looking up RR for red.eltex.loc IN A. May 11 09:34:54 ecss1 systemd-resolved[1554]: Cache miss for red.eltex.loc IN A May 11 09:34:54 ecss1 systemd-resolved[1554]: Transaction 11021 for scope dns on vlan2/*. May 11 09:34:54 ecss1 systemd-resolved[1554]: Using feature level UDP+EDNS0 for transaction 11021. May 11 09:34:54 ecss1 systemd-resolved[1554]: Using DNS server 172.16.0.250 for transaction 11021. May 11 09:34:54 ecss1 systemd-resolved[1554]: Sending query packet with id 11021. May 11 09:34:54 ecss1 systemd-resolved[1554]: Processing query. May 11 09:34:54 ecss1 systemd-resolved[1554]: Processing incoming packet on transaction 11021. (rcode=SUCCESS) May 11 09:34:54 ecss1 systemd-resolved[1554]: Added positive unauthenticated cache entry for red.eltex.loc IN A 600s on */INET/172.16.0.250 May 11 09:34:54 ecss1 systemd-resolved[1554]: Transaction 11021 for on scope dns on vlan2/* now complete with from network (unsigned). May 11 09:34:54 ecss1 systemd-resolved[1554]: Sending response packet with id 51692 on interface 1/AF_INET. May 11 09:34:54 ecss1 systemd-resolved[1554]: Freeing transaction 11021.Из лога видно, что обращение было только к серверу 172.16.0.250, как и нужно.
Запрос домена system.restfs.ecss
$ dig system.restfs.ecss ; > DiG 9.11.3-1ubuntu1.17-Ubuntu > system.restfs.ecss ;; global options: +cmd ;; Got answer: ;; ->>HEADERЛог:
May 11 09:38:07 ecss1 systemd-resolved[1554]: Got DNS stub UDP query packet for id 61573 May 11 09:38:07 ecss1 systemd-resolved[1554]: Looking up RR for system.restfs.ecss IN A. May 11 09:38:07 ecss1 systemd-resolved[1554]: Cache miss for system.restfs.ecss IN A May 11 09:38:07 ecss1 systemd-resolved[1554]: Transaction 53763 for scope dns on */*. May 11 09:38:07 ecss1 systemd-resolved[1554]: Using feature level UDP+EDNS0 for transaction 53763. May 11 09:38:07 ecss1 systemd-resolved[1554]: Using DNS server 127.0.0.1 for transaction 53763. May 11 09:38:07 ecss1 systemd-resolved[1554]: Sending query packet with id 53763. May 11 09:38:07 ecss1 systemd-resolved[1554]: Processing query. May 11 09:38:07 ecss1 systemd-resolved[1554]: Processing incoming packet on transaction 53763. (rcode=SUCCESS) May 11 09:38:07 ecss1 systemd-resolved[1554]: Transaction 53763 for on scope dns on */* now complete with from network (unsigned). May 11 09:38:07 ecss1 systemd-resolved[1554]: Sending response packet with id 61573 on interface 1/AF_INET. May 11 09:38:07 ecss1 systemd-resolved[1554]: Freeing transaction 53763.Из лога видно, что обращение было только к серверу 127.0.0.1.
Запрос google.com
$ dig google.com ; > DiG 9.11.3-1ubuntu1.17-Ubuntu > google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADERЛог:
May 11 09:40:54 ecss1 systemd-resolved[1554]: Got DNS stub UDP query packet for id 22822 May 11 09:40:54 ecss1 systemd-resolved[1554]: Looking up RR for google.com IN A. May 11 09:40:54 ecss1 systemd-resolved[1554]: Removing cache entry for google.com IN A (expired 86s ago) May 11 09:40:54 ecss1 systemd-resolved[1554]: Cache miss for google.com IN A May 11 09:40:54 ecss1 systemd-resolved[1554]: Transaction 8415 for scope dns on vlan3/*. May 11 09:40:54 ecss1 systemd-resolved[1554]: Using feature level UDP+EDNS0 for transaction 8415. May 11 09:40:54 ecss1 systemd-resolved[1554]: Using DNS server 8.8.8.8 for transaction 8415. May 11 09:40:54 ecss1 systemd-resolved[1554]: Sending query packet with id 8415. May 11 09:40:54 ecss1 systemd-resolved[1554]: Processing query. May 11 09:40:54 ecss1 systemd-resolved[1554]: Processing incoming packet on transaction 8415. (rcode=SUCCESS) May 11 09:40:54 ecss1 systemd-resolved[1554]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:40:54 ecss1 systemd-resolved[1554]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:40:54 ecss1 systemd-resolved[1554]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:40:54 ecss1 systemd-resolved[1554]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:40:54 ecss1 systemd-resolved[1554]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:40:54 ecss1 systemd-resolved[1554]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:40:54 ecss1 systemd-resolved[1554]: Transaction 8415 for on scope dns on vlan3/* now complete with from network (unsigned). May 11 09:40:54 ecss1 systemd-resolved[1554]: Sending response packet with id 22822 on interface 1/AF_INET. May 11 09:40:54 ecss1 systemd-resolved[1554]: Freeing transaction 8415.В логе видно, что для запроса был выбран сервер 8.8.8.8. В итоге все обращения без всяких переборов идут сразу к нужному DNS серверу.
Nameservers для трех vlan
Немного измененная схема. Удалим глобальный dns сервер в conf.d systemd-resolved. Добавим vlan53 для которого зададим nameserver 127.0.0.1. Допустим, через него будет ходить SIP трафик.
Удалить глобально заданный dns сервер в conf.d systemd-resolved:
sudo rm /etc/systemd/resolved.conf.d/ecss.confКонфигурация netplan:
network: version: 2 renderer: networkd ethernets: eth0: dhcp4: no bonds: control: interfaces: - eth0 addresses: - 192.168.121.202/24 gateway4: 192.168.121.1 vlans: vlan2: id: 2 link: control addresses: - 192.168.121.2/24 nameservers: addresses: - 172.16.0.250 - 172.16.0.100 search: - eltex.loc - ngn.eltex.loc vlan3: id: 3 link: control addresses: - 172.17.0.3/24 nameservers: addresses: - 8.8.8.8 # Голбальный домен поиска search: - ~* vlan53: id: 53 link: control addresses: - 192.168.121.53/24 nameservers: addresses: - 127.0.0.1 search: - ecssПрименить настройки:
sudo netplan apply sudo systemctl restart systemd-networkd.service systemd-resolved.serviceСтатус system-resolved:
$ systemd-resolve --status Global DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa 168.192.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa corp d.f.ip6.arpa home internal intranet lan local private test Link 6 (vlan53) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 127.0.0.1 DNS Domain: ecss Link 5 (vlan3) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 8.8.8.8 DNS Domain: ~. Link 4 (vlan2) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 172.16.0.250 172.16.0.100 DNS Domain: eltex.loc ngn.eltex.loc Link 3 (control) Current Scopes: none LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no Link 2 (eth0) Current Scopes: none LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: noЗапрос red.eltex.loc:
$ dig red.eltex.loc ; > DiG 9.11.3-1ubuntu1.17-Ubuntu > red.eltex.loc ;; global options: +cmd ;; Got answer: ;; ->>HEADERЛог:
May 11 09:53:47 ecss1 systemd-resolved[1737]: Got DNS stub UDP query packet for id 44431 May 11 09:53:47 ecss1 systemd-resolved[1737]: Looking up RR for red.eltex.loc IN A. May 11 09:53:47 ecss1 systemd-resolved[1737]: Cache miss for red.eltex.loc IN A May 11 09:53:47 ecss1 systemd-resolved[1737]: Transaction 17260 for scope dns on vlan2/*. May 11 09:53:47 ecss1 systemd-resolved[1737]: Using feature level UDP+EDNS0 for transaction 17260. May 11 09:53:47 ecss1 systemd-resolved[1737]: Using DNS server 172.16.0.250 for transaction 17260. May 11 09:53:47 ecss1 systemd-resolved[1737]: Sending query packet with id 17260. May 11 09:53:47 ecss1 systemd-resolved[1737]: Processing query. May 11 09:53:47 ecss1 systemd-resolved[1737]: Processing incoming packet on transaction 17260. (rcode=SUCCESS) May 11 09:53:47 ecss1 systemd-resolved[1737]: Verified we get a response at feature level UDP+EDNS0 from DNS server 172.16.0.250. May 11 09:53:47 ecss1 systemd-resolved[1737]: Added positive unauthenticated cache entry for red.eltex.loc IN A 600s on */INET/172.16.0.250 May 11 09:53:47 ecss1 systemd-resolved[1737]: Transaction 17260 for on scope dns on vlan2/* now complete with from network (unsigned). May 11 09:53:47 ecss1 systemd-resolved[1737]: Sending response packet with id 44431 on interface 1/AF_INET. May 11 09:53:47 ecss1 systemd-resolved[1737]: Freeing transaction 17260.Из лога видно, что обращение было только к серверу 172.16.0.250, как и нужно.
Запрос домена system.restfs.ecss:
$ dig system.restfs.ecss ; > DiG 9.11.3-1ubuntu1.17-Ubuntu > system.restfs.ecss ;; global options: +cmd ;; Got answer: ;; ->>HEADERЛог:
May 11 09:54:23 ecss1 systemd-resolved[1737]: Got DNS stub UDP query packet for id 65516 May 11 09:54:23 ecss1 systemd-resolved[1737]: Looking up RR for system.restfs.ecss IN A. May 11 09:54:23 ecss1 systemd-resolved[1737]: Cache miss for system.restfs.ecss IN A May 11 09:54:23 ecss1 systemd-resolved[1737]: Transaction 49542 for scope dns on vlan53/*. May 11 09:54:23 ecss1 systemd-resolved[1737]: Using feature level UDP+EDNS0 for transaction 49542. May 11 09:54:23 ecss1 systemd-resolved[1737]: Using DNS server 127.0.0.1 for transaction 49542. May 11 09:54:23 ecss1 systemd-resolved[1737]: Sending query packet with id 49542. May 11 09:54:23 ecss1 systemd-resolved[1737]: Processing query. May 11 09:54:23 ecss1 systemd-resolved[1737]: Processing incoming packet on transaction 49542. (rcode=SUCCESS) May 11 09:54:23 ecss1 systemd-resolved[1737]: Verified we get a response at feature level UDP+EDNS0 from DNS server 127.0.0.1. May 11 09:54:23 ecss1 systemd-resolved[1737]: Transaction 49542 for on scope dns on vlan53/* now complete with from network (unsigned). May 11 09:54:23 ecss1 systemd-resolved[1737]: Sending response packet with id 65516 on interface 1/AF_INET. May 11 09:54:23 ecss1 systemd-resolved[1737]: Freeing transaction 49542.Из лога видно, что обращение было только к серверу 127.0.0.1.
Запрос google.com:
$ dig google.com ; > DiG 9.11.3-1ubuntu1.17-Ubuntu > google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADERЛог:
May 11 09:55:03 ecss1 systemd-resolved[1737]: Got DNS stub UDP query packet for id 48903 May 11 09:55:03 ecss1 systemd-resolved[1737]: Looking up RR for google.com IN A. May 11 09:55:03 ecss1 systemd-resolved[1737]: Cache miss for google.com IN A May 11 09:55:03 ecss1 systemd-resolved[1737]: Transaction 40683 for scope dns on vlan3/*. May 11 09:55:03 ecss1 systemd-resolved[1737]: Using feature level UDP+EDNS0 for transaction 40683. May 11 09:55:03 ecss1 systemd-resolved[1737]: Using DNS server 8.8.8.8 for transaction 40683. May 11 09:55:03 ecss1 systemd-resolved[1737]: Sending query packet with id 40683. May 11 09:55:03 ecss1 systemd-resolved[1737]: Processing query. May 11 09:55:04 ecss1 systemd-resolved[1737]: Processing incoming packet on transaction 40683. (rcode=SUCCESS) May 11 09:55:04 ecss1 systemd-resolved[1737]: Verified we get a response at feature level UDP+EDNS0 from DNS server 8.8.8.8. May 11 09:55:04 ecss1 systemd-resolved[1737]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:55:04 ecss1 systemd-resolved[1737]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:55:04 ecss1 systemd-resolved[1737]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:55:04 ecss1 systemd-resolved[1737]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:55:04 ecss1 systemd-resolved[1737]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:55:04 ecss1 systemd-resolved[1737]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 09:55:04 ecss1 systemd-resolved[1737]: Transaction 40683 for on scope dns on vlan3/* now complete with from network (unsigned). May 11 09:55:04 ecss1 systemd-resolved[1737]: Sending response packet with id 48903 on interface 1/AF_INET. May 11 09:55:04 ecss1 systemd-resolved[1737]: Freeing transaction 40683.В логе видно, что для запроса был выбран сервер 8.8.8.8
В итоге получилась точно такая же рабочая схема, как и в варинанте выше, только тут мы указали nameserver 127.0.0.1 для vlan-а через netpalan и исключили его из глобальной секции.
Nameservers для bond-а
ДАННЫЙ ВАРИАНТ НЕ ЯВЛЯЕТСЯ РАБОЧИМ И ИСПОЛЬЗУЕТСЯ В ПРИМЕРАХ ДЛЯ ДЕМОНСТРАЦИИ ТОГО, КАК ДЕЛАТЬ НЕЛЬЗЯ!
В данном примере показывается, почему так делать нельзя. Здесь задается для bond статический адрес, и указывается для него 2 nameserver-а. Первый — это dnsmasq, второй — DNS офисной сети. Задается два домена маршрутизации: ~ecss и ~eltex.loc. В качестве глобального DNS сервера указывается 8.8.8.8 и домен поиска ~. (т.е. для всех остальных адресов).
Удаляется глобально заданный dns сервер в conf.d systemd-resolved и задается глобальный DNS сервер на 8.8.8.8:
$ sudo rm /etc/systemd/resolved.conf.d/ecss.conf $ cat /etc/systemd/resolved.conf.d/google.conf [Resolve] DNS=8.8.8.8 Domains=~.Netplan:
network: version: 2 renderer: networkd ethernets: eth0: dhcp4: no bonds: control: nameservers: addresses: - 127.0.0.1 # dnsmasq - 172.16.0.250 search: - ecss - eltex.loc interfaces: - eth0 addresses: - 192.168.121.202/24 gateway4: 192.168.121.1Применить:
$ sudo netplan apply $ sudo systemctl restart systemd-networkd.service systemd-resolved.serviceСтатус system-resolved:
$ systemd-resolve --status Global DNS Servers: 8.8.8.8 DNS Domain: ~. DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa 168.192.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa corp d.f.ip6.arpa home internal intranet lan local private test Link 3 (control) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 127.0.0.1 172.16.0.250 DNS Domain: ~ecss ~eltex.loc Link 2 (eth0) Current Scopes: none LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: noЗапрос домена system.restfs.ecss:
$ dig system.restfs.ecss ; > DiG 9.11.3-1ubuntu1.17-Ubuntu > system.restfs.ecss ;; global options: +cmd ;; Got answer: ;; ->>HEADERЛог:
May 11 10:48:42 ecss1 systemd-resolved[644]: Got DNS stub UDP query packet for id 13970 May 11 10:48:42 ecss1 systemd-resolved[644]: Looking up RR for system.restfs.ecss IN A. May 11 10:48:42 ecss1 systemd-resolved[644]: Cache miss for system.restfs.ecss IN A May 11 10:48:42 ecss1 systemd-resolved[644]: Transaction 64740 for scope dns on control/*. May 11 10:48:42 ecss1 systemd-resolved[644]: Using feature level UDP+EDNS0 for transaction 64740. May 11 10:48:42 ecss1 systemd-resolved[644]: Using DNS server 127.0.0.1 for transaction 64740. May 11 10:48:42 ecss1 systemd-resolved[644]: Sending query packet with id 64740. May 11 10:48:42 ecss1 systemd-resolved[644]: Processing query. May 11 10:48:42 ecss1 systemd-resolved[644]: Processing incoming packet on transaction 64740. (rcode=SUCCESS) May 11 10:48:42 ecss1 systemd-resolved[644]: Verified we get a response at feature level UDP+EDNS0 from DNS server 127.0.0.1. May 11 10:48:42 ecss1 systemd-resolved[644]: Transaction 64740 for on scope dns on control/* now complete with from network (unsigned). May 11 10:48:42 ecss1 systemd-resolved[644]: Sending response packet with id 13970 on interface 1/AF_INET. May 11 10:48:42 ecss1 systemd-resolved[644]: Freeing transaction 64740Обращение ушло к 127.0.0.1, все нормально.
Запрос google.com:
$ dig google.com ; > DiG 9.11.3-1ubuntu1.17-Ubuntu > google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADERЛог:
May 11 10:50:44 ecss1 systemd-resolved[644]: Got DNS stub UDP query packet for id 41642 May 11 10:50:44 ecss1 systemd-resolved[644]: Looking up RR for google.com IN A. May 11 10:50:44 ecss1 systemd-resolved[644]: Cache miss for google.com IN A May 11 10:50:44 ecss1 systemd-resolved[644]: Transaction 51644 for scope dns on */*. May 11 10:50:44 ecss1 systemd-resolved[644]: Using feature level UDP+EDNS0 for transaction 51644. May 11 10:50:44 ecss1 systemd-resolved[644]: Using DNS server 8.8.8.8 for transaction 51644. May 11 10:50:44 ecss1 systemd-resolved[644]: Sending query packet with id 51644. May 11 10:50:44 ecss1 systemd-resolved[644]: Processing query. May 11 10:50:44 ecss1 systemd-resolved[644]: Processing incoming packet on transaction 51644. (rcode=SUCCESS) May 11 10:50:44 ecss1 systemd-resolved[644]: Verified we get a response at feature level UDP+EDNS0 from DNS server 8.8.8.8. May 11 10:50:44 ecss1 systemd-resolved[644]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 10:50:44 ecss1 systemd-resolved[644]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 10:50:44 ecss1 systemd-resolved[644]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 10:50:44 ecss1 systemd-resolved[644]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 10:50:44 ecss1 systemd-resolved[644]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 10:50:44 ecss1 systemd-resolved[644]: Added positive unauthenticated cache entry for google.com IN A 300s on */INET/8.8.8.8 May 11 10:50:44 ecss1 systemd-resolved[644]: Transaction 51644 for on scope dns on */* now complete with from network (unsigned). May 11 10:50:44 ecss1 systemd-resolved[644]: Sending response packet with id 41642 on interface 1/AF_INET. May 11 10:50:44 ecss1 systemd-resolved[644]: Freeing transaction 51644.Снова все отлично, запрос ушел к 8.8.8.8.
Запрос red.eltex.loc:
$ dig red.eltex.loc ; > DiG 9.11.3-1ubuntu1.17-Ubuntu > red.eltex.loc ;; global options: +cmd ;; Got answer: ;; ->>HEADERЛог:
May 11 10:51:35 ecss1 systemd-resolved[644]: Got DNS stub UDP query packet for id 62383 May 11 10:51:35 ecss1 systemd-resolved[644]: Looking up RR for red.eltex.loc IN A. May 11 10:51:35 ecss1 systemd-resolved[644]: Cache miss for red.eltex.loc IN A May 11 10:51:35 ecss1 systemd-resolved[644]: Transaction 44104 for scope dns on control/*. May 11 10:51:35 ecss1 systemd-resolved[644]: Using feature level UDP+EDNS0 for transaction 44104. May 11 10:51:35 ecss1 systemd-resolved[644]: Using DNS server 127.0.0.1 for transaction 44104. May 11 10:51:35 ecss1 systemd-resolved[644]: Sending query packet with id 44104. May 11 10:51:35 ecss1 systemd-resolved[644]: Processing query. May 11 10:51:35 ecss1 systemd-resolved[644]: Processing incoming packet on transaction 44104. (rcode=REFUSED) May 11 10:51:35 ecss1 systemd-resolved[644]: Server returned REFUSED, switching servers, and retrying. May 11 10:51:35 ecss1 systemd-resolved[644]: Retrying transaction 44104. May 11 10:51:35 ecss1 systemd-resolved[644]: Switching to DNS server 172.16.0.250 for interface control. May 11 10:51:35 ecss1 systemd-resolved[644]: Cache miss for red.eltex.loc IN A May 11 10:51:35 ecss1 systemd-resolved[644]: Transaction 44104 for scope dns on control/*. May 11 10:51:35 ecss1 systemd-resolved[644]: Using feature level UDP+EDNS0 for transaction 44104. May 11 10:51:35 ecss1 systemd-resolved[644]: Using DNS server 172.16.0.250 for transaction 44104. May 11 10:51:35 ecss1 systemd-resolved[644]: Sending query packet with id 44104. May 11 10:51:35 ecss1 systemd-resolved[644]: Processing incoming packet on transaction 44104. (rcode=SUCCESS) May 11 10:51:35 ecss1 systemd-resolved[644]: Verified we get a response at feature level UDP+EDNS0 from DNS server 172.16.0.250. May 11 10:51:35 ecss1 systemd-resolved[644]: Added positive unauthenticated cache entry for red.eltex.loc IN A 600s on */INET/172.16.0.250 May 11 10:51:35 ecss1 systemd-resolved[644]: Transaction 44104 for on scope dns on control/* now complete with from network (unsigned). May 11 10:51:35 ecss1 systemd-resolved[644]: Sending response packet with id 62383 on interface 1/AF_INET. May 11 10:51:35 ecss1 systemd-resolved[644]: Freeing transaction 44104.Видно, что-systemd сначала выбрал сервер 127.0.0.1, получил от него ответ REFUSED, затем выбрал второй сервер 172.16.0.250 в списке namerser-ов bond-а который и отдал ответ.
И теперь снова запрос system.restfs.ecss:
$ dig system.restfs.ecssА ответа нет:
; > DiG 9.11.3-1ubuntu1.17-Ubuntu > system.restfs.ecss ;; global options: +cmd ;; Got answer: ;; ->>HEADERЛог:
May 11 10:54:25 ecss1 systemd-resolved[644]: Got DNS stub UDP query packet for id 38877 May 11 10:54:25 ecss1 systemd-resolved[644]: Looking up RR for system.restfs.ecss IN A. May 11 10:54:25 ecss1 systemd-resolved[644]: Cache miss for system.restfs.ecss IN A May 11 10:54:25 ecss1 systemd-resolved[644]: Transaction 13078 for scope dns on control/*. May 11 10:54:25 ecss1 systemd-resolved[644]: Using feature level UDP+EDNS0 for transaction 13078. May 11 10:54:25 ecss1 systemd-resolved[644]: Using DNS server 172.16.0.250 for transaction 13078. May 11 10:54:25 ecss1 systemd-resolved[644]: Sending query packet with id 13078. May 11 10:54:25 ecss1 systemd-resolved[644]: Processing query. May 11 10:54:25 ecss1 systemd-resolved[644]: Processing incoming packet on transaction 13078. (rcode=NXDOMAIN) May 11 10:54:25 ecss1 systemd-resolved[644]: Server returned error NXDOMAIN in EDNS0 mode, retrying transaction with reduced feature level UDP (DVE-2018-0001 mitigation) May 11 10:54:25 ecss1 systemd-resolved[644]: Retrying transaction 13078. May 11 10:54:25 ecss1 systemd-resolved[644]: Cache miss for system.restfs.ecss IN A May 11 10:54:25 ecss1 systemd-resolved[644]: Transaction 13078 for scope dns on control/*. May 11 10:54:25 ecss1 systemd-resolved[644]: Using feature level UDP for transaction 13078. May 11 10:54:25 ecss1 systemd-resolved[644]: Sending query packet with id 13078. May 11 10:54:25 ecss1 systemd-resolved[644]: Processing incoming packet on transaction 13078. (rcode=NXDOMAIN) May 11 10:54:25 ecss1 systemd-resolved[644]: Added NXDOMAIN cache entry for system.restfs.ecss IN ANY 7200s May 11 10:54:25 ecss1 systemd-resolved[644]: Transaction 13078 for on scope dns on control/* now complete with from network (unsigned). May 11 10:54:25 ecss1 systemd-resolved[644]: Sending response packet with id 38877 on interface 1/AF_INET. May 11 10:54:25 ecss1 systemd-resolved[644]: Freeing transaction 13078.Что произошло: systemd-resolved запомнил предыдущий выбор dns сервера для данного интрейфейса и теперь обращается к нему.
172.16.0.250 ничего не знает о записях в домене ecss и отвечает на это дело NXDOMAIN. Для systemd-resolved это означает конец поиска, он больше не будет пытаться использовать другие сервера.В итоге получилась сломанная схема которая отрабатывает ровно один раз.
Таким образом становится понятно, что для одного линка допустимо указывать только dns сервера, которые содержат одинаковые записи.