Es wird immer wieder eine neue Warnung angezeigt: Der Server hat den Fehler NXDOMAIN zurückgegeben, wodurch die potenzielle DNS-Verletzung DVE-2018-0001 verringert wird

Ich habe gerade einen neuen Ubuntu Server 18.04 installiert. Ich setze meinen Hostnamen hostnamectl set-hostname ****.openbayou.bizund ich setze /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

Ich habe auch OSSEC installiert, um nach neuen Dateien, Fehlern und Änderungen auf meinem Server zu suchen. Jetzt erhalte ich die folgenden Warnungen:

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

Es wiederholt sich jetzt:

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.]

Ich habe online nach einer Lösung gesucht und niemand meldet dieses Problem.

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

Der gleiche Fehler ist bei meinem Desktop-Computer aufgetreten. Ich weiß nicht, ob er auch für den Server gilt.

Es scheint, dass mein System die alte Konfiguration an der richtigen Stelle hatte, was zu einem Konflikt zwischen zwei Diensten führte: resolvconfund systemd-resolved.

Der Symlink /etc/resolv.confzeigte auf../run/resolvconf/resolv.conf

Ändern Sie es in einen Punkt, /run/systemd/resolve/resolv.confder von systemd verwaltet wird, und korrigieren Sie es für mich.

Lesen Sie hier mehr .

Hoffe das hat geholfen.

Ich habe im OSSEC GitHub nach diesem Fehler gefragt und sie haben empfohlen, eine Regel zu schreiben, um NXDOMAIN-Fehler zu ignorieren. Hinzufügen/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>

Diese Warnung wird von systemd-resolved protokolliert, wenn ein Name vom DNS-System nicht aufgelöst werden kann (z. B. nslookup www.kjfoiqaefah34876asdf.com). Dies kann toleriert werden und ist kein Grund zur Besorgnis. Dies ist kein Fehler und es muss nichts behoben werden.

Die Umleitung von /etc/resolv.conf nach /run/systemd/resolve/resolv.conf ist falsch, da auf diese Weise systemaufgelöst übersprungen wird und die Anwendung mit der fehlerhaften DNS-Anforderung direkt mit dem Nameserver und nicht mit dem systemaufgelösten Server kommuniziert Stummel mehr. Auf diese Weise bemerkt systemd-resolved die NXDOMAIN-Ereignisse nicht mehr und kann sie daher nicht mehr protokollieren.

Die NXDOMAIN-Ereignisse werden von Paketen verursacht, die versuchen, während des Systemstarts auf nicht vorhandene Server zuzugreifen.

Ich habe dasselbe auf einem Ubuntu 18.04-Server bemerkt, der kürzlich auf 18.04.1 aktualisiert wurde.

Es scheint, dass systemd-resolve diese Nachricht protokolliert, wenn eine NXDOMAIN-Antwort eingeht. In meinem Fall habe ich Postfix ausgeführt. Daher bekomme ich viele NXDOMAINS, wenn zufällige Server eine Verbindung herstellen, für die kein PTR-Datensatz festgelegt ist.

Sie können es mit testen

systemd-resolve securelogin.example.com

Anschließend sollte die Protokollmeldung angezeigt werden.

In diesem Sinne scheint es sich um einen relativ harmlosen Fehler zu handeln, den Sie ignorieren können.

Nachdem ich die vorherigen Antworten und andere Webseiten wie den von Ubuntu 18.04 systemd aufgelösten Fehler NXDOMAIN gelesen habe , habe ich verstanden, dass dies eher eine Warnung als ein Fehler ist und ich nichts dagegen tun kann.

Daher stimme ich denen zu, die sagen, wir sollten nicht versuchen, etwas auf unserer Seite zu tun, damit diese Botschaften nicht mehr produziert werden. Wenn dies gelingt, haben wir wahrscheinlich die normale Art und Weise geändert, wie das System DNS-Anforderungen auflöst.

