¿Cómo evitar conflictos entre dnsmasq y systemd-resolve?


57

Recientemente instalé dnsmasq para actuar como Servidor DNS para mi red local. dnsmasq escucha en el puerto 53, que ya está en uso por el receptor de resguardo DNS local desde systemd-resolve .

Simplemente detener systemd-resolve y luego reiniciarlo después de que dnsmasq se esté ejecutando resuelve este problema. Pero regresa después de un reinicio: systemd-resolve se inicia con preferencia y dnsmasq no se iniciará porque el puerto 53 ya está en uso.

Supongo que la primera pregunta obvia es: ¿cómo hago para que systemd resuelto comprenda que no debe iniciar el receptor de DNS local y, por lo tanto, mantener el puerto 53 para que lo use dnsmasq?

Sin embargo, una pregunta más interesante es cómo los dos servicios generalmente están destinados a trabajar juntos. ¿Están destinados a trabajar uno al lado del otro o están resueltos por el sistema de la misma manera si uno está usando dnsmasq?


44
¿Has intentado simplemente deshabilitar vía sudo systemctl disable systemd-resolved? dnsmasq si está configurado correctamente debería manejar la resolución de dominio, creo.
pbhj

1
También debe emitir sudo systemctl stop systemd-resolvedsi se está ejecutando. Utilice sudo systemctl status systemd-resolvedpara verificar
Bruce Barnett

Respuestas:


42

A partir de systemd 232 (lanzado en 2017), puede editar /etc/systemd/resolved.confy agregar esta línea:

DNSStubListener=no

Esto desactivará el enlace al puerto 53.

La opción se describe con más detalles en la página de manual de resolve.conf .

Puede encontrar la versión de systemd con la que se ejecuta su sistema:

systemctl --version

2
Haciendo este giro de la conexión a internet
Ravinder

2
@Ravinder: deshabilitará el servidor DNS del sistema, sí. Si su sistema está configurado para usar este servidor, parecerá que la conexión a Internet deja de funcionar (porque lo apagó). Deberá configurar su sistema para utilizar otro servidor DNS en su lugar. Por lo general, las personas desactivan el enlace en el puerto 53 porque quieren ejecutar su propio servidor DNS allí, por lo que no es un problema.
Malvineous

18

Puede deshabilitar la systemd-resolvedcarga en el arranque usando sudo systemctl disable systemd-resolved.

Si desea ejecutar los dos juntos, puede redirigirlos systemd-resolvedpara usar el host local como el servidor de nombres principal. Esto asegurará que todas las consultas se dirijan a dnsmasq para su resolución antes de llegar al servidor DNS externo. Esto se puede hacer agregando la línea nameserver 127.0.0.1en la parte superior de su /etc/resolv.confarchivo. Esto también deshabilitará el almacenamiento en caché local de systemd.

Puedes leer más en la wiki de Arch Linux . Copié esto desde allí y lo cubre bastante bien.

Sin embargo, esto no evita de manera confiable el error en el momento del arranque, es decir, dnsmasq seguirá fallando si systemd-resolve se inicia primero. Si su versión de systemdes lo suficientemente nueva, use la respuesta de Malvineous . Si su versión de systemdes demasiado antigua, puede solucionar este problema modificando la unidad dnsmasq: en la [Unit]sección, agregue Before=systemd-resolved.

Después de esto, si se quiere, se puede crear una separada /etc/dnsmasq-resolv.confde archivo para los servidores DNS upstream y pasarlo con el -ro la --resolv-fileopción, o añadir los servidores DNS upstream en el fichero de configuración de dnsmasq y utilizar el -Ro --no-resolvopción. De esta manera solo tienes el localhost en tu /etc/resolv.confy todo pasa por dnsmasq.


2
Tuve que eliminar mi comentario anterior porque ya no puedo confirmar que esto resolvió el problema. Leí el wiki antes de preguntar aquí, y ya tenía un archivo resolv.conf con el servidor de nombres localhost en la parte superior. Esto no ayudó. Luego seguí sus instrucciones para mover los servidores de nombres externos a un segundo archivo para dnsmasq. Después del primer reinicio, dnsmasq se cargó primero para que no surgiera el problema. En el segundo reinicio, se resolvió cargar primero para que dnsmasq saliera con el error descrito. Estoy tan lejos como antes.
vic

