Ubuntu 18.04 systemd-разрешенная ошибка NXDOMAIN

Я установил Ubuntu 18.04, и системный журнал показывает мне следующую ошибку:

systemd-resolved: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

Что это означает, и как я разрешаю эти сообщения об ошибках?

6
задан 5 February 2019 в 12:48

5 ответов

Самый короткий и самый простой ответ - это:

Эти 'ошибки' в Вашем системном журнале сгенерированы в результате обходного решения, определенного в 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' поведение запроса.

9
ответ дан 23 November 2019 в 07:18

Хотя это не фактическая ошибка, если Вы хотите, чтобы эти сообщения остановились, можно изменить цель, на которую указывает/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

5
ответ дан 23 November 2019 в 07:18

Как был указан, ошибка NXDOMAIN не является Вашей проблемой, но она может вызвать Ubuntu 18.04 по умолчанию (18.10?) установка для сбоя на определенных запросах DNS как pop3.comcast.net (см., systemd-разрешенные ошибки панели запуска имеют проблемы, когда ответ составляет более чем 512 байтов с EDNS, отключенным, и systemd-разрешенным не может разрешить адреса почтового сервера Comcast, простая фиксация должна установить пакет libnss-твердости, который изменяет/etc/nsswitch.conf файл для лучше обработки ситуации.

3
ответ дан 23 November 2019 в 07:18

Прибывая немного поздно к этой стороне. Имел это всплывающее окно ошибки/проблемы когда я "непрокомментированный" UseDNS no в /etc/ssh/sshd_conf. Примечание к комментарию, что я присоединил к этому изменению чтения,

отключите разрешение имени хоста

С при прочих равных условиях, это может некоторые как "влияние" эта проблема. Пока еще, не проверили это - как в возвращении назад исходных настроек.

Надежда это помогает где-нибудь.

0
ответ дан 23 November 2019 в 07:18

Вы можете удалить большую часть этого шума, добавив одну конечную точку в этот файл конфигурации:

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 — лишь одно из них)

2
ответ дан 22 May 2020 в 20:59

Другие вопросы по тегам:

Похожие вопросы: