Я установил Ubuntu 18.04, и системный журнал показывает мне следующую ошибку:
systemd-resolved: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
Что это означает, и как я разрешаю эти сообщения об ошибках?
Самый короткий и самый простой ответ - это:
Эти 'ошибки' в Вашем системном журнале сгенерированы в результате обходного решения, определенного в DVE-2018-0001, указав, что система пытается смягчить дальнейшие случаи DVE-2018-0001 нарушений путем повторения того же запроса без расширений EDNS. Это не указывает на ошибку, которую сами можно зафиксировать, и при этом это не означает, что существует что-либо для фиксации в этом случае.
Это просто указывает что systemd-resolved
сервис пытается повторить тот же запрос, чтобы попытаться предотвратить дальнейшие проблемы DVE-2018-0001, который может быть вызван присоединенными порталами, не поддерживающими расширения EDNS0.
Нет никаких дальнейших действий, необходимых Вам в этом случае, это - больше 'информационной' информации, предоставленной системному журналу systemd-resolved
.
Однако..., если Вы хотите знать немного больше о том, что точно продолжается здесь, затем продолжает читать далее, я предоставляю сводку этого и некоторых данных в качестве примера, чтобы показать Вам точно, что продолжается негласно этих сообщений.
Детали (если Вы хотите считать их):
Ошибка, которую Вы видите, не является на самом деле сообщением об ошибке, на которое необходимо реагировать, и оператор "Сервера возвратился, ошибка" вводит в заблуждение. Скорее это - уведомление, что мы следуем за обходным решением, определенным в Нарушении DNS DVE-2018-0001.
Это - пример самого журнала от моего компьютера здесь:
Feb 5 13:29:17 overlord systemd-resolved[857]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
На DVE-2018-0001 было обнаружено что в Ubuntu 17.10 и позже:
При попытке соединиться и авторизовать с присоединенным порталом по securelogin.arubanetworks.com, в какой-то момент этому не удается решить правильно, и таким образом пользователям не удается передать присоединенную портала авторизацию и Интернет доступа.
Далее, это продолжает объяснять проблему:
Первоначально это было отчетами о средстве отслеживания ошибки Ubuntu в https://bugs.launchpad.net/ubuntu / + source/systemd / + ошибка/1727237
Это могло бы быть ошибкой в Ubuntu/systemd-resolved и/или securelogin.arubanetworks.com спуфинг/захват DNS и/или оба.
От захвата пакетов кажется, что запрос DNS с EDNS0 ДЕЛАЕТ (DNSSEC хорошо) набор битов для обнуления, на отвечают с NXDOMAIN.
На запросы без EDNS0, отвечают с корректным портала IP-адресом.
То, что это означает, - то, что существуют определенные ответы, идущие в присоединенные порталы здесь, которые правильно не поддерживают запросы EDNS0; и что это должно быть скорректировано производителями.
Текущее обходное решение, реализованное в systemd-resolved
в рамках Ubuntu то, что генерирует информационные сообщения, которые Вы видите. Это в сочетании с предложенным обходным решением в DVE (акцент полужирного текста и форматирование простого текста для названий команды, и коды/ответы являются моими):
В
systemd-resolved
, при выполнении поиска доменных имен с 'безопасным' в них и полученияNXDOMAIN
ответ, повторите снова без EDNS0.
Это поэтому - то, что Ваши сообщения указывают, но с более широким покрытием. А именно, когда запрос DNS регистрируется, и Вы добираетесь NXDOMAIN
ответ от поиска DNS, мы хотим удостовериться, что мы не поражаем эту проблему EDNS0; поэтому, systemd-resolved
делает попытку поиска DNS снова, но без расширений EDNS0 - мы видим это в моем сервере имен Bind9, который обрабатывает все запросы на моей машине также с примером (хотя это - главный пример недомена, запрашиваемого и в свою очередь главный пример того, как это смягчение может показать себя, когда 'смягчение' на самом деле не собирается решать головную боль):
05-Feb-2019 13:29:17.976 queries: info: client @0x7f6cd400aee0 127.0.0.1#41213 (favicon.png): query: favicon.png IN A +E(0) (127.0.2.1)
05-Feb-2019 13:29:17.976 queries: info: client @0x7f6cd400aee0 127.0.0.1#41213 (favicon.png): query: favicon.png IN A + (127.0.2.1)
Как Вы видите вместо +E (0), запрос повторен без того расширения; это - 'сниженный уровень функции UDP' поведение запроса.
Хотя это не фактическая ошибка, если Вы хотите, чтобы эти сообщения остановились, можно изменить цель, на которую указывает/etc/resolv.conf символьная ссылка. По умолчанию это указывает на/run/systemd/resolve/stub-resolv.conf. Путем изменения его для указания на/run/systemd/resolve/resolv.conf не стало проблемы.
Команда, чтобы сделать это, sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
Как был указан, ошибка NXDOMAIN не является Вашей проблемой, но она может вызвать Ubuntu 18.04 по умолчанию (18.10?) установка для сбоя на определенных запросах DNS как pop3.comcast.net (см., systemd-разрешенные ошибки панели запуска имеют проблемы, когда ответ составляет более чем 512 байтов с EDNS, отключенным, и systemd-разрешенным не может разрешить адреса почтового сервера Comcast, простая фиксация должна установить пакет libnss-твердости, который изменяет/etc/nsswitch.conf файл для лучше обработки ситуации.
Прибывая немного поздно к этой стороне. Имел это всплывающее окно ошибки/проблемы когда я "непрокомментированный" UseDNS no
в /etc/ssh/sshd_conf
. Примечание к комментарию, что я присоединил к этому изменению чтения,
отключите разрешение имени хоста
С при прочих равных условиях, это может некоторые как "влияние" эта проблема. Пока еще, не проверили это - как в возвращении назад исходных настроек.
Надежда это помогает где-нибудь.
Вы можете удалить большую часть этого шума, добавив одну конечную точку в этот файл конфигурации:
diff -u -r1.1 /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
--- /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
+++ /usr/lib/NetworkManager/conf.d/20-connectivity-ubuntu.conf
@@ -1,2 +1,2 @@
[connectivity]
-uri=http://connectivity-check.ubuntu.com/
+uri=http://connectivity-check.ubuntu.com./
Конечная точка для DNS эквивалентна начальному '/' для файлов : делает любое относительное DNS-имя абсолютным. Другими словами, система останавливает поиск connectivity-check.ubuntu.com.yourlocal_domain
. это вряд ли существует (если только ваш интернет-провайдер не пытается захватить это конкретное имя).
https://askubuntu.com./
Вы можете найти другие ошибки NXDOMAIN, одновременно отслеживая эти две команды:
journalctl --boot -u systemd-resolved -f
tcpdump -i any 'port domain'
Посмотрите разницу до/после:
nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
# wait, observe
Редактируйте файл, как указано выше. , затем:
systemctl reload NetworkManager
nmcli c down "Wired connection 1"; nmcli c up "Wired connection 1"
# wait, observe
(Есть и другие имена, вызывающие NXDOMAIN, подключение-check.ubuntu.com — лишь одно из них)