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

Щойно я встановив новий сервер Ubuntu 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>

Це попередження реєструється систематизованим рішенням, коли ім’я неможливо вирішити системою DNS (наприклад, nslookup www.kjfoiqaefah34876asdf.com). Це можна допустити, і це не є підставою для занепокоєння. Це не помилка, і нічого не потрібно виправляти.

Неправильне перенаправлення /etc/resolv.conf на /run/systemd/resolve/resolv.conf, оскільки цей спосіб вирішення системи пропускається, і додаток із несправним запитом DNS переходить безпосередньо до сервера імен, а не до вирішеного systemd заглушка більше. Таким чином, вирішене системою більше не помічає події NXDOMAIN і тому більше не може реєструвати їх.

Події NXDOMAIN викликаються пакетами, які намагаються отримати доступ до неіснуючих серверів під час запуску системи.

Я помітив те саме на сервері Ubuntu 18.04, який нещодавно оновлено до 18.04.1.

Здається, що системне рішення записує це повідомлення щоразу, коли воно отримує будь-яку відповідь NXDOMAIN. У моєму випадку працює постфікс. Тому я отримую багато NXDOMAINS, коли підключаються випадкові сервери, на яких не встановлено запис PTR.

Ви можете протестувати

systemd-resolve securelogin.example.com

Тоді ви побачите, як з’являється повідомлення журналу.

Зважаючи на це, це може бути відносно нешкідливою помилкою, і ви можете її проігнорувати.

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

Тому я згоден з тими, хто каже, що ми не повинні намагатися щось робити на своїй стороні, щоб ці повідомлення більше не видавались. Якщо нам це вдасться, цілком ймовірно, що ми змінили звичайний спосіб системи вирішувати запити DNS.

Однак, оскільки у мене їх тисячі (я також на робочому столі - це не сервер), я не хочу їх у своєму файлі syslog. Тому, слідкуючи за 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. Один встановлений пакет, який може пояснити зникнення цього повідомлення, - це рішення лібнів.

Підсумок:

Повідомлення про помилку 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 VM не systemd-resolvedналаштовано поза коробкою (станом на сьогодні, 20191008).

Рішення:

Налаштувати systemd-resolved.

Міні- systemd-resolvedналаштування HowTo:

ПРИМІТКА . Наступні інструкції були підготовлені за допомогою Ubuntu 18.04

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