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.bizet j'ai défini /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.

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 avait l'ancienne configuration à la place, ce qui a entraîné un conflit entre deux services: resolvconfet systemd-resolved.

Le lien symbolique /etc/resolv.confpointé vers../run/resolvconf/resolv.conf

Le changer pour /run/systemd/resolve/resolv.confqu'il soit dirigé par systemd, corrige-le pour moi.

Lire la suite ici .

J'espère que ça a aidé.

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>

Cet avertissement est enregistré par systemd-resolu, chaque fois qu'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 causés par des packages qui tentent d'accéder à des serveurs non existants lors du démarrage du système.

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é. Ainsi, je reçois beaucoup de NXDOMAINS lorsque des serveurs aléatoires se connectent et que le jeu d’enregistrements PTR n’est pas défini.

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.

Après avoir lu les réponses précédentes et d’autres pages Web telles que Ubuntu 18.04, erreur résolue par systemd NXDOMAIN, j’ai bien compris qu’il s’agissait plus d’un avertissement que d’une erreur et que je ne pouvais rien faire à ce sujet.

Par conséquent, je suis 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 y parvenons, 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 le préfixe de paire de numéros pour les fichiers de configuration , j'ai ajouté un fichier nommé 10-resolv.confavec 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.confn'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 ~dans la commande indique 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 tel que coché journalctl -u systemd-resolved -f. Un paquet installé pouvant expliquer la disparition de ce message est libnss-resol.

Sommaire:

Le message d'erreur NXDOMAIN 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 se produire suite à 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/

J'ai réussi à me débarrasser du message et, par la même occasion, à pouvoir enfin me connecter à mon serveur samba, en changeant le nom du serveur au server.domainlieu de server.

Cela semble lié à EDNS. La différence entre utiliser stub-resolv.confet resolv.confest 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 accroître 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".

Problème

Bien que cette erreur puisse se produire dans d’autres circonstances, je peux affirmer que c’est ce que j’ai vu apparaître dans la sortie de:

systemctl status systemd-resolved

... quand systemd-resolvedn'est pas configuré.

Et une machine virtuelle Azure Ubuntu 18.04 n'a pas déjà été systemd-resolvedconfigurée (à ce jour, 20191008).

Solution:

Configurer systemd-resolved.

Mini systemd-resolvedconfig HowTo:

NOTE : Les instructions suivantes ont été préparées avec Ubuntu 18.04

Modifiez la hostsdirective en /etc/nsswitch.confajoutant des préfixes resolvequi définissent la résolution de systemd comme première source de résolution DNS qui sera consultée:

hosts:          resolve files dns

Modifier /etc/systemd/resolved.conf. Quelques réglages suggérés:

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

Redémarrer systemd-resolved:

sudo systemctl restart systemd-resolved

Lors de la prochaine vérification systemd-resolveddu statut, l'erreur devrait maintenant être effacée:

systemctl status systemd-resolved

Et la résolution DNS doit maintenant se comporter comme prévu.