Como evitar conflitos entre dnsmasq e systemd-resolved?


57

Instalei recentemente o dnsmasq para atuar como servidor DNS na minha rede local. O dnsmasq escuta na porta 53, que já está em uso pelo ouvinte de stub DNS local em systemd-resolved .

Apenas parar o systemd-resolved e depois reiniciá-lo após a execução do dnsmasq resolve esse problema. Mas ele retorna após uma reinicialização: systemd-resolved é iniciado com preferência e o dnsmasq não inicia porque a porta 53 já está em uso.

A primeira pergunta óbvia, eu acho, é como fazer com que o resolvido pelo systemd entenda que ele não deve iniciar o ouvinte de stub do DNS local e, assim, manter a porta 53 para uso pelo dnsmasq?

Uma questão mais interessante, no entanto, é como os dois serviços geralmente devem trabalhar juntos. Eles são feitos para trabalhar lado a lado ou são resolvidos pelo sistema apenas da maneira que alguém usa dnsmasq?


4
Você já tentou desativar via sudo systemctl disable systemd-resolved? dnsmasq se configurado corretamente deve lidar com a resolução de domínio, eu acho.
Pbhj 6/06

11
Você também deve emitir sudo systemctl stop systemd-resolvedse estiver em execução. Use sudo systemctl status systemd-resolvedpara verificar
Bruce Barnett

Respostas:


42

A partir do systemd 232 (lançado em 2017), você pode editar /etc/systemd/resolved.confe adicionar esta linha:

DNSStubListener=no

Isso desativará a ligação à porta 53.

A opção é descrita em mais detalhes na página de manual resolved.conf .

Você pode encontrar a versão do systemd com a qual seu sistema está executando:

systemctl --version

2
Fazer isso vez da ligação à Internet
Ravinder

2
@ Ravinder: Desabilitará o servidor DNS do systemd, sim. Se o seu sistema estiver configurado para usar este servidor, parecerá que a conexão com a Internet para de funcionar (porque você o desativou). Você precisará configurar seu sistema para usar outro servidor DNS. Normalmente, as pessoas desativam a ligação na porta 53 porque, em vez disso, desejam executar seu próprio servidor DNS, portanto não há problema.
Malvineous 30/08/19

18

Você pode desativar o systemd-resolvedcarregamento na inicialização usando sudo systemctl disable systemd-resolved.

Se você quiser executar os dois juntos, poderá redirecionar o systemd-resolvedpara usar o host local como o servidor de nomes principal. Isso garantirá que todas as consultas sejam direcionadas ao dnsmasq para resolução antes de atingir o servidor DNS externo. Isso pode ser feito adicionando a linha nameserver 127.0.0.1na parte superior do seu /etc/resolv.confarquivo. Isso também desativará o cache local do systemd.

Você pode ler mais no wiki do Arch Linux . Copiei isso de lá e ele cobre muito bem.

No entanto, isso não evita confiavelmente o erro no momento da inicialização, ou seja, o dnsmasq ainda falhará se o resolvido pelo systemd for iniciado primeiro. Se a sua versão systemdfor nova o suficiente, use a resposta de Malvineous . Se sua versão do systemdé muito antiga, você pode solucionar esse problema modificando a unidade dnsmasq: na [Unit]seção, inclua Before=systemd-resolved.

Depois disso, se quiser, você pode criar um separado /etc/dnsmasq-resolv.confarquivo para os servidores de nomes a montante e passá-lo usando o -rou --resolv-fileopção, ou adicionar os servidores de nomes de upstream para o arquivo de configuração dnsmasq e usar o -Rou --no-resolvopção. Dessa forma, você só tem o host local no seu /etc/resolv.confe tudo passa pelo dnsmasq.


2
Eu tive que remover meu comentário anterior, pois não posso mais confirmar que isso resolveu o problema. Eu li o wiki antes de perguntar aqui e já tinha um arquivo resolv.conf com o servidor de nomes localhost na parte superior. Isso não ajudou. Segui suas instruções para mover os servidores de nomes externos para um segundo arquivo do dnsmasq. Após a primeira reinicialização, o dnsmasq foi carregado primeiro para que o problema não surgisse. Na segunda reinicialização, o resolvido foi carregado primeiro e o dnsmasq saiu com o erro descrito. Estou tão longe quanto antes.
vic

6
Na unidade dnsmasq, coloque a Before=systemd-resolvedna [Unit]seção Dessa forma, o dnsmasq sempre será iniciado primeiro.
Munir

7

A julgar pelas páginas de manual do systemd, não se destina a ser capaz de desativar manualmente o servidor DNS stub. Curiosamente, só notei o problema descrito após a atualização do systemd de 230 para 231.

Desabilitar o systemd-resolved não era uma opção para mim, porque eu preciso lidar com servidores DNS upstream recebidos por meio do DHCP.

Minha solução foi fazer o dnsmasq parar o systemd-resolved antes de iniciar e iniciá-lo novamente novamente.

Eu criei uma configuração drop-in em /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

Parece ser uma solução bastante hackeada, mas funciona.


2
Ei, na verdade, esta solução é bastante lisa. É persistente mesmo após as atualizações do pacote, pois mantém o arquivo da unidade original. Bem feito. O seguinte é declarado DNSStubListenerno manual resolved.conf: "Observe que o ouvinte de stub do DNS é desativado implicitamente quando seu endereço de escuta e porta já estão em uso." É por isso que esse método funciona bem, eu acho.
precisa

Uma solução ++ !!!
S2 #

Eu tive que mudar / usr / bin / systemctl para / bin / systemctl
Bruce Barnett

5

Acabei de ativar a opção "bind-interfaces" removendo '#' no início da linha em /etc/dnsmasq.conf.

Consegui iniciar o dnsmasq novamente:

  • o dnsmasq liga a porta DNS em todas as interfaces (incluindo 127.0.0.1), porta 53,
  • O systemd-resolv continua ouvindo no 127.0.0. 53 : 53

Fui apontado para esta solução por esta discussão resolvida: adicione uma opção para desativar o resolvedor de stub


Esta é a melhor resposta para o que é um incêndio de lixeira. Não há razão para o systemd estar ocupando essa porta, mesmo em loopback.
Jonathan S. Fisher


2

Se você estiver usando uma instalação padrão do Ubuntu 18.04, isso pode ser causado por um conflito entre systemd-resolved(o servidor DNS padrão) e dnsmasq. Se você dnsmasqse instalou deliberadamente porque o queria explicitamente, uma das outras respostas a esta pergunta, explicando como desabilitar systemd-resolved, provavelmente será útil para você. Se você não instalou explicitamente dnsmasq, é provável que esteja no lugar porque você está usando lxd. Pode ser porque você realmente usa lxdpara gerenciar contêineres, mas é mais provável que os snaps usem lxdpara protegê-lo quando os aplicativos são instalados. Da minha perspectiva, quero manter dnsmasq(porque lxdquer), mas também quero mantersystemd-resolved como servidor DNS (porque é o que a equipe do Ubuntu escolheu e eu confio neles mais do que em mim).

Então, isso parece ser um lxdproblema no coração. Em caso afirmativo, a maneira como eu o corrigi , de acordo com uma postagem da lista de discussão lxd-users , é esta:

$ lxc network edit lxdbr0

Isso editará sua configuração em um editor de terminal. Vai parecer algo assim:

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

Adicione três linhas a ele:

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 isso deve causar dnsmasq, que está sendo executado lxd, detectar loops de DNS. Isso, pelo menos para mim, resolveu o problema e parou systemd-resolvede dnsmasqusando 100% da CPU.


2

Aqui está a solução para (X) Ubuntu 18.04 Bionic.

Instale o dnsmasq

sudo apt install dnsmasq

Desative o ouvinte resolvido pelo sistema na porta 53 (não toque em /etc/systemd/resolved.conf, pois pode ser substituído na atualização):

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

e reinicie

$ sudo systemctl restart systemd-resolved

(alternativamente, desative-o completamente por $ sudo systemctl disable systemd-resolved.service )

Exclua /etc/resolv.conf e crie novamente. Isso é importante, porque resolv.conf é um link simbólico para /run/systemd/resolve/stub-resolv.conf por padrão. Se você não excluir o link simbólico, o arquivo será substituído pelo systemd na reinicialização (mesmo que tenhamos desabilitado o systemd-resolved!). O NetworkManager (NM) também verifica se é um link simbólico para detectar a configuração resolvida pelo sistema.

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

Desative a substituição do /etc/resolv.conf pelo NM (também existe uma opção rc-manager, mas não funciona, apesar de ser descrito no manual do NM):

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

e reinicie-o:

$ sudo systemctl restart NetworkManager

Diga ao dnsmasq para usar o resolv.conf do NM:

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

e reinicie-o:

$ sudo systemctl restart dnsmasq

Use dnsmasq para resolver:

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

11
Depois de tentar algumas outras soluções, a sua foi a que resolveu meu problema no Linux Mint 19.1. Muito obrigado!
Renan Lazarotto

1

Eu resolvi assim:

Adicione ou remova o comentário da seguinte linha em / etc / default / dnsmasq :

IGNORE_RESOLVCONF=yes

Crie seu próprio arquivo de resolução (/etc/resolv.personal) para definir servidores de nomes. Você pode usar qualquer servidor de nomes aqui. Tirei duas de https://www.opennic.org

nameserver 5.132.191.104
nameserver 103.236.162.119

No /etc/dnsmasq.conf, adicione ou descomente a seguinte linha:

resolv-file=/etc/resolv.personal

Em seguida, reinicie o dnsmasq e desative o resolvedor padrão: systemd-resolved.

sudo service dnsmasq restart

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

1

Não sei por que os dois serviços estão tentando usar o mesmo endereço. Talvez você possa organizá-los como no meu caso no Xubuntu 18.04.1, onde a configuração deles é a seguinte:

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 resolver o systemd usando meu dnsmasq, basta definir:

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

Na minha configuração do dnsmasq, defino meus servidores de nomes externos:

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

Depois de reiniciar tudo:

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

systemd-resolved definirá o servidor DNS padrão como dnsmasq em:

#/etc/resolv.conf
nameserver 127.0.0.1

Essa última linha me surpreendeu, então eu procurei. Parece que, no seu caso, /etc/resolv.confé um link simbólico para /run/systemd/resolve/resolv.conf. Aparentemente, este é um dos quatro (!) Possíveis modos diferentes em que o systemd-resolvido pode estar operando. Acho que depende de como a sua distribuição o configura, ou seja, é verdade para o seu Xubuntu 18.04.1, mas pode ser diferente em outros sistemas.
sourcejedi

0

Não consegui que o dnsmasq começasse a usar as soluções encontradas online, ou seja, desabilitando o systemd-resolved, alterando o dnsmasq.conf para fazer "bind dynamic" em vez de "bind interfaces". Consegui fazê-lo iniciar na inicialização com o dnsmasq start After network-online.service em vez 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

Obrigado por postar a abordagem que você está usando. Observe que, normalmente, quando você faz o pedido em network-online.target, também deve adicionar network-online.target à lista de Wants=. freedesktop.org/wiki/Software/systemd/NetworkTarget
sourcejedi

0

Aqui está o que funcionou para mim (depois de horas de dor) no Ubuntu 18.10 Cosmic Cuttlefish. Fiz isso para aproveitar dnsmasqo mecanismo de armazenamento em cache comparativamente mais robusto e evitar as vulnerabilidades do resolver NGINX . Observe que estou usando a edição Ubuntu Server (no NetworkManager/ nmcli, just systemd-networkd) e ela está sendo executada no AWS EC2, então eu também precisava manter o DNS e o DHCP trabalhando com o domínio de pesquisa padrão do EC2. Não queria desabilitar systemd-resolvedcompletamente, porque não tenho idéia de como isso pode afetar as atualizações futuras. Tudo aqui é executado como root / sudo, a menos que seja indicado de outra forma (isso acontece por padrão quando transmitido como Dados do Usuário do 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 se 127.0.0.1#53está sendo usado para resolução e se o DNSSEC está funcionando com algo comodig +trace facebook.com


Você sabe por que você ainda precisa desse arquivo de unidade dropin hack, quando você definiu DNSStubListener=no?
sourcejedi
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.