Search domains ubuntu что это

Обновлено: 03.07.2024

Я пытаюсь переопределить настройки сервера имен в конфигурации netplan yaml, но похоже, что это не работает. Вот файл /etc/netplan/01-netcfg.yaml:

я бегу Ubuntu 18.04.3 LTS (Я изменил IP-адрес сервера имен, но все остальное осталось прежним). Кроме того, когда я бегу netplan --debug generate , он производит это:

И действительно сбивает с толку то, что нет никаких /run/netplan каталог.

Я также должен упомянуть, что это виртуальный частный сервер, поэтому у меня нет доступа к голому железу. Не уверен, что это важно. Кроме того, я использую eth0 потому, что это единственный что появляется, когда я бегу ifconfig , кроме адреса обратной связи. Оригинал /etc/netplan/01-netcfg.yaml файл с того момента, когда я получил сервер от хостинговой компании, был:

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

РЕДАКТИРОВАТЬ Просто хотел упомянуть вывод systemd-resolve --status показывает, что DNS-серверы являются исходными, настроенными DHCP, а не теми, которые переопределены конфигурацией netplan выше. Кажется, он не принимает настройки netplan.

РЕДАКТИРОВАТЬ 2 В ответ на некоторые вопросы, опубликованные в комментариях, я считаю, что хостинговая компания установила Ubuntu Server, а не настольную установку. Насколько мне известно, я могу получить доступ к VPS только через терминал, и я не верю, что у меня есть доступ к рабочему столу с графическим интерфейсом. Что касается других вопросов, я вернулся к исходному /etc/netplan/01-netcfg.yaml файл и перезагрузил сервер. Теперь он должен вернуться к своей исходной конфигурации:

Кроме того, не похоже, что dhclient запущен, когда я ps aux | grep -i dhc . Каким образом файл /etc/netplan/01-netcfg.yaml может иметь dhcp4: yes настроен, если dhclient не запущен на машине?

Когда я бегу ip a , Я получил

А вот про enp0s3 упоминания нет. Аналогично для ifconfig команда, в ней упоминается только eth0, а не enp0s3.

Вот файл /etc/resolv.conf:

Я изменил значение nameserver выше, а также значение seach вариант.

systemd-resolve --status включает следующее в конце вывода:

где IP1, IP2 и IP3 - это три адреса IPv4, которые я бы предпочел не использовать для DNS, а domain1 - это доменное имя, которое мне также не нужно. Пожалуйста, дайте мне знать в комментариях, если можно найти другую полезную информацию. Следует ли мне настраивать статический IP-адрес в /etc/netplan/01-netcfg.yaml, поскольку dhclient не запущен? Другой вопрос, не было бы смысла использовать eth0 для сетевого устройства вместо enp0s3 , поскольку последнего нет, когда ip a запускается?

РЕДАКТИРОВАТЬ 3 Было бы полезно знать, что рассматриваемые серверы предоставляются Linode. Я отключил их Linode Network Helper, чтобы настроить свои собственные DNS-серверы. Просто подумал, что это полезная информация. Это должно быть обычное Ubuntu 18.04 сервер.

Ответ на обновление 1 - см. Ответ Хейннема

Итак, после перезагрузки с /etc/netplan/01-netcnf.yaml в виде

и /etc/systemd/resolved.conf в виде

/run/resolvconf/resolv.conf отсутствует в системе.

cat /run/systemd/resolve/resolv.conf производит:

где IP1, IP2 и IP3 соответствуют значениям в исходном выводе systemd-resolve --status .

cat /run/systemd/resolve/stub-resolv.conf производит:

Также, dpkg -l *dnsmasq* | grep ii производит:

и dpkg -l *dhcp* | grep ii производит:

Однако когда я бегу ps aux | grep dns и ps aux | grep dh , кроме самого grep, не возвращаются никакие результаты.

Редактировать 4