66
En la unidad dnsmasq, ponga un Before=systemd-resolveden la [Unit]sección. De esa manera, dnsmasq siempre comenzará primero.
Munir

7

A juzgar por las páginas de manual de systemd, no se pretende poder deshabilitar manualmente el servidor DNS de código auxiliar. Curiosamente, solo noté el problema descrito después de actualizar systemd de 230 a 231.

Deshabilitar systemd-resolve no era una opción para mí porque lo necesito para manejar los servidores DNS ascendentes recibidos a través de DHCP.

Mi solución fue hacer que dnsmasq dejara de resolver systemd antes de comenzar e iniciarlo nuevamente nuevamente.

Creé una configuración desplegable en /etc/systemd/system/dnsmasq.service.d/resolved-fix.conf:

[Unit]
After=systemd-resolved.service

[Service]
ExecStartPre=/usr/bin/systemctl stop systemd-resolved.service
ExecStartPost=/usr/bin/systemctl start systemd-resolved.service

Esto parece ser una solución bastante hack pero funciona.


2
Hola, en realidad esta solución es bastante ingeniosa. Es persistente incluso después de las actualizaciones del paquete porque mantiene el archivo de la unidad original. Bien hecho. En DNSStubListenerel manual resuelto.conf se indica lo siguiente : "Tenga en cuenta que el oyente de código auxiliar DNS se desactiva implícitamente cuando su dirección de escucha y puerto ya están en uso". Es por eso que este método funciona bien, creo.
Jonathan Komar

¡Una solución ++!
sjas

Tuve que cambiar / usr / bin / systemctl a / bin / systemctl
Bruce Barnett

5

Acabo de habilitar la opción "bind-interfaces" eliminando '#' al comienzo de la línea en /etc/dnsmasq.conf.

Pude iniciar dnsmasq nuevamente:

  • dnsmasq enlaza el puerto DNS en todas las interfaces (incluido 127.0.0.1) puerto 53,
  • systemd-resolv sigue escuchando en 127.0.0. 53 : 53

Esta discusión resolvió esta solución : agregué una opción para deshabilitar el stub resolver


Esta es la mejor respuesta para lo que es un incendio en un contenedor de basura. No hay ninguna razón por la que systemd deba ocupar ese puerto, incluso en bucle invertido.
Jonathan S. Fisher


2

Si está utilizando una configuración predeterminada de Ubuntu 18.04, esto puede deberse a un conflicto entre systemd-resolved(el servidor DNS predeterminado) y dnsmasq. Si se instaló dnsmasqdeliberadamente porque lo quería explícitamente, entonces una de las otras respuestas a esta pregunta, explicando cómo deshabilitarla systemd-resolved, probablemente será buena para usted. Si no lo instaló explícitamente dnsmasq, es probable que esté en su lugar porque lo está utilizando lxd. Esto podría deberse a que realmente lo usa lxdpara administrar contenedores, pero lo más probable es que las instantáneas lo usen lxdpara protegerlo cuando se instalan aplicaciones. Desde mi perspectiva, quiero mantener dnsmasq(porque lo lxdquiere) pero también quiero mantenersystemd-resolved como el servidor DNS (porque es lo que eligió el equipo de Ubuntu y confío en ellos más que en mí).

Entonces, esto parece ser un lxdproblema en el fondo. Si es así, la forma en que lo arreglé, según una publicación de la lista de correo de lxd-users , es la siguiente:

$ lxc network edit lxdbr0

Esto editará su configuración en un editor de terminal. Se verá algo como esto:

config:
  ipv4.address: 10.216.134.1/24
  ipv4.nat: "true"
  ipv6.address: none
  ipv6.nat: "true"
name: lxdbr0
type: bridge

Agregue tres líneas:

config:
  ipv4.address: 10.216.134.1/24
  ipv4.nat: "true"
  ipv6.address: none
  ipv6.nat: "true"
  raw.dnsmasq: |
    auth-zone=lxd
    dns-loop-detect
name: lxdbr0
type: bridge

