Como evitar conflitos entre o dnsmasq e o systemd-resolved?

34

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

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

A primeira pergunta óbvia, eu acho, é como eu faço melhor que o systemd-resolved entenda que ele não deve iniciar o listener de stub de 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 funcionam juntos. Eles estão mesmo destinados a trabalhar lado a lado ou são resolvidos pelo sistema apenas no modo como se está usando dnsmasq?

    
por vic 17.08.2016 / 21:37

9 respostas

24

A partir do systemd 232 (lançado em 2017), é possível editar /etc/systemd/resolved.conf e adicione esta linha:

DNSStubListener=no

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

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

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

systemctl --version
    
por 12.04.2017 / 09:34
14

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

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

Você pode ler mais no wiki do Arch Linux . Eu copiei isso de lá e o cobre bastante bem.

Depois disso, se desejar, você pode criar um arquivo /etc/dnsmasq-resolv.conf separado para os servidores de nomes upstream e passá-lo usando a opção -r ou --resolv-file , ou adicionar os nameservers upstream ao arquivo de configuração dnsmasq e usar o -R ou --no-resolv opção. Desta forma você só tem o localhost no seu /etc/resolv.conf e tudo passa pelo dnsmasq.

    
por 17.08.2016 / 23:31
6

A julgar pelos manpages do systemd, não se destina a desativar manualmente o servidor DNS stub. Curiosamente eu só notei o problema descrito após a atualização do systemd de 230 para 231.

Desativar systemd-resolved não era uma opção para mim, porque eu preciso disso para lidar com servidores DNS enviados por meio de DHCP.

Minha solução foi fazer com que o dnsmasq parasse de resolver o sistema antes de iniciar e iniciar novamente.

Eu criei uma configuração de 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

Esta parece ser uma solução um tanto hackeada, mas funciona.

    
por 21.08.2016 / 15:34
4

Haverá uma opção em systemd version 232 para desativar o ouvinte de stub. Veja o link .

    
por 19.10.2016 / 18:30
3

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

Consegui iniciar novamente o dnsmasq:

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

Eu fui apontado para esta solução por esta discussão resolvido: adicione uma opção para desativar o resolvedor de stub

    
por 28.10.2016 / 11:44
1

Se você estiver usando uma configuraçã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ê instalou dnsmasq deliberadamente porque queria explicitamente, então uma das outras respostas a essa pergunta, explicando como desabilitar systemd-resolved , provavelmente será boa para você. Se você não instalou explicitamente dnsmasq , provavelmente está em vigor porque você está usando lxd . Isso pode ser porque você realmente usa lxd para gerenciar contêineres, mas é mais provável que seja porque os snaps usam lxd para proteger você quando os aplicativos são instalados. Do meu ponto de vista, quero manter dnsmasq (porque lxd quer), mas também quero manter systemd-resolved como o servidor DNS (porque é o que a equipe do Ubuntu escolheu e confio neles mais do que eu). / p>

Então, isso parece ser um problema lxd no coração. Se assim for, a maneira como eu corrigi-lo, como por uma lista de discussão lxd-users post a>, é isto:

$ lxc network edit lxdbr0

Isto irá editar sua configuração em um editor de terminal. Será algo parecido com isto:

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 por lxd , para detectar loops DNS. Isso, pelo menos para mim, resolveu o problema e parou systemd-resolved e dnsmasq usando 100% da CPU.

    
por 04.09.2018 / 13:25
0

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 os servidores de nomes. Você pode usar qualquer servidor de nomes aqui. Eu peguei dois do link

nameserver 5.132.191.104
nameserver 103.236.162.119

Em /etc/dnsmasq.conf adicione ou remova o comentário da 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
    
por 22.08.2018 / 22:36
0

Não sei por que ambos os 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 sua configuração é 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 tornar o systemd resolvido usando o meu dnsmasq eu acabei de definir:

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

Na minha configuração do dnsmasq, eu configurei 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 irá definir o servidor DNS padrão para dnsmasq em:

#/etc/resolv.conf
nameserver 127.0.0.1
    
por 17.09.2018 / 12:23
0

Não consegui fazer com que o dnsmasq começasse a usar as soluções encontradas on-line, ou seja, desabilitar o systemd-resolved, alterando o dnsmasq.conf para fazer "bind dynamic" em vez de "bind interfaces". Eu era capaz de fazê-lo para iniciar na inicialização, tendo 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
    
por 17.11.2018 / 16:59