ubuntuusers.de

Ich habe ein sehr frisches Ubuntu 18.04 Server hier, das nach Installation von OSSEC angefangen hat, mir regelmäßig

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

zu schicken. Kann gut sein, dass es auch vorher schon kam, aber seitdem bekomme ich es per E-Mail, aber das nur am Rande. Ich habe eine ganze Weile diverseste Meinungen in Foren recherchiert, aber ich bin der Ansicht, dass es keine Fehlkonfiguration sein dürfte, wie sie wohl vor einiger Zeit bei Ubuntu 18.04 vorkam, da ich valide DNS-Einträge problemlos resolven kann:

systemd-resolve www.example.com

und das Resolven eines nichtexistierenden DNS-Eintrags

systemd-resolve com.example.www

mir genau die Fehlermeldung schickt, die auch sonst einmal am Tag kommt.

Meine Schlussfolgerung: irgendetwas läuft auf dem Server und will einmal am Tag eine DNS resolven, die es nicht gibt. Ich würde mich nun brennend dafür interessieren, was das ist, also PID, Name der Datei, die ausgeführt wurde, Usercontext, und last but not least um welche DNS es eigentlich geht.

Gibt es einen Weg, wie ich systemd-resolved dazu bringen kann, mir zu verraten, welcher Request diese Fehlermeldung jeweils ausgelöst hat? Vielen Dank schonmal für jedwede Hilfe.

Hallo!

Falls die Problematik nicht von einem zweiten DNS-Dienst (resolvconf, o.ä.) liegt, sollte die Antwort in der Ausgabe von

journalctl --unit systemd-resolved

zu finden sein.

Vielen Dank für die Rückmeldung.

Leider liefert mir auch

1

journalctl --unit systemd-resolved

nur Zeilen der Form

1

Mär 13 20:30:10 higris systemd-resolved[13618]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.

Es wirkt auf mich schon so, als wären da nicht die Informationen, um den verursachenden Prozess auszumachen. Einen zweiten Resolve-Dienst hab ich zumindest nicht von Hand installiert, in /etc/resolv.conf steht

1

../run/systemd/resolve/stub-resolv.conf

Ich habe noch versucht, über

1

sudo systemctl edit systemd-resolved

in die override.conf ein

1
2

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

einzutragen, wie beschrieben unter https://unix.stackexchange.com/questions/328131/how-to-troubleshoot-dns-with-systemd-resolved aber das hat dazu geführt, dass der resolved gar nicht mehr starten wollte. Ist das veraltet, gibt es da eine aktueller Vorgehensweise?

tim.lammarsch schrieb:

Es wirkt auf mich schon so, als wären da nicht die Informationen, um den verursachenden Prozess auszumachen. Einen zweiten Resolve-Dienst hab ich zumindest nicht von Hand installiert, in /etc/resolv.conf steht

1	../run/systemd/resolve/stub-resolv.conf

Lösche mal die Verlinkung und setz sie neu auf /run/systemd/resolve/resolv.conf, danach sollte die Meldung nicht mehr vorhanden sein.

Zum Debugging kann ich dir wenig sagen. Du könntest beim Neustart das Kernelkommando um systemd.log_level=debug erweitern (siehe Bootoptionen), dann spammt er aber ziemlich viel. Wie man einzelne Units debuggt, weiß ich leider auch nicht.

Die stub-resolved ist eine der richtigen Verlinkungen. Es gäbe neben /run/systemd/resolve/stub-resolv.conf noch /usr/lib/systemd/resolv.conf und /run/systemd/resolve/resolv.conf.

Normalerweise steht in stub nur die 127.0.0.53 drin, als Namensserver für alles, so dass alle Anwendungen, die ihre Namensserver aus der /etc/resolv.conf beziehen auf diesen umgeleitet werden. Suchdomänen in dieser Datei sind flexibel und werden von systemd aktualisiert. Die lib-Datei ist das selbe, nur ohne Suchdomänen. Die /run/systemd/resolve/resolv.conf wiederum enthält alle systemweit bekannten DNS-Server. Falls die /etc/resolv.conf manuell angelegt wurde, ändert systemd-resolved nichts, sondern wird Client der Datei und nutzt die dort angegebenen Nameserver und Suchdomänen.
Ist etwas verwirrend und unübersichtlich, hatte damit auch schon öfter zu kämpfen 😉

Nun mal konkret zum Ubuntu: Hast du die Netzwerkkonfiguration mit Netplan oder systemd/networkd eingerichtet? Welche DNS-Server sind dort angegeben? Tauchen die auch bei resolvectl auf?

Meine Focal-VM löst alles soweit korrekt auf und ohne unerwartete Fehlermeldungen:

user@usrv:~$ resolvectl query ubuntuusers.de
ubuntuusers.de: 213.95.41.4                    -- link: enp1s0

-- Information acquired via protocol DNS in 36.8ms.
-- Data is authenticated: no
user@usrv:~$ resolvectl query whatever.ubuntuusers.de
whatever.ubuntuusers.de: resolve call failed: 'whatever.ubuntuusers.de' does not have any RR of the requested type
user@usrv:~$ resolvectl query de.example.www         
de.example.www: resolve call failed: 'de.example.www' not found
user@usrv:~$ resolvectl query www.example.de 
www.example.de: 217.160.0.248                  -- link: enp1s0

-- Information acquired via protocol DNS in 70.9ms.
-- Data is authenticated: no
user@usrv:~$ 

Danke soweit noch mal an beide. Für mich scheinen sowohl die stub-resolved als auch /etc/resolv.conf problemlos zu funktionieren, sofern die entsprechende DNS gültig ist. Darum gehe ich eben wie gesagt eigentlich nicht von einem Fehler aus, den resolved verursacht, es ist nur die Stelle, wo das eigentliche, noch versteckte Problem hinprojiziert wird.

Der Server steht nicht wirklich physisch hier sondern in einem Rechenzentrum, vom Betreiber stammt auch das Installationsimage. Daher habe ich persönlich keine gesonderte Netzwerkkonfiguration eingerichtet, müsste aber dort nachfragen, um zu erfahren, ob im Image etwas vorgegeben ist. Ich habe jetzt noch mal ein paar DNS-Adressen getestet und würde auch sagen, dass korrekte Einträge auch korrekt aufgelöst werden, was auch immer die Fehlermeldung verursacht muss eine nichtexistente Adresse auflösen wollen.

Etwas Lesestoff, gefunden hier.

Hat eine Weile gedauert, aber ich glaube ich habe die Zusammenhänge langsam begriffen:

[Theorie mit diversen Indizien] DNS-Requests gehen zuerst über UDP raus, da klappt es nicht weil UDP inbound geblockt ist, danach gehen sie über TCP raus, dann klappt es (weil die Antworten dann ein ACK-Flag haben was man bei UDP halt nicht als Sicherheitsmaßnahme prüfen kann) und damit läuft das System theoretisch fehlerfrei. [/]

Ich würde die Fehlermeldungen und den unnötigen Traffic dennoch gerne vermeiden und einfach gleich alle DNS-Anfragen per TCP rausschicken. Erstes Googeln erklärt mir ich soll in /etc/resolv.conf zu den options use-vc hinzufügen. Das ist aber wohl mit system-resolved nicht mehr der richtige Weg. Weiß eventuell jemand, wie ich das ganze resolven auf dem System komplett auf TCP beschränke? Vielen Dank.