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 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
dns
systemd-resolved
Gregory Schultz
la source
la source
Réponses:
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:
resolvconf
etsystemd-resolved
.Le lien symbolique
/etc/resolv.conf
pointé vers../run/resolvconf/resolv.conf
Le changer pour
/run/systemd/resolve/resolv.conf
qu'il soit dirigé par systemd, corrige-le pour moi.Lire la suite ici .
J'espère que ça a aidé.
la source
/run/systemd/resolve/stub-resolv.conf
sur une instance Ubuntu 18.10./run/systemd/resolve/resolv.conf
de/run/systemd/resolve/stub-resolv.conf
résolu le problème pour moi. Je ne vois plus cette erreur./etc/resolv.conf -> /run/systemd/resolve/resolv.conf
fait le tour.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
la source
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.
la source
tcpdump -vv port 53 | grep NXDomain
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
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.
la source
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.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~
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.la source
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/
la source
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.domain
lieu deserver
.la source
Cela semble lié à EDNS. La différence entre utiliser
stub-resolv.conf
etresolv.conf
estoptions edns0
.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".
la source
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:
... quand
systemd-resolved
n'est pas configuré.Et une machine virtuelle Azure Ubuntu 18.04 n'a pas déjà été
systemd-resolved
configurée (à ce jour, 20191008).Solution:
Configurer
systemd-resolved
.Mini
systemd-resolved
config HowTo:NOTE : Les instructions suivantes ont été préparées avec Ubuntu 18.04
Modifiez la
hosts
directive en/etc/nsswitch.conf
ajoutant des préfixesresolve
qui définissent la résolution de systemd comme première source de résolution DNS qui sera consultée:Modifier
/etc/systemd/resolved.conf
. Quelques réglages suggérés:Redémarrer
systemd-resolved
:Lors de la prochaine vérification
systemd-resolved
du statut, l'erreur devrait maintenant être effacée:Et la résolution DNS doit maintenant se comporter comme prévu.
la source