Nueva alerta sigue apareciendo: el servidor devolvió el error NXDOMAIN, mitigando la posible violación de DNS DVE-2018-0001

Acabo de instalar un nuevo Ubuntu Server 18.04. Configuré mi nombre de host hostnamectl set-hostname ****.openbayou.bizy configuré /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

También instalé OSSEC para monitorear nuevos archivos, errores y cambios en mi servidor y ahora recibo estas alertas:

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

Ahora se repite:

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

Busqué una solución en línea y nadie informa este problema.

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

El mismo error le ocurrió a mi máquina de escritorio, no sé si también se aplica al servidor.

Parece que mi sistema tenía la configuración anterior en el lugar, lo que resulta en un conflicto entre dos servicios: resolvconfy systemd-resolved.

El enlace simbólico /etc/resolv.confapuntó a../run/resolvconf/resolv.conf

Cambiándolo para que apunte /run/systemd/resolve/resolv.confcuál es administrado por systemd, lo arregló para mí.

Lee más aquí .

Espero que haya ayudado.

Pregunté en el OSSEC GitHub sobre este error y me recomendaron escribir una regla para ignorar los errores de NXDOMAIN. añadir/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>

Systemd-resolve esta advertencia, siempre que el sistema DNS no pueda resolver un nombre (por ejemplo, nslookup www.kjfoiqaefah34876asdf.com). Esto puede tolerarse y no es motivo para alarmarse. Esto no es un error y no hay nada que arreglar.

Redireccionar /etc/resolv.conf a /run/systemd/resolve/resolv.conf está mal, porque de esta forma se omite systemd-resolve y la aplicación con la solicitud DNS defectuosa se comunica directamente con el servidor de nombres y no con el systemd-resolve trozo más. De esta forma, systemd-resolve ya no se da cuenta de los eventos NXDOMAIN y, por lo tanto, no puede registrarlo más.

Los eventos NXDOMAIN son causados ​​por paquetes, que intentan acceder a servidores no existentes durante el inicio del sistema.

Noté lo mismo en un servidor Ubuntu 18.04 que se actualizó recientemente a 18.04.1.

Parece que systemd-resolve registra ese mensaje cada vez que recibe una respuesta NXDOMAIN. En mi caso tengo postfix ejecutándose. Entonces obtengo muchos NXDOMAINS cuando se conectan servidores aleatorios que no tienen establecido el registro PTR.

Puedes probarlo con

systemd-resolve securelogin.example.com

Entonces debería ver aparecer el mensaje de registro.

Con esto en mente, parecería ser un error relativamente inocuo y puede ignorarlo.

Según tengo entendido después de haber leído las respuestas anteriores y otras páginas web, como el error de Ubuntu 18.04 resuelto por systemd NXDOMAIN, es más una advertencia que un error y no hay nada que pueda hacer de mi parte.

Por lo tanto, estoy de acuerdo con aquellos que dicen que no debemos intentar hacer algo de nuestro lado para que estos mensajes ya no se produzcan. Si tenemos éxito, es probable que hayamos alterado la forma normal en que el sistema resuelve las solicitudes de DNS.

Sin embargo, dado que tengo miles de ellos (también estoy en un escritorio, no es un servidor), no los quiero en mi archivo syslog. Por lo tanto, siguiendo https://www.rsyslog.com/doc/v8-stable/configuration/filters.html y el prefijo de par de números para los archivos de configuración , agregué un archivo 10-resolv.confcon una sola línea :msg, contains, "Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP" ~en el directorio /etc/rsyslog.d .

El nombre 10-resolv.confno es importante, pero debe preceder a todos los demás nombres de archivo en el directorio en orden alfabético. El comando :msg, contains, <message-part> ~dice que todos los mensajes que contienen <message-part> deben ignorarse: la tilde ~en el comando dice que se debe soltar el mensaje.

Nota agregada: desde que escribí esta respuesta, instalé algunos paquetes (por otras razones) y el mensaje de error ya no se produce como se verificó con journalctl -u systemd-resolved -f. Un paquete instalado que podría explicar la desaparición de este mensaje es libnss-resolve.

Resumen:

El mensaje de error NXDOMAIN significa que no existe un dominio.

Algunos ISP comenzaron el secuestro de DNS o la redirección de DNS para los mensajes de error de NXDOMAIN. Es la práctica de redirigir la resolución de los nombres del Sistema de nombres de dominio (DNS) a otros servidores DNS o servidores web.

Comúnmente utilizado para mostrar anuncios o recopilar estadísticas.

Esta práctica viola el estándar RFC para las respuestas DNS (NXDOMAIN).

Suplantación de identidad (phishing): pueden producirse ataques de secuencias de comandos entre sitios debido a un secuestro malicioso

Censura: proveedores de servicios DNS para bloquear el acceso a dominios seleccionados.

Se muestra aquí: https://www.dnsknowledge.com/whatis/nxdomain-non-existent-domain-2/

Pude deshacerme del mensaje y, por cierto, también pude finalmente conectarme a mi servidor samba, cambiando el nombre del servidor a en server.domainlugar de solo server.

Esto parece relacionado con EDNS. La diferencia entre usar stub-resolv.confy resolv.confes options edns0.

Los mecanismos de extensión para DNS (EDNS) son una especificación para expandir el tamaño de varios parámetros del protocolo del Sistema de nombres de dominio (DNS) que tenía restricciones de tamaño que la comunidad de ingenieros de Internet consideraba demasiado limitadas para aumentar la funcionalidad del protocolo.

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

Más detalles sobre este problema: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1766969

Parece que simplemente puede desactivar esa "opción".

Problema

Aunque puede haber otras circunstancias en las que ocurrirá este error, definitivamente puedo decir que lo he visto vomitar en la salida de:

systemctl status systemd-resolved

... cuando systemd-resolvedno está configurado.

Y una máquina virtual Azure Ubuntu 18.04 no tiene una systemd-resolvedconfiguración lista para usar (a partir de hoy, 20191008).

Solución:

Configurar systemd-resolved.

Mini systemd-resolvedConfig HowTo:

NOTA : Las siguientes instrucciones se prepararon con Ubuntu 18.04

Edite la hostsdirectiva /etc/nsswitch.confintroduciendo previamente resolveque establece systemd-resolve como primera fuente de resolución DNS que se consultará:

hosts:          resolve files dns

Editar /etc/systemd/resolved.conf. Algunas configuraciones sugeridas:

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

Reiniciar systemd-resolved:

sudo systemctl restart systemd-resolved

La próxima vez que verifique systemd-resolvedel estado, el error ahora debería borrarse:

systemctl status systemd-resolved

Y la resolución DNS ahora debería comportarse de la manera esperada.