где IP1, IP2 и IP3 были IP-адресами сервера имен, которые мне нужно было переопределить, а domain1 было доменным именем, созданным хостинг-провайдером. Шлюз и две настройки адреса были правильными, что мне было нужно. Я просто хотел переопределить настройки DNS, поэтому переименование файла, чтобы он не использовался, помогло.

При этом часто встречаю в конфигах когда используются одновременно и никаких проблем с этим нет. DHCP так всегда добавляет оба. Собственно в чем соль?

Я думаю что это ошибка перевода. Быть может domain имеет более высокий приоритет над search? И смысла и то и то одновременно с одинаковым значением использовать видимо действительно нету.

Такой ответ подходит:

The domain and search keywords are mutually exclusive. If more than one instance of these keywords is present, the last instance wins.

Тогда не совсем ясен смысл слова domain. У меня может ведь быть:

По-крайней мере так сделает windows.

DALDON ★★★★★ ( 28.11.14 22:49:42 )
Последнее исправление: DALDON 28.11.14 22:50:01 (всего исправлений: 1)

Тогда не совсем ясен смысл слова domain.

Ключевые слова domain и search.

В ″man resolv.conf″, откуда я взял цитату, они подчёркнуты.

Вариант с переводом неверен. Вот что в английской версии:

Что сделает linux, ИМХО, вам было проще проверить, чем писать пост на ЛОР.

Упаси боже, я не топикстартер, я так, потереться начас пришёл. :)

А вот это полное УГ! Ведь через dhcp официально можно раздавать несколько search одному клиенту. Ведь зачем-то это было придуманно?

Подходит, будет работать то, что указано последним в resolv.conf. При этом если указано два то первое работать не будет, только второе. Это касается только domain и search, если указать два search или два domain то работают оба. Видимо поэтому и не стоит использовать их одновременно, так как они исключают друг друга.

если указать два search или два domain то работают оба

Еще раз — man resolv.conf. Из написанного там (и подтвержденного выше по теме) следует, что из двух (трех, десяти) хоть search, хоть domain будет учитываться только последний. Если хочется искать в нескольких зонах (до шести), то нужно указывать их в одном search через пробел.

Ваша правда, действительно работает только последний. Видимо я допустил ошибку в эксперементе. Но вопрос остается окрытым, почему нельзя использовать domain и search одновременно?

почему нельзя использовать domain и search одновременно

Потому, цитирую man resolv.conf, что

The domain and search keywords are mutually exclusive. If more than one instance of these keywords is present, the last instance wins.

То есть потому и нельзя, что работает только последний. В конфигах часто встречается (мне встречалось, во всяком случае) search и domain с одинаковым значением — так делать можно, но бессмысленно. А вот если написать, к примеру

Стало достаточно традиционным для Linux запускать небольшой локальный DNS-сервер, который ускоряет работу, кешируя ответы на повторяющиеся DNS-запросы. В этом случае в общесистемный /etc/resolv.conf помещается директива nameserver 127.0.0.1 , а ip-адреса внешних DNS-серверов переносятся в настройки локального.

При изменении сетевой конфигурации, запуске и остановке процессов, некоторым программам необходимо динамически изменять файл resolv.conf . При одновременном доступе программы мешают друг другу и сохраняют неверную информацию в файл. Утилита resolvconf действует как посредник между программами, которые предоставляют информацию о сервере имен, и программами, которые используют информацию о сервере имен.

При этом файл resolv.conf заменяется символической ссылкой на /run/resolvconf/resolv.conf и программы используют динамически сгенерированный файл. В системе без службы resolvconf.service файл resolv.conf поддерживается вручную или набором скриптов. И эти скрипты могут мешать друг другу при попытках одновременного доступа к файлу.

Всё работало хорошо, пока не появились NetworkManager и Systemd. Система инициализации Systemd имеет свой собственный резолвер systemd-resolved , запущенный по умолчанию и требующий отдельной настройки. А NetworkManager пытается дружить со всеми — с resolvconf , с Systemd , с наиболее распространёнными DNS-резолверами.

