Come evitare i conflitti tra dnsmasq e systemd risolti?

Di recente ho installato dnsmasq per fungere da server DNS per la mia rete locale. dnsmasq è in ascolto sulla porta 53 che è già in uso dal listener di stub DNS locale da systemd risolto .

Basta arrestare systemd-risolto e quindi riavviarlo dopo l'esecuzione di dnsmasq risolve questo problema. Ma ritorna dopo un riavvio: systemd-resolved viene avviato con preferenza e dnsmasq non si avvia perché la porta 53 è già in uso.

La prima domanda ovvia, immagino, è come posso far capire meglio a systemd-resolved che non dovrebbe avviare il listener di stub DNS locale e quindi mantenere la porta 53 per l'uso da parte di dnsmasq?

Una domanda più interessante, tuttavia, è come i due servizi sono generalmente destinati a lavorare insieme. Sono anche pensati per lavorare fianco a fianco o se il sistema sta usando dnsmasq?

A partire da systemd 232 (rilasciato nel 2017) è possibile modificare /etc/systemd/resolved.confe aggiungere questa riga:

DNSStubListener=no

Questo disattiverà il binding alla porta 53.

L'opzione è descritta in maggior dettaglio nella manpage resolved.conf .

Puoi trovare la versione di systemd con cui il tuo sistema è in esecuzione:

systemctl --version

È possibile disabilitare il systemd-resolvedcaricamento all'avvio tramite sudo systemctl disable systemd-resolved.

Se si desidera eseguire i due insieme, è possibile reindirizzare systemd-resolvedper utilizzare localhost come nameserver primario. Ciò assicurerà che tutte le query siano indirizzate a dnsmasq per la risoluzione prima di colpire il server DNS esterno. Questo può essere fatto aggiungendo la riga nameserver 127.0.0.1nella parte superiore del /etc/resolv.conffile. Questo disabiliterà anche la memorizzazione nella cache locale di systemd.

Puoi leggere di più sul wiki di Arch Linux . L'ho copiato da lì e lo copre abbastanza bene.

Tuttavia, ciò non evita in modo affidabile l'errore al momento dell'avvio, ovvero dnsmasq continuerà a fallire se il sistema risolto si avvia per primo. Se la tua versione di systemdè abbastanza nuova, usa la risposta di Malvineous . Se la tua versione di systemdè troppo vecchia, puoi aggirare questo problema modificando l'unità dnsmasq: nella [Unit]sezione, aggiungi Before=systemd-resolved.

Dopo di ciò, se si desidera, è possibile creare un separato /etc/dnsmasq-resolv.conffile per i server dei nomi a monte ea passarlo utilizzando l' -ro --resolv-fileopzione, o aggiungere i server dei nomi a monte per il file di configurazione dnsmasq e utilizzare il -Ro --no-resolvopzione. In questo modo hai solo il localhost nel tuo /etc/resolv.confe tutto passa attraverso dnsmasq.

A giudicare dalle manpage di systemd non si intende poter disabilitare manualmente il server DNS di stub. È interessante notare che ho notato il problema descritto solo dopo aver aggiornato systemd da 230 a 231.

Disabilitare systemd-resolved non è stata un'opzione per me perché ne ho bisogno per gestire i server DNS upstream ricevuti tramite DHCP.

La mia soluzione consisteva nel rendere dnsmasq stop systemd risolto prima di avviarlo e riavviarlo successivamente.

Ho creato una configurazione drop-in in /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

Questa sembra essere una soluzione piuttosto hacker ma funziona.

Ho appena abilitato l'opzione "interfacce bind" rimuovendo '#' all'inizio della riga in /etc/dnsmasq.conf.

Sono stato in grado di riavviare dnsmasq:

• dnsmasq collega la porta DNS su tutte le interfacce (inclusa 127.0.0.1) porta 53,
• systemd-resolv continua ad ascoltare su 127.0.0. 53 : 53

Questa discussione è stata indicata da questa discussione risolta: aggiungere un'opzione per disabilitare il risolutore di stub

Ci sarà un'opzione nella systemdversione 232per disabilitare il listener stub. Vedi https://github.com/systemd/systemd/pull/4061 .

Se stai usando un'impostazione predefinita di Ubuntu 18.04, ciò potrebbe essere causato da un conflitto tra systemd-resolved(il server DNS predefinito) e dnsmasq. Se ti sei installato dnsmasqdeliberatamente perché lo volevi esplicitamente, allora una delle altre risposte a questa domanda, spiegando come disabilitare systemd-resolved, sarà probabilmente buona per te. Se non hai installato esplicitamente dnsmasq, è probabile che sia installato perché lo stai utilizzando lxd. Ciò potrebbe essere dovuto al fatto che utilizzi effettivamente lxdper gestire i contenitori, ma è molto probabilmente perché gli snap utilizzano lxdper proteggerti quando vengono installate le app. Dal mio punto di vista, voglio mantenere dnsmasq(perché lo lxdvuole) ma voglio anche manteneresystemd-resolved come server DNS (perché è quello che il team di Ubuntu ha scelto e mi fido di loro più di me).

Quindi, questo sembra essere un lxdproblema profondo. In tal caso, il modo in cui l'ho risolto, come per un post della mailing list di lxd-users , è questo:

$ lxc network edit lxdbr0

Questo modificherà la tua configurazione in un editor terminale. Sarà simile a questo:

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

Aggiungi tre righe ad esso:

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

e ciò dovrebbe causare dnsmasq, che viene gestito da lxd, rilevare loop DNS. Questo, almeno per me, ha risolto il problema e si è fermato systemd-resolvede dnsmasqusando una CPU al 100%.

Ecco la soluzione per (X) Ubuntu 18.04 Bionic.

Installa dnsmasq

sudo apt install dnsmasq

Disabilita il listener risolto da systemd sulla porta 53 (non toccare /etc/systemd/resolved.conf, perché potrebbe essere sovrascritto durante l'aggiornamento):

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

e riavviarlo

$ sudo systemctl restart systemd-resolved

(in alternativa disabilitarlo completamente entro $ sudo systemctl disable systemd-resolved.service )

Elimina /etc/resolv.conf e crea di nuovo. Questo è importante, perché resolv.conf è un collegamento simbolico a /run/systemd/resolve/stub-resolv.conf per impostazione predefinita. Se non si eliminerà il collegamento simbolico, il file verrà sovrascritto da systemd al riavvio (anche se abbiamo disabilitato systemd-risolto!). Inoltre NetworkManager (NM) verifica se si tratta di un collegamento simbolico per rilevare la configurazione risolta dal sistema.

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

Disabilita la sovrascrittura di /etc/resolv.conf da NM (esiste anche un'opzione rc-manager, ma non funziona, nonostante sia descritta nel manuale NM):

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

e riavviarlo:

$ sudo systemctl restart NetworkManager

Di 'a dnsmasq di usare resolv.conf da NM:

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

e riavviarlo:

$ sudo systemctl restart dnsmasq

Utilizzare dnsmasq per la risoluzione:

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

L'ho risolto in questo modo:

Aggiungi o decommenta la seguente riga in / etc / default / dnsmasq :

IGNORE_RESOLVCONF=yes

Crea il tuo file resolv (/etc/resolv.personal) per definire i nameserver. Puoi usare qualsiasi nameserver qui. Ne ho presi due da https://www.opennic.org

nameserver 5.132.191.104
nameserver 103.236.162.119

In /etc/dnsmasq.conf aggiungere o rimuovere il commento dalla seguente riga:

resolv-file=/etc/resolv.personal

Quindi riavviare dnsmasq e disabilitare il resolver predefinito: systemd-resolved.

sudo service dnsmasq restart

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

Non sono sicuro del motivo per cui entrambi i servizi stanno cercando di utilizzare lo stesso indirizzo. Forse puoi sistemarli come nel mio caso su Xubuntu 18.04.1, dove la loro configurazione è la seguente:

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 

Per rendere systemd risolto usando il mio dnsmasq ho appena impostato:

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

Nella mia configurazione di dnsmasq ho impostato i miei nameserver esterni:

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

Dopo aver riavviato tutto:

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

systemd-resolved imposterà il server DNS predefinito su dnsmasq in:

#/etc/resolv.conf
nameserver 127.0.0.1

Non sono riuscito a ottenere dnsmasq per iniziare a utilizzare le soluzioni trovate online, ovvero disabilitare il sistema risolto, cambiando dnsmasq.conf per fare "bind dynamic" anziché "bind interfaces". Sono stato in grado di avviarlo all'avvio facendo partire dnsmasq After network-online.service anziché 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

Ecco cosa ha funzionato per me (dopo ore di dolore) in Ubuntu 18.10 Cosmic Cuttlefish. L'ho fatto per sfruttare il dnsmasqmeccanismo di cache relativamente più efficace e per evitare vulnerabilità del resolver NGINX . Nota che sto usando Ubuntu Server Edition (no NetworkManager/ nmcli, solo systemd-networkd) e questo è in esecuzione su AWS EC2, quindi dovevo anche far funzionare DNS e DHCP con il dominio di ricerca EC2 predefinito. Non volevo disabilitare del systemd-resolvedtutto perché non ho idea di come ciò possa influire sui futuri aggiornamenti. Tutto qui viene eseguito come root / sudo se non diversamente specificato (ciò accade per impostazione predefinita quando viene passato come Dati utente 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

Verifica che 127.0.0.1#53venga utilizzato per la risoluzione e che DNSSEC funzioni con qualcosa del generedig +trace facebook.com