Новое предупреждение продолжает отображаться: сервер возвратил ошибку NXDOMAIN, уменьшая потенциальное нарушение DNS DVE-2018-0001

Я только что установил новый Ubuntu Server 18.04. Я установил свое имя хоста, hostnamectl set-hostname ****.openbayou.bizи я установил /etc/hosts:

127.0.0.1 localhost
[ip address] ****.openbayou.biz hostname
# The following lines are desirable for IPv6 capable hosts
[ip6 address] *****.openbayou.biz hostname
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Я также установил OSSEC для отслеживания новых файлов, ошибок и изменений на моем сервере, и теперь я получаю следующие предупреждения:

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

Это сейчас повторяется:

systemd-resolved[3195]: message repeated 4 times: [ Server returned error 
NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction 
with reduced feature level UDP.]

Я искал в Интернете решение, и никто не сообщает об этой проблеме.

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

Та же самая ошибка произошла с моим настольным компьютером, я не знаю, относится ли она и к серверу.

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

Симлинк /etc/resolv.confуказал на../run/resolvconf/resolv.conf

Изменив его так, чтобы он указывал на то, /run/systemd/resolve/resolv.confчем управляет systemd, исправил это для меня.

Узнайте больше здесь .

Надеюсь, что это помогло.

Я спросил на OSSEC GitHub об этой ошибке, и они рекомендовали написать правило, игнорирующее ошибки NXDOMAIN. добавить в/var/ossec/rules/local_rules.xml

<rule id="234567" level="0">
 <program_name>systemd-resolved</program_name>
 <match>Server returned error NXDOMAIN</match>
 <description>Usless systemd-resolvd log message</description>
</rule>

Это предупреждение регистрируется systemd-resolved, когда имя не может быть разрешено системой DNS (например, nslookup www.kjfoiqaefah34876asdf.com). Это можно терпеть и нет причин для беспокойства. Это не ошибка и ничего не нужно исправлять.

Перенаправление /etc/resolv.conf в /run/systemd/resolve/resolv.conf неверно, так как этот путь пропускается systemd-resolved и приложение с ошибочным запросом DNS обращается непосредственно к серверу имен, а не к systemd-resolved заглушка больше. Таким образом, systemd-resolved больше не замечает события NXDOMAIN и, следовательно, не может больше его регистрировать.

События NXDOMAIN вызваны пакетами, которые пытаются получить доступ к несуществующим серверам во время запуска системы.

Я заметил то же самое на сервере Ubuntu 18.04, который был недавно обновлен до 18.04.1.

Похоже, что systemd-resolv регистрирует это сообщение всякий раз, когда получает ответ NXDOMAIN. В моем случае у меня работает постфикс. Поэтому я получаю много NXDOMAINS, когда подключаются случайные серверы, для которых не установлен PTR.

Вы можете проверить это с

systemd-resolve securelogin.example.com

Затем вы должны увидеть сообщение журнала.

Имея это в виду, это может показаться относительно безобидной ошибкой, и вы можете ее игнорировать.

Мое понимание после прочтения предыдущих ответов и других веб-страниц, таких как системная ошибка Ubuntu 18.04 NXDOMAIN, заключается в том, что это скорее предупреждение, чем ошибка, и я ничего не могу с этим поделать.

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

Однако, поскольку у меня их тысячи (я тоже на рабочем столе - это не сервер), я не хочу, чтобы они были в моем файле системного журнала. Поэтому, следуя https://www.rsyslog.com/doc/v8-stable/configuration/filters.html и префикс номера пары в файлах конфигурации , я добавил файл с именем 10-resolv.confодной строкой :msg, contains, "Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP" ~в каталоге /etc/rsyslog.d .

Имя 10-resolv.confне важно, но оно должно предшествовать все другие имена файлов в каталоге в алфавитном порядке. Команда :msg, contains, <message-part> ~говорит, что все сообщения, которые содержат <message-part>, должны игнорироваться: тильда ~в команде говорит, что нужно отбросить сообщение.

Примечание добавлено: так как я написал этот ответ, я установил некоторые пакеты (по другим причинам), и сообщение об ошибке больше не выдается, как проверено с journalctl -u systemd-resolved -f. Один из установленных пакетов, который может объяснить исчезновение этого сообщения, - libnss-resolv.

Резюме:

Сообщение об ошибке NXDOMAIN означает, что домен не существует.

Некоторые интернет-провайдеры начали перехват DNS или переадресацию DNS для сообщений об ошибках NXDOMAIN. Это практика перенаправления разрешения имен системы доменных имен (DNS) на другие DNS-серверы или веб-серверы.

Обычно используется для отображения рекламы или сбора статистики.

Эта практика нарушает стандарт RFC для ответов DNS (NXDOMAIN).

Фишинг: межсайтовые скриптовые атаки могут происходить из-за злонамеренного захвата.

Цензура: DNS-провайдеры блокируют доступ к отдельным доменам.

Показанный здесь: https://www.dnsknowledge.com/whatis/nxdomain-non-existent-domain-2/

Мне удалось избавиться от сообщения, и, кстати, я также смог наконец подключиться к своему серверу Samba, изменив имя сервера server.domainвместо «только» server.

Это связано с EDNS. Разница между использованием stub-resolv.confи resolv.confесть options edns0.

Механизмы расширения для DNS (EDNS) - это спецификация для расширения размера нескольких параметров протокола системы доменных имен (DNS), которые имеют ограничения по размеру, которые, по мнению сообщества разработчиков Интернета, слишком ограничены для расширения функциональных возможностей протокола.

https://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS

Более подробная информация по этому вопросу: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1766969.

Похоже, вы можете просто отключить эту «опцию».

проблема

Хотя могут быть и другие обстоятельства, при которых эта ошибка возникнет, я могу с уверенностью сказать, что я видел ее в выводе:

systemctl status systemd-resolved

... когда systemd-resolvedне настроен.

А виртуальная машина Azure Ubuntu 18.04 не имеет встроенной systemd-resolvedконфигурации (на сегодняшний день 20191008).

Решение:

Настройка systemd-resolved.

Mini systemd-resolvedConfig HowTo:

ПРИМЕЧАНИЕ . Следующие инструкции были подготовлены с использованием Ubuntu 18.04.

Отредактируйте hostsдирективу /etc/nsswitch.conf, добавив предопределение, resolveкоторое устанавливает systemd-resolved в качестве первого источника разрешения DNS, к которому будет обращаться:

hosts:          resolve files dns

Редактировать /etc/systemd/resolved.conf. Некоторые предлагаемые настройки:

[Resolve]
DNS=8.8.8.8 8.8.4.4
#FallbackDNS=
#Domains=
#LLMNR=no
#MulticastDNS=no
#DNSSEC=no
Cache=yes
DNSStubListener=yes

Перезагрузка systemd-resolved:

sudo systemctl restart systemd-resolved

Когда вы будете в следующий раз проверять systemd-resolvedстатус, теперь ошибка должна быть очищена:

systemctl status systemd-resolved

И разрешение DNS теперь должно вести себя ожидаемым образом.