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

Я спросил относительно GitHub OSSEC об этой ошибке, и они рекомендовали писать правило проигнорировать ошибки 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>

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

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

Можно протестировать его с

systemd-resolve securelogin.example.com

Затем необходимо видеть, что сообщение журнала появляется.

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

Я смог избавиться от сообщения, и по тому, как я также смог наконец соединиться со своим сервером самбы путем изменения имени сервера на server.domain вместо только server.

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

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

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

Сводка:

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

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

Наиболее часто используемый для отображения рекламных объявлений или собирания статистических данных.

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

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

Цензура: поставщики услуг DNS для блокирования доступа к выбранным доменам.

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

Мое понимание, считав предыдущие ответы и другие веб-страницы, такие как Ubuntu 18.04 systemd-разрешенная ошибка, которая 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> ~ говорит, что должны быть проигнорированы все сообщения, который содержит <часть сообщения>: тильда ~ в команде говорит для отбрасывания сообщения.

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

Это кажется связанным с 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 / + ошибка/1766969

Это походит, можно просто выключить ту "опцию".

Проблема

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

systemctl status systemd-resolved

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

И Azure Ubuntu 18.04 VM не имеет systemd-resolved настроенный out-of-the-box (с сегодняшнего дня, 20191008).

Решение:

Настроить systemd-resolved.

Мини- systemd-resolved Конфигурация HowTo:

Примечание: Следующие инструкции были подготовлены с помощью Ubuntu 18.04

Править hosts директива в /etc/nsswitch.conf путем предварительного ожидания resolve который устанавливает systemd-разрешенный как первый источник разрешения 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 должно теперь вести себя ожидаемым способом.

В моем случае Google Cloud не любит CloudFlare DNS. После выполнения следующей команды из bain выше

sudo tcpdump -vv port 53 | grep NXDomain

Когда я открываю свой домен в браузере, я получаю:

dns.google.domain> ....: [сумма udp ок] .... NXDomain q: PTR? ... нс: .... SOA .... cloudflare.com. dns.cloudflare.com. ....

Также может быть случай с другими провайдерами VPS-CDN.

Перенос DNS на вашего VPS / облачного провайдера может помочь.