Options edns0 trust ad что это
Перейти к содержимому

Options edns0 trust ad что это

  • автор:

Форум русскоязычного сообщества Ubuntu

Страница сгенерирована за 0.037 секунд. Запросов: 26.

  • Сайт
  • Об Ubuntu
  • Скачать Ubuntu
  • Семейство Ubuntu
  • Новости
  • Форум
  • Помощь
  • Правила
  • Документация
  • Пользовательская документация
  • Официальная документация
  • Семейство Ubuntu
  • Материалы для загрузки
  • Совместимость с оборудованием
  • RSS лента
  • Сообщество
  • Наши проекты
  • Местные сообщества
  • Перевод Ubuntu
  • Тестирование
  • RSS лента

© 2012 Ubuntu-ru — Русскоязычное сообщество Ubuntu Linux.
© 2012 Canonical Ltd. Ubuntu и Canonical являются зарегистрированными торговыми знаками Canonical Ltd.

Options edns0 trust ad что это

bug

Provided by: manpages-ru_4.21.0-2_all

ИМЯ
resolv.conf - файл настройки для процедур определения имён (resolver)
СИНТАКСИС
ОПИСАНИЕ
The resolver is a set of routines in the C library that provide access to the Internet Domain Name System (DNS). The resolver configuration file contains information that is read by the resolver routines the first time they are invoked by a process. The file is designed to be human readable and contains a list of keywords with values that provide various types of resolver information. The configuration file is considered a trusted source of DNS information; see the trust-ad option below for details. If this file does not exist, only the name server on the local machine will be queried, and the search list contains the local domain name determined from the hostname. Поддерживаются следующие параметры настройки: nameserver IP-адрес сервера имён Задает интернет-адрес сервера имён, на который надо переправлять все запросы, или в виде адреса IPv4 (в точечном формате), или в виде адреса IPv6 в формате с двоеточиями (и, возможно, точками), определённом в RFC 2373. Может быть указано до MAXNS (в настоящее время 3, см. ) серверов имён, повторяя каждый раз ключевое слово. Если указано несколько серверов, функции разрешения имён будут обращаться к серверам имен в порядке перечисления. Если в файле нет строк nameserver, то функции разрешения имён используют сервер имён на локальной машине. (Функции разрешения имён работают по следующему алгоритму: попробовать обратиться к первому указанному серверу имён. Если нет ответа в отведённое время, попробовать обратиться к следующему серверу, и т.д. пока не будет исчерпан список серверов.) search список поиска By default, the search list contains one entry, the local domain name. It is determined from the local hostname returned by gethostname(2); the local domain name is taken to be everything after the first '.'. Finally, if the hostname does not contain a '.', the root domain is assumed as the local domain name. This may be changed by listing the desired domain search path following the search keyword with spaces or tabs separating the names. Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found. For environments with multiple subdomains please read options ndots:n below to avoid man-in-the-middle attacks and unnecessary traffic for the root-dns-servers. Note that this process may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is available for one of the domains. If there are multiple search directives, only the search list from the last instance is used. В glibc 2.25 и старее список поиска может содержать не более шести доменов и не может быть длиннее 256 символов. Начиная с glibc 2.26 список поиска безграничен. The domain directive is an obsolete name for the search directive that handles one search list entry only. sortlist Вызывает сортировку адресов, возвращаемых функцией gethostbyname(3). Список сортировки задается в виде пар IP-адрес/маска сети. Маску сети указывать не обязательно — по умолчанию используется естественная маска сети. IP-адрес и необязательная маска сети разделяются косой чертой. В списке можно указывать до 10 пар. Пример: sortlist 130.155.160.0/255.255.240.0 130.155.0.0 options С помощью параметров изменяются некоторые внутренние переменные функций определения имён. Синтаксис options параметр . где параметр может иметь следующие значения: debug Задаёт RES_DEBUG в _res.options (только, если glibc собрана с поддержкой отладки; смотрите resolver(3)). ndots:n Задаёт минимальное количество точек, которые должны обязательно присутствовать в имени, переданном функции res_query(3) (см. resolver(3)) прежде чем будет выполнен начальный абсолютный запрос. По умолчанию n равно 1, поэтому если в имени есть точки, сначала имя пытаются разрешить как абсолютное, прежде чем добавлять к нему элементы из списка поиска. Значение этого параметра внутренне доходит до 15. timeout:n Задаёт промежуток времени, который функции определения имён будут ждать ответа от удалённого сервера имён перед тем как повторить запрос другому серверу имён. Он не может быть равным общему времени, затрачиваемым вызовом программного интерфейса определителя, и не гарантируется, что один вызов программного интерфейса определителя соответствует одному промежутку. Измеряется в секундах, по умолчанию RES_TIMEOUT (в настоящее время равно 5, смотрите ). Значение этого параметра внутренне доходит до 30. attempts:n Задаёт количество раз, которое функции определения имён будут посылать запрос серверам имён перед тем как закончить работу и вернуть ошибку вызывавшему их приложению. По умолчанию равно RES_DFLRETRY (в настоящее время 2, см. ). Значение этого параметра внутренне доходит до 5. rotate Задаёт значение RES_ROTATE в _res.options, что приводит к циклическому выбору указанных серверов имён. Это приводит к распределению нагрузки среди серверов, чтобы исключить использование каждый раз только первого сервера всеми клиентами. no-check-names Задаёт значение RES_NOCHECKNAME в _res.options, что приводит к выключению в современном BIND проверки в поступающих именах узлов и почтовых именах недопустимых символов, таких как символы подчёркивания (_), не-ASCII или управляющие символы. inet6 Задаёт значение RES_USE_INET6 в _res.options. Это приводит к выполнению запроса AAAA раньше запроса A внутри функции gethostbyname(3), и отображению ответов IPv4 в «туннелированную форму» IPv6, если записи AAAA не были обнаружены, но есть запись типа A. Начиная с glibc 2.25 этот параметр считается устаревшим; приложения должны использовать getaddrinfo(3), а не gethostbyname(3). Some programs behave strangely when this option is turned on. ip6-bytestring (since glibc 2.3.4 to glibc 2.24) Задаёт значение RES_USE_BSTRING в _res.options. Это приводит к поиску обратной записи IPv6 с помощью формата значимых битов, описанного в RFC 2673; если этот параметр не задан (по умолчанию), то используется полубайтовый формат. Данный параметр был удалён в glibc 2.25, так как он полагается на обратно несовместимое расширение DNS, которое никогда не разворачивалось в Интернете. ip6-dotint/no-ip6-dotint (glibc 2.3.4 to glibc 2.24) Clear/set RES_NOIP6DOTINT in _res.options. When this option is clear (ip6-dotint), reverse IPv6 lookups are made in the (deprecated) ip6.int zone; when this option is set (no-ip6-dotint), reverse IPv6 lookups are made in the ip6.arpa zone by default. These options are available up to glibc 2.24, where no-ip6-dotint is the default. Since ip6-dotint support long ago ceased to be available on the Internet, these options were removed in glibc 2.25. edns0 (начиная с glibc 2.6) Задаёт значение RES_USE_EDNS0 в _res.options. Включает поддержку расширений DNS, описанных в RFC 2671. single-request (начиная с glibc 2.10) Sets RES_SNGLKUP in _res.options. By default, glibc performs IPv4 and IPv6 lookups in parallel since glibc 2.9. Some appliance DNS servers cannot handle these queries properly and make the requests time out. This option disables the behavior and makes glibc perform the IPv6 and IPv4 requests sequentially (at the cost of some slowdown of the resolving process). single-request-reopen (начиная с glibc 2.9) Задаёт RES_SNGLKUPREOP в _res.options. Для разрешения имён используется единый сокет для запросов A а AAAA. Некоторая аппаратура ошибочно посылает обратно только один ответ. Когда это происходит, клиент остаётся ждать второго ответа. Указание этого параметра изменяет такое поведение так, что если два запроса с одного порта не обрабатываются правильно, то сокет будет закрыт и открыт новый перед посылкой второго запроса. no-tld-query (начиная с glibc 2.14) Задаёт значение RES_NOTLDQUERY в _res.options. Этот параметр указывает res_nsearch() не пытаться определить неполное имя как если бы это домен верхнего уровня. Данный параметр может привести к проблемам, если сайт указал «localhost» как TLD, но содержит localhost в одном или более элементах списка поиска. Данный параметр не действует, если не установлен RES_DEFNAMES или RES_DNSRCH. use-vc (начиная с glibc 2.14) Задаёт RES_USEVC в _res.options. Данный параметр включает принудительное использование TCP для запросов DNS. no-reload (начиная с glibc 2.26) Устанавливает RES_NORELOAD в _res.options. Этот параметр выключает автоматическую перезагрузку изменённого файла настройки. trust-ad (начиная с glibc 2.31) Sets RES_TRUSTAD in _res.options. This option controls the AD bit behavior of the stub resolver. If a validating resolver sets the AD bit in a response, it indicates that the data in the response was verified according to the DNSSEC protocol. In order to rely on the AD bit, the local system has to trust both the DNSSEC-validating resolver and the network path to it, which is why an explicit opt-in is required. If the trust-ad option is active, the stub resolver sets the AD bit in outgoing DNS queries (to enable AD bit support), and preserves the AD bit in responses. Without this option, the AD bit is not set in queries, and it is always removed from responses before they are returned to the application. This means that applications can trust the AD bit in responses if the trust-ad option has been set correctly. In glibc 2.30 and earlier, the AD is not set automatically in queries, and is passed through unchanged to applications in responses. Значение ключевого слова search в системном файле resolv.conf может быть изменено назначением переменной окружения для определённого процесса LOCALDOMAIN списка доменов, разделённых пробелами. Значение ключевого слова options в системном файле resolv.conf может быть дополнено назначением переменной окружения для определённого процесса RES_OPTIONS списка вышеописанных в options параметров настройки функций определения имён. Ключевое слово и значение должны быть в одной строке, и кроме того, ключевое слово(например, nameserver), должно быть в начале строки. Значение должно отделяться от ключевого слова пробельным символом. Строки, в которых в первой колонке содержится точка с запятой (;) или символ решётки (#), считаются комментариями.
ФАЙЛЫ
СМ. ТАКЖЕ
gethostbyname(3), resolver(3), host.conf(5), hosts(5), nsswitch.conf(5), hostname(7), named(8) Руководство по работе с сервером имён BIND
ПЕРЕВОД
Русский перевод этой страницы руководства был сделан aereiae aereiae@gmail.com>, Azamat Hackimov azamat.hackimov@gmail.com>, Dmitriy S. Seregin dseregin@59.ru>, Katrin Kutepova blackkatelv@gmail.com>, Lockal lockalsash@gmail.com>, Yuri Kozlov yuray@komyakino.ru>, Баринов Владимир и Иван Павлов pavia00@gmail.com> Этот перевод является бесплатной документацией; прочитайте Стандартную общественную лицензию GNU версии 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ или более позднюю, чтобы узнать об условиях авторского права. Мы не несем НИКАКОЙ ОТВЕТСТВЕННОСТИ. Если вы обнаружите ошибки в переводе этой страницы руководства, пожалуйста, отправьте электронное письмо на ⟨man-pages-ru-talks@lists.sourceforge.net⟩.

Чиним резолвинг адресов в VPN-локалке (openconnect) для docker и systemd-resolved

Для подключения к корпоративной сети у нас используется CiscoAnyConnect, работает хорошо, но не с докером. Как только докер пытается приподнять свою сеть, утилитка тут же отрубает VPN и переподключает. От этого докер себя плохо чувствует. Поэтому я решил использовать обычный линуксовый openconnect соместно с NetworkManager.

systemd-resolved

  • /run/systemd/resolve/stub-resolv.conf это опция по умолчанию и этот файл будет содержать примерно такое
    nameserver 127.0.0.53
    options edns0 trust-ad
    search somedomain.local
  • /run/systemd/resolve/resolv.conf это можно использовать если функционал systemd-resolved чем то не устроил когда он прикидывается DNS сервером 127.0.0.53. В итоге это не пригодилось, так для информации пишу.

docker

Теперь в хост системе работает резолвинг адресов, но при запуске докера резолвинг локальных адресов в VPN может не работать по прежнему. И тут есть несколько вариантов.
Контейнер запущен с network_mode: host в таком случае будет использоваться для резольвинга то, что лежит в /run/systemd/resolve/resolv.conf и там у меня первый же днс сервер выбирается для резольва local и он для этого не подходит. Итог, не работает. Зато все сервисы хост машины видно из контейнера, что еще и неправильно.
Контейнер запущен с network_mode: bridge с созданием отдельной сети. В таком случае сервисы хоста будет не видно, помимо этого будет использован все тот же не работающий у меня /run/systemd/resolve/resolv.conf
Контейнер запущен без настроек сети и использует дефолтный bridge, созданный докером при инсталляции (docker0). В этом случае используется для резольва имен внутренний докеровский DNS, который судя по всему нормально взаимодействует с systemd-resolved и все резолвит как надо. В /etc/resolv.conf будет такое:
bash-5.0# cat /etc/resolv.conf
search local
nameserver 127.0.0.11
options ndots:0

Если надо показать сервисы хост машины для доступа из контейнера, то просто запускаем сервисы слушать на docker0 IP и получаем доступ.
ifconfig|grep -n1 docker0
27-
28:docker0: flags=4099 mtu 1500
29- inet 192.168.32.1 netmask 255.255.240.0 broadcast 192.168.47.255

Не забываем открыть порты, например у меня ufw зарезал 8080 и пришлось открывать.
Было бы отлично если бы docker просто использовал systemd-resolved dns stub как в последнем описанном варианте всегда. Но к сожалению это не так. В версии systemd-resolved 248, которая только вышла и в дистрах ее нет в документации есть параметр DNSStubListenerExtra, который может задать адрес где слушать для stub. Подробности тут
В итоге можно будет указать адрес где слушать не захардкоженный 127.0.0.53, а доступный изнутри докера и все будет работать, но пока нет.
Есть другое решение, когда контейнер пойдет на порт 53 мы будем перебрасывать его запросы в стаб systemd с помощью чего то вроде
socat UDP-LISTEN:53,fork,reuseaddr,bind=yourInterfaceIP UDP:127.0.0.53:53
Соответственно, этот DNS можно указать докеру при старте и весь функционал systemd будет работать. Но не стал это использовать.
В итоге мы получаем работающий VPN на хосте, который резолвит имена в локалной сети, работающий докер, который может резолвить эти адреса как родные.

Не работает dns

Пингую ping 8.8.8.8 — пинги проходят, а если ping google.com, то получаю ответ:

ping: google.com: Temporary failure in name resolution

В файл /etc/resolve.conf я вместо значения по-умолчанию поставил 8.8.8.8. Перезагрузил командой:

sudo systemctl restart systemd-resolved.service

paa66
18.02.23 19:46:06 MSK

  • Ответить на это сообщение
  • Ссылка

Покажи этот самый /etc/resolve.conf

urxvt ★★★★★
( 18.02.23 19:58:31 MSK )

  • Ответить на это сообщение
  • Показать ответ
  • Ссылка

koxoho4192
( 18.02.23 20:07:26 MSK )

  • Ответить на это сообщение
  • Показать ответы
  • Ссылка

Ответ на: комментарий от koxoho4192 18.02.23 20:07:26 MSK

Скор набиваешь нерелевантными сообщениями? Не надо.

Dimez ★★★★★
( 18.02.23 20:17:27 MSK )

  • Ответить на это сообщение
  • Ссылка

  1. /etc/resolve.conf не существует. Это твой злой вымысел.
  2. Если используется systemd-resolved в качестве резолвера, то конфиг ему писать надо в /etc/systemd/resolved.conf

Grapow ★
( 18.02.23 20:23:25 MSK )

  • Ответить на это сообщение
  • Показать ответ
  • Ссылка

Ответ на: комментарий от urxvt 18.02.23 19:58:31 MSK

При таком resolve.conf пинги идут на 8.8.8.8 и не идут на google.com:

nameserver 127.0.0.53 options edns0 trust-ad search .

Это значение по-умолчанию.

paa66
( 18.02.23 20:30:55 MSK ) автор топика

  • Ответить на это сообщение
  • Показать ответы
  • Ссылка

Ответ на: комментарий от koxoho4192 18.02.23 20:07:26 MSK
paa66
( 18.02.23 20:34:05 MSK ) автор топика

  • Ответить на это сообщение
  • Ссылка

Ответ на: комментарий от paa66 18.02.23 20:30:55 MSK

Файл называется правильно resolv.conf, в современных системах он является символьной ссылкой на файл, который наполняется systemd-resolved или networkmanager`ом.

Удали ссылку, пропиши туда строку с указанием dns от Гугл.

kostik87 ★★★★★
( 18.02.23 20:36:30 MSK )

  • Ответить на это сообщение
  • Ссылка

Ответ на: комментарий от paa66 18.02.23 20:30:55 MSK

Это адрес systemd-resolved. Проверяй, почему он не работает. Выше тебе написали, где его конфиг.

shell-script ★★★★★
( 18.02.23 20:43:24 MSK )

  • Ответить на это сообщение
  • Ссылка

Ответ на: комментарий от Grapow 18.02.23 20:23:25 MSK

В файл /etc/systemd/resolved.conf записал по аналогии с /etc/resolved.conf следующее:

[code]nameserver 8.8.8.8 options edns0 trust-ad search .[/code]

sudo systemctl restart systemd-resolved.service

paa66
( 18.02.23 20:43:40 MSK ) автор топика

  • Ответить на это сообщение
  • Показать ответы
  • Ссылка

Ответ на: комментарий от paa66 18.02.23 20:43:40 MSK

Можно, наверное, попробовать почитать, прежде чем что-то делать и жаловаться, что не работает.

kravzo ★★
( 18.02.23 20:47:47 MSK )

  • Ответить на это сообщение
  • Ссылка

Ответ на: комментарий от paa66 18.02.23 20:43:40 MSK

Повторяю ещё раз, система для разрешения имён использует информацию указанную в файле resolv.conf, сейчас он является символьной ссылкой. И наполнением файлов занимается либо systemd-resolved, либо networkmanager.

Перезапуск systemd-resolved приводит к тому, что он перезаписывает твои правки.

Если ты хочешь использовать dns от Гугл.

То удали символьную ссылку /etc/resolv.conf, создай файл и пропиши в него указание dns от Гугл.

kostik87 ★★★★★
( 18.02.23 20:53:57 MSK )

  • Ответить на это сообщение
  • Показать ответы
  • Ссылка

Ответ на: комментарий от kostik87 18.02.23 20:53:57 MSK

Зачем это, если можно настроить systemd-resolved?

kravzo ★★
( 18.02.23 20:58:04 MSK )

  • Ответить на это сообщение
  • Показать ответ
  • Ссылка

Ответ на: комментарий от kravzo 18.02.23 20:58:04 MSK

А зачем он нужен, зачем лишняя сущность? Его вообще можно остановить.

kostik87 ★★★★★
( 18.02.23 21:02:27 MSK )
Последнее исправление: kostik87 18.02.23 21:05:57 MSK (всего исправлений: 1)

  • Ответить на это сообщение
  • Ссылка

Ответ на: комментарий от kostik87 18.02.23 20:53:57 MSK

Нет, не всё. /etc/resolv.conf нужен только для приложений без поддержки nsswitch, systemd-resolved перехватит DNS-запрос еще раньше, см. /etc/nsswitch.conf , строка hosts: .

ValdikSS ★★★★★
( 18.02.23 21:06:14 MSK )

  • Ответить на это сообщение
  • Ссылка

Ответ на: комментарий от kostik87 18.02.23 20:53:57 MSK

Переименовал /etc/@resolve.conf в @resolve.conf.old. Создал файл /etc/resolve.conf, в нём прописал:

nameserver 8.8.8.8 options edns0 trust-ad search .

sudo systemctl restart systemd-resolved.service

paa66
( 18.02.23 21:14:26 MSK ) автор топика

  • Ответить на это сообщение
  • Показать ответы
  • Ссылка

Ответ на: комментарий от paa66 18.02.23 21:14:26 MSK
kostik87 ★★★★★
( 18.02.23 21:16:01 MSK )

  • Ответить на это сообщение
  • Показать ответы
  • Ссылка

Ответ на: комментарий от paa66 18.02.23 21:14:26 MSK

Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: missing Link 2 (eth1) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported DNS Servers: 8.8.8.8

paa66
( 18.02.23 21:16:31 MSK ) автор топика

  • Ответить на это сообщение
  • Ссылка

Ответ на: комментарий от kostik87 18.02.23 21:16:01 MSK

Что не так сделал?

paa66
( 18.02.23 21:17:36 MSK ) автор топика

  • Ответить на это сообщение
  • Ссылка

Ответ на: комментарий от kostik87 18.02.23 21:16:01 MSK
paa66
( 18.02.23 21:30:17 MSK ) автор топика

  • Ответить на это сообщение
  • Ссылка

Сеть-то у тебя через какой демон настроена и дистрибутив какой?

ls -l /etc/resolv.conf cat /etc/resolv.conf sudo systemctl list-units --type service --all | grep -i -e net -e resolv cat /etc/*release*

Vsevolod-linuxoid ★★★★★
( 18.02.23 22:08:56 MSK )

  • Ответить на это сообщение
  • Показать ответ
  • Ссылка

Ответ на: комментарий от Vsevolod-linuxoid 18.02.23 22:08:56 MSK

ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 39 Jan 21 15:52 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf cat /etc/resolv.conf # This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8). # Do not edit. # # This file might be symlinked as /etc/resolv.conf. If you're looking at # /etc/resolv.conf and seeing this text, you have followed the symlink. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run "resolvectl status" to see details about the uplink DNS servers # currently in use. # # Third party programs should typically not access this file directly, but only # through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a # different way, replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 options edns0 trust-ad search . sudo systemctl list-units --type service --all | grep -i -e net -e resolv netplan-ovs-cleanup.service loaded inactive dead OpenVSwitch configuration for cleanup networkd-dispatcher.service loaded active running Dispatcher daemon for systemd-networkd ● NetworkManager.service not-found inactive dead NetworkManager.service systemd-networkd-wait-online.service loaded inactive dead Wait for Network to be Configured systemd-networkd.service loaded active running Network Configuration systemd-resolved.service loaded active running Network Name Resolution systemd-timesyncd.service loaded inactive dead Network Time Synchronization cat /etc/*release* DISTRIB_ID=Ubuntu DISTRIB_RELEASE=22.04 DISTRIB_CODENAME=jammy DISTRIB_DESCRIPTION="Ubuntu 22.04.1 LTS" PRETTY_NAME="Ubuntu 22.04.1 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.1 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=jammy

Все эти настройки по-умолчанию, какие были изначально. Я потом вносил изменения, но откатил обратно.

paa66
( 18.02.23 22:36:57 MSK ) автор топика
Последнее исправление: paa66 18.02.23 22:38:32 MSK (всего исправлений: 1)

  • Ответить на это сообщение
  • Показать ответ
  • Ссылка

Ответ на: комментарий от paa66 18.02.23 22:36:57 MSK

sudo resolvectl status покажи

Vsevolod-linuxoid ★★★★★
( 18.02.23 22:38:33 MSK )
Последнее исправление: Vsevolod-linuxoid 18.02.23 22:38:40 MSK (всего исправлений: 1)

  • Ответить на это сообщение
  • Показать ответ
  • Ссылка

Ответ на: комментарий от Vsevolod-linuxoid 18.02.23 22:38:33 MSK

resolvectl status Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (eth1) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 8.8.8.8 DNS Servers: 8.8.8.8

paa66
( 18.02.23 22:39:37 MSK ) автор топика

  • Ответить на это сообщение
  • Показать ответ
  • Ссылка

Ответ на: комментарий от paa66 18.02.23 22:39:37 MSK

Хм… странно… указан 8.8.8.8, а пинги на него идут, с твоих слов…

ls -l /etc/netplan/ cat /etc/netplan/*

Vsevolod-linuxoid ★★★★★
( 18.02.23 22:41:18 MSK )

  • Ответить на это сообщение
  • Показать ответы
  • Ссылка
Похожие публикации:
  1. Fe разработчик что это
  2. Focus visible css как убрать
  3. В чем разница языков программирования
  4. Как открыть файл vvd в blender

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *