web-dev-qa-db-fra.com

Comment éviter les conflits entre dnsmasq et résolus par systemd?

J'ai récemment installé dnsmasq pour agir comme serveur DNS pour mon réseau local. dnsmasq écoute sur le port 53 qui est déjà utilisé par l'écouteur de stub DNS local depuis résolu par systemd .

L'arrêt de la résolution de systemd et le redémarrage après l'exécution de dnsmasq résout ce problème. Mais il revient après un redémarrage: la résolution de systemd est démarrée avec préférence et dnsmasq ne démarrera pas car le port 53 est déjà utilisé.

La première question évidente, je suppose, est de savoir comment faire pour que systemd-resolve comprenne qu'il ne doit pas démarrer l'écouteur de stub DNS local et donc conserver le port 53 pour une utilisation par dnsmasq?

Une question plus intéressante, cependant, est de savoir comment les deux services sont généralement censés fonctionner ensemble. Sont-ils même destinés à fonctionner côte à côte ou sont-ils résolus par le système de la même manière si l'on utilise dnsmasq?

66
vic

Depuis systemd 232 (sorti en 2017), vous pouvez modifier /etc/systemd/resolved.conf et ajoutez cette ligne:

DNSStubListener=no

Cela désactivera la liaison au port 53.

L'option est décrite plus en détail dans la page de manuel resolue.conf .

Vous pouvez trouver la version systemd avec laquelle votre système fonctionne:

systemctl --version
52
Malvineous

Vous pouvez désactiver systemd-resolved du chargement au démarrage à l'aide de Sudo systemctl disable systemd-resolved.

Si vous souhaitez exécuter les deux ensemble, vous pouvez rediriger le systemd-resolved pour utiliser l'hôte local comme serveur de noms principal. Cela garantira que toutes les requêtes sont dirigées vers dnsmasq pour résolution avant de frapper le serveur DNS externe. Cela peut être fait en ajoutant la ligne nameserver 127.0.0.1 en haut de votre /etc/resolv.conf fichier. Cela désactivera également la mise en cache locale de systemd.

Vous pouvez en savoir plus sur le wiki Arch Linux . J'ai copié cela à partir de là et ça le couvre assez bien.

Cependant, cela n'évite pas de manière fiable l'erreur au démarrage, c'est-à-dire que dnsmasq échouera toujours si la résolution de systemd se produit en premier. Si votre version de systemd est suffisamment nouvelle, utilisez la réponse par Malvineous . Si votre version de systemd est trop ancienne, vous pouvez contourner ce problème en modifiant l'unité dnsmasq: dans le [Unit] section, ajoutez Before=systemd-resolved.

Après cela, si vous le souhaitez, vous pouvez créer un /etc/dnsmasq-resolv.conf fichier pour les serveurs de noms en amont et passez-le en utilisant le -r ou --resolv-file, ou ajoutez les serveurs de noms en amont au fichier de configuration dnsmasq et utilisez -R ou --no-resolv option. De cette façon, vous n'avez que l'hôte local dans votre /etc/resolv.conf et tout passe par dnsmasq.

19
Munir

A en juger par les pages de manuel systemd, il n'est pas prévu de pouvoir désactiver manuellement le serveur DNS de stub. Fait intéressant, je n'ai remarqué le problème décrit qu'après la mise à niveau de systemd de 230 à 231.

La désactivation de la résolution de systemd n'était pas une option pour moi car j'en ai besoin pour gérer les serveurs DNS en amont reçus via DHCP.

Ma solution consistait à faire en sorte que dnsmasq arrête la résolution de systemd avant de le démarrer et de le redémarrer ensuite.

J'ai créé une configuration drop-in dans /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

Cela semble être une solution plutôt hackish mais cela fonctionne.

7
freaker

Je viens d'activer l'option "bind-interfaces" en supprimant '#' au début de la ligne dans /etc/dnsmasq.conf.

J'ai pu redémarrer dnsmasq:

  • dnsmasq lie le port DNS sur toutes les interfaces (y compris 127.0.0.1) le port 53,
  • systemd-resolv continue d'écouter sur 127.0.0. 53 : 53

J'ai été signalé à cette solution par cette discussion résolu: ajoutez une option pour désactiver le résolveur de stub

5
tomtom

Il y aura une option dans systemd version 232 pour désactiver l'écouteur de stub. Voir https://github.com/systemd/systemd/pull/4061 .

4
Christoph

Si vous utilisez une configuration par défaut d'Ubuntu 18.04, cela peut être causé par un conflit entre systemd-resolved (le serveur DNS par défaut) et dnsmasq. Si vous avez installé dnsmasq vous-même délibérément parce que vous le vouliez explicitement, alors l'une des autres réponses à cette question, expliquant comment désactiver systemd-resolved, sera probablement bon pour vous. Si vous n'avez pas installé explicitement dnsmasq, cela est probablement en place parce que vous utilisez lxd. Cela peut être dû au fait que vous utilisez lxd pour gérer les conteneurs, mais il est fort probable que ce soit parce que les snaps utilisent lxd pour vous protéger lorsque les applications sont installées. De mon point de vue, je veux garder dnsmasq (parce que lxd le veut) mais je veux aussi garder systemd-resolved comme serveur DNS (car c'est ce que l'équipe Ubuntu a choisi et je lui fais plus confiance que moi).