Всё это привело к тому, что теперь в одной системе порт 53 может слушать несколько разных резолверов, причём для избежания конфликтов NetworkManager и systemd-resolved используют вместо 127.0.0.1 другие ip-адреса в loopback-сети:

127.0.0.1 — dnsmasq или unbound с настройками по умолчанию
127.0.1.1 — dnsmasq или unbound , запущенный NetworkManager
127.0.0.53 — systemd-resolved , запущенный по умолчанию

Настройка службы systemd-resolved

В Ubuntu Server эта служба уже установлена и запущена сразу после установки операционной системы. Но если это не так, установить ее несложно:

Следующим шагом будет правка файла /etc/nsswitch.conf — находим строку, которая начинается с hosts :

Эта строка отвечает за последовательность обращений приложения к системным компонентам с целью резолвинга доменного имени. В данном случае сначала программа заглянет в файл /etc/hosts , затем запросит демона systemd-resolved , а потом — к DNS серверам.

Осталось сообщить systemd-resolved ip-адреса DNS-серверов, к которым следует обращаться для резолвинга:

Для целей совместимости с приложениями, которые не используют библиотечные вызовы, а обращаются к DNS-серверам напрямую, получая их ip-адреса из /etc/resolv.conf , следует создать символическую ссылку. Обычно этого не требуется, ссылка уже существует после установки systemd-resolved :

В файле /run/systemd/resolve/stub-resolv.conf указан один-единственный сервер 127.0.0.53 :

Кроме того, можно создать символическую ссылку на /run/systemd/resolve/resolv.conf . Этот файл содержит DNS-сервера, полученные от DHCP-сервера и из файла конфигурации /etc/systemd/resolved.conf . В этом случае локальный кеширующий сервер не используется, что замедлит резолвинг.

Как видите, у меня DNS-серверов получилось слишком много, так что последняя запись может быть проигнорирована. Все готово, остается только разрешить запуск службы при загрузке системы, если это еще не было сделано:

Настройка службы resolvconf.service

Служба предоставляет остальным программам централизованный интерфейс для добавления и удаления записей в /etc/resolv.conf при изменении сетевой конфигурации, запуске и остановке процессов и т.д.

После установки /etc/resolv.conf будет представлять из себя ссылку на /run/resolvconf/resolv.conf .

При этом исходный файл /etc/resolv.conf (который на самом деле ссылка на /run/systemd/resolve/resolv.conf ) будет сохранен как original в директории /etc/resolvconf/resolv.conf.d/ (чтобы восстановить его при удалении службы resolvconf.service ). В этой же директории есть есть еще три файла — base , head и tail — которые позволяют вручную добавить записи в динамически формируемый /run/resolvconf/resolv.conf .

Теперь добавим пару записей в файл tail (сервера OpenDNS):

Перезагрузим службу и посмотрим сформированный /run/resolvconf/resolv.conf :

Первая запись — это резолвер systemd-resolved , а две другие записи были добавлены в конец resolv.conf из файла tail . Благодаря тому, что первая запись это 127.0.0.53 — резолвинг будет работать быстро, потому что systemd-resolved кеширует ответы DNS-серверов.

Но если мы остановим службу systemd-resolved , резолвинг все равно будет работать, используя сервера 208.67.222.222 и 208.67.220.220 — хотя и гораздо медленнее.

Используем только resolv.conf

Так делать не рекомендуется, потому что резолвинг будет работать медленно, но рассмотрим и этот вариант для полноты картины. Первым делом изменим имя файла /etc/resolv.conf на /etc/resolv.conf.back , а потом создадим свой resolv.conf :

Для Ubuntu Desktop запретим вездесущему NetworkManager вмешиваться в процесс распознавания доменных имен:

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 .