Da ich jedoch Tausende davon habe (ich bin auch auf einem Desktop - es ist kein Server), möchte ich sie nicht in meiner Syslog-Datei haben. Aus diesem Grund habe ich nach dem Präfix https://www.rsyslog.com/doc/v8-stable/configuration/filters.html und dem Nummernpaar-Präfix für Konfigurationsdateien eine Datei 10-resolv.confmit einem Namen und einer einzelnen Zeile :msg, contains, "Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP" ~im Verzeichnis hinzugefügt /etc/rsyslog.d .

Der Name 10-resolv.confist nicht wichtig, muss jedoch in alphabetischer Reihenfolge vor allen anderen Dateinamen im Verzeichnis stehen. Der Befehl :msg, contains, <message-part> ~besagt, dass alle Nachrichten, die <message-part> enthalten, ignoriert werden müssen: Die Tilde ~im Befehl sagt, dass die Nachricht gelöscht werden soll.

Anmerkung hinzugefügt: Seitdem ich diese Antwort geschrieben habe, habe ich einige Pakete (aus anderen Gründen) installiert und die Fehlermeldung wird nicht mehr wie angekreuzt ausgegeben journalctl -u systemd-resolved -f. Ein installiertes Paket, das das Verschwinden dieser Meldung erklären könnte, ist libnss-resolve.

Zusammenfassung:

NXDOMAIN Fehlermeldung bedeutet, dass eine Domain nicht existiert.

Einige ISPs haben DNS-Hijacking oder DNS-Umleitung für NXDOMAIN-Fehlermeldungen gestartet. In der Praxis wird die Auflösung von DNS-Namen (Domain Name System) auf andere DNS-Server oder Webserver umgeleitet.

Wird häufig zum Anzeigen von Werbung oder zum Sammeln von Statistiken verwendet.

Diese Vorgehensweise verstößt gegen den RFC-Standard für DNS-Antworten (NXDOMAIN).

Phishing: Siteübergreifende Skriptangriffe können aufgrund von böswilligem Hijacking auftreten.

Zensur: DNS-Dienstanbieter, die den Zugriff auf ausgewählte Domänen blockieren.

Hier gezeigt: https://www.dnsknowledge.com/whatis/nxdomain-non-existent-domain-2/

Ich konnte die Nachricht loswerden und mich schließlich mit meinem Samba-Server verbinden, indem ich den Servernamen auf server.domainanstatt nur änderte server.

Dies scheint mit EDNS zu tun zu haben. Der Unterschied zwischen der Verwendung von stub-resolv.confund resolv.confist options edns0.

Erweiterungsmechanismen für DNS (EDNS) sind eine Spezifikation zum Erweitern der Größe mehrerer Parameter des DNS-Protokolls (Domain Name System), die Größenbeschränkungen aufwiesen, die die Internet-Entwicklergemeinde als zu begrenzt ansah, um die Funktionalität des Protokolls zu erhöhen.

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

Weitere Details zu dieser Ausgabe: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1766969

Es klingt so, als ob Sie diese "Option" einfach ausschalten können.

Problem

Obwohl es andere Umstände geben könnte, unter denen dieser Fehler auftreten wird, kann ich definitiv sagen, dass ich gesehen habe, wie er in der Ausgabe von:

systemctl status systemd-resolved

... wenn systemd-resolvednicht konfiguriert ist.

Eine Azure Ubuntu 18.04-VM ist nicht systemd-resolvedsofort einsatzbereit (Stand: 20191008).

Lösung:

Konfigurieren systemd-resolved.

Mini systemd-resolvedConfig HowTo:

HINWEIS : Die folgenden Anweisungen wurden mit Ubuntu 18.04 erstellt

Bearbeiten Sie die hostsDirektive in /etc/nsswitch.confdurch Voranstellen, resolvewodurch systemd-aufgelöst als erste Quelle für die DNS-Auflösung festgelegt wird, die konsultiert wird:

hosts:          resolve files dns

Bearbeiten /etc/systemd/resolved.conf. Einige vorgeschlagene Einstellungen:

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

Neustart systemd-resolved:

sudo systemctl restart systemd-resolved

Beim nächsten Überprüfen systemd-resolveddes Status sollte der Fehler nun behoben sein:

systemctl status systemd-resolved

Die DNS-Auflösung sollte sich nun wie erwartet verhalten.