Donc, cela semble être un problème de lxd dans l'âme. Si c'est le cas, la façon dont je l'ai corrigé, selon n message de la liste de diffusion lxd-users , est la suivante:

$ lxc network edit lxdbr0

Cela modifiera votre configuration dans un éditeur de terminal. Cela ressemblera à ceci:

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

Ajoutez-y trois lignes:

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

et cela devrait provoquer dnsmasq, qui est exécuté par lxd, pour détecter les boucles DNS. Cela, au moins pour moi, a résolu le problème et a arrêté systemd-resolved et dnsmasq en utilisant 100% CPU.

3
sil

Voici la solution pour (X) Ubuntu 18.04 Bionic.

Installer dnsmasq

Sudo apt install dnsmasq

Désactivez l'écouteur résolu par systemd sur le port 53 (ne touchez pas /etc/systemd/resolved.conf, car il peut être remplacé lors de la mise à niveau):

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

et redémarrez-le

$ Sudo systemctl restart systemd-resolved

(sinon, désactivez-le complètement par $ Sudo systemctl disable systemd-resolved.service)

Supprimez /etc/resolv.conf et créez à nouveau. Ceci est important, car resolv.conf est un lien symbolique vers /run/systemd/resolve/stub-resolv.conf par défaut. Si vous ne supprimez pas le lien symbolique, le fichier sera écrasé par systemd au redémarrage (même si nous avons désactivé systemd-resolu!). NetworkManager (NM) vérifie également s'il s'agit d'un lien symbolique pour détecter la configuration résolue par le système.

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

Désactiver l'écrasement de /etc/resolv.conf par NM (il y a aussi une option rc-manager, mais cela ne fonctionne pas, bien qu'elle soit décrite dans le manuel NM):

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

et redémarrez-le:

$ Sudo systemctl restart NetworkManager

Dites à dnsmasq d'utiliser resolv.conf depuis NM:

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

et redémarrez-le:

$ Sudo systemctl restart dnsmasq

Utilisez dnsmasq pour résoudre:

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

Je ne sais pas pourquoi les deux services essaient d'utiliser la même adresse. Vous pouvez peut-être les organiser comme dans mon cas sur Xubuntu 18.04.1, où leur configuration est la suivante:

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 

Pour que systemd soit résolu en utilisant mon dnsmasq, je viens de définir:

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

Dans ma configuration dnsmasq, j'ai défini mes serveurs de noms externes:

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

Après avoir tout redémarré:

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

résolu par systemd définira le serveur DNS par défaut sur dnsmasq dans:

#/etc/resolv.conf
nameserver 127.0.0.1
1
JonnyTischbein

Je l'ai résolu de cette façon:

Ajoutez ou décommentez la ligne suivante dans /etc/default/dnsmasq:

IGNORE_RESOLVCONF=yes

Créez votre propre fichier resolv (/etc/resolv.personal) pour définir les serveurs de noms. Vous pouvez utiliser n'importe quel serveur de noms ici. J'en ai pris deux https://www.opennic.org

nameserver 5.132.191.104
nameserver 103.236.162.119

Dans /etc/dnsmasq.conf ajoutez ou décommentez la ligne suivante:

resolv-file=/etc/resolv.personal

Redémarrez ensuite dnsmasq et désactivez le résolveur par défaut: résolu par systemd.

Sudo service dnsmasq restart

Sudo systemctl stop systemd-resolved
Sudo systemctl disable systemd-resolved
1
Daniel Pernold

Je n'ai pas réussi à faire en sorte que dnsmasq commence à utiliser les solutions trouvées en ligne, c'est-à-dire à désactiver systemd-resolution, en changeant dnsmasq.conf pour faire "bind dynamic" au lieu de "bind interfaces". J'ai pu le faire démarrer au démarrage en faisant démarrer dnsmasq après network-online.service plutôt que 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
0
omegahelix

Voici ce qui a fonctionné pour moi (après des heures de douleur) dans Ubuntu 18.10 Cosmic Cuttlefish. J'ai fait cela pour profiter du mécanisme de mise en cache comparativement plus robuste de dnsmasq et pour éviter vulnérabilités du résolveur NGINX . Notez que j'utilise l'édition Ubuntu Server (pas de NetworkManager/nmcli, juste systemd-networkd) et cela fonctionne sur AWS EC2, donc je devais également garder DNS et DHCP fonctionnant avec le domaine de recherche EC2 par défaut. Je ne voulais pas désactiver systemd-resolved entièrement parce que je ne sais pas comment cela pourrait affecter les futures mises à jour. Tout ici est exécuté en tant que root/Sudo, sauf indication contraire (cela se produit par défaut lorsqu'il est transmis en tant que données utilisateur 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

Vérifier que 127.0.0.1#53 est utilisé pour la résolution et DNSSEC travaille avec quelque chose comme Dig +trace facebook.com

0
Justin Garrick

Dans mon cas (devant fournir un service DNS à d'autres machines), j'ai pu résoudre le problème en disant à dnsmasq de se lier uniquement à l'interface Ethernet (systemd-resolvd se lie à la boucle) en définissant ....

...
interface=eth0
...
bind-interfaces

dans dnsmasq.conf

0
symcbean