La nouvelle alerte continue de s'afficher: le serveur a renvoyé l'erreur NXDOMAIN, atténuant ainsi les risques de violation DNS DVE-2018-0001
Je viens d'installer un nouveau serveur Ubuntu 18.04. J'ai défini mon nom d'hôte hostnamectl set-hostname ****.openbayou.biz et /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
J'ai également installé OSSEC pour surveiller les nouveaux fichiers, les erreurs et les modifications sur mon serveur et je reçois maintenant les alertes suivantes:
Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-
0001, retrying transaction with reduced feature level UDP.`
Il se répète maintenant:
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.]
J'ai cherché une solution en ligne et personne n'a signalé ce problème.
J'ai demandé à OSSEC GitHub à propos de cette erreur et ils ont recommandé d'écrire une règle pour ignorer les erreurs NXDOMAIN. Ajouter à /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>
Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018- 0001, retrying transaction with reduced feature level UDP.
La même erreur s'est produite sur mon ordinateur de bureau, je ne sais pas si cela s'applique également au serveur.
Il semble que mon système contienne l’ancienne configuration à la place, ce qui a entraîné un conflit entre deux services: resolvconf et systemd-resolved.
Le lien symbolique /etc/resolv.conf a désigné ../run/resolvconf/resolv.conf
Le changer pour qu'il pointe vers /run/systemd/resolve/resolv.conf qui est géré par systemd, le corrige pour moi.
Lire la suite ici .
J'espère que ça a aidé.
J'ai remarqué la même chose sur un serveur Ubuntu 18.04 récemment mis à jour le 18.04.1.
Il semblerait que systemd-resolution enregistre ce message chaque fois qu'il reçoit une réponse NXDOMAIN. Dans mon cas, j'ai postfixé. Donc, je reçois beaucoup de NXDOMAINS lorsque des serveurs aléatoires se connectent sans que les enregistrements PTR ne soient définis.
Vous pouvez le tester avec
systemd-resolve securelogin.example.com
Ensuite, le message du journal devrait apparaître.
En gardant cela à l'esprit, cela semble être une erreur relativement inoffensive et vous pouvez l'ignorer.
Cet avertissement est consigné par systemd-resol, lorsqu'un nom ne peut pas être résolu par le système DNS (par exemple, nslookup www.kjfoiqaefah34876asdf.com). Cela peut être toléré et n’est pas une raison pour s’alarmer. Ce n'est pas une erreur et rien ne doit être corrigé.
La redirection de /etc/resolv.conf vers /run/systemd/resolve/resolv.conf est incorrecte, car de cette manière, la résolution de systemd est ignorée et l'application avec la requête DNS défectueuse parle directement au serveur de noms et non au système de résolution systemd. souche plus. De cette façon, systemd-resolu ne remarque plus les événements NXDOMAIN et ne peut donc plus le consigner.
Les événements NXDOMAIN sont provoqués par des packages qui tentent d'accéder à des serveurs non existants lors du démarrage du système.
Résumé:
NXDOMAIN message d'erreur signifie qu'un domaine n'existe pas.
Certains FAI ont commencé le piratage DNS ou la redirection DNS pour les messages d'erreur NXDOMAIN. C'est la pratique de rediriger la résolution des noms DNS (Domain Name System) vers d'autres serveurs DNS ou serveurs Web.
Couramment utilisé pour afficher des publicités ou collecter des statistiques.
Cette pratique enfreint le standard RFC pour les réponses DNS (NXDOMAIN).
Hameçonnage: des attaques par scripts intersites peuvent être causées par un piratage malveillant.
Censure: fournisseurs de services DNS pour bloquer l'accès aux domaines sélectionnés.
Montré ici: https://www.dnsknowledge.com/whatis/nxdomain-non-existent-domain-2/
Je pouvais me débarrasser du message et, en passant, je pouvais enfin me connecter à mon serveur samba en changeant le nom du serveur en server.domain au lieu de seulement server =.
Cela semble lié à EDNS. La différence entre stub-resolv.conf et resolv.conf est de options edns0.
Les mécanismes d'extension pour DNS (EDNS) sont une spécification permettant d'étendre la taille de plusieurs paramètres du protocole DNS (Domain Name System) qui comportait des restrictions de taille que la communauté des ingénieurs Internet a jugées trop limitées pour augmenter les fonctionnalités du protocole.
https://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS
Plus de détails dans ce numéro: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1766969
Cela ressemble à, vous pouvez simplement désactiver cette "option".
D'après ce que j'ai compris après avoir lu les réponses précédentes et d'autres pages Web telles que erreur NXDOMAIN résolue par systemd sous Ubuntu 18.04 , c'est plus un avertissement qu'une erreur et je ne peux rien y faire. .
Je suis donc d’accord avec ceux qui disent que nous ne devrions pas essayer de faire quelque chose de notre côté pour que ces messages ne soient plus produits. Si nous réussissons, il est probable que nous ayons modifié la manière habituelle de résolution des requêtes DNS par le système.
Cependant, comme j'en ai des milliers (je suis aussi dans un bureau - ce n'est pas un serveur), je ne les veux pas dans mon fichier syslog. Par conséquent, après https://www.rsyslog.com/doc/v8-stable/configuration/filters.html et préfixe de paire de numéros pour les fichiers de configuration , j'ai ajouté un fichier nommé 10-resolv.conf avec une seule ligne :msg, contains, "Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP" ~ dans le répertoire /etc/rsyslog.d.
Le nom 10-resolv.conf n'est pas important, mais il doit précéder tous les autres noms de fichiers du répertoire par ordre alphabétique. La commande :msg, contains, <message-part> ~ indique que tous les messages contenant <partie de message> doivent être ignorés: le tilde ~ de la commande dit de supprimer le message.
Note ajoutée: Depuis que j'ai écrit cette réponse, j'ai installé des paquets (pour d'autres raisons) et le message d'erreur n'est plus produit comme vérifié avec journalctl -u systemd-resolved -f. Un paquet installé pouvant expliquer la disparition de ce message est libnss-resol.