С файлом DNS-заглушки systemd — файл /run/systemd/resolve/stub-resolv.conf содержит указание использовать локальную заглушку (local stub) на адресе 127.0.0.53 в качестве единственного DNS-сервера, а также список доменов для поиска. Это рекомендуемый режим работы. Файл /etc/resolv.conf стоит заменить символической ссылкой на файл заглушки, чтобы все процессы использовали последний при разрешения имён:
С файлом resolv.conf — systemd-resolved работает с файлом /etc/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.

Вручную

В режиме локальной DNS-заглушки можно назначить произвольные DNS-серверы, указав их в файле resolved.conf(5) :

. , то systemd-resolved может использовать DNS-серверы из настроек отдельных сетевых интерфейсов, если параметр Domains=

Резерв

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

Примечание: В качестве резервных используются следующие сервера: Cloudflare, Quad9 (без фильтрации и DNSSEC) и Google; сервера и их порядок определены в файле PKGBUILD пакета systemd.

Изменить адреса можно с помощью параметра FallbackDNS= в файле resolved.conf(5) , например:

Чтобы полностью отключить функциональность резервных DNS-серверов, задайте параметр FallbackDNS без указания адреса:

DNSSEC

Проверка DNSSEC настраивается параметром DNSSEC= в файле resolved.conf(5) .

DNSSEC=allow-downgrade — проверка выполняется только в том случае, если опрашиваемый сервер её поддерживает.
DNSSEC=true — проверка выполняется всегда; если сервер не поддерживает DNSSEC, то разрешение доменных имён работать не будет. Пример:

Если ваш DNS-сервер не поддерживает DNSSEC и вы испытываете проблемы в стандартном (используется по умолчанию) allow-downgrade-режиме (см. systemd issue 10579), попробуйте полностью отключить DNSSEC в systemd-resolved параметром DNSSEC=false .
systemd-resolved может отключить DNSSEC после нескольких неудачных попыток выполнить проверку. Если задано значение DNSSEC=true , то разрешение имён вообще перестанет работать. См. systemd issue 9867.

Проверьте, работает ли DNSSEC, отправив запрос к домену с неправильной подписью:

Затем проверьте домен, подпись которого в порядке:

DNS over TLS

Важно: В systemd до версии 245.2-2 systemd-resolved проверяет сертификат DNS-сервера только в том случае, если он был выдан для IP-адреса сервера (что встречается довольно редко). Сертификаты без IP-адреса не проверяются, что открывает возможность для атаки "человек-посередине". См. systemd issue 9397. Примечание: DNS-сервер должен тоже поддерживать DNS over TLS, иначе он просто не будет отвечать на запросы.

С помощью ngrep можно проверить, работает ли DNS over TLS. В этом режиме для DNS-запросов используется порт 853 (вместо стандартного 53). По этой причине при разрешении имени с DoT команда ngrep port 53 не выдаст ничего, а команда ngrep port 853 выведет зашифрованные данные.

systemd-resolved может работать в режиме multicast DNS, причём и как распознаватель (resolver), так и как передатчик (responder).

Распознаватель выполняет разрешение имени хоста по схеме "имя_хоста.local"

mDNS будет работать для конкретного соединения только в том случае, если он включён одновременно и в глобальных настройках systemd-resolved (параметр MulticastDNS= в resolved.conf(5) ), и в настройках сетевого менеджера для данного соединения. systemd-resolved по умолчанию работает как mDNS-передатчик, но systemd-networkd и NetworkManager [1] требуют дополнительных настроек, чтобы включить этот режим для соединений:

Примечание: Если в системе установлен 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] требуют дополнительных настроек, чтобы включить этот режим для соединений:

Совет: Можно задать общие настройки для всех соединений NetworkManager. Создайте файл настроек в каталоге /etc/NetworkManager/conf.d/ и задайте параметр connection.llmnr= в разделе [connection] . См. NetworkManager.conf(5) .

