Wie vermeide ich Konflikte zwischen dnsmasq und systemd aufgelöst?

Ich habe kürzlich dnsmasq installiert , um als DNS-Server für mein lokales Netzwerk zu fungieren. dnsmasq lauscht auf Port 53, der bereits vom lokalen DNS-Stub-Listener von systemd-resolved verwendet wird .

Beheben Sie dieses Problem, indem Sie systemd-resolved stoppen und nach der Ausführung von dnsmasq neu starten. Es wird jedoch nach einem Neustart zurückgegeben: systemd-resolved wird mit Voreinstellung gestartet und dnsmasq wird nicht gestartet, da Port 53 bereits belegt ist.

Die erste naheliegende Frage ist wohl, wie ich systemd-aufgelösten Benutzern am besten verständlich machen kann, dass der lokale DNS-Stub-Listener nicht gestartet werden soll und Port 53 für die Verwendung durch dnsmasq beibehalten wird.

Interessanter ist jedoch die Frage, wie die beiden Dienste im Allgemeinen zusammenarbeiten sollen. Sollen sie überhaupt Seite an Seite arbeiten, oder wird das System nur auf die gleiche Weise aufgelöst, wenn man dnsmasq verwendet?

Ab systemd 232 (veröffentlicht in 2017) können /etc/systemd/resolved.confSie diese Zeile bearbeiten und hinzufügen:

DNSStubListener=no

Dadurch wird die Bindung an Port 53 deaktiviert.

Weitere Informationen zu dieser Option finden Sie in der Hilfeseite zu resolved.conf .

Sie können die systemd-Version finden, mit der Ihr System ausgeführt wird:

systemctl --version

Sie können das systemd-resolvedLaden beim Booten mit deaktivieren sudo systemctl disable systemd-resolved.

Wenn Sie die beiden zusammen ausführen möchten, können Sie die umleiten systemd-resolved, um den localhost als primären Nameserver zu verwenden. Dadurch wird sichergestellt, dass alle Abfragen zur Lösung an dnsmasq geleitet werden, bevor der externe DNS-Server aufgerufen wird. Fügen Sie dazu die Zeile nameserver 127.0.0.1oben in Ihre /etc/resolv.confDatei ein. Dadurch wird auch das lokale Caching von systemd deaktiviert.

Weitere Informationen finden Sie im Arch Linux-Wiki . Ich habe das von dort kopiert und es deckt es ziemlich gut ab.

Dies verhindert jedoch nicht zuverlässig den Fehler beim Booten, dh dnsmasq schlägt immer noch fehl, wenn systemd-resolved zuerst gestartet wird. Wenn Ihre Version von systemdneu genug ist, verwenden Sie die Antwort von Malvineous . Wenn Ihre Version von systemdzu alt ist, können Sie dieses Problem umgehen, indem Sie die Einheit dnsmasq ändern: Fügen Sie im [Unit]Abschnitt hinzu Before=systemd-resolved.

Wenn Sie nach diesem, möchten, können Sie eine separate erstellen /etc/dnsmasq-resolv.confDatei für den Upstream - Name - Server und übergeben sie die Verwendung -roder --resolv-fileOption, oder die Upstream - Name - Server - Datei in der dnsmasq Konfiguration hinzuzufügen und die Verwendung -Roder --no-resolvOption. Auf diese Weise haben Sie nur den localhost in Ihrem /etc/resolv.confSystem und alles durchläuft dnsmasq.

Den systemd-Manpages zufolge ist es nicht beabsichtigt, den Stub-DNS-Server manuell zu deaktivieren. Interessanterweise habe ich das beschriebene Problem erst nach einem Upgrade von systemd von 230 auf 231 bemerkt.

Das Deaktivieren von systemd-resolved war für mich keine Option, da ich es benötige, um empfangene Upstream-DNS-Server über DHCP zu verwalten.

Meine Lösung bestand darin, dnsmasq vor dem Start zu stoppen und danach wieder zu starten.

Ich habe eine Drop-In-Konfiguration erstellt 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

Dies scheint eine ziemlich hackige Lösung zu sein, aber es funktioniert.

Ich habe gerade die Option "bind-interfaces" aktiviert, indem ich '#' am Anfang der Zeile in /etc/dnsmasq.conf entfernt habe.

Ich konnte dnsmasq erneut starten:

• DNSMASQ Bind DNS-Port an allen Schnittstellen (einschließlich 127.0.0.1) Port 53,
• systemd-resolv lauscht weiter auf 127.0.0. 53 : 53

Ich wurde durch diese Diskussion auf diese Lösung hingewiesen. Gelöst: Option zum Deaktivieren des Stub-Resolvers hinzufügen

In der systemdVersion gibt es eine Option 232zum Deaktivieren des Stub-Listeners. Siehe https://github.com/systemd/systemd/pull/4061 .

Wenn Sie ein Ubuntu 18.04-Standardsetup verwenden, kann dies durch einen Konflikt zwischen systemd-resolved(dem Standard-DNS-Server) und verursacht werden dnsmasq. Wenn Sie dnsmasqsich absichtlich installiert haben, weil Sie es ausdrücklich wollten, ist eine der anderen Antworten auf diese Frage, in der erklärt wird, wie Sie es deaktivieren systemd-resolved, wahrscheinlich gut für Sie. Wenn Sie es nicht explizit installiert haben dnsmasq, ist es wahrscheinlich vorhanden, weil Sie es verwenden lxd. Dies kann daran liegen, dass Sie lxdContainer tatsächlich verwalten. Am wahrscheinlichsten ist es jedoch, dass Snaps verwendet werden lxd, um Sie bei der Installation von Apps zu schützen. Aus meiner Sicht möchte ich behalten dnsmasq(weil lxdich es will), aber ich möchte auch behaltensystemd-resolved als DNS-Server (weil es das Ubuntu-Team gewählt hat und ich ihnen mehr vertraue als mir selbst).

Das scheint also ein lxdProblem zu sein. Wenn ja, ist die Art und Weise, wie ich sie gemäß einem Post einer Mailingliste für LXD-Benutzer repariert habe , folgende:

$ lxc network edit lxdbr0

Dadurch wird Ihre Konfiguration in einem Terminal-Editor bearbeitet. Es wird ungefähr so ​​aussehen:

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

Fügen Sie drei Zeilen hinzu:

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

und dies sollte dazu führen dnsmasq, dass , was von ausgeführt wird lxd, DNS-Schleifen erkannt werden. Dies löste, zumindest für mich, das Problem und stoppte systemd-resolvedund dnsmasqverwendete 100% CPU.

Hier ist die Lösung für (X) Ubuntu 18.04 Bionic.

Installieren Sie dnsmasq

sudo apt install dnsmasq

Deaktivieren Sie den systemaufgelösten Listener an Port 53 (berühren Sie nicht /etc/systemd/resolved.conf, da er beim Upgrade möglicherweise überschrieben wird):

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

und neu starten

$ sudo systemctl restart systemd-resolved

(Alternativ deaktivieren Sie es vollständig durch $ sudo systemctl disable systemd-resolved.service )

Löschen Sie die Datei /etc/resolv.conf und erstellen Sie sie erneut. Dies ist wichtig, da resolv.conf standardmäßig eine symbolische Verknüpfung zu /run/systemd/resolve/stub-resolv.conf ist. Wenn Sie den symbolischen Link nicht löschen, wird die Datei beim Neustart von systemd überschrieben (obwohl wir systemd-resolved deaktiviert haben!). Außerdem überprüft NetworkManager (NM), ob es sich um eine symbolische Verknüpfung handelt, um eine vom System aufgelöste Konfiguration zu erkennen.

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

Deaktivieren Sie das Überschreiben von /etc/resolv.conf durch NM (es gibt auch eine Option rc-manager, die jedoch nicht funktioniert, obwohl dies im NM-Handbuch beschrieben ist):

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

und starte es neu:

$ sudo systemctl restart NetworkManager

Weisen Sie dnsmasq an, resolv.conf von NM zu verwenden:

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

und starte es neu:

$ sudo systemctl restart dnsmasq

Verwenden Sie dnsmasq zum Auflösen von:

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

Ich habe es so gelöst:

Fügen Sie die folgende Zeile in / etc / default / dnsmasq hinzu oder kommentieren Sie sie aus :

IGNORE_RESOLVCONF=yes

Erstellen Sie Ihre eigene Resolv-Datei (/etc/resolv.personal), um Nameserver zu definieren. Sie können hier einen beliebigen Nameserver verwenden. Ich habe zwei von https://www.opennic.org genommen

nameserver 5.132.191.104
nameserver 103.236.162.119

Fügen Sie in /etc/dnsmasq.conf die folgende Zeile hinzu oder kommentieren Sie sie aus:

resolv-file=/etc/resolv.personal

Starten Sie dann dnsmasq neu und deaktivieren Sie den Standard-Resolver: systemd-resolved.

sudo service dnsmasq restart

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

Ich bin nicht sicher, warum beide Dienste versuchen, dieselbe Adresse zu verwenden. Vielleicht können Sie sie wie in meinem Fall auf Xubuntu 18.04.1 anordnen, wobei ihre Konfiguration wie folgt lautet:

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 

Um das System mit meinem dnsmasq aufzulösen, setze ich einfach:

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

In meiner dnsmasq Konfiguration habe ich meine externen Nameserver eingestellt:

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

Nach dem Neustart alles:

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

systemd-resolved setzt den Standard-DNS-Server auf dnsmasq in:

#/etc/resolv.conf
nameserver 127.0.0.1

Ich konnte dnsmasq nicht dazu bringen, die online gefundenen Lösungen zu verwenden, dh systemd-resolved zu deaktivieren und dnsmasq.conf so zu ändern, dass "bind dynamic" statt "bind interfaces" ausgeführt wird. Ich konnte es beim Booten starten, indem ich dnsmasq start After network-online.service anstatt network.service hatte:

[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

Hier ist, was bei mir (nach stundenlangen Schmerzen) in Ubuntu 18.10 Cosmic Cuttlefish funktioniert hat. Ich habe dies getan, um dnsmasqden vergleichsweise robusteren Caching-Mechanismus zu nutzen und um NGINX Resolver-Schwachstellen zu vermeiden . Beachten Sie, dass ich die Ubuntu Server Edition verwende (nein NetworkManager/ nmclinur systemd-networkd) und diese unter AWS EC2 ausgeführt wird. Daher musste ich auch DNS und DHCP mit der Standard-EC2-Suchdomäne arbeiten lassen. Ich wollte nicht systemd-resolvedvollständig deaktivieren, da ich keine Ahnung habe, wie sich dies auf zukünftige Updates auswirken könnte. Sofern nicht anders angegeben, wird alles hier als root / sudo ausgeführt (dies geschieht standardmäßig, wenn es als EC2-Benutzerdaten übergeben wird).

## 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

Stellen Sie sicher, 127.0.0.1#53dass für die Auflösung verwendet wird und DNSSEC mit so etwas wie zusammenarbeitetdig +trace facebook.com