Il nuovo avviso continua a comparire: il server ha restituito l'errore NXDOMAIN, mitigando la potenziale violazione del DNS DVE-2018-0001

Ho appena installato un nuovo Ubuntu Server 18.04. Ho impostato il mio nome host hostnamectl set-hostname ****.openbayou.bize ho impostato /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

Ho anche installato OSSEC per monitorare nuovi file, errori e modifiche sul mio server e ora ricevo questi avvisi:

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

Ora si sta ripetendo:

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

Ho cercato online una soluzione e nessuno sta segnalando questo problema.

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

Lo stesso errore si è verificato sul mio computer desktop, non so se si applica anche al server.

Sembra che il mio sistema avesse la vecchia configurazione sul posto, risultando in un conflitto tra due servizi: resolvconfe systemd-resolved.

Il link simbolico /etc/resolv.confindicava../run/resolvconf/resolv.conf

Modificandolo per indicare a /run/systemd/resolve/resolv.confquale è gestito da systemd, l'ho risolto per me.

Leggi di più qui .

Spero che abbia aiutato.

Ho chiesto al GitHub OSSEC di questo errore e mi hanno consigliato di scrivere una regola per ignorare gli errori NXDOMAIN. Aggiungere a/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>

Questo avviso viene registrato da systemd-risolto, ogni volta che un nome non può essere risolto dal sistema DNS (ad esempio nslookup www.kjfoiqaefah34876asdf.com). Questo può essere tollerato e non c'è motivo di allarmarsi. Questo non è un errore e non è necessario correggere nulla.

Il reindirizzamento di /etc/resolv.conf su /run/systemd/resolve/resolv.conf è errato, perché in questo modo viene risolto systemd risolto e l'applicazione con la richiesta DNS difettosa comunica direttamente con il server dei nomi e non con systemd risolto più stub. In questo modo systemd-risolto non nota più gli eventi NXDOMAIN e quindi non può più registrarlo.

Gli eventi NXDOMAIN sono causati da pacchetti che tentano di accedere a server inesistenti durante l'avvio del sistema.

Ho notato la stessa cosa su un server Ubuntu 18.04 che è stato recentemente aggiornato a 18.04.1.

Sembrerebbe che la risoluzione del sistema registri quel messaggio ogni volta che riceve una risposta NXDOMAIN. Nel mio caso ho Postfix in esecuzione. Quindi ricevo molti NXDOMAINS quando si collegano server casuali che non hanno record record PTR.

Puoi provarlo con

systemd-resolve securelogin.example.com

Quindi dovresti visualizzare il messaggio di registro.

Con questo in mente sembrerebbe un errore relativamente innocuo e puoi ignorarlo.

La mia comprensione dopo aver letto le risposte precedenti e altre pagine Web come Ubuntu 18.04 errore risolto dal sistema NXDOMAIN è che questo è più un avvertimento che un errore e non c'è nulla che io possa fare al riguardo.

Pertanto, sono d'accordo con coloro che affermano che non dovremmo provare a fare qualcosa dalla nostra parte in modo che questi messaggi non vengano più prodotti. Se ci riusciamo, è probabile che abbiamo modificato il modo normale in cui il sistema risolve le richieste DNS.

Tuttavia, dal momento che ne ho migliaia (sono anche su un desktop - non è un server), non li voglio nel mio file syslog. Pertanto, seguendo https://www.rsyslog.com/doc/v8-stable/configuration/filters.html e il prefisso della coppia numerica per configurare i file , ho aggiunto un file denominato 10-resolv.confcon una sola riga :msg, contains, "Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP" ~nella directory /etc/rsyslog.d .

Il nome 10-resolv.confnon è importante, ma deve precedere tutti gli altri nomi di file nella directory in ordine alfabetico. Il comando :msg, contains, <message-part> ~dice che tutti i messaggi che contengono <message-part> devono essere ignorati: la tilde ~nel comando dice di eliminare il messaggio.

Nota aggiunta: da quando ho scritto questa risposta, ho installato alcuni pacchetti (per altri motivi) e il messaggio di errore non viene più prodotto come verificato journalctl -u systemd-resolved -f. Un pacchetto installato che potrebbe spiegare la scomparsa di questo messaggio è libnss-resolver.

Sommario:

Il messaggio di errore NXDOMAIN indica che non esiste un dominio.

Alcuni ISP hanno avviato il dirottamento DNS o il reindirizzamento DNS per i messaggi di errore NXDOMAIN. È pratica reindirizzare la risoluzione dei nomi DNS (Domain Name System) su altri server DNS o server Web.

Comunemente utilizzato per visualizzare annunci pubblicitari o raccogliere statistiche.

Questa pratica viola lo standard RFC per le risposte DNS (NXDOMAIN).

Phishing: possono verificarsi attacchi di scripting tra siti a causa del dirottamento dannoso.

Censura: fornitori di servizi DNS per bloccare l'accesso ai domini selezionati.

Qui mostrato: https://www.dnsknowledge.com/whatis/nxdomain-non-existent-domain-2/

Sono stato in grado di sbarazzarmi del messaggio e, tra l'altro, sono stato anche in grado di connettermi finalmente al mio server samba, cambiando il nome del server in server.domainanziché solo server.

Questo sembra correlato a EDNS. La differenza tra usare stub-resolv.confe resolv.confè options edns0.

I meccanismi di estensione per DNS (EDNS) sono una specifica per espandere le dimensioni di numerosi parametri del protocollo Domain Name System (DNS) che aveva restrizioni di dimensioni che la comunità di ingegneri di Internet considerava troppo limitate per aumentare la funzionalità del protocollo.

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

Maggiori dettagli su questo problema: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1766969

Sembra che puoi semplicemente disattivare quella "opzione".

Problema

Sebbene possano esserci altre circostanze in cui si verificherà questo errore, posso sicuramente dire che l'ho visto vomitato nell'output di:

systemctl status systemd-resolved

... quando systemd-resolvednon è configurato.

E una macchina virtuale Ubuntu 18.04 di Azure non è stata systemd-resolvedconfigurata immediatamente (ad oggi, 20191008).

Soluzione:

Configura systemd-resolved.

Mini systemd-resolvedConfig HowTo:

NOTA : Le seguenti istruzioni sono state preparate usando Ubuntu 18.04

Modifica la hostsdirettiva /etc/nsswitch.confanteponendo resolveche imposta systemd risolto come prima fonte di risoluzione DNS che verrà consultata:

hosts:          resolve files dns

Modifica /etc/systemd/resolved.conf. Alcune impostazioni suggerite:

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

Riavvio systemd-resolved:

sudo systemctl restart systemd-resolved

Alla successiva verifica dello systemd-resolvedstato, l'errore dovrebbe ora essere cancellato:

systemctl status systemd-resolved

E la risoluzione DNS dovrebbe ora comportarsi nel modo previsto.