Если вы планируете использовать LLMNR при работающем межсетевом экране, не забудьте открыть UDP- и TCP-порт 5355 .

Запросы

С помощью утилиты resolvectl можно отправлять запросы к DNS-серверам, а также к mDNS- или LLMNR-хостам.

Например, DNS-запрос выглядит следующим образом:

Решение проблем

systemd-resolved не ищет в локальном домене

Отключите 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) .

Судя по всему, это работает только с отключённым LLMR ( LLMR=no ).

Как добавить дополнительные DNS-поисковые домены в сетевое соединение, настроенное с помощью DHCP?

В более поздних версиях Ubuntu Network Manager позволяет добавлять дополнительные поисковые домены и DNS-серверы, все еще используя значения из DHCP.

Нажмите индикатор Network Manager и выберите Edit Connections . Выберите подключение, которое вы хотите настроить, и нажмите «Изменить». В зависимости от типа подключения вам может потребоваться переключить вкладки. В диалоговом окне «Редактирование» перейдите на вкладку «Параметры IPv4» (или вкладку «Параметры IPv6», если вы используете IPv6). Оставьте его в автоматическом режиме (DHCP). Просто заполните поле Дополняемые домены с разделенным запятыми списком доменов и нажмите «Сохранить». Возможно, вам придется отключить и снова подключиться.

Он работает с 16.04 LTS, и мне пришлось отключиться и снова подключиться. – Rudy Vissers 15 May 2017 в 13:23

в ubuntu 11.10 отредактируйте файл /etc/dhcp/dhclient.conf и добавьте эту строку

append domain-name "domain.com";

Затем перезапустите свою сеть.

в ubuntu 11.10 отредактируйте файл /etc/dhcp/dhclient.conf и добавьте эту строку

Затем перезагрузите сеть.

Нажмите на индикатор Network Manager и выберите Изменить соединения . Выберите подключение, которое вы хотите настроить, и нажмите Изменить . В зависимости от типа соединения вам может потребоваться переключить вкладки.
В диалоговом окне «Редактирование» перейдите на вкладку IPv4 Settings (или Настройки IPv6 , если вы используете IPv6).
Оставьте его установленным в Автоматическим (DHCP) . Просто заполните поле Дополнительные области поиска с разделенным запятыми списком доменов и нажмите Сохранить .
Возможно, вам придется отключить и снова подключиться.

Попробуйте ниже в этом случае, когда пользователи получают ip-адрес с сервера dhcp, он получает mulitple dns servers

вариант local-wpad code 252 = текст;

option domain-name -servers 10.0.0.15, 8.8.8.8, 192.168.1.1;

опция смещение по времени 0

Вот полное решение, которое работает, по крайней мере, с 12.04 :

(вы также можете использовать sudo -e /etc/dhcp/dhclient.conf , если вы доверяете редактору по умолчанию )

Если вы находитесь в какой-либо «профессиональной» сети с собственными DNS-серверами и / или если вы настроили свой собственный DNS-сервис (ы) в указанной сети, а также на своей рабочей станции, то вам также может понадобиться прокомментировать эту строку:

- Это позволяет использовать ваши собственные серверы имен доменов, позволяя вашему персонализированному доменному поиску работать намного плавно, что, вероятно, лучше, чем использование того, что у кого-то еще есть для вас. Е.Г .: Я в сети 192.168.10.0; компания имеет сервер имен 192.168.10.10 и 192.168.10.11, но я запускаю собственный сервер имен с более обширным списком имен на 192.168.10.20 (который будет перенаправлен на 192.168.10.10 и .11 по мере необходимости). Все мои сетевые конфигурации объявляют 192.168.10.20 и 8.8.8.8 и 8.8.4.4 (серверы имен Google), но DHCP будет отклонять эту предпочтение, подавая мне 192.168.10.10 в качестве сервера по умолчанию. В конце концов, не запрашивая эти аспекты из DHCP, вы значительно улучшите сетевой ресурс.

Читайте также: