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

38

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.

Gregory Schultz
fuente
¿Estás detrás de un portal cautivo?
dobey
No, este es un servidor Linode de 4GB
Gregory Schultz
Si comenta las dos líneas que agregó, ¿hace alguna diferencia? No creo que los errores sean sobre su / etc / hosts. Están sucediendo debido a que la infraestructura detrás del servidor probablemente esté haciendo algo mal. github.com/systemd/systemd/pull/8608 parece ser el problema que está teniendo, y fue el primer resultado de búsqueda para "DVE-2018-0001". No creo que vaya a obtener una respuesta satisfactoria hasta que se solucione y se libere el problema aguas arriba.
dobey

Respuestas:

34

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.

Panagiotis Tabakis
fuente
66
El mío apunta a /run/systemd/resolve/stub-resolv.confuna instancia de Ubuntu 18.10.
datashaman
Olvidé mencionar mi sistema. Último KDE Neon, (basado en Ubuntu), 18.04.1, 4.15.0-39-generic.
Panagiotis Tabakis
1
Esto solucionó el problema para mí también. ¡Gracias!
Witek
3
@datashaman Fue el mismo caso para mí, pero cambiando el enlace a punto /run/systemd/resolve/resolv.confde /run/systemd/resolve/stub-resolv.conffijado el problema para mí. Ya no veo ese error.
Karthic Raghupathi
Lo mismo funcionó para mí. Estoy en 18.10, pero migré desde 18.04. Cambiar el /etc/resolv.conf -> /run/systemd/resolve/resolv.confhizo el truco.
Igor Kupczyński
10

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>
Gregory Schultz
fuente
¿Le importaría agregar el enlace a la recomendación en su respuesta? Sería útil para otros que tienen el mismo problema. ¡Gracias!
Leo
1
no funciona en ubunto 18.04
ajcg
9

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.

Hermann Klein
fuente
44
¿Hay alguna forma de descubrir cuáles son los nombres sin resolver?
Deja de dañar a Mónica el
55
@OrangeDogtcpdump -vv port 53 | grep NXDomain
baño
7

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.

Rwky
fuente
Se agregó el registro PTR y no he recibido un aviso (hasta ahora). ¡Gracias!
Gregory Schultz
No Todavía los tengo. Piense que la siguiente etapa es hacer que OSSEC los ignore. ¿Sería algo relacionado con Cloudflare ya que está pasando por sus sistemas y no se pasa por alto? Además, veo que OSSEC tiene una actualización (en 2.9.4, actualización a 3.0.0). Se actualizará y verá qué pasa.
Gregory Schultz
Es solo parte de cómo funciona systemd. Si systemd-resolve intenta resolver un dominio que no lo resuelve, registra ese mensaje.
Rwky
3

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.

Dominic108
fuente
2

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/

Huésped
fuente
0

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.

rosch
fuente
0

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

Carson Reinke
fuente
0

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.

F1Linux
fuente