y esto debería causar dnsmasq, que está siendo ejecutado por lxd, detectar bucles DNS. Esto, al menos para mí, resolvió el problema y se detuvo systemd-resolvedy dnsmasqusó el 100% de la CPU.


2

Aquí hay una solución para (X) Ubuntu 18.04 Bionic.

Instalar dnsmasq

sudo apt install dnsmasq

Deshabilite el oyente resuelto systemd en el puerto 53 (no toque /etc/systemd/resolved.conf, porque puede sobrescribirse en la actualización):

$ cat /etc/systemd/resolved.conf.d/noresolved.conf 
[Resolve]
DNSStubListener=no

y reiniciarlo

$ sudo systemctl restart systemd-resolved

(alternativamente deshabilítelo por completo $ sudo systemctl disable systemd-resolved.service )

Elimine /etc/resolv.conf y vuelva a crear. Esto es importante, porque resolv.conf es un enlace simbólico a /run/systemd/resolve/stub-resolv.conf de forma predeterminada. Si no va a eliminar el enlace simbólico, systemd sobrescribirá el archivo al reiniciarlo (¡aunque hayamos deshabilitado systemd-resolve!). También NetworkManager (NM) verifica si es un enlace simbólico para detectar la configuración resuelta por el sistema.

$ sudo rm /etc/resolv.conf
$ sudo touch /etc/resolv.conf

Deshabilite la sobrescritura de /etc/resolv.conf por parte de NM (también hay una opción rc-manager, pero no funciona, a pesar de que se describe en el manual de NM):

$ cat /etc/NetworkManager/conf.d/disableresolv.conf 
[main]
dns=none

y reiniciarlo:

$ sudo systemctl restart NetworkManager

Dígale a dnsmasq que use resolv.conf de NM:

$ cat /etc/dnsmasq.d/nmresolv.conf 
resolv-file=/var/run/NetworkManager/resolv.conf

y reiniciarlo:

$ sudo systemctl restart dnsmasq

Use dnsmasq para resolver:

$ cat /etc/resolv.conf 
# Use local dnsmasq for resolving
nameserver 127.0.0.1

1
Después de probar algunas otras soluciones, la suya fue la que resolvió mi problema en Linux Mint 19.1. ¡Muchas gracias!
Renan Lazarotto

1

Lo resolví de esta manera:

Agregue o descomente la siguiente línea en / etc / default / dnsmasq :

IGNORE_RESOLVCONF=yes

Cree su propio archivo resolv (/etc/resolv.personal) para definir servidores de nombres. Puedes usar cualquier servidor de nombres aquí. Tomé dos de https://www.opennic.org

nameserver 5.132.191.104
nameserver 103.236.162.119

En /etc/dnsmasq.conf agregue o descomente la siguiente línea:

resolv-file=/etc/resolv.personal

Luego reinicie dnsmasq y desactive la resolución predeterminada: systemd-resolve.

sudo service dnsmasq restart

sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved

1

No estoy seguro de por qué ambos servicios intentan usar la misma dirección. Tal vez pueda organizarlos como en mi caso en Xubuntu 18.04.1, donde su configuración es la siguiente:

xy@zq:~$ sudo netstat -tulpn | grep 53
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      13549/systemd-resol 
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      9632/dnsmasq 

Para hacer que systemd resuelva usando mi dnsmasq simplemente configuré:

#/etc/systemd/resolved.conf 
[Resolve]
DNS=127.0.0.1

En mi configuración de dnsmasq configuro mis servidores de nombres externos:

#/etc/dnsmasq.conf
nameserver x.x.x.x
nameserver y.y.y.y

Después de reiniciar todo:

# sudo systemctl restart systemd-resolved.service
# sudo systemctl restart dnsmasq.service

systemd-resolve establecerá el servidor DNS predeterminado en dnsmasq en:

#/etc/resolv.conf
nameserver 127.0.0.1

Esa última línea me sorprendió, así que lo busqué. Parece que en tu caso, /etc/resolv.confes un enlace simbólico a /run/systemd/resolve/resolv.conf. Aparentemente, este es uno de los cuatro (!) Modos diferentes posibles en los que systemd-resolve podría estar operando. Supongo que depende de cómo lo configure su distribución, es decir, es cierto para su Xubuntu 18.04.1, pero puede ser diferente en otros sistemas.
sourcejedi

0

No pude hacer que dnsmasq comenzara a usar las soluciones que se encuentran en línea, es decir, deshabilitar systemd-resolve, cambiar dnsmasq.conf para hacer "bind dynamic" en lugar de "bind interfaces". Pude hacer que se iniciara en el arranque haciendo que dnsmasq start After network-online.service en lugar de network.service:

[Unit]
Description=dnsmasq - A lightweight DHCP and caching DNS server
Requires=network.target
Wants=nss-lookup.target
Before=nss-lookup.target
After=network-online.target #This line changed

Gracias por publicar el enfoque que está utilizando. Tenga en cuenta que normalmente cuando realiza un pedido contra network-online.target, también se supone que debe agregar network-online.target a la lista de Wants=. freedesktop.org/wiki/Software/systemd/NetworkTarget
sourcejedi

0

Esto es lo que funcionó para mí (después de horas de dolor) en Ubuntu 18.10 Cosmic Cuttlefish. Hice esto para aprovechar dnsmasqel mecanismo de almacenamiento en caché comparativamente más robusto y para evitar vulnerabilidades de resolución de NGINX . Tenga en cuenta que estoy usando la edición Ubuntu Server (no NetworkManager/ nmcli, solo systemd-networkd) y esto se ejecuta en AWS EC2, por lo que también necesitaba mantener DNS y DHCP funcionando con el dominio de búsqueda EC2 predeterminado. No quería deshabilitarlo por systemd-resolvedcompleto porque no tengo idea de cómo eso podría afectar futuras actualizaciones. Todo aquí se ejecuta como root / sudo a menos que se indique lo contrario (esto ocurre de manera predeterminada cuando se pasa como Datos de usuario EC2).

## Configure dnsmasq to work with systemd-resolved
# Set static hostname with hostnamectl
hostnamectl set-hostname mydomainname
# Add an entry for the hostname to /etc/hosts
tee --append /etc/hosts <<EOF
127.0.0.1 mydomainname
EOF
# Disable stub listener for resolvconf and set DNS to loopback
tee --append /etc/systemd/resolved.conf <<EOF
DNSStubListener=no
DNS=127.0.0.1
EOF
# Tell dnsmasq to ignore resolvconf
tee --append /etc/default/dnsmasq <<EOF
IGNORE_RESOLVCONF=yes
EOF
# Create dropin directory
mkdir -p /etc/systemd/system/dnsmasq.service.d
# Create systemd dropin to make sure systemd-resolved stops before dnsmasq starts
tee /etc/systemd/system/dnsmasq.service.d/resolved-fix.conf <<EOF
[Unit]
After=systemd-resolved.service
[Service]
ExecStartPre=bin/systemctl stop systemd-resolved.service
ExecStartPost=bin/systemctl start systemd-resolved.service
EOF
# Create custom resolvconf with name servers (I usec cloudflare)
tee /etc/resolv.mydomainname <<EOF
nameserver 1.1.1.1
nameserver 1.0.0.1 
nameserver [2606:4700:4700::1111] 
nameserver [2606:4700:4700::1001] 
EOF
# Configure dnsmasq
tee /etc/dnsmasq.d/mydomainname.conf <<EOF
# Region comes from:
# EC2_AVAIL_ZONE=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)
# EC2_REGION=${EC2_AVAIL_ZONE%?}
domain=$EC2_REGION.compute.internal
resolv-file=/etc/resolv.mydomainname
listen-address=127.0.0.1
port=53
interface=lo
bind-dynamic
domain-needed
bogus-priv
dnssec
dns-forward-max=300
cache-size=1000
neg-ttl=3600
EOF
# Reload to pick up dropin
systemctl daemon-reload
# Stop systemd-resolved
systemctl stop systemd-resolved
# Start dnsmasq
systemctl restart dnsmasq

Verifique que 127.0.0.1#53se está utilizando para la resolución y DNSSEC está trabajando con algo comodig +trace facebook.com


¿Sabes por qué todavía necesitas este archivo de unidad dropin hack, cuando lo has configurado DNSStubListener=no?
sourcejedi
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.