Как запросы поиска с одной меткой DNS обрабатываются с помощью systemd-resolved?
zsh сохраняет позицию курсора в переменной CURSOR так:
paste-from-clipboard ()
{
CLIPOUT=`xclip -o`
BUFFER=$LBUFFER$CLIPOUT$RBUFFER
CURSOR=$(( $CURSOR + ${#CLIPOUT} ))
}
Объяснять этот вопрос очень долго. Краткое (неточное )описание::
Куда будут направляться одиночные -запросы на поиск метки?
Один ярлык? (, а не localhostи др.):Всегда в систему LLMNR.
Мульти -ярлык? :На DNS-серверы каждого интерфейса. При сбое (или если не настроено ), на глобальные DNS-серверы.
Да, общая последовательность действий такая, как описано в systemd -resolve.service (8)НО:
Routing of lookups may be influenced by configuring per-interface domain names. See systemd.network(5) for details.
Устанавливает systemd.network (5)в качестве дополнительного ресурса для разрешения DNS.
И поймите, что Из RFC 4795:
Since LLMNR only operates on the local link, it cannot be considered a substitute for DNS.
Последовательность (упрощенная )представляет собой:
Локальное настроенное имя хоста преобразуется во все локально настроенные IP-адреса, упорядоченные по их области действия, или — если ни один не настроен — в IPv4-адрес 127.0.0.2 (, который находится в локальной петле )и IPv6-адрес ::1 (, который является локальным хостом ).
Имена хостов «localhost» и «localhost.localdomain» (и любое имя хоста, оканчивающееся на «.localhost» или «.localhost.localdomain» ), преобразуются в IP-адреса 127.0.0.1 и ::1.
Имя хоста «_gateway» преобразуется в …
Отображения, определенные в
/etc/hosts, включаются (вперед и назад ).Если имя для поиска не содержит точек(имя типа
home.содержит точку ), оно разрешается протоколом LLMNR.LLMNR queries are sent to and received on port 5355. RFC 4795
Многословные (одна точка или более )имена для некоторых доменных суффиксов (, таких как «.local», см. полный список с
systemd-resolve --status), разрешаются через протокол MulticastDNS.Имена, состоящие из нескольких слов, проверяются по списку
Domains=в systemd.network (5)на каждый интерфейс и, если совпадают, по списку DNS-серверов , которые интерфейс используется.Другие имена с несколькими метками -направляются на все локальные интерфейсы, для которых настроен DNS-сервер, а также на глобально настроенный DNS-сервер, если он есть.
#Редактировать
Название вашего вопроса гласит:
How single-label dns lookup requests are handled by systemd-resolved?
Итак, я сосредоточил свой ответ исключительно на systemd-resolved.
Теперь вы спросите:
Если интерфейс настроен с поисковым доменом «mydomain» и отключен LLMNR, будет ли какой-либо отдельный -запрос на поиск метки направляться в этот интерфейс?
Если интерфейс настроен с поисковым доменом «mydomain» и включенным LLMNR, и поступает запрос на поиск «xyz», будут ли выполняться «xyz» через LLMNR и «xyz.mydomain» через указанный DNS-сервер?
Похоже, что они находятся исключительно за пределами systemd-resolved.
Попробуем их проанализировать:
- LLMNR отключен? Как? Могу я спросить?. Путем отключения
systemd-resolvedсамого чем-то похожим наsystemctl mask systemd-resolved?
Если systemd-resolvedотключен/остановлен, LLMNR не используется (скорее всего, если только вы не установите Avahi, Apple bonjour или подобную программу )Но, конечно, это выходит за рамки systemd-resolvedконфигурация.
В этом случае мы должны спросить :, что происходит, когда разрешение имени не удается? (так как нет сервера, чтобы ответить на него ). Это , настроенный вnsswitch(файле /etc/nsswitch.conf). Конфигурация по умолчанию для Ubuntu (, поскольку Debian )содержит эту строку:
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
Что означает(на языке nsswitch):
Начните с проверки файла
/etc/hosts. Если не найдено, продолжайте.Попробуйте
mdns4_minimal(Avahi et al. ), который попытается разрешить имя через многоадресную DNS, только если оно заканчивается на.local. Если это так, но такой хост mDNS не обнаружен, mdns4 _Minimum вернет NOTFOUND.Ответом переключателя службы имен по умолчанию на NOTFOUND будет попытка использования следующей службы из списка, но запись [NOTFOUND=return] переопределяет это и останавливает поиск с неразрешенным именем. Если mdns4 _минимальный возврат UNAVAIL (не работает ), перейдите к dns.
Сюжет закручивается все хотят быть первыми в списке на разрешение имён и каждый предлагает сделать все разрешения самостоятельно.
Запись
dnsвnsswitchфактически вызываетnss-resolveсначала , которые заменяют nss -dnsnss-resolve is a plug-in module for the GNU Name Service Switch (NSS) functionality of the GNU C Library (glibc) enabling it to resolve host names via the systemd-resolved(8) local network name resolution service. It replaces the nss-dns plug-in module that traditionally resolves hostnames via DNS.
Который будет зависеть от нескольких
DOMAINS=записей в целом/etc/systemd/resolved.confи/или каждого интерфейса через/etc/systemd/networkфайлы. Это было объяснено выше записи EDIT .Имейте в виду, что sytemd -разрешенный может сам запрашивать DNS-серверы перед записью DNS в nsswitch.
Если еще не найдено (без записи
[notfound=return]), попробуйте DNS-серверы. Это произойдет более -или -менее быстро, если имя не заканчивается на.local, или вообще не произойдет, если оканчивается. Если вы удалите запись [NOTFOUND=return], nsswitch попытается найти неразрешенные.local хосты через одноадресную DNS. Как правило, это плохо, так как будет отправлено много таких запросов на DNS-серверы Интернета, которые никогда не разрешат их. Видимо, так часто бывает.Окончательный
myhostnameдействует как последний -преобразователь для localhost, hostname, *.local и некоторых других основных имен.
Еслиsystemd-resolvedимеет LLMNR=noнабор в /etc/systemd/resolved.conf, применяется тот же список, что и выше, но systemd-resolvedпо-прежнему может разрешать localhostи применять DOMAINS=настройки (глобальные или на интерфейс ).
Имейте в виду, что параметр LLMNR в systemd -разрешен, а также параметр LLMNR для -ссылки в systemd -networkd.ссылка .
#Что все это значит? Что очень трудно с уверенностью сказать, что произойдет, если только конфигурация не будет очень конкретной. вам придется отключить службы и попробовать (на вашем компьютере с вашей конфигурацией ), что произойдет.
#Q1
If an interface is configured with search domain "mydomain" and LLMNR disabled, will any single-label lookup request be routed into this interface?
Да, конечно, может . Отключение LLMNR блокирует только локальное разрешение (никаких других серверов в локальной(да :.local)сети будет запрошено ), но разрешение для этого имени должно найти ответ (даже если отрицательный ), то может(если нет NOTFOUND=return запись, например )произойдет, что DNS-серверы для соответствующего интерфейса связываются для разрешения mylocalhost.mylocaldomainкогда было запущено разрешение для mylocalhostи есть запись для mylocaldomainв "домене поиска". ответить в общем смысле почти невозможно, слишком много переменных.
#Q2
If an interface is configured with search domain "mydomain" and LLMNR enabled and a lookup request for "xyz" comes in, will "xyz" through LLMNR and "xyz.mydomain" throuth specified dns server both happen?
Нет. если все настроено правильно одно имя метки "xyz" должно разрешаться только LLMNR, и, даже если запрашивается, DNS-сервер не должен пытаться разрешить его. Ну это теория. Но система DNS должна разрешатьcom(четко, иначе сеть рухнет, как сейчас ). Но есть простой обходной путь :запросите com., у него есть точка, это полное доменное имя. В любом случае DNS-сервер должен ответитьNOERROR(с пустым A (или AAAA )), если у сервера недостаточно информации о метке, и разрешение следует продолжить с корневыми серверами (для .). Или с NXDOMAIN (лучший ответ, чтобы избежать дальнейших разрешений )для известных доменов, которые не существуют.
Единственный безопасный способ контролировать это — иметь локальный DNS-сервер и выбирать, какие имена разрешать, а какие нет.
Он будет направлен всем им с использованием как LLMNR, так и DNS, и будет использоваться первый полученный ответ.
См. эту часть справочной страницы systemd -разрешено:
If lookups are routed to multiple interfaces, the first successful response is returned (thus effectively merging the lookup zones on all matching interfaces). If the lookup failed on all interfaces, the last failing response is returned.